原文 https://tools.ietf.org/html/rfc6797

警告，文章很枯燥，也没什么内容
大体意思就是服务器和客户端都遵循一些行为模式，
在服务器端是声明自己是HSTS
在客户端有一个声明HSTS的检查列表
大家通过HSTS交互，一句话就是能转https的就把http转https，如果发现任何问题就报错，中断链接等等

编号及提出者

Internet Engineering Task Force (IETF) Request for Comments: 6797
Category: Standards Track
ISSN: 2070-1721
J. Hodges PayPal C. Jackson Carnegie Mellon University A. Barth

摘要

Abstract
HTTP Strict Transport Security (HSTS)
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.

描述了一个只通过安全链接的上网机制
接下来是一些版权信息和目录，跳过

1.简介

HTTP [RFC2616] may be used over various transports, typically the Transmission Control Protocol (TCP). However, TCP does not provide channel integrity protection, confidentiality, or secure host identification. Thus, the Secure Sockets Layer (SSL) protocol [RFC6101] and its successor, Transport Layer Security (TLS) [RFC5246] were developed in order to provide channel-oriented security and are typically layered between application protocols and TCP. [RFC2818] specifies how HTTP is layered onto TLS and defines the Uniform Resource Identifier (URI) scheme of "https" (in practice, however, HTTP user agents (UAs) typically use either TLS or SSL3, depending upon a combination of negotiation with the server and user preferences).

意思是说https（属于应用层）是在tcp（属于传输层）上为了解决信息完整，信息机密，身份认证问题的协议。
ps: UAS, user agents 指的是用户上网的身份，包含浏览器，系统等一些附加信息

UAs employ various local security policies with respect to the characteristics of their interactions with web resources, depending on (in part) whether they are communicating with a given web resource’s host using HTTP or HTTP-over-Secure-Transport. For example, cookies ([RFC6265]) may be flagged as Secure. UAs are to send such Secure cookies to their addressed host only over a secure transport. This is in contrast to non-Secure cookies, which are returned to the host regardless of transport (although subject to other rules).

UAs行为多种多样，举了个cookies的例子

UAs typically announce to their users any issues with secure connection establishment, such as being unable to validate a TLS server certificate trust chain, or if a TLS server certificate is expired, or if a TLS host’s domain name appears incorrectly in the TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs enable users to elect to continue to interact with a web resource’s host in the face of such issues. This behavior is sometimes referred to as "click(ing) through" security [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09]; thus, it can be described as "click-through insecurity".

UAs 回提示一些安全问题，比如网站证书过期，或者网站域名和证书里记载的对不上。这时候会通知用户，不过用户可以选择继续访问，这个问题叫做 click-through insecurity 继续点击产生的不安全

A key vulnerability enabled by click-through insecurity is the leaking of any cookies the web resource may be using to manage a user’s session. The threat here is that an attacker could obtain the cookies and then interact with the legitimate web resource while impersonating the user.

这种行为的最大的问题是泄露了cookies，从而使得攻击者有可能伪造用户身份去访问互联网资源

Jackson and Barth proposed an approach, in [ForceHTTPS], to enable web resources to declare that any interactions by UAs with the web resource must be conducted securely and that any issues with establishing a secure transport session are to be treated as fatal and without direct user recourse. The aim is to prevent click- through insecurity and address other potential threats.

Jackson和Barth提出了ForceHTTPS，意思就是任何不对劲就不让继续访问，防止了click-through insecurity

This specification embodies and refines the approach proposed in [ForceHTTPS]. For example, rather than using a cookie to convey policy from a web resource’s host to a UA, it defines an HTTP response header field for this purpose. Additionally, a web resource’s host may declare its policy to apply to the entire domain name subtree rooted at its host name. This enables HTTP Strict Transport Security (HSTS) to protect so-called "domain cookies", which are applied to all subdomains of a given web resource’s host name.

在这里实现并改进了ForceHTTPS，改进点包括使用HTTP响应头的数据来完成cookie的工作。另外，网站可以声明域名树，把策略用于所有子域名，这个东西叫 domain cookie

This specification also incorporates notions from [JacksonBarth2008] in that policy is applied on an "entire-host" basis: it applies to HTTP (only) over any TCP port of the issuing host.
Note that the policy defined by this specification is distinctly different than the "same-origin policy" defined in "The Web Origin Concept" [RFC6454]. These differences are summarized in Appendix B.

说HSTS使用了不太一样的策略，和同源策略（same-origin policy）有出入，见附录B

