HTTP Strict Transport Security (HSTS)
Extracted elements (27)
HSTS Policy is established only when the STS header is received over error-free secure transport to prevent a MITM from maliciously setting, updating, or zeroing the max-age — which could cause unauthorized policy establishment, denial-of-service, or removal of Known HSTS Host status.
The `includeSubDomains` directive is necessary because without it, HSTS cannot protect 'domain cookies' (Secure-flagged cookies scoped to a parent domain). An attacker who registers a novel subdomain can still receive such cookies from a UA that has no HSTS Policy for that specific subdomain.
UAs MUST NOT heed `http-equiv` meta elements for HSTS because a page served over HTTP (or injected by a MITM) could otherwise set HSTS Policy fraudulently; policy must only be established via the out-of-band HTTP response header over verified secure transport.
The `includeSubDomains` directive can break services (e.g., CRL distribution, OCSP) offered only over plain HTTP at subdomains of an HSTS Host. Operators must either avoid `includeSubDomains`, migrate subdomains to HTTPS, use a different domain for HTTP-only services, or adopt OCSP Stapling.
All directives in an STS header field MUST appear only once; unrecognized directives MUST be ignored; if the STS header otherwise satisfies the requirements, the UA MUST process the recognized directives.
An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
If a UA receives HTTP responses from a Known HSTS Host over a secure channel but the responses lack the STS header field, the UA MUST continue to treat the host as a Known HSTS Host until the max-age expires. The absence of the header does not remove Known HSTS Host status.
If a UA receives more than one STS header field in an HTTP response over secure transport, the UA MUST process only the first such header field.
If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). Additionally, the UA MUST ignore any STS header fields not conforming to the grammar in Section 6.1.
The UA MUST NOT note a host as a Known HSTS Host if the host component of the Request-URI syntactically matches an IP-literal or IPv4address production (i.e., HSTS Policy does not apply to IP addresses, only domain names).
UAs MUST NOT heed `http-equiv="Strict-Transport-Security"` attribute settings on `<meta>` elements in received content; the HSTS policy can only be set via the HTTP response header field.
User agents SHOULD implement IDNA2008 (RFC 5890) for domain name canonicalization. If a UA does not implement IDNA2008, it MUST implement IDNA2003 (RFC 3490). All domain names must be IDNA-canonicalized before HSTS processing.
When a UA prepares to load any `http` URI and the domain name matches a Known HSTS Host (directly or via an includeSubDomains superdomain match), the UA MUST replace the URI scheme with `https`, convert explicit port 80 to 443, preserve any other explicit port, and not add a port if none was present.
When an HSTS Host receives an HTTP request over a non-secure transport, it SHOULD send a permanent redirect (e.g., 301) with a Location header value using the `https` scheme. The HSTS Host SHOULD include the STS header field in responses over secure transport.
When connecting to a Known HSTS Host, the UA MUST terminate the connection if there are any errors or warnings with the underlying secure transport, including certificate validity errors (CRL, OCSP) and TLS server identity checking failures. No user recourse is permitted.
The OPTIONAL `includeSubDomains` directive is a valueless directive that, when present, signals the UA to apply HSTS Policy to the HSTS Host and all subdomains of its domain name. Its presence is ignored when max-age is zero.
The REQUIRED `max-age` directive specifies the number of seconds (delta-seconds) after reception of the STS header during which the UA regards the host as a Known HSTS Host. A value of zero signals the UA to delete the cached HSTS Policy, including any asserted includeSubDomains directive.
The Strict-Transport-Security (STS) HTTP response header field is the mechanism by which an HSTS Host declares its HSTS Policy to user agents. It must be sent only over secure transport (TLS/SSL) and its reception causes the UA to treat the issuing host as a Known HSTS Host.
RFC 6797 registers the permanent HTTP message header field `Strict-Transport-Security` with IANA per RFC 3864. Applicable protocol: http; Status: standard; Change controller: IETF. Future STS directives may be defined via other specifications with an IANA registry governed by IETF Review policy.
Active network attackers can subvert NTP to manipulate system clocks, potentially causing HSTS policy entries to appear expired prematurely or extending them beyond their intended lifetime, undermining max-age-based enforcement.
Bootstrap MITM vulnerability: the first contact with an unknown HSTS Host via an `http` URI is inherently insecure and vulnerable to man-in-the-middle attack before HSTS Policy is established. Mitigations include pre-loaded HSTS lists and user-declared policies.
HSTS can be abused to mount Denial-of-Service attacks: an attacker who can inject a spurious STS header (e.g., via HTTP response splitting or a spoofed redirect) can cause a UA to refuse all HTTP connections to a site that does not uniformly support HTTPS, rendering it unreachable.
HSTS policy stores can be abused for user tracking: because Known HSTS Host domain names are cached, an attacker controlling multiple HSTS hosts can encode information in subdomains, cache it in UAs, and later retrieve it via crafted resource loads to determine prior site visits.
Inconsistent IDNA processing can cause false-positive or false-negative domain name matching in HSTS enforcement, potentially connecting users to unintended hosts or blocking intended ones. IDNA-canonicalization with full Unicode and IDNA validation MUST occur before HSTS domain matching.
Non-conformant UAs that ignore the STS header field receive no HSTS protection, leaving their users vulnerable to passive network sniffing of non-Secure cookies and active MITM attacks with click-through dialogs — the pre-HSTS status quo.
A UA transitions a host to 'Known HSTS Host' upon receiving a valid STS header over error-free secure transport; updates cached max-age and includeSubDomains on subsequent valid headers; transitions back to 'unknown' when max-age=0 is received or the cached entry expires. Expired Known HSTS Hosts MUST be evicted from cache.
The STS header field ABNF: `Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] )` where `directive = directive-name [ "=" directive-value ]`. Directive names are case-insensitive tokens; values are tokens or quoted-strings as defined in RFC 2616.