idnits 2.17.1 draft-ietf-websec-strict-transport-sec-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jul 3, 2012) is 4308 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-17' is mentioned on line 1839, but not defined == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-15' is mentioned on line 2113, but not defined == Missing Reference: 'HASMAT' is mentioned on line 2145, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-19 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5894 ** Downref: Normative reference to an Informational RFC: RFC 5895 -- Possible downref: Non-RFC (?) normative reference: ref. 'UTS46' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBSEC Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track C. Jackson 5 Expires: January 4, 2013 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 Jul 3, 2012 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-10 13 Abstract 15 This specification defines a mechanism enabling web sites to declare 16 themselves accessible only via secure connections, and/or for users 17 to be able to direct their user agent(s) to interact with given sites 18 only over secure connections. This overall policy is referred to as 19 HTTP Strict Transport Security (HSTS). The policy is declared by web 20 sites via the Strict-Transport-Security HTTP response header field, 21 and/or by other means, such as user agent configuration, for example. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 4, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Organization of this specification . . . . . . . . . . . . 5 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. HTTP Strict Transport Security Policy Effects . . . . . . 5 62 2.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3.1. Threats Addressed . . . . . . . . . . . . . . . . . . 6 64 2.3.1.1. Passive Network Attackers . . . . . . . . . . . . 6 65 2.3.1.2. Active Network Attackers . . . . . . . . . . . . . 7 66 2.3.1.3. Web Site Development and Deployment Bugs . . . . . 7 67 2.3.2. Threats Not Addressed . . . . . . . . . . . . . . . . 7 68 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 7 69 2.3.2.2. Malware and Browser Vulnerabilities . . . . . . . 8 70 2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 71 2.4.1. Overall Requirement . . . . . . . . . . . . . . . . . 8 72 2.4.1.1. Detailed Core Requirements . . . . . . . . . . . . 8 73 2.4.1.2. Detailed Ancillary Requirements . . . . . . . . . 9 74 3. Conformance Criteria . . . . . . . . . . . . . . . . . . . . . 9 75 3.1. Document Conventions . . . . . . . . . . . . . . . . . . . 10 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. HSTS Mechanism Overview . . . . . . . . . . . . . . . . . . . 12 78 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1. Strict-Transport-Security HTTP Response Header Field . . . 13 80 6.1.1. The max-age Directive . . . . . . . . . . . . . . . . 14 81 6.1.2. The includeSubDomains Directive . . . . . . . . . . . 14 82 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7. Server Processing Model . . . . . . . . . . . . . . . . . . . 15 84 7.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 15 85 7.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 15 86 8. User Agent Processing Model . . . . . . . . . . . . . . . . . 16 87 8.1. Strict-Transport-Security Response Header Field 88 Processing . . . . . . . . . . . . . . . . . . . . . . . . 16 89 8.1.1. Noting an HSTS Host . . . . . . . . . . . . . . . . . 17 90 8.2. Known HSTS Host Domain Name Matching . . . . . . . . . . . 18 91 8.3. URI Loading and Port Mapping . . . . . . . . . . . . . . . 19 92 8.4. Errors in Secure Transport Establishment . . . . . . . . . 20 93 8.5. HTTP-Equiv Element Attribute . . . . . . . . . . . 20 94 8.6. Missing Strict-Transport-Security Response Header Field . 20 95 9. Domain Name IDNA-Canonicalization . . . . . . . . . . . . . . 20 96 10. Server Implementation and Deployment Advice . . . . . . . . . 21 97 10.1. HSTS Policy expiration time considerations . . . . . . . . 21 98 10.2. Using HSTS in conjunction with self-signed public-key 99 certificates . . . . . . . . . . . . . . . . . . . . . . . 22 100 10.3. Implications of includeSubDomains . . . . . . . . . . . . 23 101 11. User Agent Implementation Advice . . . . . . . . . . . . . . . 24 102 11.1. No User Recourse . . . . . . . . . . . . . . . . . . . . . 24 103 11.2. User-declared HSTS Policy . . . . . . . . . . . . . . . . 24 104 11.3. HSTS Pre-Loaded List . . . . . . . . . . . . . . . . . . . 25 105 11.4. Disallow Mixed Security Context Loads . . . . . . . . . . 25 106 11.5. HSTS Policy Deletion . . . . . . . . . . . . . . . . . . . 25 107 12. Constructing an Effective Request URI . . . . . . . . . . . . 25 108 12.1. ERU Fundamental Definitions . . . . . . . . . . . . . . . 26 109 12.2. Determining the Effective Request URI . . . . . . . . . . 26 110 12.2.1. Effective Request URI Examples . . . . . . . . . . . . 27 111 13. Internationalized Domain Names for Applications (IDNA): 112 Dependency and Migration . . . . . . . . . . . . . . . . . . . 27 113 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 114 14.1. Ramifications of HSTS Policy Establishment only over 115 Error-free Secure Transport . . . . . . . . . . . . . . . 28 116 14.2. The Need for includeSubDomains . . . . . . . . . . . . . . 29 117 14.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 118 14.4. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 31 119 14.5. Network Time Attacks . . . . . . . . . . . . . . . . . . . 31 120 14.6. Bogus Root CA Certificate Phish plus DNS Cache 121 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 31 122 14.7. Creative Manipulation of HSTS Policy Store . . . . . . . . 32 123 14.8. Internationalized Domain Names . . . . . . . . . . . . . . 32 124 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 125 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 126 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 127 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 128 Appendix A. Design Decision Notes . . . . . . . . . . . . . . . . 37 129 Appendix B. Differences between HSTS Policy and Same-Origin 130 Policy . . . . . . . . . . . . . . . . . . . . . . . 38 131 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 39 132 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 39 133 D.1. For draft-ietf-websec-strict-transport-sec . . . . . . . . 40 134 D.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 46 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 137 1. Introduction 139 The HTTP protocol [RFC2616] may be used over various transports, 140 typically the Transmission Control Protocol (TCP). However, TCP does 141 not provide channel integrity protection, confidentiality, nor secure 142 host identification. Thus the Secure Sockets Layer (SSL) protocol 143 [RFC6101] and its successor Transport Layer Security (TLS) [RFC5246], 144 were developed in order to provide channel-oriented security, and are 145 typically layered between application protocols and TCP. [RFC2818] 146 specifies how HTTP is layered onto TLS, and defines the Uniform 147 Resource Identifier (URI) scheme of "https" (in practice however, 148 HTTP user agents (UAs) typically offer their users choices among 149 SSL2, SSL3, and TLS for secure transport). 151 UAs employ various local security policies with respect to the 152 characteristics of their interactions with web resources depending on 153 (in part) whether they are communicating with a given web resource's 154 host using HTTP or HTTP-over-a-Secure-Transport. For example, 155 cookies ([RFC6265]) may be flagged as Secure. UAs are to send such 156 Secure cookies to their addressed host only over a secure transport. 157 This is in contrast to non-Secure cookies, which are returned to the 158 host regardless of transport (although subject to other rules). 160 UAs typically announce to their users any issues with secure 161 connection establishment, such as being unable to validate a TLS 162 server certificate trust chain, or if a TLS server certificate is 163 expired, or if a TLS host's domain name appears incorrectly in the 164 TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs 165 enable users to elect to continue to interact with a web resource's 166 host in the face of such issues. This behavior is sometimes referred 167 to as "click(ing) through" security [GoodDhamijaEtAl05] 168 [SunshineEgelmanEtAl09], and thus can be described as "click-through 169 insecurity". 171 A key vulnerability enabled by click-through insecurity is the 172 leaking of any cookies the web resource may be using to manage a 173 user's session. The threat here is that an attacker could obtain the 174 cookies and then interact with the legitimate web resource while 175 impersonating the user. 177 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 178 web resources to declare that any interactions by UAs with the web 179 resource must be conducted securely, and that any issues with 180 establishing a secure transport session are to be treated as fatal 181 and without direct user recourse. The aim is to prevent click- 182 through insecurity, and address other potential threats. 184 This specification embodies and refines the approach proposed in 186 [ForceHTTPS]. For example, rather than using a cookie to convey 187 policy from a web resource's host to a UA, it defines an HTTP 188 response header field for this purpose. Additionally, a web 189 resource's host may declare its policy to apply to the entire domain 190 name subtree rooted at its host name. This enables HSTS to protect 191 so-called "domain cookies", which are applied to all subdomains of a 192 given web resource's host name. 194 This specification also incorporates notions from [JacksonBarth2008] 195 in that policy is applied on an "entire-host" basis: it applies to 196 HTTP (only) over any TCP port of the issuing host. 198 Note that the policy defined by this specification is distinctly 199 different than the "same-origin policy" defined in "The Web Origin 200 Concept" [RFC6454]. These differences are summarized below in 201 Appendix B. 203 1.1. Organization of this specification 205 This specification begins with an overview of the use cases, policy 206 effects, threat models, and requirements for HSTS (in Section 2). 207 Then, Section 3 defines conformance requirements. The HSTS mechanism 208 itself is formally specified in Section 4 through Section 15. 210 2. Overview 212 This section discusses the use cases, summarizes the HTTP Strict 213 Transport Security (HSTS) policy, and continues with a discussion of 214 the threat model, non-addressed threats, and derived requirements. 216 2.1. Use Cases 218 The high-level use case is a combination of: 220 o Web browser user wishes to interact with various web sites (some 221 arbitrary, some known) in a secure fashion. 223 o Web site deployer wishes to offer their site in an explicitly 224 secure fashion for both their own, as well as their users', 225 benefit. 227 2.2. HTTP Strict Transport Security Policy Effects 229 The effects of the HTTP Strict Transport Security (HSTS) Policy, as 230 applied by a conformant UA in interactions with a web resource host 231 wielding such policy (known as an HSTS Host), are summarized as 232 follows: 234 1. UAs transform insecure URI references to an HSTS Host into secure 235 URI references before dereferencing them. 237 2. The UA terminates any secure transport connection attempts upon 238 any and all secure transport errors or warnings. 240 2.3. Threat Model 242 HSTS is concerned with three threat classes: passive network 243 attackers, active network attackers, and imperfect web developers. 244 However, it is explicitly not a remedy for two other classes of 245 threats: phishing and malware. Addressed and not addressed threats 246 are briefly discussed below. Readers may wish refer to Section 2 of 247 [ForceHTTPS] for details as well as relevant citations. 249 2.3.1. Threats Addressed 251 2.3.1.1. Passive Network Attackers 253 When a user browses the web on a local wireless network (e.g., an 254 802.11-based wireless local area network) a nearby attacker can 255 possibly eavesdrop on the user's unencrypted Internet Protocol-based 256 connections, such as HTTP, regardless of whether or not the local 257 wireless network itself is secured [BeckTews09]. Freely available 258 wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive 259 eavesdropping attacks, even if the local wireless network is 260 operating in a secure fashion. A passive network attacker using such 261 tools can steal session identifiers/cookies and hijack the user's web 262 session(s), by obtaining cookies containing authentication 263 credentials [ForceHTTPS]. For example, there exist widely-available 264 tools, such as Firesheep (a web browser extension) [Firesheep], which 265 enable their wielder to obtain other local users' session cookies for 266 various web applications. 268 To mitigate such threats, some Web sites support, but usually do not 269 force, access using end-to-end secure transport -- e.g., signaled 270 through URIs constructed with the "https" scheme [RFC2818]. This can 271 lead users to believe that accessing such services using secure 272 transport protects them from passive network attackers. 273 Unfortunately, this is often not the case in real-world deployments 274 as session identifiers are often stored in non-Secure cookies to 275 permit interoperability with versions of the service offered over 276 insecure transport ("Secure cookies" are those cookies containing the 277 "Secure" attribute [RFC6265]). For example, if the session 278 identifier for a web site (an email service, say) is stored in a non- 279 Secure cookie, it permits an attacker to hijack the user's session if 280 the user's UA makes a single insecure HTTP request to the site. 282 2.3.1.2. Active Network Attackers 284 A determined attacker can mount an active attack, either by 285 impersonating a user's DNS server or, in a wireless network, by 286 spoofing network frames or offering a similarly-named evil twin 287 access point. If the user is behind a wireless home router, an 288 attacker can attempt to reconfigure the router using default 289 passwords and other vulnerabilities. Some sites, such as banks, rely 290 on end-to-end secure transport to protect themselves and their users 291 from such active attackers. Unfortunately, browsers allow their 292 users to easily opt-out of these protections in order to be usable 293 for sites that incorrectly deploy secure transport, for example by 294 generating and self-signing their own certificates (without also 295 distributing their certification authority (CA) certificate to their 296 users' browsers). 298 2.3.1.3. Web Site Development and Deployment Bugs 300 The security of an otherwise uniformly secure site (i.e. all of its 301 content is materialized via "https" URIs), can be compromised 302 completely by an active attacker exploiting a simple mistake, such as 303 the loading of a cascading style sheet or a SWF (Shockwave Flash) 304 movie over an insecure connection (both cascading style sheets and 305 SWF movies can script the embedding page, to the surprise of many web 306 developers, plus some browsers do not issue so-called "mixed content 307 warnings" when SWF files are embedded via insecure connections). 308 Even if the site's developers carefully scrutinize their login page 309 for "mixed content", a single insecure embedding anywhere on the 310 overall site compromises the security of their login page because an 311 attacker can script (i.e., control) the login page by injecting code 312 (e.g., a script) into another, insecurely loaded, site page. 314 Note: "Mixed content" as used above (see also Section 5.3 in 315 [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed 316 security context" in this specification, and should not be 317 confused with the same "mixed content" term used in the 318 context of markup languages such as XML and HTML. 320 2.3.2. Threats Not Addressed 322 2.3.2.1. Phishing 324 Phishing attacks occur when an attacker solicits authentication 325 credentials from the user by hosting a fake site located on a 326 different domain than the real site, perhaps driving traffic to the 327 fake site by sending a link in an email message. Phishing attacks 328 can be very effective because users find it difficult to distinguish 329 the real site from a fake site. HSTS is not a defense against 330 phishing per se; rather, it complements many existing phishing 331 defenses by instructing the browser to protect session integrity and 332 long-lived authentication tokens [ForceHTTPS]. 334 2.3.2.2. Malware and Browser Vulnerabilities 336 Because HSTS is implemented as a browser security mechanism, it 337 relies on the trustworthiness of the user's system to protect the 338 session. Malicious code executing on the user's system can 339 compromise a browser session, regardless of whether HSTS is used. 341 2.4. Requirements 343 This section identifies and enumerates various requirements derived 344 from the use cases and the threats discussed above, and lists the 345 detailed core requirements HTTP Strict Transport Security addresses, 346 as well as ancillary requirements that are not directly addressed. 348 2.4.1. Overall Requirement 350 o Minimize the risks to web browser users and web site deployers 351 that are derived from passive and active network attackers, web 352 site development and deployment bugs, as well as insecure user 353 actions. 355 2.4.1.1. Detailed Core Requirements 357 These core requirements are derived from the overall requirement, and 358 are addressed by this specification. 360 1. Web sites need to be able to declare to UAs that they should be 361 accessed using a strict security policy. 363 2. Web sites need to be able to instruct UAs that contact them 364 insecurely to do so securely. 366 3. UAs need to retain persistent data about web sites that signal 367 strict security policy enablement, for time spans declared by the 368 web sites. Additionally, UAs need to cache the "freshest" strict 369 security policy information, in order to allow web sites to 370 update the information. 372 4. UAs need to re-write all insecure UA "http" URI loads to use the 373 "https" secure scheme for those web sites for which secure policy 374 is enabled. 376 5. Web site administrators need to be able to signal strict security 377 policy application to subdomains of higher-level domains for 378 which strict security policy is enabled, and UAs need to enforce 379 such policy. 381 For example, both example.com and foo.example.com could set 382 policy for bar.foo.example.com. 384 6. UAs need to disallow security policy application to peer domains, 385 and/or higher-level domains, by domains for which strict security 386 policy is enabled. 388 For example, neither bar.foo.example.com nor foo.example.com can 389 set policy for example.com, nor can bar.foo.example.com set 390 policy for foo.example.com. Also, foo.example.com cannot set 391 policy for sibling.example.com. 393 7. UAs need to prevent users from clicking-through security 394 warnings. Halting connection attempts in the face of secure 395 transport exceptions is acceptable. 397 Note: A means for uniformly securely meeting the first core 398 requirement above is not specifically addressed by this 399 specification (see Section 14.4 "Bootstrap MITM 400 Vulnerability"). It may be addressed by a future revision of 401 this specification or some other specification. Note also 402 that there are means by which UA implementations may more 403 fully meet the first core requirement; see Section 11 "User 404 Agent Implementation Advice". 406 2.4.1.2. Detailed Ancillary Requirements 408 These ancillary requirements are also derived from the overall 409 requirement. They are not normatively addressed in this 410 specification, but could be met by UA implementations at their 411 implementor's discretion, although meeting these requirements may be 412 complex. 414 1. Disallow "mixed security context" loads (see Section 2.3.1.3). 416 2. Facilitate user declaration of web sites for which strict 417 security policy is enabled, regardless of whether the sites 418 signal HSTS Policy. 420 3. Conformance Criteria 422 This specification is written for hosts and user agents (UAs). 424 [[IESG Note: the next two paragraphs are for readers with a 425 background in W3C specification style, of which we expect many. RFC 426 Editor, please remove this note before publication.]] 428 A conformant host is one that implements all the requirements listed 429 in this specification that are applicable to hosts. 431 A conformant user agent is one that implements all the requirements 432 listed in this specification that are applicable to user agents. 434 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 435 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 436 document are to be interpreted as described in [RFC2119]. 438 3.1. Document Conventions 440 Note: This is a note to the reader. These are points that should be 441 expressly kept in mind and/or considered. 443 Warning: This is how a warning is shown. These are things that can 444 have negative downside risks if not heeded. 446 4. Terminology 448 Terminology is defined in this section. 450 ASCII case-insensitive comparison: 451 means comparing two strings exactly, codepoint for 452 codepoint, except that the characters in the range 453 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 454 LATIN CAPITAL LETTER Z) and the corresponding 455 characters in the range U+0061 .. U+007A (i.e. 456 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 457 considered to also match. See [Unicode] for 458 details. 460 codepoint: is a colloquial contraction of Code Point, which is 461 any value in the Unicode codespace; that is, the 462 range of integers from 0 to 10FFFF(hex) [Unicode]. 464 domain name: domain names, also referred to as DNS Names, are 465 defined in [RFC1035] to be represented outside of 466 the DNS protocol itself (and implementations 467 thereof) as a series of labels separated by dots, 468 e.g., "example.com" or "yet.another.example.org". 469 In the context of this specification, domain names 470 appear in that portion of a URI satisfying the reg- 471 name production in "Appendix A. Collected ABNF for 472 URI" in [RFC3986], and the host component from the 473 Host HTTP header field production in Section 14.23 474 of [RFC2616]. 476 Note: The domain names appearing in actual URI 477 instances and matching the aforementioned 478 production components may or may not be a 479 fully qualified domain name. 481 domain name label: is that portion of a domain name appearing 482 "between the dots", i.e. consider 483 "foo.example.com": "foo", "example", and "com" are 484 all domain name labels. 486 Effective Request URI: 487 is a URI, identifying the target resource, that can 488 be inferred by an HTTP host for any given HTTP 489 request it receives. Such inference is necessary 490 because HTTP requests often do not contain a 491 complete "absolute" URI identifying the target 492 resource. See Section 12 "Constructing an 493 Effective Request URI". 495 HTTP Strict Transport Security: 496 is the overall name for the combined UA- and 497 server-side security policy defined by this 498 specification. 500 HTTP Strict Transport Security Host: 501 is a HTTP host implementing the server aspects of 502 the HSTS Policy. This means that an HSTS Host 503 returns the "Strict-Transport-Security" HTTP 504 response header field in its HTTP response messages 505 sent over secure transport. 507 HTTP Strict Transport Security Policy: 508 is the name of the combined overall UA- and server- 509 side facets of the behavior defined in this 510 specification. 512 HSTS: See HTTP Strict Transport Security. 514 HSTS Host: See HTTP Strict Transport Security Host. 516 HSTS Policy: See HTTP Strict Transport Security Policy. 518 Known HSTS Host: is an HSTS Host for which the UA has an HSTS Policy 519 in effect. I.e., the UA has noted this host as a 520 Known HSTS Host. 522 Local policy: is comprised of policy rules deployers specify and 523 which are often manifested as configuration 524 settings. 526 MITM: is an acronym for man-in-the-middle. See "man-in- 527 the-middle attack" in [RFC4949]. 529 Request URI: is the URI used to cause a UA to issue an HTTP 530 request message. 532 UA: is a an acronym for user agent. For the purposes 533 of this specification, a UA is an HTTP client 534 application typically actively manipulated by a 535 user [RFC2616] . 537 unknown HSTS Host: is an HSTS Host that the user agent in question 538 has not yet noted. 540 5. HSTS Mechanism Overview 542 This section provides an overview of the mechanism by which an HSTS 543 Host conveys its HSTS Policy to UAs, and how UAs process the HSTS 544 Policies received from HSTS Hosts. The mechanism details are 545 specified in Section 6 through Section 15. 547 An HSTS Host conveys its HSTS Policy to UAs via the Strict-Transport- 548 Security HTTP response header field over secure transport (e.g., 549 TLS). Receipt of this header field signals to UAs to enforce the 550 HSTS Policy for all subsequent connections made to the HSTS Host, for 551 a specified time duration. Application of the HSTS Policy to 552 subdomains of the HSTS Host name may optionally be specified. 554 HSTS Hosts manage their advertised HSTS Policies by sending Strict- 555 Transport-Security HTTP response header fields to UAs with new values 556 for policy time duration and application to subdomains. UAs cache 557 the "freshest" HSTS Policy information on behalf of an HSTS Host. 558 Specifying a zero time duration signals to the UA to delete the HSTS 559 Policy for that HSTS Host. 561 Section 6.2 presents examples of Strict-Transport-Security HTTP 562 response header fields. 564 6. Syntax 566 This section defines the syntax of the Strict-Transport-Security HTTP 567 response header field and its directives, and presents some examples. 569 Section 7 "Server Processing Model" then details how hosts employ 570 this header field to declare their HSTS Policy, and Section 8 "User 571 Agent Processing Model" details how user agents process the header 572 field and apply the HSTS Policy. 574 6.1. Strict-Transport-Security HTTP Response Header Field 576 The Strict-Transport-Security HTTP response header field (STS header 577 field) indicates to a UA that it MUST enforce the HSTS Policy in 578 regards to the host emitting the response message containing this 579 header field. 581 The ABNF (Augmented Backus-Naur Form) syntax for the STS header field 582 is given below. It is based on the Generic Grammar defined in 583 Section 2 of [RFC2616] (which includes a notion of "implied linear 584 whitespace", also known as "implied *LWS"). 586 Strict-Transport-Security = "Strict-Transport-Security" ":" 587 [ directive ] *( ";" [ directive ] ) 589 directive = token [ "=" ( token | quoted-string ) ] 591 where: 593 token = 594 quoted-string = 596 The two directives defined in this specification are described below. 597 The overall requirements for directives are: 599 1. The order of appearance of directives is not significant. 601 2. All directives MUST appear only once in an STS header field. 602 Directives are either optional or required, as stipulated in 603 their definitions. 605 3. Directive names are case-insensitive. 607 4. UAs MUST ignore any STS header fields containing directives, or 608 other header field value data, that does not conform to the 609 syntax defined in this specification. 611 5. If an STS header field contains directive(s) not recognized by 612 the UA, the UA MUST ignore the unrecognized directives and if the 613 STS header field otherwise satisfies the above requirements (1 614 through 4), the UA MUST process the recognized directives. 616 Additional directives extending the semantic functionality of the STS 617 header field can be defined in other specifications. 619 6.1.1. The max-age Directive 621 The REQUIRED "max-age" directive specifies the number of seconds, 622 after the reception of the STS header field, during which the UA 623 regards the host (from whom the message was received) as a Known HSTS 624 Host. See also Section 8.1.1 "Noting an HSTS Host". The delta- 625 seconds production is specified in [RFC2616]. 627 The syntax of the max-age directive's value (after quoted-string 628 unescaping, if necessary) is defined as: 630 max-age-value = delta-seconds 632 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 634 Note: A max-age value of zero (i.e., "max-age=0") signals the UA to 635 cease regarding the host as a Known HSTS Host. 637 6.1.2. The includeSubDomains Directive 639 The OPTIONAL "includeSubDomains" directive is a valueless flag which, 640 if present, signals to the UA that the HSTS Policy applies to this 641 HSTS Host as well as any subdomains of the host's domain name. 643 6.2. Examples 645 The below HSTS header field stipulates that the HSTS Policy is to 646 remain in effect for one year (there are approximately 31 536 000 647 seconds in a year), and the policy applies only to the domain of the 648 HSTS Host issuing it: 650 Strict-Transport-Security: max-age=31536000 652 The below HSTS header field stipulates that the HSTS Policy is to 653 remain in effect for approximately six months and the policy applies 654 only to the domain of the issuing HSTS Host and all of its 655 subdomains: 657 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 659 The max-age directive value can optionally be quoted: 661 Strict-Transport-Security: max-age="31536000" 663 7. Server Processing Model 665 This section describes the processing model that HSTS Hosts 666 implement. The model is comprised of two facets: the first being the 667 processing rules for HTTP request messages received over a secure 668 transport (e.g., TLS [RFC5246], SSL [I-D.ietf-tls-ssl-version3], or 669 perhaps others), the second being the processing rules for HTTP 670 request messages received over non-secure transports, i.e. over 671 TCP/IP. 673 7.1. HTTP-over-Secure-Transport Request Type 675 When replying to an HTTP request that was conveyed over a secure 676 transport, an HSTS Host SHOULD include in its response message an STS 677 header field that MUST satisfy the grammar specified above in 678 Section 6.1 "Strict-Transport-Security HTTP Response Header Field". 679 If an STS header field is included, the HSTS Host MUST include only 680 one such header field. 682 Note: Including the STS header field is stipulated as a "SHOULD" in 683 order to accommodate various server- and network-side caches 684 and load-balancing configurations where it may be difficult to 685 uniformly emit STS header fields on behalf of a given HSTS 686 Host. 688 Establishing a given host as a Known HSTS Host, in the context 689 of a given UA, MAY be accomplished over the HTTP protocol by 690 correctly returning, per this specification, at least one 691 valid STS header field to the UA. Other mechanisms, such as a 692 client-side pre-loaded Known HSTS Host list MAY also be used. 693 E.g., see Section 11 "User Agent Implementation Advice". 695 7.2. HTTP Request Type 697 If an HSTS Host receives a HTTP request message over a non-secure 698 transport, it SHOULD send a HTTP response message containing a status 699 code indicating a permanent redirect, such as status code 301 700 (Section 10.3.2 of [RFC2616]), and a Location header field value 701 containing either the HTTP request's original Effective Request URI 702 (see Section 12 "Constructing an Effective Request URI") altered as 703 necessary to have a URI scheme of "https", or a URI generated 704 according to local policy (which SHOULD employ a URI scheme of 705 "https"). 707 Note: The above behavior is a "SHOULD" rather than a "MUST" due to: 709 * Risks in server-side non-secure-to-secure redirects 710 [owaspTLSGuide]. 712 * Site deployment characteristics. For example, a site that 713 incorporates third-party components may not behave correctly 714 when doing server-side non-secure-to-secure redirects in the 715 case of being accessed over non-secure transport, but does 716 behave correctly when accessed uniformly over secure transport. 717 The latter is the case given a HSTS-capable UA that has already 718 noted the site as a Known HSTS Host (by whatever means, e.g., 719 prior interaction or UA configuration). 721 An HSTS Host MUST NOT include the STS header field in HTTP responses 722 conveyed over non-secure transport. 724 8. User Agent Processing Model 726 This section describes the HTTP Strict Transport Security processing 727 model for UAs. There are several facets to the model, enumerated by 728 the following subsections. 730 This processing model assumes that the UA implements IDNA2008 731 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 732 "Internationalized Domain Names for Applications (IDNA): Dependency 733 and Migration". It also assumes that all domain names manipulated in 734 this specification's context are already IDNA-canonicalized as 735 outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to 736 the processing specified in this section. 738 The above assumptions mean that this processing model also 739 specifically assumes that appropriate IDNA and Unicode validations 740 and character list testing have occurred on the domain names, in 741 conjunction with their IDNA-canonicalization, prior to the processing 742 specified in this section. See the IDNA-specific security 743 considerations in Section 14.8 "Internationalized Domain Names" for 744 rationale and further details. 746 8.1. Strict-Transport-Security Response Header Field Processing 748 If an HTTP response, received over a secure transport, includes an 749 STS header field, conforming to the grammar specified in Section 6.1 750 "Strict-Transport-Security HTTP Response Header Field", and there are 751 no underlying secure transport errors or warnings (see Section 8.4), 752 the UA MUST either: 754 o Note the host as a Known HSTS Host if it is not already so noted 755 (see Section 8.1.1 "Noting an HSTS Host"), 757 or, 759 o Update the UA's cached information for the Known HSTS Host if 760 either or both of the max-age and includeSubDomains header field 761 value tokens are conveying information different than that already 762 maintained by the UA. 764 The max-age value is essentially a "time to live" value relative 765 to the reception time of the STS header field. 767 If the max-age header field value token has a value of zero, the 768 UA MUST remove its cached HSTS Policy information if the HSTS Host 769 is known, or, MUST NOT note this HSTS Host if it is not yet known. 771 If a UA receives more than one STS header field in a HTTP response 772 message over secure transport, then the UA MUST process only the 773 first such header field. 775 Otherwise: 777 o If an HTTP response is received over insecure transport, the UA 778 MUST ignore any present STS header field(s). 780 o The UA MUST ignore any STS header fields not conforming to the 781 grammar specified in Section 6.1 "Strict-Transport-Security HTTP 782 Response Header Field". 784 8.1.1. Noting an HSTS Host 786 If the substring matching the host production from the Request-URI 787 (of the message to which the host responded) syntactically matches 788 the IP-literal or IPv4address productions from Section 3.2.2 of 789 [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. 791 Otherwise, if the substring does not congruently match a Known HSTS 792 Host's domain name, per the matching procedure specified in 793 Section 8.2 "Known HSTS Host Domain Name Matching", then the UA MUST 794 note this host as a Known HSTS Host, caching the HSTS Host's domain 795 name and noting along with it the expiry time of this information, as 796 effectively stipulated per the given max-age value, as well as 797 whether the includeSubDomains flag is asserted or not. See also 798 Section 10.1 "HSTS Policy expiration time considerations". 800 Note: The UA MUST NOT modify the expiry time nor the 801 includeSubDomains flag of any superdomain matched Known HSTS 802 Host. 804 8.2. Known HSTS Host Domain Name Matching 806 A given domain name may match a Known HSTS Host's domain name in one 807 or both of two fashions: a congruent match, or a superdomain match. 808 Or, there may be no match. 810 The below steps determine whether there are any matches, and if so, 811 of which fashion: 813 Compare the given domain name with the domain name of each of the 814 UA's Known HSTS Hosts. For each Known HSTS Host's domain name, 815 the comparison is done with the given domain name label-by-label 816 (comparing only labels) using an ASCII case-insensitive comparison 817 beginning with the rightmost label, and continuing right-to-left. 818 See also Section 2.3.2.4. of [RFC5890]. 820 * Superdomain Match 822 If a label-for-label match between an entire Known HSTS Host's 823 domain name and a right-hand portion of the given domain name 824 is found, then this Known HSTS Host's domain name is a 825 superdomain match for the given domain name. There could be 826 multiple superdomain matches for a given domain name. 828 For example: 830 Given Domain Name: qaz.bar.foo.example.com 832 Superdomain matched 833 Known HSTS Host DN: bar.foo.example.com 835 Superdomain matched 836 Known HSTS Host DN: foo.example.com 838 * Congruent Match 840 If a label-for-label match between a Known HSTS Host's domain 841 name and the given domain name is found -- i.e., there are no 842 further labels to compare -- then the given domain name 843 congruently matches this Known HSTS Host. 845 For example: 847 Given Domain Name: foo.example.com 849 Congruently matched 850 Known HSTS Host DN: foo.example.com 852 * Otherwise, if no matches are found, the given domain name does 853 not represent a Known HSTS Host. 855 8.3. URI Loading and Port Mapping 857 Whenever the UA prepares to "load", also known as "dereference", any 858 "http" URI [RFC3986] (including when following HTTP redirects 859 [RFC2616]), the UA MUST first determine whether a domain name is 860 given in the URI and whether it matches a Known HSTS Host, using 861 these steps: 863 1. Extract from the URI any substring described by the host 864 component of the authority component of the URI. 866 2. If the substring is null, then there is no match with any Known 867 HSTS Host. 869 3. Else, if the substring is non-null and syntactically matches the 870 IP-literal or IPv4address productions from Section 3.2.2 of 871 [RFC3986], then there is no match with any Known HSTS Host. 873 4. Otherwise, the substring is a given domain name, which MUST be 874 matched against the UA's Known HSTS Hosts using the procedure in 875 Section 8.2 "Known HSTS Host Domain Name Matching". 877 If a superdomain match with an asserted includeSubDomains flag is 878 found, or if a congruent match is found -- without any found 879 superdomain matches having asserted includeSubDomains flags -- then 880 before proceeding with the load: 882 The UA MUST replace the URI scheme with "https" [RFC2818], and, 884 if the URI contains an explicit port component of "80", then the 885 UA MUST convert the port component to be "443", or, 887 if the URI contains an explicit port component that is not equal 888 to "80", the port component value MUST be preserved, otherwise, 890 if the URI does not contain an explicit port component, the UA 891 MUST NOT add one. 893 Note: The the above steps ensure that the HSTS Policy applies to 894 HTTP over any TCP port of an HSTS Host. 896 8.4. Errors in Secure Transport Establishment 898 When connecting to a Known HSTS Host, the UA MUST terminate the 899 connection (see also Section 11 "User Agent Implementation Advice") 900 if there are any errors (e.g., certificate errors), whether "warning" 901 or "fatal" or any other error level, with the underlying secure 902 transport. This includes any issues with certificate revocation 903 checking whether via the Certificate Revocation List (CRL) [RFC5280], 904 or via the Online Certificate Status Protocol (OCSP) [RFC2560]. 906 8.5. HTTP-Equiv Element Attribute 908 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 909 settings on elements [W3C.REC-html401-19991224] in received 910 content. 912 8.6. Missing Strict-Transport-Security Response Header Field 914 If a UA receives HTTP responses from a Known HSTS Host over a secure 915 channel, but they are missing the STS header field, the UA MUST 916 continue to treat the host as a Known HSTS Host until the max-age 917 value for the knowledge of that Known HSTS Host is reached. Note 918 that the max-age value could be effectively infinite for a given 919 Known HSTS Host. For example, this would be the case if the Known 920 HSTS Host is part of a pre-configured list that is implemented such 921 that the list entries never "age out". 923 9. Domain Name IDNA-Canonicalization 925 An IDNA-canonicalized domain name is the output string generated by 926 the following steps. The input is a putative domain name string 927 ostensibly composed of any combination of "A-labels", "U-labels", and 928 "NR-LDH labels" (see Section 2 of [RFC5890]) concatenated using some 929 separator character (typically "."). 931 1. Convert the input putative domain name string to a order- 932 preserving sequence of individual label strings. 934 2. When implementing IDNA2008, convert, validate, and test each 935 A-label and U-label found among the sequence of individual label 936 strings, using the procedures defined in Sections 5.3 through 5.5 937 of [RFC5891]. 939 Otherwise, when implementing IDNA2003, convert each label using 940 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 941 definition of "equivalence of labels" in Section 2 of the latter 942 specification). 944 3. If no errors occurred during the foregoing step, concatenate all 945 the labels in the sequence, in order, into a string, separating 946 each label from the next with a %x2E (".") character. The 947 resulting string, known as a IDNA-canonicalized domain name, is 948 appropriate for use in the context of Section 8 "User Agent 949 Processing Model". 951 Otherwise, errors occurred. The input putative domain name 952 string was not successfully IDNA-canonicalized. Invokers of this 953 procedure should attempt appropriate error recovery. 955 See also Section 13 "Internationalized Domain Names for Applications 956 (IDNA): Dependency and Migration" and Section 14.8 "Internationalized 957 Domain Names" of this specification for further details and 958 considerations. 960 10. Server Implementation and Deployment Advice 962 This section is non-normative. 964 10.1. HSTS Policy expiration time considerations 966 Server implementations and deploying web sites need to consider 967 whether they are setting an expiry time that is a constant value into 968 the future, or whether they are setting an expiry time that is a 969 fixed point in time. 971 The constant value into the future approach can be accomplished by 972 constantly sending the same max-age value to UAs. 974 For example, a max-age value of 7776000 seconds is 90 days: 976 Strict-Transport-Security: max-age=7776000 978 Note that each receipt of this header by a UA will require the UA to 979 update its notion of when it must delete its knowledge of this Known 980 HSTS Host. 982 The fixed point in time approach can be accomplished by sending max- 983 age values that represent the remaining time until the desired expiry 984 time. This would require the HSTS Host to send a newly-calculated 985 max-age value on each HTTP response. 987 A consideration here is whether a deployer wishes to have the 988 signaled HSTS Policy expiry time match that for the web site's domain 989 certificate. 991 Additionally, server implementers should consider employing a default 992 max-age value of zero in their deployment configuration systems. 993 This will require deployers to wilfully set max-age in order to have 994 UAs enforce the HSTS Policy for their host, and protects them from 995 inadvertently enabling HSTS with some arbitrary non-zero duration. 997 10.2. Using HSTS in conjunction with self-signed public-key 998 certificates 1000 If a web site/organization/enterprise is generating its own secure 1001 transport public-key certificates for web sites, and that 1002 organization's root certification authority (CA) certificate is not 1003 typically embedded by default in browser and/or operating system CA 1004 certificate stores, and if HSTS Policy is enabled on a host 1005 identifying itself using a certificate signed by the organization's 1006 CA (i.e., a "self-signed certificate"), and this certificate does not 1007 match a usable TLS certificate association (as defined by Section 4 1008 of the TLSA protocol specification [I-D.ietf-dane-protocol]), then 1009 secure connections to that site will fail, per the HSTS design. This 1010 is to protect against various active attacks, as discussed above. 1012 However, if said organization wishes to employ its own CA, and self- 1013 signed certificates, in concert with HSTS, it can do so by deploying 1014 its root CA certificate to its users' browsers or operating system CA 1015 root certificate stores. It can also, in addition or instead, 1016 distribute to its users' browsers the end-entity certificate(s) for 1017 specific hosts. There are various ways in which this can be 1018 accomplished (details are out of scope for this specification). Once 1019 its root CA certificate is installed in the browsers, it may employ 1020 HSTS Policy on its site(s). 1022 Alternately, that organization can deploy the TLSA protocol; all 1023 browsers that also use TLSA will then be able to trust the 1024 certificates identified by usable TLS certificate associations as 1025 denoted via TLSA. 1027 Note: Interactively distributing root CA certificates to users, 1028 e.g., via email, and having the users install them, is 1029 arguably training the users to be susceptible to a possible 1030 form of phishing attack. See Section 14.6 "Bogus Root CA 1031 Certificate Phish plus DNS Cache Poisoning Attack". Thus care 1032 should be taken in the manner in which such certificates are 1033 distributed and installed on users' systems and browsers. 1035 10.3. Implications of includeSubDomains 1037 The includeSubDomains directive has some practical implications. For 1038 example, if an HSTS Host offers HTTP-based services on various ports 1039 or at various subdomains of its host domain name, then they will all 1040 have to be available over secure transport in order to work properly. 1042 For example, certification authorities often offer their CRL 1043 distribution and OCSP services [RFC2560] over plain HTTP, and 1044 sometimes at a subdomain of a publicly-available web application 1045 which may be secured by TLS/SSL. For example, 1046 is a publicly-available web application for 1047 "Example CA", a certification authority. Customers use this web 1048 application to register their public keys and obtain certificates. 1049 Example CA generates certificates for customers containing 1050 as the value for the "CRL 1051 Distribution Points" and "Authority Information Access:OCSP" 1052 certificate fields. 1054 If ca.example.com were to issue an HSTS Policy with the 1055 includeSubDomains directive, then HTTP-based user agents implementing 1056 HSTS that have interacted with the ca.example.com web application 1057 would fail to retrieve CRLs, and fail to check OCSP for certificates, 1058 because these services are offered over plain HTTP. 1060 In this case, Example CA can either: 1062 o not use the includeSubDomains directive, or, 1064 o ensure HTTP-based services offered at subdomains of ca.example.com 1065 are also uniformly offered over TLS/SSL, or, 1067 o offer plain HTTP-based services at a different domain name, e.g., 1068 crl-and-ocsp.ca.example.NET, or, 1070 o utilize an alternative approach to distributing certificate status 1071 information, obviating the need to offer CRL distribution and OCSP 1072 services over plain HTTP (e.g., the "Certificate Status Request" 1073 TLS extension [RFC6066], often colloquially referred to as "OCSP 1074 Stapling"). 1076 Note: The above points are expressly only an example and do not 1077 purport to address all the involved complexities. For 1078 instance, there are many considerations -- on the part of CAs, 1079 certificate deployers, and applications (e.g., browsers) -- 1080 involved in deploying an approach such as "OCSP Stapling". 1081 Such issues are out of scope for this specification. 1083 11. User Agent Implementation Advice 1085 This section is non-normative. 1087 In order to provide users and web sites more effective protection, as 1088 well as controls for managing their UA's caching of HSTS Policy, UA 1089 implementers should consider including features such as: 1091 11.1. No User Recourse 1093 Failing secure connection establishment on any warnings or errors 1094 (per Section 8.4 "Errors in Secure Transport Establishment") should 1095 be done with "no user recourse". This means that the user should not 1096 be presented with a dialog giving her the option to proceed. Rather, 1097 it should be treated similarly to a server error where there is 1098 nothing further the user can do with respect to interacting with the 1099 target web application, other than wait and re-try. 1101 Essentially, "any warnings or errors" means anything that would cause 1102 the UA implementation to announce to the user that something is not 1103 entirely correct with the connection establishment. 1105 Not doing this, i.e., allowing user recourse such as "clicking- 1106 through warning/error dialogs", is a recipe for a Man-in-the-Middle 1107 attack. If a web application advertises HSTS, then it is opting into 1108 this scheme, whereby all certificate errors or warnings cause a 1109 connection termination, with no chance to "fool" the user into making 1110 the wrong decision and compromising themselves. 1112 11.2. User-declared HSTS Policy 1114 A User-declared HSTS Policy is the ability for users to explicitly 1115 declare a given Domain Name as representing an HSTS Host, thus 1116 seeding it as a Known HSTS Host before any actual interaction with 1117 it. This would help protect against the Section 14.4 "Bootstrap MITM 1118 Vulnerability". 1120 Note: Such a feature is difficult to get right on a per-site basis. 1121 See the discussion of "rewrite rules" in Section 5.5 of 1122 [ForceHTTPS]. For example, arbitrary web sites may not 1123 materialize all their URIs using the "https" scheme, and thus 1124 could "break" if a UA were to attempt to access the site 1125 exclusively using such URIs. Also note that this feature 1126 would complement, but is independent of, the following 1127 described facility. 1129 11.3. HSTS Pre-Loaded List 1131 An HSTS Pre-Loaded List is a facility whereby web site administrators 1132 can have UAs pre-configured with HSTS Policy for their site(s) by the 1133 UA vendor(s) -- a so-called "pre-loaded list" -- in a manner similar 1134 to how root CA certificates are embedded in browsers "at the 1135 factory". This would help protect against the Section 14.4 1136 "Bootstrap MITM Vulnerability". 1138 Note: Such a facility would complement a "User-declared HSTS Policy" 1139 feature. 1141 11.4. Disallow Mixed Security Context Loads 1143 "Mixed security context" loads are when an web application resource, 1144 fetched by the UA over a secure transport, subsequently fetches and 1145 loads one or more other resources without using secure transport. 1146 This is also generally referred to as "mixed content" loads (see 1147 Section 5.3 "Mixed Content" in [W3C.REC-wsc-ui-20100812]), but should 1148 not be confused with the same "mixed content" term that is also used 1149 in the context of markup languages such as XML and HTML. 1151 Note: In order to provide behavioral uniformity across UA 1152 implementations, the notion of mixed security context will 1153 require further standardization work, e.g., to define the 1154 term(s) more clearly and to define specific behaviors with 1155 respect to it. 1157 11.5. HSTS Policy Deletion 1159 HSTS Policy Deletion is the ability to delete a UA's cached HSTS 1160 Policy on a per HSTS Host basis. 1162 Note: Adding such a feature should be done very carefully in both 1163 the user interface and security senses. Deleting a cache 1164 entry for a Known HSTS Host should be a very deliberate and 1165 well-considered act -- it shouldn't be something users get 1166 used to just "clicking through" in order to get work done. 1167 Also, implementations need to guard against allowing an 1168 attacker to inject code, e.g. ECMAscript, into the UA that 1169 silently and programmatically removes entries from the UA's 1170 cache of Known HSTS Hosts. 1172 12. Constructing an Effective Request URI 1174 This section specifies how an HSTS Host must construct the Effective 1175 Request URI for a received HTTP request. 1177 HTTP requests often do not carry an absoluteURI for the target 1178 resource; instead, the URI needs to be inferred from the Request-URI, 1179 Host header field, and connection context ([RFC2616], Sections 3.2.1 1180 and 5.1.2). The result of this process is called the "effective 1181 request URI (ERU)". The "target resource" is the resource identified 1182 by the effective request URI. 1184 12.1. ERU Fundamental Definitions 1186 The first line of an HTTP request message, Request-Line, is specified 1187 by the following ABNF from [RFC2616], Section 5.1: 1189 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1191 The Request-URI, within the Request-Line, is specified by the 1192 following ABNF from [RFC2616], Section 5.1.2: 1194 Request-URI = "*" | absoluteURI | abs_path | authority 1196 The Host request header field is specified by the following ABNF from 1197 [RFC2616], Section 14.23: 1199 Host = "Host" ":" host [ ":" port ] 1201 12.2. Determining the Effective Request URI 1203 If the Request-URI is an absoluteURI, then the effective request URI 1204 is the Request-URI. 1206 If the Request-URI uses the abs_path form or the asterisk form, and 1207 the Host header field is present, then the effective request URI is 1208 constructed by concatenating: 1210 o the scheme name: "http" if the request was received over an 1211 insecure TCP connection, or "https" when received over a TLS/ 1212 SSL-secured TCP connection, and, 1214 o the octet sequence "://", and, 1216 o the host, and the port (if present), from the Host header field, 1217 and 1219 o the Request-URI obtained from the Request-Line, unless the 1220 Request-URI is just the asterisk "*". 1222 If the Request-URI uses the abs_path form or the asterisk form, and 1223 the Host header field is not present, then the effective request URI 1224 is undefined. 1226 Otherwise, when Request-URI uses the authority form, the effective 1227 request URI is undefined. 1229 Effective request URIs are compared using the rules described in 1230 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1231 be treated as equivalent to an absolute path of "/". 1233 12.2.1. Effective Request URI Examples 1235 Example 1: the effective request URI for the message 1237 GET /pub/WWW/TheProject.html HTTP/1.1 1238 Host: www.example.org:8080 1240 (received over an insecure TCP connection) is "http", plus "://", 1241 plus the authority component "www.example.org:8080", plus the 1242 request-target "/pub/WWW/TheProject.html". Thus it is: 1243 "http://www.example.org:8080/pub/WWW/TheProject.html". 1245 Example 2: the effective request URI for the message 1247 OPTIONS * HTTP/1.1 1248 Host: www.example.org 1250 (received over an SSL/TLS secured TCP connection) is "https", plus 1251 "://", plus the authority component "www.example.org". Thus it is: 1252 "https://www.example.org". 1254 13. Internationalized Domain Names for Applications (IDNA): Dependency 1255 and Migration 1257 Textual domain names on the modern Internet may contain one or more 1258 "internationalized" domain name labels. Such domain names are 1259 referred to as "internationalized domain names" (IDNs). The 1260 specification suites defining IDNs and the protocols for their use 1261 are named "Internationalized Domain Names for Applications (IDNA)". 1262 At this time, there are two such specification suites: IDNA2008 1263 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1265 IDNA2008 obsoletes IDNA2003, but there are differences between the 1266 two specifications, and thus there can be differences in processing 1267 (e.g., converting) domain name labels that have been registered under 1268 one from those registered under the other. There will be a 1269 transition period of some time during which IDNA2003-based domain 1270 name labels will exist in the wild. In order to facilitate their 1271 IDNA transition, user agents SHOULD implement IDNA2008 [RFC5890] and 1272 MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46]. 1274 If a user agent does not implement IDNA2008, the user agent MUST 1275 implement IDNA2003. 1277 14. Security Considerations 1279 This specification concerns the expression, conveyance, and 1280 enforcement of the HSTS Policy. The overall HSTS Policy threat 1281 model, including addressed and unaddressed threats, is given in 1282 Section 2.3 "Threat Model". 1284 Additionally, the below sections discuss operational ramifications of 1285 the HSTS Policy, provide feature rationale, discuss potential HSTS 1286 Policy misuse, and highlight some known vulnerabilities in the HSTS 1287 Policy regime. 1289 14.1. Ramifications of HSTS Policy Establishment only over Error-free 1290 Secure Transport 1292 The User Agent Processing Model defined in Section 8, stipulates that 1293 a host is initially noted as a Known HSTS Host, or that updates are 1294 made to a Known HSTS Host's cached information, only if the UA 1295 receives the STS header field over a secure transport connection 1296 having no underlying secure transport errors or warnings. 1298 The rationale behind this is that if there is a man-in-the-middle 1299 (MITM) -- whether a legitimately deployed proxy or an illegitimate 1300 entity -- it could cause various mischief (see also Appendix A 1301 "Design Decision Notes", item 3, as well as Section 14.4 "Bootstrap 1302 MITM Vulnerability"), for example: 1304 o Unauthorized notation of the host as a Known HSTS Host, 1305 potentially leading to a denial of service situation if the host 1306 does not uniformly offer its services over secure transport (see 1307 also Section 14.3 "Denial of Service"). 1309 o Resetting the time-to-live for the host's designation as a Known 1310 HSTS Host by manipulating the max-age header field parameter value 1311 that is returned to the UA. If max-age is returned as zero, this 1312 will cause the host to cease being regarded as an Known HSTS Host 1313 by the UA, leading to either insecure connections to the host or 1314 possibly denial-of-service if the host delivers its services only 1315 over secure transport. 1317 However, this means that if a UA is "behind" a proxy -- within a 1318 corporate intranet, for example -- and interacts with an unknown HSTS 1319 Host beyond the proxy, the user will possibly be presented with the 1320 legacy secure connection error dialogs. Even if the risk is accepted 1321 and the user clicks-through, the host will not be noted as an HSTS 1322 Host. Thus, as long as the UA is behind such a proxy the user will 1323 be vulnerable, and possibly be presented with the legacy secure 1324 connection error dialogs for as yet unknown HSTS Hosts. 1326 Once the UA successfully connects to an unknown HSTS Host over error- 1327 free secure transport, the host will be noted as a Known HSTS Host. 1328 This will result in the failure of subsequent connection attempts 1329 from behind interfering proxies. 1331 The above discussion relates to the recommendation in Section 11 1332 "User Agent Implementation Advice" that the secure connection be 1333 terminated with "no user recourse" whenever there are warnings and 1334 errors and the host is a Known HSTS Host. Such a posture protects 1335 users from "clicking through" security warnings and putting 1336 themselves at risk. 1338 14.2. The Need for includeSubDomains 1340 Without the includeSubDomains directive, a web application would not 1341 be able to adequately protect so-called "domain cookies" (even if 1342 these cookies have their "Secure" flag set and thus are conveyed only 1343 on secure channels). These are cookies the web application expects 1344 UAs to return to any and all subdomains of the web application. 1346 For example, suppose example.com represents the top-level DNS name 1347 for a web application. Further suppose that this cookie is set for 1348 the entire example.com domain, i.e. it is a "domain cookie", and it 1349 has its Secure flag set. Suppose example.com is a Known HSTS Host 1350 for this UA, but the includeSubDomains flag is not set. 1352 Now, if an attacker causes the UA to request a subdomain name that is 1353 unlikely to already exist in the web application, such as 1354 "https://uxdhbpahpdsf.example.com/", but that the attacker has 1355 managed to register in the DNS and point at an HTTP server under the 1356 attacker's control, then: 1358 1. The UA is unlikely to already have an HSTS Policy established for 1359 "uxdhbpahpdsf.example.com", and, 1361 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1362 the Secure-flagged domain cookie. 1364 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1365 establishment, and the user clicks through any warning that might 1366 be presented (it is possible, but not certain, that one may 1367 obtain a requisite certificate for such a domain name such that a 1368 warning may or may not appear), then the attacker can obtain the 1369 Secure-flagged domain cookie that's ostensibly being protected. 1371 Without the "includeSubDomains" directive, HSTS is unable to protect 1372 such Secure-flagged domain cookies. 1374 14.3. Denial of Service 1376 HSTS could be used to mount certain forms of Denial-of- Service (DoS) 1377 attacks against web sites. A DoS attack is an attack in which one or 1378 more network entities target a victim entity and attempt to prevent 1379 the victim from doing useful work. This section discusses such 1380 scenarios in terms of HSTS, though this list is not exhaustive. See 1381 also [RFC4732] for a discussion of overall Internet DoS 1382 considerations. 1384 o Web applications available over HTTP 1386 There is an opportunity for perpetrating DoS attacks with web 1387 applications that are -- or critical portions of them are -- 1388 available only over HTTP without secure transport, if attackers 1389 can cause UAs to set HSTS Policy for such web applications' 1390 host(s). 1392 This is because once the HSTS Policy is set for a web 1393 application's host in a UA, the UA will only use secure transport 1394 to communicate with the host. If the host is not using secure 1395 transport, or is not for critical portions of its web application, 1396 then the web application will be rendered unusable for the UA's 1397 user. 1399 An HSTS Policy can be set for a victim host in various ways: 1401 * If the web application has a HTTP response splitting 1402 vulnerability [CWE-113] (which can be abused in order to 1403 facilitate "HTTP Header Injection"). 1405 * If an attacker can spoof a redirect from an insecure victim 1406 site, e.g., to , 1407 where the latter is attacker-controlled and has an apparently 1408 valid certificate, then the attacker can set an HSTS Policy for 1409 example.com, and also for all subdomains of example.com. 1411 * If an attacker can convince users to manually configure HSTS 1412 Policy for a victim host. This assumes their UAs offer such a 1413 capability (see Section 11 "User Agent Implementation Advice"). 1414 Or, if such UA configuration is scriptable, then an attacker 1415 can cause UAs to execute his script and set HSTS Policies for 1416 whichever desired domains. 1418 o Inadvertent use of includeSubDomains 1420 The includeSubDomains directive instructs UAs to automatically 1421 regard all subdomains of the given HSTS Host as Known HSTS Hosts. 1422 If any such subdomains do not support properly configured secure 1423 transport, then they will be rendered unreachable from such UAs. 1425 14.4. Bootstrap MITM Vulnerability 1427 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1428 vulnerability users and HSTS Hosts encounter in the situation where 1429 the user manually enters, or follows a link, to an unknown HSTS Host 1430 using a "http" URI rather than a "https" URI. Because the UA uses an 1431 insecure channel in the initial attempt to interact with the 1432 specified server, such an initial interaction is vulnerable to 1433 various attacks (see Section 5.3 of [ForceHTTPS]). 1435 Note: There are various features/facilities that UA implementations 1436 may employ in order to mitigate this vulnerability. Please 1437 see Section 11 "User Agent Implementation Advice". 1439 14.5. Network Time Attacks 1441 Active network attacks can subvert network time protocols (such as 1442 Network Time Protocol (NTP) [RFC5905]) - making HSTS less effective 1443 against clients that trust NTP or lack a real time clock. Network 1444 time attacks are beyond the scope of this specification. Note that 1445 modern operating systems use NTP by default. See also Section 2.10 1446 of [RFC4732]. 1448 14.6. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1450 An attacker could conceivably obtain a victim HSTS-protected web 1451 application's users' login credentials via a bogus root CA 1452 certificate phish plus DNS cache poisoning attack. 1454 For example, the attacker could first convince users of a victim web 1455 application (which is protected by HSTS Policy) to install the 1456 attacker's version of a root CA certificate purporting (falsely) to 1457 represent the CA of the victim web application. This might be 1458 accomplished by sending the users a phishing email message with a 1459 link to such a certificate, which their browsers may offer to install 1460 if clicked on. 1462 Then, if the attacker can perform an attack on the users' DNS 1463 servers, (e.g., via cache poisoning) and turn on HSTS Policy for 1464 their fake web application, the affected users' browsers would access 1465 the attackers' web application rather than the legitimate web 1466 application. 1468 This type of attack leverages vectors that are outside of the scope 1469 of HSTS. However, the feasibility such threats can be mitigated by 1470 appropriate employment of security facilities such as DNS Security 1471 [RFC4033], and DomainKeys Identified Mail (DKIM) [RFC6376], in 1472 addition to HSTS, on the part of a web application's overall 1473 deployment approach, 1475 14.7. Creative Manipulation of HSTS Policy Store 1477 Since an HSTS Host may select its own host name and subdomains 1478 thereof, and this information is cached in the HSTS Policy store of 1479 conforming UAs, it is possible for those who control an HSTS Host(s) 1480 to encode information into domain names they control and cause such 1481 UAs to cache this information as a matter of course in the process of 1482 noting the HSTS Host. This information can be retrieved by other 1483 hosts through clever loaded page construction causing the UA to send 1484 queries to (variations of) the encoded domain names. Such queries 1485 can reveal whether the UA had prior visited the original HSTS Host 1486 (and subdomains). 1488 Such a technique could potentially be abused as yet another form of 1489 "web tracking" [WebTracking]. 1491 14.8. Internationalized Domain Names 1493 Internet security relies in part on the DNS and the domain names it 1494 hosts. Domain names are used by users to identify and connect to 1495 Internet hosts and other network resources. For example, Internet 1496 security is compromised if a user entering an internationalized 1497 domain name (IDN) is connected to different hosts based on different 1498 interpretations of the IDN. 1500 The processing models specified in this specification assume that the 1501 domain names they manipulate are IDNA-canonicalized, and that the 1502 canonicalization process correctly performed all appropriate IDNA and 1503 Unicode validations and character list testing per the requisite 1504 specifications (e.g., as noted in Section 9 "Domain Name IDNA- 1505 Canonicalization"). These steps are necessary in order to avoid 1506 various potentially compromising situations. 1508 In brief, some examples of issues that could stem from lack of 1509 careful and consistent Unicode and IDNA validations are things such 1510 as unexpected processing exceptions, truncation errors, and buffer 1511 overflows, as well as false-positive and/or false-negative domain 1512 name matching results. Any of the foregoing issues could possibly be 1513 leveraged by attackers in various ways. 1515 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1516 terms of disallowed characters and character mapping conventions. 1517 This situation can also lead to false-positive and/or false-negative 1518 domain name matching results, resulting in, for example, users 1519 possibly communicating with unintended hosts, or not being able to 1520 reach intended hosts. 1522 For details, refer to the Security Considerations sections of 1523 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1524 they normatively reference. Additionally, [RFC5894] provides 1525 detailed background and rationale for IDNA2008 in particular, as well 1526 as IDNA and its issues in general, and should be consulted in 1527 conjunction with the former specifications. 1529 15. IANA Considerations 1531 Below is the Internet Assigned Numbers Authority (IANA) Permanent 1532 Message Header Field registration information per [RFC3864]. 1534 Header field name: Strict-Transport-Security 1535 Applicable protocol: HTTP 1536 Status: standard 1537 Author/Change controller: IETF 1538 Specification document(s): this one 1540 16. References 1542 16.1. Normative References 1544 [I-D.ietf-dane-protocol] 1545 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1546 of Named Entities (DANE) Protocol for Transport Layer 1547 Security (TLS)", draft-ietf-dane-protocol-19 (work in 1548 progress), April 2012. 1550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1551 Requirement Levels", BCP 14, RFC 2119, March 1997. 1553 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1554 Adams, "X.509 Internet Public Key Infrastructure Online 1555 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1557 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1558 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1559 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1561 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1563 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1564 "Internationalizing Domain Names in Applications (IDNA)", 1565 RFC 3490, March 2003. 1567 This specification is referenced due to its ongoing 1568 relevance to actual deployments for the foreseeable 1569 future. 1571 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1572 for Internationalized Domain Names in Applications 1573 (IDNA)", RFC 3492, March 2003. 1575 This specification is referenced due to its ongoing 1576 relevance to actual deployments for the foreseeable 1577 future. 1579 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1580 Procedures for Message Header Fields", BCP 90, RFC 3864, 1581 September 2004. 1583 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1584 Resource Identifier (URI): Generic Syntax", STD 66, 1585 RFC 3986, January 2005. 1587 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1588 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1590 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1591 Housley, R., and W. Polk, "Internet X.509 Public Key 1592 Infrastructure Certificate and Certificate Revocation List 1593 (CRL) Profile", RFC 5280, May 2008. 1595 [RFC5890] Klensin, J., "Internationalized Domain Names for 1596 Applications (IDNA): Definitions and Document Framework", 1597 RFC 5890, August 2010. 1599 [RFC5891] Klensin, J., "Internationalized Domain Names in 1600 Applications (IDNA): Protocol", RFC 5891, August 2010. 1602 [RFC5894] Klensin, J., "Internationalized Domain Names for 1603 Applications (IDNA): Background, Explanation, and 1604 Rationale", RFC 5894, August 2010. 1606 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1607 Internationalized Domain Names in Applications (IDNA) 1608 2008", RFC 5895, September 2010. 1610 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1611 Processing", Unicode Technical Standards # 46, 2010, 1612 . 1614 [Unicode] The Unicode Consortium, "The Unicode Standard", 1615 . 1617 [W3C.REC-html401-19991224] 1618 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1619 Specification", World Wide Web Consortium 1620 Recommendation REC-html401-19991224, December 1999, 1621 . 1623 16.2. Informative References 1625 [Aircrack-ng] 1626 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1627 . 1629 [BeckTews09] 1630 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1631 WPA", Second ACM Conference on Wireless Network 1632 Security Zurich, Switzerland, 2009, . 1636 [CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in 1637 HTTP Headers ('HTTP Response Splitting')", Common Weakness 1638 Enumeration , The Mitre 1639 Corporation , 1640 . 1642 [Firesheep] 1643 Various, "Firesheep", Wikipedia Online, on-going, 1644 . 1647 [ForceHTTPS] 1648 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1649 Security Web Sites from Network Attacks", In Proceedings 1650 of the 17th International World Wide Web Conference 1651 (WWW2008) , 2008, 1652 . 1654 [GoodDhamijaEtAl05] 1655 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1656 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1657 Spyware at the Gate: A User Study of Privacy, Notice and 1658 Spyware", In Proceedings of Symposium On Usable Privacy 1659 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1663 [I-D.ietf-tls-ssl-version3] 1664 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1665 Version 3.0", draft-ietf-tls-ssl-version3-00 (work in 1666 progress), November 1996, . 1669 This is the canonical reference for SSLv3.0. 1671 [JacksonBarth2008] 1672 Jackson, C. and A. Barth, "Beware of Finer-Grained 1673 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1674 2008, 1675 . 1678 [RFC1035] Mockapetris, P., "Domain names - implementation and 1679 specification", STD 13, RFC 1035, November 1987. 1681 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1682 Rose, "DNS Security Introduction and Requirements", 1683 RFC 4033, March 2005. 1685 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1686 Service Considerations", RFC 4732, December 2006. 1688 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1689 RFC 4949, August 2007. 1691 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1692 Time Protocol Version 4: Protocol and Algorithms 1693 Specification", RFC 5905, June 2010. 1695 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1696 Extension Definitions", RFC 6066, January 2011. 1698 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1699 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1700 August 2011. 1702 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1703 April 2011. 1705 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1706 Identified Mail (DKIM) Signatures", RFC 6376, 1707 September 2011. 1709 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1710 December 2011. 1712 [SunshineEgelmanEtAl09] 1713 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1714 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1715 Effectiveness", In Proceedings of 18th USENIX Security 1716 Symposium Montreal, Canada, Augus 2009, . 1720 [W3C.REC-wsc-ui-20100812] 1721 Saldhana, A. and T. Roessler, "Web Security Context: User 1722 Interface Guidelines", World Wide Web Consortium 1723 Recommendation REC-wsc-ui-20100812, August 2010, 1724 . 1726 [WEBSEC] "WebSec -- HTTP Application Security Minus Authentication 1727 and Transport", 1728 . 1730 Mailing list for IETF WebSec Working Group. [RFCEditor: 1731 please remove this reference upon publication as an RFC.] 1733 [WebTracking] 1734 Schmucker, N., "Web Tracking", SNET2 Seminar Paper Summer 1735 Term, 2011, . 1738 [owaspTLSGuide] 1739 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1740 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1741 Jul-2010, . 1744 Appendix A. Design Decision Notes 1746 This appendix documents various design decisions. 1748 1. Cookies aren't appropriate for HSTS Policy expression as they are 1749 potentially mutable (while stored in the UA), therefore an HTTP 1750 header field is employed. 1752 2. We chose to not attempt to specify how "mixed security context 1753 loads" (AMA "mixed content loads") are handled due to UA 1754 implementation considerations as well as classification 1755 difficulties. 1757 3. An HSTS Host may update UA notions of HSTS Policy via new HSTS 1758 header field parameter values. We chose to have UAs honor the 1759 "freshest" information received from a server because there is 1760 the chance of a web site sending out an errornous HSTS Policy, 1761 such as a multi-year max-age value, and/or an incorrect 1762 includeSubDomains flag. If the HSTS Host couldn't correct such 1763 errors over protocol, it would require some form of annunciation 1764 to users and manual intervention on the users' part, which could 1765 be a non-trivial problem for both web application providers and 1766 their users. 1768 4. HSTS Hosts are identified only via domain names -- explicit IP 1769 address identification of all forms is excluded. This is for 1770 simplification and also is in recognition of various issues with 1771 using direct IP address identification in concert with PKI-based 1772 security. 1774 5. The max-age approch of having the HSTS Host provide a simple 1775 integer number of seconds for a cached HSTS Policy time-to-live 1776 value, as opposed to an approach of stating an expiration time in 1777 the future was chosen for various reasons. Amongst the reasons 1778 are no need for clock syncronization, no need to define date and 1779 time value syntaxes (specification simplicity), and 1780 implementation simplicity. 1782 Appendix B. Differences between HSTS Policy and Same-Origin Policy 1784 HSTS Policy has the following primary characteristics: 1786 HSTS Policy stipulates requirements for the security 1787 characteristics of UA-to-host connection establishment, on a per- 1788 host basis. 1790 Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are 1791 obliged to implement hosts' declared HSTS Policies. 1793 HSTS Policy is conveyed over protocol from the host to the UA. 1795 The UA maintains a cache of Known HSTS Hosts. 1797 UAs apply HSTS Policy whenever making a HTTP connection to a Known 1798 HSTS Host, regardless of host port number. I.e., it applies to 1799 all ports on a Known HSTS Host. Hosts are unable to affect this 1800 aspect of HSTS Policy. 1802 Hosts may optionally declare that their HSTS Policy applies to all 1803 subdomains of their host domain name. 1805 In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following 1806 primary characteristics: 1808 An origin is the scheme, host, and port of a URI identifying a 1809 resource. 1811 A UA may dereference a URI, thus loading a representation of the 1812 resource the URI identifies. UAs label resource representations 1813 with their origins, which are derived from their URIs. 1815 The SOP refers to a collection of principles, implemented within 1816 UAs, governing the isolation of and communication between resource 1817 representations within the UA, as well as resource 1818 representations' access to network resources. 1820 In summary, although both HSTS Policy and SOP are enforced by UAs, 1821 HSTS Policy is optionally declared by hosts and is not origin-based, 1822 while the SOP applies to all resource representations loaded from all 1823 hosts by conformant UAs. 1825 Appendix C. Acknowledgments 1827 The authors thank Devdatta Akhawe, Michael Barrett, Tobias Gondrom, 1828 Paul Hoffman, Murray Kucherawy, Barry Leiba, James Manger, Alexey 1829 Melnikov, Haevard Molland, Yoav Nir, Yngve N. Pettersen, Laksh 1830 Raghavan, Marsh Ray, Julian Reschke, Tom Ritter, Peter Saint-Andre, 1831 Sid Stamm, Maciej Stachowiak, Andy Steingrubl, Brandon Sterne, Martin 1832 Thomson, Daniel Veditz, as well as all the websec working group 1833 participants and others for their various reviews and helpful 1834 contributions. 1836 Thanks to Julian Reschke for his elegant re-writing of the effective 1837 request URI text, which he did when incorporating the ERU notion into 1838 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 1839 from Julian's work in [I-D.draft-ietf-httpbis-p1-messaging-17] and 1840 adapted to the [RFC2616] ABNF. 1842 Appendix D. Change Log 1844 [RFCEditor: please remove this section upon publication as an RFC.] 1845 Changes are grouped by spec revision listed in reverse issuance 1846 order. 1848 D.1. For draft-ietf-websec-strict-transport-sec 1850 Changes from -09 to -10: 1852 1. Added "(including when following HTTP redirects [RFC2616])" to 1853 section 8.3. This addresses issue ticket #47. 1854 1856 2. Fixed max-age value in section 10.1. Substituted 7776000 1857 (actually 90 days) for 778000 (only 9 days). This addresses 1858 issue ticket #48. 1859 1861 3. Added mention of "Certificate Status Request" TLS extension 1862 [RFC6066] aka "OCSP stapling" to example in section 10.3. 1863 This addresses issue ticket #49. 1864 1866 Changes from -08 to -09: 1868 1. Added IESG Note to Section 3 "Conformance Criteria" per Barry 1869 Leiba's suggestion on the mailing list. 1872 2. Added additional requirement #5 to requirements for STS header 1873 field directives in Section 6.1 per Alexey's review. This 1874 completes the addressing of issue ticket #45. 1875 1877 3. Addressed editorial feedback in Murray's AppsDir review of 1878 -06. 1880 Most all of these changes were addressing detailed/small 1881 editorial items, however note the addition of a couple of 1882 introductory paragraphs in the Security Considerations 1883 section, as well as a re-written and expanded Section 14.6 1884 "Bogus Root CA Certificate Phish plus DNS Cache Poisoning 1885 Attack", as well the new item #5 to Appendix A "Design 1886 Decision Notes". 1888 This addresses issue ticket #46. 1889 1891 Changes from -07 to -08: 1893 1. Clarified requirement #4 for STS header field directives in 1894 Section 6.1, and removed "(which "update" this 1895 specification)". Also added explicit "max-age=0" to Section 1896 6.1.1. Reworked final sentence in 2nd para of Section 13. 1897 This addresses issue ticket #45. 1898 1900 Changes from -06 to -07: 1902 1. Various minor/modest editorial tweaks throughout as I went 1903 through it pursuing the below issue tickets. Viewing a visual 1904 diff against -06 revision recommended. 1906 2. fixed some minor editorial issues noted in review by Alexey, 1907 fixes noted in here: 1910 3. Addressed ABNF exposition issues, specifically inclusion of 1911 quoted-string syntax for directive values. Fix STS header 1912 ABNF such that a leading ";" isn't required. Add example of 1913 quoted-string-encoded max-age-value. This addresses (re- 1914 opened) issue ticket #33. 1915 1917 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm 1918 and resultant HSTS Policy application is more clear, and that 1919 it is explicitly stipulated to not muck with attributes of 1920 superdomain matching Known HSTS Hosts. This addresses issue 1921 ticket #37. 1922 1924 5. Added reference to [I-D.ietf-dane-protocol], pared back 1925 extraneous discussion in section 2.2, and updated discussion 1926 in 10.2 to accomodate TLSA (nee DANE). This addresses issue 1927 ticket #39. 1928 1930 6. Addressed various editorial items from issue ticket #40. 1931 1933 7. Loosened up the language regarding redirecting "http" requests 1934 to "https" in section 7.2 such that future flavors of 1935 permanent redirects are accommodated. This addresses issue 1936 ticket #43. 1937 1939 8. Reworked the terminology and language in Section 9, in 1940 particular defining the term "putative domain name string" to 1941 replace "valid Unicode-encoded string-serialized domain name". 1942 This addresses issue ticket #44. 1943 1945 Changes from -05 to -06: 1947 1. Addressed various editorial comments provided by Tobias G. 1948 This addresses issue ticket #38. 1949 1951 Changes from -04 to -05: 1953 1. Fixed up references to move certain ones back to the normative 1954 section -- as requested by Alexey M. Added explanation for 1955 referencing obsoleted [RFC3490] and [RFC3492]. This addresses 1956 issue ticket #36. 1957 1959 2. Made minor change to Strict-Transport-Security header field 1960 ABNF in order to address further feedback as appended to 1961 ticket #33. This addresses issue ticket #33. 1962 1964 Changes from -03 to -04: 1966 1. Clarified that max-age=0 will cause UA to forget a known HSTS 1967 Host, and more generally clarified that the "freshest" info 1968 from the HSTS Host is cached, and thus HSTS Hosts are able to 1969 alter the cached max-age in UAs. This addresses issue ticket 1970 #13. 1972 2. Updated section on "Constructing an Effective Request URI" to 1973 remove remaining reference to RFC3986 and reference RFC2616 1974 instead. Further addresses issue ticket #14. 1975 1977 3. Addresses further ABNF issues noted in comment:1 of issue 1978 ticket #27. 1981 4. Reworked the introduction to clarify the denotation of "HSTS 1982 Policy" and added the new Appendix B summarizing the primary 1983 characteristics of HSTS Policy and Same-Origin Policy, and 1984 identifying their differences. Added ref to [RFC4732]. This 1985 addresses issue ticket #28. 1986 1988 5. Reworked language in Section 2.3.1.3. wrt "mixed content", 1989 more clearly explain such vulnerability, disambiguate "mixed 1990 content" in web security context from its usage in markup 1991 language context. This addresses issue ticket #29. 1992 1994 6. Expanded Denial of Service discussion in Security 1995 Considerations. Added refs to [RFC4732] and [CWE-113]. This 1996 addresses issue ticket #30. 1997 1999 7. Mentioned in prose the case-insensitivity of directive names. 2000 This addresses issue ticket #31. 2001 2003 8. Added Section 10.3 "Implications of includeSubDomains". This 2004 addresses issue ticket #32. 2005 2007 9. Further refines text and ABNF definitions of STS header field 2008 directives. Retains use of quoted-string in directive 2009 grammar. This addresses issue ticket #33. 2010 2012 10. Added Section 14.7 "Creative Manipulation of HSTS Policy 2013 Store", including reference to [WebTracking]. This addresses 2014 issue ticket #34. 2015 2017 11. Added Section 14.1 "Ramifications of HSTS Policy 2018 Establishment only over Error-free Secure Transport" and made 2019 some accompanying editorial fixes in some other sections. 2020 This addresses issue ticket #35. 2021 2023 12. Refined references. Cleaned out un-used ones, updated to 2024 latest RFCs for others, consigned many to Informational. 2025 This addresses issue ticket #36. 2026 2028 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" 2029 section. 2031 Changes from -02 to -03: 2033 1. Updated section on "Constructing an Effective Request URI" to 2034 remove references to RFC3986. Addresses issue ticket #14. 2035 2037 2. Reference RFC5890 for IDNA, retaining subordinate refs to 2038 RFC3490. Updated IDNA-specific language, e.g. domain name 2039 canonicalization and IDNA dependencies. Addresses issue 2040 ticket #26 2041 . 2043 3. Completely re-wrote the STS header ABNF to be fully based on 2044 RFC2616, rather than a hybrid of RFC2616 and httpbis. 2045 Addresses issue ticket #27 2046 . 2048 Changes from -01 to -02: 2050 1. Updated Section 8.3 "URI Loading and Port Mapping" fairly 2051 thoroughly in terms of refining the presentation of the 2052 steps, and to ensure the various aspects of port mapping are 2053 clear. Nominally fixes issue ticket #1 2054 2056 2. Removed dependencies on 2057 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 2058 ABNF in Section 6.1 "Strict-Transport-Security HTTP Response 2059 Header Field" by lifting some productions entirely from 2060 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 2061 [RFC2616]. Addresses issue ticket #2 2062 . 2064 3. Updated Effective Request URI section and definition to use 2065 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 2066 ABNF from [RFC2616]. Fixes issue ticket #3 2067 . 2069 4. Added explicit mention that the HSTS Policy applies to all 2070 TCP ports of a host advertising the HSTS Policy. Nominally 2071 fixes issue ticket #4 2072 2074 5. Clarified the need for the "includeSubDomains" directive, 2075 e.g. to protect Secure-flagged domain cookies. In 2076 Section 14.2 "The Need for includeSubDomains". Nominally 2077 fixes issue ticket #5 2078 2080 6. Cited Firesheep as real-live threat in Section 2.3.1.1 2081 "Passive Network Attackers". Nominally fixes issue ticket #6 2082 . 2084 7. Added text to Section 11 "User Agent Implementation Advice" 2085 justifying connection termination due to tls warnings/errors. 2086 Nominally fixes issue ticket #7 2087 . 2089 8. Added new subsection Section 8.6 "Missing Strict-Transport- 2090 Security Response Header Field". Nominally fixes issue 2091 ticket #8 2092 . 2094 9. Added text to Section 8.4 "Errors in Secure Transport 2095 Establishment" explicitly note revocation check failures as 2096 errors causing connection termination. Added references to 2097 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 2098 . 2100 10. Added a sentence, noting that distributing specific end- 2101 entity certificates to browsers will also work for self- 2102 signed/private-CA cases, to Section 10 "Server Implementation 2103 and Deployment Advice" Nominally fixes issue ticket #10 2104 . 2106 11. Moved "with no user recourse" language from Section 8.4 2107 "Errors in Secure Transport Establishment" to Section 11 2108 "User Agent Implementation Advice". This nominally fixes 2109 issue ticket #11 2110 . 2112 12. Removed any and all dependencies on 2113 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 2114 on [RFC2616] only. Fixes issue ticket #12 2115 . 2117 13. Removed the inline "XXX1" issue because no one had commented 2118 on it and it seems reasonable to suggest as a SHOULD that web 2119 apps should redirect incoming insecure connections to secure 2120 connections. 2122 14. Removed the inline "XXX2" issue because it was simply for 2123 raising consciousness about having some means for 2124 distributing secure web application metadata. 2126 15. Removed "TODO1" because description prose for "max-age" in 2127 the Note following the ABNF in Section 6 seems to be fine. 2129 16. Decided for "TODO2" that "the first STS header field wins". 2130 TODO2 had read: "Decide UA behavior in face of encountering 2131 multiple HSTS headers in a message. Use first header? 2132 Last?". Removed TODO2. 2134 17. Added Section 1.1 "Organization of this specification" for 2135 readers' convenience. 2137 18. Moved design decision notes to be a proper appendix 2138 Appendix A. 2140 Changes from -00 to -01: 2142 1. Changed the "URI Loading" section to be "URI Loading and Port 2143 Mapping". 2145 2. [HASMAT] reference changed to [WEBSEC]. 2147 3. Changed "server" -> "host" where applicable, notably when 2148 discussing "HSTS Hosts". Left as "server" when discussing 2149 e.g. "http server"s. 2151 4. Fixed minor editorial nits. 2153 Changes from draft-hodges-strict-transport-sec-02 to 2154 draft-ietf-websec-strict-transport-sec-00: 2156 1. Altered spec metadata (e.g. filename, date) in order to submit 2157 as a WebSec working group Internet-Draft. 2159 D.2. For draft-hodges-strict-transport-sec 2161 Changes from -01 to -02: 2163 1. updated abstract such that means for expressing HSTS Policy 2164 other than via HSTS header field is noted. 2166 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 2167 from "Strict Transport Security". Updated use of "STS" 2168 acronym throughout spec to HSTS (except for when specifically 2169 discussing syntax of Strict-Transport-Security HTTP Response 2170 Header field), updated "Terminology" appropriately. 2172 3. Updated the discussion of "Passive Network Attackers" to be 2173 more precise and offered references. 2175 4. Removed para on nomative/non-normative from "Conformance 2176 Criteria" pending polishing said section to IETF RFC norms. 2178 5. Added examples subsection to "Syntax" section. 2180 6. Added OWS to maxAge production in Strict-Transport-Security 2181 ABNF. 2183 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 2184 Secure-Transport Request Type" section, folded 3d para into 2185 "Note:", added conformance clauses to the latter. 2187 8. Added exaplanatory "Note:" and reference to "HTTP Request 2188 Type" section. Added "XXX1" issue. 2190 9. Added conformance clause to "URI Loading". 2192 10. Moved "Notes for STS Server implementers:" from "UA 2193 Implementation dvice " to "HSTS Policy expiration time 2194 considerations:" in "Server Implementation Advice", and also 2195 noted another option. 2197 11. Added cautionary "Note:" to "Ability to delete UA's cached 2198 HSTS Policy on a per HSTS Server basis". 2200 12. Added some informative references. 2202 13. Various minor editorial fixes. 2204 Changes from -00 to -01: 2206 1. Added reference to HASMAT mailing list and request that this 2207 spec be discussed there. 2209 Authors' Addresses 2211 Jeff Hodges 2212 PayPal 2213 2211 North First Street 2214 San Jose, California 95131 2215 US 2217 Email: Jeff.Hodges@PayPal.com 2219 Collin Jackson 2220 Carnegie Mellon University 2222 Email: collin.jackson@sv.cmu.edu 2223 Adam Barth 2224 Google, Inc. 2226 Email: ietf@adambarth.com 2227 URI: http://www.adambarth.com/