2.综述

开头几个小节没什么内容，略过

2.3 威胁模型

HSTS is concerned with three threat classes: passive network attackers, active network attackers, and imperfect web developers. However, it is explicitly not a remedy for two other classes of threats: phishing and malware. Threats that are addressed, as well as threats that are not addressed, are briefly discussed below.
Readers may wish to refer to Section 2 of [ForceHTTPS] for details as well as relevant citations.

HSTS关注三类安全问题，被动网络攻击，主动网络攻击和网络应用不完善，并不解决网络钓鱼和恶意软件的问题。

2.3.1.1 被动网络攻击

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(s) by obtaining cookies containing authentication credentials
[ForceHTTPS]. For example, there exist widely available tools, such
as Firesheep (a web browser extension) [Firesheep], that enable their
wielder to obtain other local users’ session cookies for various web
applications.

在本地无线网的用户有可能被攻击者监听未加密的网络链接，比如http，有一系列工具可供攻击者使用

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

为了缓和攻击，一些网站采用了https，但是在部署的时候经常会把包含session信息保存在不安全的cookies中

2.3.1.2 主动网络攻击

A determined attacker can mount an active attack, either by
impersonating a user’s DNS server or, in a wireless network, by
spoofing network frames or offering 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 sites, such as banks, rely
on 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 incorrectly deploy secure transport, for example by
generating and self-signing their own certificates (without also
distributing their certification authority (CA) certificate to their
users’ browsers).

列举了个主动攻击的方法

2.3.1.3 网站部署和bug

