1. Introduction
HTTP [RFC2616] can operate over various transports, typically the Transmission Control Protocol (TCP). However, TCP does not provide channel integrity protection, confidentiality, or secure host identification. Thus, the Secure Sockets Layer (SSL) protocol [RFC6101] and its successor, Transport Layer Security (TLS) [RFC5246], were developed to provide channel-oriented security, typically layered between application protocols and TCP. [RFC2818] specifies how HTTP is layered on top of TLS and defines the "https" Uniform Resource Identifier (URI) scheme (effectively, HTTP UAs commonly employ TLS or SSL3, depending upon a combination of what is negotiated with servers and user preferences).
UAs employ various local security policies when interacting with web resources, the characteristics of which depend in part upon whether they are communicating with a given web resource's host using HTTP or HTTP-over-Secure-Transport. For example, cookies ([RFC6265]) can be flagged as Secure. UAs must send such Secure cookies to their addressed host only over secure transport. This contrasts with non-Secure cookies, which are returned to the host regardless of transport (although still subject to other rules).
UAs typically announce to their users any issues with securely establishing a connection, such as being unable to validate a TLS server certificate trust chain, a TLS server certificate being expired, or a TLS host's domain name appearing incorrectly in the TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs enable their users to elect to continue interacting with a web resource's host in the face of such issues. This behavior has been informally termed as "clicking through" security [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09] and can thus be described as "click-through insecurity".
A key vulnerability enabled by click-through insecurity is the leaking of any cookies a web resource may be using to manage a user's session. The threat here is that an attacker can obtain the cookies and then interact with the legitimate web resource while impersonating the user.
Jackson and Barth proposed an approach, in [ForceHTTPS], enabling web resources to declare that any interactions by UAs with the web resource must be conducted securely and that any issues in establishing a secure transport session are to be treated as fatal and without direct user recourse. The aim is to prevent click-through insecurity and address other potential threats.
This specification embodies and refines the approach proposed in [ForceHTTPS]. For example, rather than using cookies to convey policy from a web resource's host to a UA, it defines an HTTP response header field for this purpose. Additionally, a web resource's host may declare that its policy applies to the entire domain name subtree rooted at its host name. This enables HTTP Strict Transport Security (HSTS) to protect so-called "domain cookies", which apply to all subdomains of a given web resource's host name.
This specification also incorporates the <code>Strict-Transport-Security</code> HTTP response header field syntax, defined in [JacksonBarth2008], with which hosts articulate HSTS Policy to UAs.
Additionally, this specification incorporates the notion, defined in [JacksonBarth2008], that policy is applied on an "entire-host" basis: it applies to HTTP (and only HTTP) on any TCP port of the issuing host.
Note that the policy defined in this specification is distinctly different from the "same-origin policy" defined in "The Web Origin Concept" [RFC6454]. These differences are summarized in Appendix B.
1.1 Organization of This Specification
This specification begins with an overview of use cases, policy effects, threat model, and requirements for HSTS (in Section 2). Section 3 then defines conformance criteria. Section 4 defines terminology relevant to this document. The HSTS mechanism itself is formally specified in Sections 5 through 15.
1.2 Document Conventions
NOTE: This is a note to readers. These are points that should be kept in mind and/or taken into consideration.