Privileged RPCs behind a reverse proxy: accept verified proxy identity (Tailscale-User-Login) as operator equivalence — and a Host-passthrough finding

[mrlfarano]

The situation. PRIVILEGED_METHODS must pass the trust fence with an empty list, pinning them to loopback Hosts "until a real authentication layer exists." Behind a reverse proxy that preserves Host (tailscale serve does, verified), that means the entire configuration plane 403s for remote users: Settings (permissions, plugins), credentials, model discovery, agent-preset management. In our deployment the UI sections render empty and the operator falls back to an SSH tunnel — the exact workflow the proxy was supposed to replace.

A finding relevant to the current fence. While testing we found that tailscale serve passes a client-supplied Host header verbatim to the backend. Consequence: any tailnet member who can reach the serve port can send Host: 127.0.0.1:3080 and satisfy isTrustedApiRequest(request, []) today — the privileged pinning is spoofable behind any Host-preserving proxy. Not a bug in the fence's own terms (it is a rebinding defense, sound when the client controls its own Host) — but it means the pinning provides less than it appears to in proxied deployments.

The missing authentication layer can come from the proxy. Some proxies attest identity rather than forward it. tailscale serve injects on every proxied request:

Tailscale-User-Login: <tailnet-verified login, e.g. an SSO email>
Tailscale-User-Name / -Profile-Pic
X-Forwarded-For: <forced from the socket>

We verified empirically that client-supplied Tailscale-User-Login values are overwritten with the verified login (a spoofed attacker@evil.com arrived as the real one), and X-Forwarded-For is likewise forced. On the loopback bind dsh already requires by default, nothing but the proxy can reach the socket — so that header is unforgeable attestation of who is calling.

The proposal (implemented, tested). Opt-in config on the connection row:

- id: connection
  config:
    privilegedIdentityLogins: ['me@example.com']

A privileged-method request whose proxy-attested login is listed is treated as operator-equivalent; the empty default is bit-identical to today. Deliberately narrow:

• gated to privileged methods only — not a general auth layer;
• exact-match allowlist — anonymous/mismatched callers keep today's 403 (verified: allowlisted login reaches the handler, everyone else 403s);
• hard precondition: a non-empty allowlist with any non-loopback webserver bind fails the load loudly, because there the header is client-controlled.

Residual trust to review: the proxy joins the trusted computing base; other proxies emitting the same header inherit the same semantics (the loopback bind, not the proxy brand, carries the guarantee — worth documenting); the allowlist is operator-maintained.

Tested change: connection suite 110/110 green (4 new tests), tsc -b clean. Branch: mrlfarano:identity-authority · diff: compare with master (4 files, +123/−8, tests included).