The security of an otherwise uniformly secure site (i.e., all of its
content is 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 a SWF (Shockwave Flash)
movie over an insecure connection (both cascading style sheets and
SWF movies can script the embedding page, to the surprise of many web
developers, plus some browsers do not issue so-called "mixed content
warnings" when SWF files are embedded via insecure connections).
Even if the site’s developers carefully scrutinize their login page
for "mixed content", a single insecure embedding anywhere on the
overall site compromises the security of their login page because an
attacker can script (i.e., control) the login page by injecting code
(e.g., a script) into another, insecurely loaded, site page.

如果网站的部署者不小心，为css或者swf提供了不安全链接的加载，攻击者可以在其中安插脚本

2.3.2 不在解决范围的问题

网络钓鱼

Phishing attacks occur when an attacker solicits authentication
credentials from the user by hosting a fake site located on a
different domain than the real site, perhaps driving traffic to the
fake site by sending a link in an email message. Phishing attacks
can be very effective because users find it difficult to distinguish
the real site from a fake site. 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].

HSTS不解决这个问题，依赖于浏览器去识别

恶意软件和浏览器缺陷

Because HSTS is implemented as a browser security mechanism, it
relies on the trustworthiness of the user’s system to protect the
session. Malicious code executing on the user’s system can
compromise a browser session, regardless of whether HSTS is used.

也不解决这个问题，因为不在一个层面上

2.4 前提条件（实施HSTS的）

核心要求

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

网站需要能告知UAs，必须使用严格安全策略

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

网站应该安全地给出用户“不安全上网”的指示（比较迷惑）

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 the "freshest" strict
security policy information, in order to allow web sites to
update the information.

UAs应该保存一个关于实施了严格安全策略的网站的列表，并能更新

UAs need to rewrite all insecure UA "http" URI loads to use the
"https" secure scheme for those web sites for which secure policy
is enabled.

4.UAs应该把http请求重写为https请求（针对执行严格安全策略的网站）

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 could set
policy for bar.foo.example.com.

网站应该对次级域名同样使用严格安全策略，UAs应该强化这种行为，例如
example.com 或 foo.example.com 应该能对 bar.foo.example.com 同样实施严格安全策略

UAs need to disallow security policy application to peer domains,
and/or higher-level domains, by domains for which strict security
policy is enabled.
For example, neither bar.foo.example.com nor foo.example.com can
set policy for example.com, nor can bar.foo.example.com set
policy for foo.example.com. Also, foo.example.com cannot set
policy for sibling.example.com.

6.UAs不应该用于对等（或上级和平级）域名实施安全策略，比如bar.foo.example.com或foo.example.com不能对example.com实施安全策略，另外，foo.example.com也不能对sibling.example.com实施安全策略

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").

UAs应该防止用户clicking through，终止链接也是可取的

额外要求

Disallow "mixed security context" loads

不允许混合安全内容加载

Facilitate user declaration of web sites for which strict
security policy is enabled, regardless of whether the sites
signal HSTS Policy.

教育用户

3. 一致性标准

A conformant host is one that implements all the requirements listed
in this specification that are applicable to hosts.
A conformant user agent is one that implements all the requirements
listed in this specification that are applicable to user agents.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

意思就是网站和客户端都得完全实现列出的条件

4. 术语，略过

5. HSTS原理综述

5.1 声明为HSTS网站

An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS
Policy, which is represented by and conveyed via the
Strict-Transport-Security HTTP response header field over secure
transport (e.g., TLS). Upon error-free receipt and processing of
this header by a conformant UA, the UA regards the host as a Known
HSTS Host.

通过HTSTS响应头部区域来声明

5.2 HSTS策略

An HSTS Policy directs UAs to communicate with a Known HSTS Host only
over secure transport and specifies policy retention time duration.
HSTS Policy explicitly overrides the UA processing of URI references,
user input (e.g., via the "location bar"), or other information that,
in the absence of HSTS Policy, might otherwise cause UAs to
communicate insecurely with the Known HSTS Host.
An HSTS Policy may contain an optional directive -- includeSubDomains
-- specifying that this HSTS Policy also applies to any hosts whose
domain names are subdomains of the Known HSTS Host’s domain name.

HSTS策略指引UAs只通过HSTS策略的方式和网站进行交互，改变UAs的行为，同样对次级域名产生作用

5.3 HSTS策略在UAs的存储和维护

UAs store and index HSTS Policies based strictly upon the domain
names of the issuing HSTS Hosts.
This means that UAs will maintain the HSTS Policy of any given HSTS
Host separately from any HSTS Policies issued by any other HSTS Hosts
whose domain names are superdomains or subdomains of the given HSTS
Host’s domain name. Only the given HSTS Host can update or can cause
deletion of its issued HSTS Policy. It accomplishes this by sending
Strict-Transport-Security HTTP response header fields to UAs with new
values for policy time duration and subdomain applicability. Thus,
UAs cache the "freshest" HSTS Policy information on behalf of an HSTS
Host. Specifying a zero time duration signals the UA to delete the
HSTS Policy (including any asserted includeSubDomains directive) for
that HSTS Host. See Section 8.1 ("Strict-Transport-Security Response
Header Field Processing") for details. Additionally, Section 6.2
presents examples of Strict-Transport-Security HTTP response header
fields.

一些细节

5.4 UAs对HSTS的执行

When establishing an HTTP connection to a given host, however
instigated, the UA examines its cache of Known HSTS Hosts to see if
there are any with domain names that are superdomains of the given
host’s domain name. If any are found, and of those if any have the
includeSubDomains directive asserted, then HSTS Policy applies to the
given host. Otherwise, HSTS Policy applies to the given host only if
the given host is itself known to the UA as an HSTS Host. See
Section 8.3 ("URI Loading and Port Mapping") for details.

检查一下和自己进行链接的网站的域名的上级域名是否在UAs的列表中，如果是，那么认为次级域名也是HSTS的

6. 语法

This section defines the syntax of the Strict-Transport-Security HTTP
response header field and its directives, and presents some examples.
Section 7 ("Server Processing Model") then details how hosts employ
this header field to declare their HSTS Policy, and Section 8 ("User
Agent Processing Model") details how user agents process the header
field and apply the HSTS Policy.

这节开始讲语法

6.1 HSTS响应头

The Strict-Transport-Security HTTP response header field (STS header
field) indicates to a UA that it MUST enforce the HSTS Policy in
regards to the host emitting the response message containing this
header field.
The ABNF (Augmented Backus-Naur Form) syntax for the STS header field
is given below. It is based on the Generic Grammar defined in
Section 2 of [RFC2616] (which includes a notion of "implied linear
whitespace", also known as "implied *LWS").
Strict-Transport-Security = "Strict-Transport-Security" ":"
[ directive ] *( ";" [ directive ] )
directive = directive-name [ "=" directive-value ]
directive-name = token
directive-value = token | quoted-string
where:
token =
quoted-string =

一些语法的表达方式及变种

The two directives defined in this specification are described below.
The overall requirements for directives are:

The order of appearance of directives is not significant.

All directives MUST appear only once in an STS header field.
Directives are either optional or required, as stipulated in
their definitions.

Directive names are case-insensitive.

UAs MUST ignore any STS header field containing directives, or
other header field value data, that does not conform to the
syntax defined in this specification.

If an STS header field contains directive(s) not recognized by
the UA, the UA MUST ignore the unrecognized directives, and if
the STS header field otherwise satisfies the above requirements
(1 through 4), the UA MUST process the recognized directives.
Additional directives extending the semantic functionality of the STS
header field can be defined in other specifications, with a registry
(having an IANA policy definition of IETF Review [RFC5226]) defined
for them at such time.

一些细节，比如STS header field在响应头中顺序无关，大小写无关，只能出现一次等等

6.1.1 存活时间，就是UAs标记网站为HSTS网站的时间

6.1.2 是否包含次级域名（includeSubDomains）

6.2 一些例子

Strict-Transport-Security: max-age="31536000"
Strict-Transport-Security: max-age=0
Strict-Transport-Security: max-age=0; includeSubDomains

7 服务器处理模型

7.1响应HTTPS请求

When replying to an HTTP request that was conveyed over a secure
transport, an HSTS Host SHOULD include in its response message an STS
header field that MUST satisfy the grammar specified above in
Section 6.1 ("Strict-Transport-Security HTTP Response Header Field").
If an STS header field is included, the HSTS Host MUST include only
one such header field.
Establishing a given host as a Known HSTS Host, in the context of a
given UA, MAY be accomplished over HTTP, which is in turn running
over secure transport, by correctly returning (per this
specification) at least one valid STS header field to the UA. Other
mechanisms, such as a client-side pre-loaded Known HSTS Host list,
MAY also be used; e.g., see Section 12 ("User Agent Implementation
Advice").

意思就是响应带着STS header field来声明自己是HSTS网站

7.2 响应HTTP请求

If an HSTS Host receives an HTTP request message over a non-secure
transport, it SHOULD send an HTTP response message containing a
status code indicating a permanent redirect, such as status code 301
(Section 10.3.2 of [RFC2616]), and a Location header field value
containing either the HTTP request’s original Effective Request URI
(see Section 9 ("Constructing an Effective Request URI")) altered as
necessary to have a URI scheme of "https", or a URI generated
according to local policy with a URI scheme of "https".

意思就是要么报错301要么直接转成https

8 UAs处理模型

8.1 处理STS响应头部

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

一些细节，涉及标记网站为HSTS，更新缓存，存活时间和如果发现网站没有按策略行事就忽略STS头部的存在

以下几节都是在讲细节，通过名称就能看出在干什么

8.1.1 标记为HSTS网站

8.2 网站域名匹配（和以知HSTS列表对比s）

8.3 URI加载和端口映射

8.4 错误处理

8.5 忽略里面的STS设置

8.6 响应缺失STS

9 组装有效的请求URI

This section specifies how an HSTS Host must construct the Effective
Request URI for a received HTTP request.
HTTP requests often do not carry an absoluteURI for the target
resource; instead, the URI needs to be inferred from the Request-URI,
Host header field, and connection context ([RFC2616], Sections 3.2.1,
5.1.2, and 5.2). The result of this process is called the "effective
request URI (ERU)". The "target resource" is the resource identified
by the effective request URI.

意思就是一般情况下请求的URI要被推断为“有效的URI”（ERU），才能获取资源，这个小节就是讲如何组装的

9.1 ERU 基础定义

The first line of an HTTP request message, Request-Line, is specified
by the following ABNF from [RFC2616], Section 5.1:
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
The Request-URI, within the Request-Line, is specified by the
following ABNF from [RFC2616], Section 5.1.2:
Request-URI = "*" | absoluteURI | abs_path | authority
The Host request header field is specified by the following ABNF from
[RFC2616], Section 14.23:
Host = "Host" ":" host [ ":" port ]

其实就是域名+端口这样的形式

9.2 判定是否是ERU

If the Request-URI is an absoluteURI, then the effective request URI
is the Request-URI.
If the Request-URI uses the abs_path form or the asterisk form, and
the Host header field is present, then the effective request URI is
constructed by concatenating:
o the scheme name: "http" if the request was received over an
insecure TCP connection, or "https" when received over a TLS/
SSL-secured TCP connection, and
o the octet sequence "://", and
o the host, and the port (if present), from the Host header field,
and
o the Request-URI obtained from the Request-Line, unless the
Request-URI is just the asterisk "*".
If the Request-URI uses the abs_path form or the asterisk form, and
the Host header field is not present, then the effective request URI
is undefined.
Otherwise, when Request-URI uses the authority form, the effective
request URI is undefined.
Effective request URIs are compared using the rules described in
[RFC2616] Section 3.2.3, except that empty path components MUST NOT
be treated as equivalent to an absolute path of "/".