Repository navigation
A Tailscale-User-Login header is trusted from any proxy on this PC, not only tailscale serve #253
Description
What happens
On a PC where Tailscale runs, the server trusts a Tailscale-User-Login header from any connection that comes from this PC. tailscale serve sets that header for your own devices. Any other reverse proxy on the same PC (nginx, Caddy, a tunnel client) passes a visitor's own copy of the header through unless it is told to drop it, and a visitor who sends the owner's login gets full access. A token does not stop it: the login is checked before the token is asked for (decideAccess in server/access.ts).
It needs three things together: Tailscale logged in on the PC, a second proxy on that PC that faces other people, and a visitor who knows the owner's Tailscale login.
Seen
With real nginx and Caddy in front of a test upstream: a request carrying Tailscale-User-Login: owner@example.com arrives upstream with the header intact unless the proxy config removes it.
Now
The guide's proxy examples drop the header (#252). The server itself still trusts it from any loopback proxy.
Ideas for the server
- Trust the header only when the request also looks like
tailscale serve: a singleX-Forwarded-Foraddress inside Tailscale's ranges (100.64.0.0/10, fd7a:115c:a1e0::/48). A proxy that appends or overwrites that header then fails the test. Needs checking against a realtailscale servefirst, since a mistake here locks the owner's phone out until it is paired. - With a token set, ask for the token whatever the header says.
Activity
fix(access): ask for the token before trusting a Tailscale login head…
rabbitson87 commentedon Oct 3, 2026
Some findings on the first idea, from Tailscale's source (
ipn/ipnlocal/serve.goonmain). I haven't checked them against a livetailscale serve.What
tailscale servesends. Its proxy is anhttputil.ReverseProxywithRewrite, so Go strips anyForwardedandX-Forwarded-*a visitor sent before serve adds its own.addProxyForwardedHeaderssetsX-Forwarded-Forto the one source address of the tailnet peer, plusX-Forwarded-Host, andX-Forwarded-Proto: httpsover TLS.addTailscaleIdentityHeadersdeletes incomingTailscale-User-*,Tailscale-Funnel-RequestandTailscale-Headers-Info. It sets the login only for a non-tagged peer thatWhoIsresolves, together withTailscale-Headers-Info: https://tailscale.com/s/serve-headers.So requiring exactly one
X-Forwarded-Foraddress in 100.64.0.0/10 or fd7a:115c:a1e0::/48 should not lock outtailscale serveusers.What that test stops, and what it doesn't:
$proxy_add_x_forwarded_forappends the real address,$remote_addrreplaces it), Caddy, and Portal's--http-route(Go'sRewritedrops the visitor's copy and sets the relay's address): the test fails, so a forged login is refused.portal expose 7317,ssh -R, socat, frp in TCP mode): the visitor writes the whole request, so they can sendX-Forwarded-For: 100.x.y.zalong with the login and pass. No header test can tell that apart from serve, so the idea narrows the no-token case but doesn't close it.$remote_addrpasses a tailnet peer's own address, so on a shared tailnet another member could still send the owner's login.A way to close it fully, if you want one:
tailscale servecan proxy to a Unix socket (tailscale serve unix:/path/app.sock, Linux, macOS and BSD). The server could listen on a socket that onlytailscale serveuses, and honor the identity headers only there, so no other proxy on the PC can produce them. Two catches: serve sendsHost: localhostto a socket backend (serve.go:895), so on that listener the origin check would needX-Forwarded-Host; and the installer's serve command changes. So it's your call.On the Portal side, Portal's
mainnow has--strip-request-header(gosuda/portal-tunnel#564), so after its next release Portal users can drop the header themselves.fix(access): require a tailnet source for Tailscale login headers (#1062