Session pin is inert behind every documented tunnel (cloudflared / ngrok / tailscale serve)

[CrysisDeu]

Summary

A dashboard session's IP pin is inert behind every tunnel docs/guides/remote-and-mobile.md recommends — cloudflared, ngrok, and tailscale serve alike. This issue tracks the repair. The reporting of the state has landed (PR #1761); the pin itself has not been fixed.

Why it happens

The pin is bound from request.remote at the one bind site in the dashboard auth middleware. Every tunnel above runs on the gateway host and connects to the loopback-bound gateway from 127.0.0.1, so the address the session pins to is the tunnel process — identical for every client behind it.

Consequences, all live on main:

• A leaked session link is a bearer credential. Anyone who reaches the dashboard through the same tunnel satisfies the pin, for the life of the session — up to the 20-hour MAX_SESSION_TTL_SECS, and kirocrew token defaults straight to 20h.
• The remote-access audit trail cannot name anyone. The SEL log_api_access(caller=...) sites in the auth middleware all record request.remote, so every proxied request is attributed to 127.0.0.1.

This is not Tailscale-specific and not new. It is a property of "bind loopback + put a local proxy in front", which is the only remote-access shape the product documents.

What is already done

• PR fix(dashboard): report the session pin's real scope instead of asserting it #1761 (fix/session-pin-visibility) makes the state honest and visible: a is_proxied_loopback_request() predicate, observation latches in the auth module, a tri-state Security Posture row (not known yet / per-client / SHARED, not per-client), and the guide correction across all three tunnel providers. It changes no binding, comparison, or auth decision.
• RFC docs: RFC for tailnet-native dashboard access #1748 (docs/request-for-change/rfc-tailnet-dashboard-access.md) designs the repair as its Phase 3.

What is owed

Replace the address pin with a verified peer identity wherever one can be obtained from the local proxy, keeping the address pin as the fallback:

• session pin key generalises from ip:<remote> to a peer key — ts:<login>@<node> when a peer resolves, unchanged ip:<remote> otherwise;
• resolution is daemon-verified, never header-trusted: loopback immediate peer and exactly one X-Forwarded-For and tailscale whois confirming the address is a tailnet member and the resolved login agreeing with Tailscale-User-Login. Any miss falls back to the existing token path;
• a mandatory login allowlist — "any tailnet member" would be a silently-permissive default on a shared corporate tailnet;
• audit records name the resolved login as caller when a peer resolved.

Tailscale is the first case because its local daemon can answer "who is this peer". Cloudflare Access (a locally verifiable signed JWT) is the natural second, and is the test of whether the seam generalises — but not before there is a second consumer.

Explicitly not proposed here

Widening is_direct_local_request(). A verified tailnet identity is not the local machine; config-write and secret-reveal endpoints stay closed to proxied requests.

Blocking questions

Both are open in the RFC and one needs a product call:

1. Pin scope: node or login? Node is strictly stronger than today and costs a flow that does not work today either (one link, two devices — today's IP pin already refuses the second). Login survives a device's node identity changing. Note this choice only affects what happens after a session leaks; it is not the defence against a hostile tailnet member — the allowlist is.
2. Windows. The tailscale CLI location and the daemon's local API on Windows are unverified. If resolution is not reliable there, the repair is POSIX-only and must degrade to the token path rather than break.

Risk note

This is the only part of the RFC that touches the auth path. It should not land without adversarial review, and it needs explicit tests for X-Forwarded-For injection, multi-value X-Forwarded-For, header/whois disagreement, daemon-absent fallback, and timeout fail-closed.

Until it lands, PR #1761's posture row and guide text are the mitigation: they tell the user the truth so they can size their TTL and exposure accordingly.

[CrysisDeu]

Pin scope is settled: configurable, defaulting to node. Blocking question 1 is closed; the RFC change is in #1905 (§3.1).

{ "dashboard": { "tailscale": { "pin_scope": "node" } } }

node → peer key ts:<login>@<node>; login → ts:<login>. Default is node because the flow it costs — one link opened on a laptop, then used on a phone — does not work under today's IP pin either, so it removes no working behaviour. login would be a relaxation, and stays available for operators who re-enroll devices often.

One hard rule came out of it. An ACL tag replaces the user identity on a device, so tailscale whois reports the login of every tagged node as the literal tagged-devices (tailscale/tailscale#4605). Under login scope that one value would be the peer key for the whole tagged fleet, and an allowed_logins entry of tagged-devices would admit all of them. So a tagged node is always pinned to node regardless of configuration, with the override logged. An unrecognised pin_scope falls back to node, never login.

Also note for whoever implements this: a node-scope rejection needs its own reason string naming device identity. Re-enrolling Tailscale on a phone will invalidate that device's session, and surfacing it as the existing IP mismatch would be actively misleading.

Remaining blocker

Only the Windows question is left: the tailscale CLI location and the daemon's local API on Windows are unverified. If resolution is not reliable there, this is POSIX-only and must degrade to the token path rather than break.

Phase 1 (visibility + docs) landed as f8afcff7. The pin itself is still inert behind every same-host tunnel — that is what this issue tracks.

[bolichen97]

🤖 Kiro Crew Auto-Pipeline [operator: bolichen97] — claimed for the automated security-batch fix run (2026-08-09). A task spec is being generated; an implementation session will open a PR referencing this issue.