Companion to the externalUrl proposal (#3209) — together they make a loopback-bound dsh web behind tailscale serve a complete remote deployment: correct narration, working Settings, and a stricter effective privilege boundary for the 15 pinned methods than the status quo behind such proxies.

(PR creation appears restricted to collaborators, so posting here per CONTRIBUTING — glad to turn this into a PR whenever the team wants it.)

[argszero]

Verified the finding and the proposal against master (99f6f02) — the spoofing claim is real, and I want to add the precise mechanism, the impact mapping, and two hardening suggestions.

1. The finding verifies at source (and it's the precondition inversion, not a fence bug)

• packages/client/connection/src/api-request-trust.ts:96-123 — isTrustedApiRequest reads only Host (+ sec-fetch-site/Origin when a browser attaches them). Non-browser clients (curl, the SDK) are judged on Host alone. The module doc is explicit: "Network reachability and authentication stay out of scope… this fence is not an auth layer" (:12-13).
• packages/client/connection/src/index.ts:145-149 — privileged methods are enforced as PRIVILEGED_METHODS.has(method) && !isTrustedApiRequest(request, []) → 403. Note the hardcoded empty trustedHosts: the pin is loopback-only by construction.
• loopback-hostname.ts:12-20 — isLoopbackHostname accepts localhost, [::1], and any 127/8 literal. So Host: 127.0.0.1:3080 passes, exactly as you found.

The precise failure mode is a precondition inversion of the DNS-rebinding defense. The fence is sound under its original assumption: the socket is reachable only by local processes, and a browser fills Host from the URL it believes it is talking to, so a rebound page cannot forge it. A Host-preserving proxy breaks both legs: it extends socket reachability to the tailnet, and it restores client control of Host. The loopback branch then degenerates into a remotely-typeable password. Not a bug in the fence's own terms — but the deployment pattern (loopback bind + Host-preserving proxy) is precisely where the fence's guarantee evaporates, and nothing else stands behind it.

2. The impact is not theoretical — the 15 methods are the whole configuration plane

The pin protects: settings.describe (returns every exposed namespace's configuration), settings.update/replace/mutate (mutates the config plane), credentials.describe (reports whether an arbitrary env-var name is configured and where from — reconnaissance), credentials.set/unset (mutates the secret store), agentPreset.* (roster management + openDocument drives the host desktop), llm.discoverModels (host-issued GET to a caller-chosen URL — an anonymous proxy-side caller would get a probe for whatever the host can reach). This maps onto two families I've been tracking: the settings-namespace exposure boundary (#1606) and the credentials plane (#1559) — both would be reachable by any tailnet member behind a Host-preserving proxy, not just the browser's confused-deputy paths the fence was built for. Your finding upgrades those threads from "deferred work" to "currently spoofable in a specific but realistic deployment shape."

3. The proposal: right shape, two hardening suggestions

The design is sound: proxy-attested identity as an explicit auth supplement, opt-in, empty default bit-identical to today, exact-match allowlist, and the hard precondition. Two suggestions:

A. Make the identity grant an AND with the existing Host fence, not an OR replacement. The identity header is authentication; the Host fence is the rebinding/CSRF defense — different axes, both should hold. A privileged request should pass when (existing Host fence passes with the deployment's declared trustedHosts) AND (the request is legacy-loopback or the attested login is allowlisted). This keeps the fence's value against browser-initiated confused-deputy paths even for allowlisted identities, and it prevents the allowlist from becoming a tunnel that bypasses the rebinding defense entirely. (Your fork's implementation may already do this — I can't read the diff from here; if so, this is just an endorsement of the shape.)

B. The hard precondition needs a second leg: header-origin hygiene. The allowlist trusts the header name, and the guarantee rests entirely on "the proxy overwrites client-supplied values" — true for tailscale serve (verified) but not for nginx/Caddy by default, which neither emit Tailscale-User-Login nor strip a client-supplied one. A deployment that moves the same config behind a generic reverse proxy without explicitly overriding that header gets a trivially spoofable allowlist — and the "non-loopback bind" precondition won't catch it, because the bind is still 127.0.0.1 with the proxy on localhost. Two options: (1) document per-proxy header hygiene as a hard deployment requirement (the README's residual-trust note should carry a concrete "your proxy MUST overwrite this header; here is the nginx/Caddy stanza" example); (2) make the header name configurable (default Tailscale-User-Login) so non-Tailscale deployments can use a header their proxy genuinely owns — with the hygiene requirement following the header.

Also note the bind schema in master: host: '127.0.0.1' | '0.0.0.0' only (packages/host/webserver/src/index.ts:47,61). Your "non-loopback webserver bind" precondition correctly covers the 0.0.0.0 case — with all-interfaces binding the socket is directly reachable, the header is client-controlled end-to-end, and the allowlist must be refused at load. Good — just making sure 0.0.0.0 is explicitly in the check, since it is a legal non-loopback bind in the schema today.

4. Cross-links and the overall picture

• The companion dsh web behind a reverse proxy: let deployments declare the external origin (externalUrl) so DSH_WEB_URL, the surface prompt, and the URL line stop pointing at 127.0.0.1 #3209 checks out at source too: localWebUrl() hardcodes 127.0.0.1 (packages/bundle/web-app/src/index.ts:71/109) and feeds the app:web-surface prompt section (:146), DSH_WEB_URL (:155), and the URL line (:168). Together the two proposals make loopback-bound dsh web behind tailscale serve a complete, honest remote deployment — correct narration and a real privilege boundary for the 15 methods.
• One documentation nit once the model ships: the fence comment "this fence is not an auth layer" becomes partially false in the allowlisted configuration. Worth a sentence on the connection row: with a non-empty privilegedIdentityLogins, the proxy becomes the authentication authority for privileged methods; the Host fence remains the rebinding defense.

I'd be glad to see both as PRs when the channel opens — the security model (fence = rebinding defense, proxy = identity authority, both must hold) is the right end state, and the empirical verification (header overwrite + Host passthrough) is exactly the evidence these threads need.