HSTS State Closes the First-Request Downgrade Window

A site can redirect every HTTP request to HTTPS and still expose a gap before that redirect arrives. The browser has already sent an HTTP request across the network. An active intermediary can alter that exchange, suppress the redirect, or keep the client on plaintext HTTP.

HTTP Strict Transport Security (HSTS), defined by RFC 6797, changes where the decision occurs. After receiving a valid Strict-Transport-Security header over a secure connection, a conforming user agent records policy state for the host. A later HTTP navigation to that host is converted to HTTPS locally before the insecure request is emitted.

That local state is the security boundary. The redirect is no longer responsible for moving an established plaintext exchange onto TLS.

Redirects act after plaintext traffic exists

An HTTP-to-HTTPS redirect is an application response. For the browser to receive it, the browser first has to contact the server over HTTP. The initial request and the redirect response therefore travel without TLS protection.

This ordering matters on a hostile network. If an intermediary controls the plaintext exchange, server policy at the HTTPS endpoint cannot force that particular request to reach it. A 301 or 308 redirect is useful for ordinary routing, but it cannot authenticate a response delivered before TLS exists.

HSTS moves the scheme transition ahead of that network exchange. When stored policy applies, an http:// URL targeting the HSTS host is treated as an HTTPS request by the user agent. The plaintext hop never becomes part of the transaction.

The policy is accepted only over secure transport

A Strict-Transport-Security field received over HTTP must not establish HSTS policy. Accepting policy from an unauthenticated plaintext response would let an active intermediary modify the security state it is meant to protect.

A typical field looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age sets the lifetime, in seconds, for the policy recorded by the user agent. Each valid secure response can refresh that lifetime. includeSubDomains extends the policy to subdomains under the HSTS host according to RFC 6797 processing rules.

This design creates an important bootstrap condition: ordinary HSTS protects visits after secure policy has been established, but it cannot retroactively secure an initial HTTP contact made by a client with no relevant HSTS state.

Preload data changes the bootstrap source

Browser preload mechanisms address that initial-contact gap by shipping selected HSTS policy information with the user agent rather than waiting for a site response. For a preloaded host, HTTPS enforcement can exist before the first network visit.

Preloading is operationally different from receiving an HSTS header. It depends on browser-distributed state and the preload program’s inclusion and removal process. A server cannot assume that emitting a header immediately places its domain into every user’s built-in list.

The distinction also affects rollback. A short max-age can expire dynamically acquired state, while preload removal depends on updated browser data reaching clients. Deployments that request preload status therefore need HTTPS to be durable across the covered namespace, not merely available during a migration window.

Subdomain coverage changes the failure radius

Without includeSubDomains, HSTS state for example.com does not automatically impose the same policy on every subordinate host. That can leave older subdomains reachable through HTTP even when the parent uses HTTPS consistently.

With includeSubDomains, the policy boundary becomes broader. This can close downgrade paths across the namespace, but it also means an HTTPS failure on a covered subdomain cannot be bypassed by falling back to HTTP. That behavior is intentional: HSTS treats transport security as a constraint rather than a preference.

The deployment consequence is concrete. Certificate coverage, TLS termination, legacy hosts, and delegated subdomains have to be considered before expanding the policy. A forgotten service beneath the namespace can become unreachable once clients hold applicable HSTS state.

Certificate errors remain errors

HSTS does not make an invalid certificate valid. Its role is to require secure transport and constrain user-agent behavior around TLS failures. A host with expired, mismatched, or otherwise unacceptable certificate authentication still has a certificate problem.

This separation keeps the trust model coherent. HSTS determines that HTTP is not an acceptable fallback path. TLS certificate validation determines whether the HTTPS peer satisfies the user agent’s authentication requirements. One control does not substitute for the other.

HSTS is persistent transport policy at the client

The useful property of HSTS is not the response header by itself. It is the state transition caused by a securely received policy and the later client-side enforcement that happens before plaintext traffic leaves the browser.

That timing separates HSTS from a redirect rule. Redirects can canonicalize traffic that reaches a server. Stored HSTS state can prevent an insecure request from being sent at all. Preload data can extend that property to clients that have never contacted the site, at the cost of a slower operational rollback path.

The boundary is therefore temporal as well as cryptographic: secure policy established earlier controls the transport choice for a later connection.

Reference: RFC 6797 — HTTP Strict Transport Security