PROPOSED STANDARD

Errata Exist

Internet Engineering Task Force (IETF) J. Hodges Request for Comments: 6797 PayPal Category: Standards Track C. Jackson ISSN: 2070-1721 Carnegie Mellon University A. Barth Google, Inc. November 2012 HTTP Strict Transport Security (HSTS) Abstract This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6797. Hodges, et al. Standards Track [Page 1]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................4 1.1. Organization of This Specification .........................6 1.2. Document Conventions .......................................6 2. Overview ........................................................6 2.1. Use Cases ..................................................6 2.2. HTTP Strict Transport Security Policy Effects ..............6 2.3. Threat Model ...............................................6 2.3.1. Threats Addressed ...................................7 2.3.1.1. Passive Network Attackers ..................7 2.3.1.2. Active Network Attackers ...................7 2.3.1.3. Web Site Development and Deployment Bugs ...8 2.3.2. Threats Not Addressed ...............................8 2.3.2.1. Phishing ...................................8 2.3.2.2. Malware and Browser Vulnerabilities ........8 2.4. Requirements ...............................................9 2.4.1. Overall Requirement .................................9 2.4.1.1. Detailed Core Requirements .................9 2.4.1.2. Detailed Ancillary Requirements ...........10 3. Conformance Criteria ...........................................10 4. Terminology ....................................................11 5. HSTS Mechanism Overview ........................................13 5.1. HSTS Host Declaration .....................................13 5.2. HSTS Policy ...............................................13 5.3. HSTS Policy Storage and Maintenance by User Agents ........14 5.4. User Agent HSTS Policy Enforcement ........................14 6. Syntax .........................................................14 6.1. Strict-Transport-Security HTTP Response Header Field ......15 6.1.1. The max-age Directive ..............................16 6.1.2. The includeSubDomains Directive ....................16 6.2. Examples ..................................................16 Hodges, et al. Standards Track [Page 2]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 7. Server Processing Model ........................................17 7.1. HTTP-over-Secure-Transport Request Type ...................17 7.2. HTTP Request Type .........................................18 8. User Agent Processing Model ....................................18 8.1. Strict-Transport-Security Response Header Field Processing ................................................19 8.1.1. Noting an HSTS Host - Storage Model ................20 8.2. Known HSTS Host Domain Name Matching ......................20 8.3. URI Loading and Port Mapping ..............................21 8.4. Errors in Secure Transport Establishment ..................22 8.5. HTTP-Equiv <Meta> Element Attribute .......................22 8.6. Missing Strict-Transport-Security Response Header Field ...23 9. Constructing an Effective Request URI ..........................23 9.1. ERU Fundamental Definitions ...............................23 9.2. Determining the Effective Request URI .....................24 9.2.1. Effective Request URI Examples .....................24 10. Domain Name IDNA-Canonicalization .............................25 11. Server Implementation and Deployment Advice ...................26 11.1. Non-Conformant User Agent Considerations .................26 11.2. HSTS Policy Expiration Time Considerations ...............26 11.3. Using HSTS in Conjunction with Self-Signed Public-Key Certificates .............................................27 11.4. Implications of includeSubDomains ........................28 11.4.1. Considerations for Offering Unsecured HTTP Services at Alternate Ports or Subdomains of an HSTS Host ........................................28 11.4.2. Considerations for Offering Web Applications at Subdomains of an HSTS Host .......................29 12. User Agent Implementation Advice ..............................30 12.1. No User Recourse .........................................30 12.2. User-Declared HSTS Policy ................................30 12.3. HSTS Pre-Loaded List .....................................31 12.4. Disallow Mixed Security Context Loads ....................31 12.5. HSTS Policy Deletion .....................................31 13. Internationalized Domain Names for Applications (IDNA): Dependency and Migration ......................................32 Hodges, et al. Standards Track [Page 3]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 14. Security Considerations .......................................32 14.1. Underlying Secure Transport Considerations ...............32 14.2. Non-Conformant User Agent Implications ...................33 14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport ..............................33 14.4. The Need for includeSubDomains ...........................34 14.5. Denial of Service ........................................35 14.6. Bootstrap MITM Vulnerability .............................36 14.7. Network Time Attacks .....................................37 14.8. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack .........................................37 14.9. Creative Manipulation of HSTS Policy Store ...............37 14.10. Internationalized Domain Names ..........................38 15. IANA Considerations ...........................................39 16. References ....................................................39 16.1. Normative References .....................................39 16.2. Informative References ...................................40 Appendix A. Design Decision Notes .................................44 Appendix B. Differences between HSTS Policy and Same-Origin Policy ................................................45 Appendix C. Acknowledgments .......................................46 1 . Introduction RFC2616] may be used 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 in order to provide channel-oriented security and are typically layered between application protocols and TCP. [RFC2818] specifies how HTTP is layered onto TLS and defines the Uniform Resource Identifier (URI) scheme of "https" (in practice, however, HTTP user agents (UAs) typically use either TLS or SSL3, depending upon a combination of negotiation with the server and user preferences). UAs employ various local security policies with respect to the characteristics of their interactions with web resources, depending on (in part) whether they are communicating with a given web resource's host using HTTP or HTTP-over-Secure-Transport. For example, cookies ([RFC6265]) may be flagged as Secure. UAs are to send such Secure cookies to their addressed host only over a secure transport. This is in contrast to non-Secure cookies, which are returned to the host regardless of transport (although subject to other rules). Hodges, et al. Standards Track [Page 4]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Section 3.1 of [RFC2818]). Often, UAs enable users to elect to continue to interact with a web resource's host in the face of such issues. This behavior is sometimes referred to as "click(ing) through" security [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09]; thus, it can be described as "click-through insecurity". A key vulnerability enabled by click-through insecurity is the leaking of any cookies the web resource may be using to manage a user's session. The threat here is that an attacker could obtain the cookies and then interact with the legitimate web resource while impersonating the user. Jackson and Barth proposed an approach, in [ForceHTTPS], to enable web resources to declare that any interactions by UAs with the web resource must be conducted securely and that any issues with 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 a cookie 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 its policy to apply 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 are applied to all subdomains of a given web resource's host name. This specification also incorporates notions from [JacksonBarth2008] in that policy is applied on an "entire-host" basis: it applies to HTTP (only) over any TCP port of the issuing host. Note that the policy defined by this specification is distinctly different than the "same-origin policy" defined in "The Web Origin Concept" [RFC6454]. These differences are summarized in Appendix B. Hodges, et al. Standards Track [Page 5]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 ForceHTTPS] for details as well as relevant citations. 2.3.1 . Threats Addressed 2.3.1.1 . Passive Network Attackers BeckTews09]. Freely available wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive eavesdropping attacks, even if the local wireless network is operating in a secure fashion. A passive network attacker using such tools can steal session identifiers/cookies and hijack the user's web session(s) by obtaining cookies containing authentication credentials [ForceHTTPS]. For example, there exist widely available tools, such as Firesheep (a web browser extension) [Firesheep], that enable their wielder to obtain other local users' session cookies for various web applications. To mitigate such threats, some web sites support, but usually do not force, access using end-to-end secure transport -- e.g., signaled through URIs constructed with the "https" scheme [RFC2818]. This can lead users to believe that accessing such services using secure transport protects them from passive network attackers. Unfortunately, this is often not the case in real-world deployments, as session identifiers are often stored in non-Secure cookies to permit interoperability with versions of the service offered over insecure transport ("Secure cookies" are those cookies containing the "Secure" attribute [RFC6265]). For example, if the session identifier for a web site (an email service, say) is stored in a non-Secure cookie, it permits an attacker to hijack the user's session if the user's UA makes a single insecure HTTP request to the site. 2.3.1.2 . Active Network Attackers Hodges, et al. Standards Track [Page 7]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 2.3.1.3 . Web Site Development and Deployment Bugs W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed security context" in this specification and should not be confused with the same "mixed content" term used in the context of markup languages such as XML and HTML. 2.3.2 . Threats Not Addressed 2.3.2.1 . Phishing ForceHTTPS]. 2.3.2.2 . Malware and Browser Vulnerabilities Hodges, et al. Standards Track [Page 8]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Section 12.1 ("No User Recourse"). NOTE: A means for uniformly securely meeting the first core requirement above is not specifically addressed by this specification (see Section 14.6 ("Bootstrap MITM Vulnerability")). It may be addressed by a future revision of this specification or some other specification. Note also that there are means by which UA implementations may more fully meet the first core requirement; see Section 12 ("User Agent Implementation Advice"). 2.4.1.2 . Detailed Ancillary Requirements Section 2.3.1.3). 2. Facilitate user declaration of web sites for which strict security policy is enabled, regardless of whether the sites signal HSTS Policy. 3 . Conformance Criteria Hodges, et al. Standards Track [Page 10]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 RFC2119]. 4 . Terminology Unicode] for details. codepoint: is a colloquial contraction of Code Point, which is any value in the Unicode codespace; that is, the range of integers from 0 to 10FFFF(hex) [Unicode]. domain name: is also referred to as "DNS name" and is defined in [RFC1035] to be represented outside of the DNS protocol itself (and implementations thereof) as a series of labels separated by dots, e.g., "example.com" or "yet.another.example.org". In the context of this specification, domain names appear in that portion of a URI satisfying the reg-name production in "Appendix A. Collected ABNF for URI" in [RFC3986], and the host component from the Host HTTP header field production in Section 14.23 of [RFC2616]. NOTE: The domain names appearing in actual URI instances and matching the aforementioned production components may or may not be a fully qualified domain name. domain name label: is that portion of a domain name appearing "between the dots", i.e., consider "foo.example.com": "foo", "example", and "com" are all domain name labels. Hodges, et al. Standards Track [Page 11]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Section 9 ("Constructing an Effective Request URI"). HTTP Strict Transport Security: is the overall name for the combined UA- and server-side security policy defined by this specification. HTTP Strict Transport Security Host: is a conformant host implementing the HTTP server aspects of the HSTS Policy. This means that an HSTS Host returns the "Strict-Transport-Security" HTTP response header field in its HTTP response messages sent over secure transport. HTTP Strict Transport Security Policy: is the name of the combined overall UA- and server-side facets of the behavior defined in this specification. HSTS: See HTTP Strict Transport Security. HSTS Host: See HTTP Strict Transport Security Host. HSTS Policy: See HTTP Strict Transport Security Policy. Known HSTS Host: is an HSTS Host for which the UA has an HSTS Policy in effect; i.e., the UA has noted this host as a Known HSTS Host. See Section 8.1.1 ("Noting an HSTS Host - Storage Model") for particulars. Local policy: comprises policy rules that deployers specify and that are often manifested as configuration settings. Hodges, et al. Standards Track [Page 12]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 RFC4949]. Request URI: is the URI used to cause a UA to issue an HTTP request message. See also "Effective Request URI". UA: is an acronym for "user agent". For the purposes of this specification, a UA is an HTTP client application typically actively manipulated by a user [RFC2616]. unknown HSTS Host: is an HSTS Host that the user agent has not noted. 5 . HSTS Mechanism Overview 6 through 15. 5.1 . HSTS Host Declaration 5.2 . HSTS Policy Hodges, et al. Standards Track [Page 13]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 6.1 . Strict-Transport-Security HTTP Response Header Field Section 2 of [RFC2616] (which includes a notion of "implied linear whitespace", also known as "implied *LWS"). Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] ) directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token | quoted-string where: token = <token, defined in [RFC2616], Section 2.2> quoted-string = <quoted-string, defined in [RFC2616], Section 2.2> The two directives defined in this specification are described below. The overall requirements for directives are: 1. The order of appearance of directives is not significant. 2. All directives MUST appear only once in an STS header field. Directives are either optional or required, as stipulated in their definitions. 3. Directive names are case-insensitive. 4. UAs MUST ignore any STS header field containing directives, or other header field value data, that does not conform to the syntax defined in this specification. 5. If an STS header field contains directive(s) not recognized by the UA, the UA MUST ignore the unrecognized directives, and if the STS header field otherwise satisfies the above requirements (1 through 4), the UA MUST process the recognized directives. Additional directives extending the semantic functionality of the STS header field can be defined in other specifications, with a registry (having an IANA policy definition of IETF Review [RFC5226]) defined for them at such time. Hodges, et al. Standards Track [Page 15]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 7 . Server Processing Model RFC5246] or SSL [RFC6101]; see also Section 14.1 ("Underlying Secure Transport Considerations")), and the second being the processing rules for HTTP request messages received over non-secure transports, such as TCP. 7.1 . HTTP-over-Secure-Transport Request Type Section 6.1 ("Strict-Transport-Security HTTP Response Header Field"). If an STS header field is included, the HSTS Host MUST include only one such header field. Establishing a given host as a Known HSTS Host, in the context of a given UA, MAY be accomplished over HTTP, which is in turn running over secure transport, by correctly returning (per this specification) at least one valid STS header field to the UA. Other mechanisms, such as a client-side pre-loaded Known HSTS Host list, MAY also be used; e.g., see Section 12 ("User Agent Implementation Advice"). NOTE: Including the STS header field is stipulated as a "SHOULD" in order to accommodate various server- and network-side caches and load-balancing configurations where it may be difficult to uniformly emit STS header fields on behalf of a given HSTS Host. Hodges, et al. Standards Track [Page 17]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 7.2 . HTTP Request Type Section 10.3.2 of [RFC2616]), and a Location header field value containing either the HTTP request's original Effective Request URI (see Section 9 ("Constructing an Effective Request URI")) altered as necessary to have a URI scheme of "https", or a URI generated according to local policy with a URI scheme of "https". NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to: * Risks in server-side non-secure-to-secure redirects [OWASP-TLSGuide]. * Site deployment characteristics. For example, a site that incorporates third-party components may not behave correctly when doing server-side non-secure-to-secure redirects in the case of being accessed over non-secure transport but does behave correctly when accessed uniformly over secure transport. The latter is the case given an HSTS-capable UA that has already noted the site as a Known HSTS Host (by whatever means, e.g., prior interaction or UA configuration). An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. 8 . User Agent Processing Model RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration"). It also assumes that all domain names manipulated in this specification's context are already IDNA-canonicalized as outlined in Section 10 ("Domain Name IDNA-Canonicalization") prior to the processing specified in this section. NOTE: [RFC3490] is referenced due to its ongoing relevance to actual deployments for the foreseeable future. The above assumptions mean that this processing model also specifically assumes that appropriate IDNA and Unicode validations and character list testing have occurred on the domain names, in Hodges, et al. Standards Track [Page 18]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Section 14.10 ("Internationalized Domain Names") for rationale and further details. 8.1 . Strict-Transport-Security Response Header Field Processing Section 6.1 ("Strict-Transport-Security HTTP Response Header Field"), and there are no underlying secure transport errors or warnings (see Section 8.4), the UA MUST either: o Note the host as a Known HSTS Host if it is not already so noted (see Section 8.1.1 ("Noting an HSTS Host - Storage Model")), or o Update the UA's cached information for the Known HSTS Host if either or both of the max-age and includeSubDomains header field value tokens are conveying information different than that already maintained by the UA. The max-age value is essentially a "time to live" value relative to the reception time of the STS header field. If the max-age header field value token has a value of zero, the UA MUST remove its cached HSTS Policy information (including the includeSubDomains directive, if asserted) if the HSTS Host is known, or the UA MUST NOT note this HSTS Host if it is not yet known. If a UA receives more than one STS header field in an HTTP response message over secure transport, then the UA MUST process only the first such header field. Otherwise: o If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). o The UA MUST ignore any STS header fields not conforming to the grammar specified in Section 6.1 ("Strict-Transport-Security HTTP Response Header Field"). Hodges, et al. Standards Track [Page 19]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 8.1.1 . Noting an HSTS Host - Storage Model Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. Otherwise, if the substring does not congruently match a Known HSTS Host's domain name, per the matching procedure specified in Section 8.2 ("Known HSTS Host Domain Name Matching"), then the UA MUST note this host as a Known HSTS Host, caching the HSTS Host's domain name and noting along with it the expiry time of this information, as effectively stipulated per the given max-age value, as well as whether the includeSubDomains directive is asserted or not. See also Section 11.2 ("HSTS Policy Expiration Time Considerations"). The UA MUST NOT modify the expiry time or the includeSubDomains directive of any superdomain matched Known HSTS Host. A Known HSTS Host is "expired" if its cache entry has an expiry date in the past. The UA MUST evict all expired Known HSTS Hosts from its cache if, at any time, an expired Known HSTS Host exists in the cache. 8.2 . Known HSTS Host Domain Name Matching Section 2.3.2.4 of [RFC5890]. * Superdomain Match If a label-for-label match between an entire Known HSTS Host's domain name and a right-hand portion of the given domain name is found, then this Known HSTS Host's domain name is a superdomain match for the given domain name. There could be multiple superdomain matches for a given domain name. Hodges, et al. Standards Track [Page 20]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 8.3 . URI Loading and Port Mapping RFC3986] (including when following HTTP redirects [RFC2616]), the UA MUST first determine whether a domain name is given in the URI and whether it matches a Known HSTS Host, using these steps: 1. Extract from the URI any substring described by the host component of the authority component of the URI. 2. If the substring is null, then there is no match with any Known HSTS Host. 3. Else, if the substring is non-null and syntactically matches the IP-literal or IPv4address productions from Section 3.2.2 of [RFC3986], then there is no match with any Known HSTS Host. Hodges, et al. Standards Track [Page 21]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Section 8.2 ("Known HSTS Host Domain Name Matching"). 5. If, when performing domain name matching any superdomain match with an asserted includeSubDomains directive is found, or, if no superdomain matches with asserted includeSubDomains directives are found and a congruent match is found (with or without an asserted includeSubDomains directive), then before proceeding with the load: The UA MUST replace the URI scheme with "https" [RFC2818], and if the URI contains an explicit port component of "80", then the UA MUST convert the port component to be "443", or if the URI contains an explicit port component that is not equal to "80", the port component value MUST be preserved; otherwise, if the URI does not contain an explicit port component, the UA MUST NOT add one. NOTE: These steps ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS Host. NOTE: In the case where an explicit port is provided (and to a lesser extent with subdomains), it is reasonably likely that there is actually an HTTP (i.e., non-secure) server running on the specified port and that an HTTPS request will thus fail (see item 6 in Appendix A ("Design Decision Notes")). 8.4 . Errors in Secure Transport Establishment Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125]. 8.5 . HTTP-Equiv Element Attribute W3C.REC-html401-19991224] in received content. Hodges, et al. Standards Track [Page 22]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 9.2 . Determining the Effective Request URI [RFC2616] Section 3.2.3, except that empty path components MUST NOT be treated as equivalent to an absolute path of "/". 9.2.1 . Effective Request URI Examples http://www.example.org:8080/pub/WWW/TheProject.html". Hodges, et al. Standards Track [Page 24]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 10 . Domain Name IDNA-Canonicalization Section 2 of [RFC5890]) concatenated using some separator character (typically "."). 1. Convert the input putative domain name string to an order- preserving sequence of individual label strings. 2. When implementing IDNA2008, convert, validate, and test each A-label and U-label found among the sequence of individual label strings, using the procedures defined in Sections 5.3 through 5.5 of [RFC5891]. Otherwise, when implementing IDNA2003, convert each label using the "ToASCII" conversion in Section 4 of [RFC3490] (see also the definition of "equivalence of labels" in Section 2 of [RFC3490]). 3. If no errors occurred during the foregoing step, concatenate all the labels in the sequence, in order, into a string, separating each label from the next with a %x2E (".") character. The resulting string, known as an IDNA-canonicalized domain name, is appropriate for use in the context of Section 8 ("User Agent Processing Model"). Otherwise, errors occurred. The input putative domain name string was not successfully IDNA-canonicalized. Invokers of this procedure should attempt appropriate error recovery. See also Sections 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration") and 14.10 ("Internationalized Domain Names") of this specification for further details and considerations. Hodges, et al. Standards Track [Page 25]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 11.3 . Using HSTS in Conjunction with Self-Signed Public-Key Certificates If all four of the following conditions are true... o a web site/organization/enterprise is generating its own secure transport public-key certificates for web sites, and o that organization's root certification authority (CA) certificate is not typically embedded by default in browser and/or operating system CA certificate stores, and o HSTS Policy is enabled on a host identifying itself using a certificate signed by the organization's CA (i.e., a "self-signed certificate"), and o this certificate does not match a usable TLS certificate association (as defined by Section 4 of the TLSA protocol specification [RFC6698]), ...then secure connections to that site will fail, per the HSTS design. This is to protect against various active attacks, as discussed above. However, if said organization wishes to employ its own CA, and self- signed certificates, in concert with HSTS, it can do so by deploying its root CA certificate to its users' browsers or operating system CA root certificate stores. It can also, in addition or instead, distribute to its users' browsers the end-entity certificate(s) for specific hosts. There are various ways in which this can be accomplished (details are out of scope for this specification). Once its root CA certificate is installed in the browsers, it may employ HSTS Policy on its site(s). Alternatively, that organization can deploy the TLSA protocol; all browsers that also use TLSA will then be able to trust the certificates identified by usable TLS certificate associations as denoted via TLSA. NOTE: Interactively distributing root CA certificates to users, e.g., via email, and having the users install them, is arguably training the users to be susceptible to a possible form of phishing attack. See Section 14.8 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack"). Thus, care should be taken in the manner in which such certificates are distributed and installed on users' systems and browsers. Hodges, et al. Standards Track [Page 27]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 11.4 . Implications of includeSubDomains 11.4.1 . Considerations for Offering Unsecured HTTP Services at Alternate Ports or Subdomains of an HSTS Host For example, certification authorities often offer their CRL distribution and OCSP services [RFC2560] over plain HTTP, and sometimes at a subdomain of a publicly available web application that may be secured by TLS/SSL. For example, <https://ca.example.com/> is a publicly available web application for "Example CA", a certification authority. Customers use this web application to register their public keys and obtain certificates. "Example CA" generates certificates for customers containing <http://crl-and-ocsp.ca.example.com/> as the value for the "CRL Distribution Points" and "Authority Information Access:OCSP" certificate fields. If ca.example.com were to issue an HSTS Policy with the includeSubDomains directive, then HTTP-based user agents implementing HSTS that have interacted with the ca.example.com web application would fail to retrieve CRLs and fail to check OCSP for certificates, because these services are offered over plain HTTP. In this case, Example CA can either: o not use the includeSubDomains directive, or o ensure that HTTP-based services offered at subdomains of ca.example.com are also uniformly offered over TLS/SSL, or Hodges, et al. Standards Track [Page 28]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 RFC6066], often colloquially referred to as "OCSP Stapling"). NOTE: The above points are expressly only an example and do not purport to address all the involved complexities. For instance, there are many considerations -- on the part of CAs, certificate deployers, and applications (e.g., browsers) -- involved in deploying an approach such as "OCSP Stapling". Such issues are out of scope for this specification. 11.4.2 . Considerations for Offering Web Applications at Subdomains of an HSTS Host In this scenario, an HSTS Host declares an HSTS Policy with an includeSubDomains directive, and there also exist distinct web applications offered at distinct subdomains of the HSTS Host such that UAs often interact directly with these subdomain web applications without having necessarily interacted with the HSTS Host. In such a case, the UAs will not receive or enforce the HSTS Policy. For example, the HSTS Host is "example.com", and it is configured to emit the STS header field with the includeSubDomains directive. However, example.com's actual web application is addressed at "www.example.com", and example.com simply redirects user agents to "https://www.example.com/". If the STS header field is only emitted by "example.com" but UAs typically bookmark -- and links (from anywhere on the web) are typically established to -- "www.example.com", and "example.com" is not contacted directly by all user agents in some non-zero percentage of interactions, then some number of UAs will not note "example.com" as an HSTS Host, and some number of users of "www.example.com" will be unprotected by HSTS Policy. To address this, HSTS Hosts should be configured such that the STS header field is emitted directly at each HSTS Host domain or subdomain name that constitutes a well-known "entry point" to one's web application(s), whether or not the includeSubDomains directive is employed. Hodges, et al. Standards Track [Page 29]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 12 . User Agent Implementation Advice 12.1 . No User Recourse Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry. Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment. Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves. 12.2 . User-Declared HSTS Policy Section 14.6 ("Bootstrap MITM Vulnerability"). Hodges, et al. Standards Track [Page 30]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 ForceHTTPS]. For example, arbitrary web sites may not materialize all their URIs using the "https" scheme and thus could "break" if a UA were to attempt to access the site exclusively using such URIs. Also note that this feature would complement, but is independent of, an "HSTS pre-loaded list" feature (see Section 12.3). 12.3 . HSTS Pre-Loaded List Section 14.6). NOTE: Such a facility would complement a "user-declared HSTS Policy" feature (Section 12.2). 12.4 . Disallow Mixed Security Context Loads Section 5.3 ("Mixed Content") in [W3C.REC-wsc-ui-20100812]) but should not be confused with the same "mixed content" term that is also used in the context of markup languages such as XML and HTML. NOTE: In order to provide behavioral uniformity across UA implementations, the notion of mixed security context will require further standardization work, e.g., to define the term(s) more clearly and to define specific behaviors with respect to it. 12.5 . HSTS Policy Deletion Hodges, et al. Standards Track [Page 31]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 13 . Internationalized Domain Names for Applications (IDNA): Dependency and Migration Textual domain names on the modern Internet may contain one or more "internationalized" domain name labels. Such domain names are referred to as "internationalized domain names" (IDNs). The specification suites defining IDNs and the protocols for their use are named "Internationalized Domain Names for Applications (IDNA)". At this time, there are two such specification suites: IDNA2008 [RFC5890] and its predecessor IDNA2003 [RFC3490]. IDNA2008 obsoletes IDNA2003, but there are differences between the two specifications, and thus there can be differences in processing (e.g., converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. In order to facilitate their IDNA transition, user agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46]. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003. 14 . Security Considerations Section 2.3 ("Threat Model"). Additionally, the sections below discuss operational ramifications of the HSTS Policy, provide feature rationale, discuss potential HSTS Policy misuse, and highlight some known vulnerabilities in the HSTS Policy regime. 14.1 . Underlying Secure Transport Considerations Section 2 ("Overview") in fact presume TLS or SSL as the underlying secure transport. Thus, employment of HSTS in the context of HTTP running over some other secure transport protocol would require assessment of that secure transport protocol's security Hodges, et al. Standards Track [Page 32]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 14.2 . Non-Conformant User Agent Implications Section 2.3.1 ("Threats Addressed"). This means that the web application and its users wielding non-conformant UAs will be vulnerable to both of the following: o Passive network attacks due to web site development and deployment bugs: For example, if the web application contains any insecure references (e.g., "http") to the web application server, and if not all of its cookies are flagged as "Secure", then its cookies will be vulnerable to passive network sniffing and, potentially, subsequent misuse of user credentials. o Active network attacks: For example, if an attacker is able to place a "man in the middle", secure transport connection attempts will likely yield warnings to the user, but without HSTS Policy being enforced, the present common practice is to allow the user to "click through" and proceed. This renders the user and possibly the web application open to abuse by such an attacker. This is essentially the status quo for all web applications and their users in the absence of HSTS Policy. Since web application providers typically do not control the type or version of UAs their web applications interact with, the implication is that HSTS Host deployers must generally exercise the same level of care to avoid web site development and deployment bugs (see Section 2.3.1.3) as they would if they were not asserting HSTS Policy. 14.3 . Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport The user agent processing model defined in Section 8 ("User Agent Processing Model") stipulates that a host is initially noted as a Known HSTS Host, or that updates are made to a Known HSTS Host's cached information, only if the UA receives the STS header field over a secure transport connection having no underlying secure transport errors or warnings. Hodges, et al. Standards Track [Page 33]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability")); for example: o Unauthorized notation of the host as a Known HSTS Host, potentially leading to a denial-of-service situation if the host does not uniformly offer its services over secure transport (see also Section 14.5 ("Denial of Service")). o Resetting the time to live for the host's designation as a Known HSTS Host by manipulating the max-age header field parameter value that is returned to the UA. If max-age is returned as zero, this will cause the host to cease being regarded as a Known HSTS Host by the UA, leading to either insecure connections to the host or possibly denial of service if the host delivers its services only over secure transport. However, this means that if a UA is "behind" a MITM non-transparent TLS proxy -- within a corporate intranet, for example -- and interacts with an unknown HSTS Host beyond the proxy, the user could possibly be presented with the legacy secure connection error dialogs. Even if the risk is accepted and the user "clicks through", the host will not be noted as an HSTS Host. Thus, as long as the UA is behind such a proxy, the user will be vulnerable and will possibly be presented with the legacy secure connection error dialogs for as-yet unknown HSTS Hosts. Once the UA successfully connects to an unknown HSTS Host over error- free secure transport, the host will be noted as a Known HSTS Host. This will result in the failure of subsequent connection attempts from behind interfering proxies. The above discussion relates to the recommendation in Section 12 ("User Agent Implementation Advice") that the secure connection be terminated with "no user recourse" whenever there are warnings and errors and the host is a Known HSTS Host. Such a posture protects users from "clicking through" security warnings and putting themselves at risk. 14.4 . The Need for includeSubDomains Hodges, et al. Standards Track [Page 34]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 14.5 . Denial of Service RFC4732] for a discussion of overall Internet DoS considerations. o Web applications available over HTTP There is an opportunity for perpetrating DoS attacks with web applications (or critical portions of them) that are available only over HTTP without secure transport, if attackers can cause UAs to set HSTS Policy for such web applications' host(s). This is because once the HSTS Policy is set for a web application's host in a UA, the UA will only use secure transport to communicate with the host. If the host is not using secure Hodges, et al. Standards Track [Page 35]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Section 12.5 ("HSTS Policy Deletion"). An HSTS Policy can be set for a victim host in various ways: * If the web application has an HTTP response splitting vulnerability [CWE-113] (which can be abused in order to facilitate "HTTP header injection"). * If an attacker can spoof a redirect from an insecure victim site, e.g., <http://example.com/> to <https://example.com/>, where the latter is attacker-controlled and has an apparently valid certificate. In this situation, the attacker can then set an HSTS Policy for example.com and also for all subdomains of example.com. * If an attacker can convince users to manually configure HSTS Policy for a victim host. This assumes that their UAs offer such a capability (see Section 12 ("User Agent Implementation Advice")). Alternatively, if such UA configuration is scriptable, then an attacker can cause UAs to execute his script and set HSTS Policies for whichever desired domains. o Inadvertent use of includeSubDomains The includeSubDomains directive instructs UAs to automatically regard all subdomains of the given HSTS Host as Known HSTS Hosts. If any such subdomains do not support properly configured secure transport, then they will be rendered unreachable from such UAs. 14.6 . Bootstrap MITM Vulnerability ForceHTTPS]). NOTE: There are various features/facilities that UA implementations may employ in order to mitigate this vulnerability. Please see Section 12 ("User Agent Implementation Advice"). Hodges, et al. Standards Track [Page 36]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 14.7 . Network Time Attacks RFC5905]) -- making HSTS less effective against clients that trust NTP or lack a real time clock. Network time attacks are beyond the scope of this specification. Note that modern operating systems use NTP by default. See also Section 2.10 of [RFC4732]. 14.8 . Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack RFC4033], plus techniques to block email phishing and fake certificate injection. 14.9 . Creative Manipulation of HSTS Policy Store Hodges, et al. Standards Track [Page 37]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 WebTracking]. 14.10 . Internationalized Domain Names Section 10 ("Domain Name IDNA- Canonicalization")). These steps are necessary in order to avoid various potentially compromising situations. In brief, examples of issues that could stem from lack of careful and consistent Unicode and IDNA validations include unexpected processing exceptions, truncation errors, and buffer overflows, as well as false-positive and/or false-negative domain name matching results. Any of the foregoing issues could possibly be leveraged by attackers in various ways. Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in terms of disallowed characters and character mapping conventions. This situation can also lead to false-positive and/or false-negative domain name matching results, resulting in, for example, users possibly communicating with unintended hosts or not being able to reach intended hosts. For details, refer to the Security Considerations sections of [RFC5890], [RFC5891], and [RFC3490], as well as the specifications they normatively reference. Additionally, [RFC5894] provides detailed background and rationale for IDNA2008 in particular, as well as IDNA and its issues in general, and should be consulted in conjunction with the former specifications. Hodges, et al. Standards Track [Page 38]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 W3C.REC-wsc-ui-20100812] Roessler, T. and A. Saldhana, "Web Security Context: User Interface Guidelines", World Wide Web Consortium Recommendation REC-wsc-ui-20100812, August 2010, <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>. [WebTracking] Schmucker, N., "Web Tracking", SNET2 Seminar Paper - Summer Term, 2011, <http://www.snet.tu-berlin.de/ fileadmin/fg220/courses/SS11/snet-project/ web-tracking_schmuecker.pdf>. Hodges, et al. Standards Track [Page 43]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Appendix A . Design Decision Notes Hodges, et al. Standards Track [Page 44]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Appendix B . Differences between HSTS Policy and Same-Origin Policy RFC6454] has the following primary characteristics: An origin is the scheme, host, and port of a URI identifying a resource. A UA may dereference a URI, thus loading a representation of the resource the URI identifies. UAs label resource representations with their origins, which are derived from their URIs. The SOP refers to a collection of principles, implemented within UAs, governing the isolation of and communication between resource representations within the UA, as well as resource representations' access to network resources. In summary, although both HSTS Policy and SOP are enforced by UAs, HSTS Policy is optionally declared by hosts and is not origin-based, while the SOP applies to all resource representations loaded from all hosts by conformant UAs. Hodges, et al. Standards Track [Page 45]

RFC 6797 HTTP Strict Transport Security (HSTS) November 2012 Appendix C . Acknowledgments HTTP1_1-UPD]. Subsequently, the ERU text in this spec was lifted from Julian's work in the updated HTTP/1.1 (part 1) specification and adapted to the [RFC2616] ABNF. Authors' Addresses Jeff Hodges PayPal 2211 North First Street San Jose, California 95131 US EMail: Jeff.Hodges@PayPal.com Collin Jackson Carnegie Mellon University EMail: collin.jackson@sv.cmu.edu Adam Barth Google, Inc. EMail: ietf@adambarth.com URI: http://www.adambarth.com/ Hodges, et al. Standards Track [Page 46]