2. Overview

This section discusses use cases, summarizes the HSTS Policy, and continues with a discussion of the threat model, unaddressed threats, and derived requirements.

2.1 Use Cases

The high-level use case is a combination of:

• Web browser users who wish to interact with various web sites (some arbitrary, some known) in a secure fashion.

• Web site deployers who wish to offer their sites in a maximally secure fashion, both for themselves and their users.

2.2 HTTP Strict Transport Security Policy Effects

The effects of the HSTS Policy, when applied in the interactions of conformant UAs with a web resource's host that implements such policy (an HSTS Host), are summarized as follows:

1. UAs transform insecure URI references to an HSTS Host into secure URI references before dereferencing them.

2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings.

2.3 Threat Model

HSTS is concerned with three classes of threat: passive network attackers, active network attackers, and imperfect web developers. However, it is explicitly not a remedy for two other classes of threat: phishing and malware. The addressed and unaddressed threats are briefly discussed below.

Readers may wish to refer to Section 2 of [ForceHTTPS] for details and references.

2.3.1 Threats Addressed

2.3.1.1 Passive Network Attackers

When a user browses the web on a local wireless network (e.g., an 802.11-based wireless local area network), a nearby attacker can possibly eavesdrop on the user's unencrypted Internet-Protocol-based connections, such as HTTP, regardless of whether or not the local wireless network itself is secured [BeckTews09]. Freely available wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive eavesdropping attacks, even if the local wireless network is operating in a secure fashion. A passive network attacker using such tools can steal session identifiers/cookies and hijack the user's web session by obtaining cookies containing authentication credentials [ForceHTTPS]. For example, there exist widely available tools, such as Firesheep (a web browser extension) [Firesheep], that enable their wielders to obtain the session cookies of other local users for various web applications.

To mitigate such threats, some web sites support (but usually do not enforce) access using end-to-end secure transport -- e.g., signaled through URIs constructed with the "https" scheme [RFC2818]. This can lead users to assume that accessing such services using secure transport protects them from passive network attackers. Unfortunately, this is often not the case in practice, because session identifiers are often stored in non-Secure cookies to permit interoperation with versions of services offered over insecure transport (a "Secure cookie" is a cookie containing the "Secure" attribute [RFC6265]). For example, if a web site (such as an email service) stores a session identifier in a non-Secure cookie, it permits an attacker to hijack the user's session if the user's UA makes a single insecure HTTP request to the site.

2.3.1.2 Active Network Attackers

A determined attacker can mount an active attack, either by impersonating a user's DNS server or, on a wireless network, by spoofing network frames or providing a similarly named evil twin access point. If the user is behind a wireless home router, an attacker can attempt to reconfigure the router using default passwords and other vulnerabilities. Some web sites, such as banks, rely upon end-to-end secure transport to protect themselves and their users from such active attackers. Unfortunately, browsers allow their users to easily opt out of these protections in order to be usable for sites that deploy secure transport in an incorrect manner, such as by generating and self-signing their own certificates (rather than also having their Certification Authority (CA) certificate distributed to their users' browsers).

2.3.1.3 Web Site Development and Deployment Bugs

The security of an otherwise uniformly secure site (i.e., one whose content is all materialized via "https" URIs) can be compromised completely by an active attacker exploiting a simple mistake, such as the loading of a cascading style sheet or SWF (Shockwave Flash) movie over an insecure connection (both cascading style sheets and SWF movies can script the embedding page, a fact that surprises many web developers, and, in addition, some browsers do not issue a so-called "mixed content warning" when SWF files are embedded via insecure connections). Even if a site's developers carefully scrutinize their login page for "mixed content", a single insecure embedding anywhere on the entire web site compromises the security of their login page because an attacker can script (i.e., control) the login page by injecting code (e.g., script) into another, insecurely-loaded, site page.

NOTE: The term "Mixed content" used above (also see Section 5.3 of [W3C.REC-wsc-ui-20100812]) refers to the notion labeled as "mixed security context" in this specification and should not be confused with the same "mixed content" term as used in the context of markup languages such as XML and HTML.

2.3.2 Threats Not Addressed

2.3.2.1 Phishing

Phishing attacks occur when an attacker solicits authentication credentials from the user by hosting a fake web site on a domain distinct from the real web site, perhaps driving traffic to the fake site by sending a link in email. Phishing attacks can be very effective because users find it difficult to distinguish real web sites from fake web sites. HSTS is not a defense against phishing per se; rather, it complements many existing phishing defenses by instructing the browser to protect session integrity and long-lived authentication tokens [ForceHTTPS].

2.3.2.2 Malware and Browser Vulnerabilities

Because HSTS is implemented as a browser security mechanism, it relies upon the trustworthiness of the user's system to protect sessions. Malicious code executing on the user's system can compromise browsing sessions, with or without HSTS.

2.4 Requirements

This section identifies and enumerates various requirements derived from the above use cases and threats, and lists both the detailed core requirements that HTTP Strict Transport Security addresses as well as ancillary requirements that are not directly addressed.

2.4.1 Overall Requirement

• Minimize risk to web browser users and web site deployers arising from passive and active network attackers, web site development and deployment bugs, and insecure user actions.

2.4.1.1 Detailed Core Requirements

These core requirements derive from the overall requirement and are addressed in this specification.

1. Web sites need to be able to declare to UAs that they should be accessed using a strict security policy.

2. Web sites need to be able to instruct UAs that contact them insecurely to do so securely.

3. UAs need to retain persistent data about web sites that signal strict security policy enablement, for time spans declared by the web sites. Additionally, UAs need to cache "fresh" strict security policy information to allow web sites to update it.

4. UAs need to rewrite all insecure UA "http" URI loads to use the "https" secure scheme for web sites with strict security policy enabled.

5. Web site administrators need to be able to signal strict security policy application to subdomains of higher-level domains for which strict security policy is enabled, and UAs need to enforce such policy.

   For example, both example.com and foo.example.com can set policy for bar.foo.example.com.

6. UAs need to disallow security policy application by domains with strict security policy enabled to peer domains and/or higher-level domains.

   For example, neither bar.foo.example.com nor foo.example.com can set policy for example.com, and bar.foo.example.com cannot set policy for foo.example.com. Additionally, foo.example.com cannot set policy for sibling.example.com.

7. UAs need to prevent users from "clicking through" security warnings. Halting connection attempts in the face of secure transport exceptions is acceptable. See also Section 12.1, "No User Recourse".

NOTE: This specification does not address in particular how to uniformly secure first contact to satisfy the above first core requirement (see Section 14.6, "Bootstrap MITM Vulnerability"). It may be addressed in future revisions of this specification or in some other specification. Also note that there are some ways by which UA implementations can more fully address the first core requirement; see Section 12, "User Agent Implementation Advice".

2.4.1.2 Detailed Ancillary Requirements

These ancillary requirements also derive from the overall requirement. They are not normatively addressed in this specification but could be satisfied by UA implementations at the implementor's discretion, although satisfying them may be complex.

1. Disallow "mixed security context" loads (see Section 2.3.1.3).

2. Facilitate user declaration of web sites with strict security policy enabled, regardless of whether or not the site signals HSTS Policy.