Repository navigation
agentmesh-one infers its public router address from X-Forwarded-* but the audit remediation stopped trusting those headers for the OIDC issuer: one rule for both #752
Description
Two parts of the same binary treat forwarded headers differently.
Issuer. Until e67f5eab (2026-10-06, "security: remediate audit findings") the control plane built its OIDC issuer URL from the request and trusted X-Forwarded-Proto for the scheme. That commit put the header behind Options.TrustForwardedHeaders, default false, and nothing sets it in either binary. Behind a TLS-terminating proxy the issuer is therefore http://<host> unless the operator sets --external-url (agentmesh-one) or --sts-issuer-url (agentmesh-control-plane). This is the audited state: a deployment behind a proxy states its public URL.
Router address. #735 (ce32a935, 2026-10-17) made agentmesh-one infer the public wss:// multiaddr it advertises on /info, /enroll, /enroll/status and /register from Host / X-Forwarded-Host and X-Forwarded-Proto, unconditionally, when --external-url is not set (wrapPublicHTTPHandler, inferredRequestMultiaddr). That re-introduced for the router address the trust the audit removed for the issuer, without a review against that finding.
What a forged header buys an attacker. For the issuer: a client that reaches the plain listener directly chooses the scheme of the issuer in its own discovery response and in the iss of the JWT minted for its request; a relying party pinning the issuer sees a value that varies per request. For the router address: a client choosing X-Forwarded-Host gets a /info answer that names a router address of its choosing — only in its own response, but /enroll responses are what a node persists as its mesh configuration. In both cases the exposure needs direct access to the plain listener; behind Cloud Run the front door sets the headers itself.
Options.
- One rule: a hosted deployment states its public URL. Revert the inference half of standalone: put the inferred public router address on the /info router entries #735 (keep the
/infoentry fix), and haveagentmesh-onerefuse to start on a non-loopback listener without--external-urlor--tunnel, with a message that names the flag. Zero config stays zero trust: the Cloud Run guide gains one flag. - One rule, opt-in: a
--trust-forwarded-headersflag onagentmesh-onethat sets both the router inference andTrustForwardedHeaders, off by default, help text naming the risk. - Leave as is and document the asymmetry.
I would take 1: it matches the audit's decision and the two guides already pass --external-url. #749 (guide for federated Google credentials) was written for that state; an earlier revision of it set TrustForwardedHeaders in agentmesh-one and was withdrawn for this discussion.
Activity
aojea commentedon Oct 18, 2026
Analysis and proposal, after reading what a node does with an advertised address.
An address is a reachability hint, not a trust anchor. The multiaddr a node receives from
/enrollor/infoends in/p2p/<PeerID>, and inagentmesh-onethat PeerID is the server's own; a forged header changes host, port or scheme, never the PeerID. The node then (1) runs the libp2p security handshake, which fails onpeer id mismatch(ErrFatalAuth), and (2) at/mesh/authrequires a router Biscuit signed by a control plane key it already trusts, with the expected router as subject (VerifyBiscuitAndGetKey). A wrong address makes a node dial the wrong place; it cannot make the wrong place be the router. The issuer is parallel:issends up in a discovery document and in JWTs signed by the control plane's key; a relying party pins the issuer URL, so a forgedissmakes the forger's own tokens useless and nothing else. The inference wrapper rewrites only the response to the request that carried the header; nothing is stored. So the concrete effect of a forged forwarded header is self-inflicted unavailability, plus one amplification path if an operator puts a caching proxy in front of an authenticated API. Zero trust and inference do not conflict: the mesh verifies identity on every connection and call, and does not trust the address it learned a peer at.Why inference exists. One reason: a PaaS hostname was not known before the first deploy, so the Cloud Run guide would need two passes. That reason is weaker than it looked. Cloud Run URLs are deterministic,
https://<service>-<project number>.<region>.run.app, known before the first deploy; Fly.io and Render hostnames are deterministic too.--tunnellearns its URL from the provider. A hub bound to a VM address advertises its interfaces as before #735.Proposal: always state the public URL; remove inference.
wrapPublicHTTPHandler,inferredRequestMultiaddr,prependInferredRouterAddr, the response recorder); keep the/infoentry fix, which is correct when--external-urlis set.Options.TrustForwardedHeaders(unused sincee67f5eab).--external-urlis absent and a request arrives withX-Forwarded-ProtoorX-Forwarded-Host, log a warning once and count it: the advertised router address and OIDC issuer will not be reachable from outside.gcloud projects describe … projectNumber) and passes--external-url.agentmesh-control-planekeeps--sts-issuer-url; no inference there today.Result: nothing the hub advertises or signs derives from a request header; one advertised address and one issuer for every client; the lease and
/infoagree; less code. Cost: one flag whose value is computable before the deploy.standalone: the public URL is stated, not inferred from request headers