Web sign-in cookie lacks Secure when published through HTTPS #166

Summary #

The web sign-in cookie is not marked Secure even when the server is published through HTTPS with --public-url https://… or --tailnet-https.

Reviewed commit: 154c6911d6a491aeeecacf26a06b6ae8c4bc70e1.

Code #

cli/internal/webui/server.go:145–153 sets:

http.SetCookie(w, &http.Cookie{
    Name: cookieName, Value: s.key, Path: "/",
    MaxAge: 400 * 24 * 60 * 60,
    HttpOnly: true, SameSite: http.SameSiteStrictMode,
})

Secure is omitted. The cookie value is the persistent launch key, so disclosure also discloses the sign-in credential until it is rotated.

Impact and conditions #

For an HTTPS-published hostname, a non-Secure cookie is eligible for transmission on HTTP requests to that hostname. If an attacker can intercept/serve that HTTP traffic, and no already-enforced HSTS or equivalent transport policy prevents it, they may obtain the credential. HttpOnly and SameSite=Strict do not substitute for transport protection.

This is conditional on HTTPS publishing plus an HTTP exposure/downgrade opportunity; it is not a claim that intentional plain-HTTP loopback operation is itself a vulnerability. An independently enforced HSTS policy can mitigate the downgrade path.

Validation status #

The missing attribute and HTTPS publishing configuration were source-reviewed. No live browser, reverse-proxy, or credential-interception reproduction was performed.

Expected behavior #

Issue a Secure cookie when the configured public origin is HTTPS (or TLS is served directly). Account for TLS termination: checking only r.TLS would miss the supported HTTPS-proxy configuration. Preserve intentional local HTTP operation where appropriate.

A regression test should inspect Set-Cookie for HTTPS-published and loopback-HTTP configurations, including a TLS terminator forwarding to a plain-HTTP listener.