Internet Engineering Task Force (IETF) J. Hodges
Request for Comments: 6797 PayPal
Category: Standards Track C. Jackson
ISSN: 2070-1721 Carnegie Mellon University
A. Barth
Google, Inc.
November 2012
Internet Engineering Task Force (IETF) J. Hodges
Request for Comments: 6797 PayPal
Category: Standards Track C. Jackson
ISSN: 2070-1721 Carnegie Mellon University
A. Barth
Google, Inc.
November 2012
HTTP Strict Transport Security (HSTS)
HTTP严格传输安全（HSTS）
Abstract
摘要
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.
本规范定义了一种机制，使网站能够声明自己只能通过安全连接访问和/或用户能够指示其用户代理仅通过安全连接与给定网站交互。此总体策略称为HTTP严格传输安全性（HSTS）。网站通过严格传输安全HTTP响应头字段和/或其他方式（例如，用户代理配置）声明策略。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6797.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6797.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Organization of This Specification .........................6
1.2. Document Conventions .......................................6
2. Overview ........................................................6
2.1. Use Cases ..................................................6
2.2. HTTP Strict Transport Security Policy Effects ..............6
2.3. Threat Model ...............................................6
2.3.1. Threats Addressed ...................................7
2.3.1.1. Passive Network Attackers ..................7
2.3.1.2. Active Network Attackers ...................7
2.3.1.3. Web Site Development and Deployment Bugs ...8
2.3.2. Threats Not Addressed ...............................8
2.3.2.1. Phishing ...................................8
2.3.2.2. Malware and Browser Vulnerabilities ........8
2.4. Requirements ...............................................9
2.4.1. Overall Requirement .................................9
2.4.1.1. Detailed Core Requirements .................9
2.4.1.2. Detailed Ancillary Requirements ...........10
3. Conformance Criteria ...........................................10
4. Terminology ....................................................11
5. HSTS Mechanism Overview ........................................13
5.1. HSTS Host Declaration .....................................13
5.2. HSTS Policy ...............................................13
5.3. HSTS Policy Storage and Maintenance by User Agents ........14
5.4. User Agent HSTS Policy Enforcement ........................14
6. Syntax .........................................................14
6.1. Strict-Transport-Security HTTP Response Header Field ......15
6.1.1. The max-age Directive ..............................16
6.1.2. The includeSubDomains Directive ....................16
6.2. Examples ..................................................16
1. Introduction ....................................................4
1.1. Organization of This Specification .........................6
1.2. Document Conventions .......................................6
2. Overview ........................................................6
2.1. Use Cases ..................................................6
2.2. HTTP Strict Transport Security Policy Effects ..............6
2.3. Threat Model ...............................................6
2.3.1. Threats Addressed ...................................7
2.3.1.1. Passive Network Attackers ..................7
2.3.1.2. Active Network Attackers ...................7
2.3.1.3. Web Site Development and Deployment Bugs ...8
2.3.2. Threats Not Addressed ...............................8
2.3.2.1. Phishing ...................................8
2.3.2.2. Malware and Browser Vulnerabilities ........8
2.4. Requirements ...............................................9
2.4.1. Overall Requirement .................................9
2.4.1.1. Detailed Core Requirements .................9
2.4.1.2. Detailed Ancillary Requirements ...........10
3. Conformance Criteria ...........................................10
4. Terminology ....................................................11
5. HSTS Mechanism Overview ........................................13
5.1. HSTS Host Declaration .....................................13
5.2. HSTS Policy ...............................................13
5.3. HSTS Policy Storage and Maintenance by User Agents ........14
5.4. User Agent HSTS Policy Enforcement ........................14
6. Syntax .........................................................14
6.1. Strict-Transport-Security HTTP Response Header Field ......15
6.1.1. The max-age Directive ..............................16
6.1.2. The includeSubDomains Directive ....................16
6.2. Examples ..................................................16
7. Server Processing Model ........................................17
7.1. HTTP-over-Secure-Transport Request Type ...................17
7.2. HTTP Request Type .........................................18
8. User Agent Processing Model ....................................18
8.1. Strict-Transport-Security Response Header Field
Processing ................................................19
8.1.1. Noting an HSTS Host - Storage Model ................20
8.2. Known HSTS Host Domain Name Matching ......................20
8.3. URI Loading and Port Mapping ..............................21
8.4. Errors in Secure Transport Establishment ..................22
8.5. HTTP-Equiv <Meta> Element Attribute .......................22
8.6. Missing Strict-Transport-Security Response Header Field ...23
9. Constructing an Effective Request URI ..........................23
9.1. ERU Fundamental Definitions ...............................23
9.2. Determining the Effective Request URI .....................24
9.2.1. Effective Request URI Examples .....................24
10. Domain Name IDNA-Canonicalization .............................25
11. Server Implementation and Deployment Advice ...................26
11.1. Non-Conformant User Agent Considerations .................26
11.2. HSTS Policy Expiration Time Considerations ...............26
11.3. Using HSTS in Conjunction with Self-Signed Public-Key
Certificates .............................................27
11.4. Implications of includeSubDomains ........................28
11.4.1. Considerations for Offering Unsecured HTTP
Services at Alternate Ports or Subdomains of an
HSTS Host ........................................28
11.4.2. Considerations for Offering Web Applications at
Subdomains of an HSTS Host .......................29
12. User Agent Implementation Advice ..............................30
12.1. No User Recourse .........................................30
12.2. User-Declared HSTS Policy ................................30
12.3. HSTS Pre-Loaded List .....................................31
12.4. Disallow Mixed Security Context Loads ....................31
12.5. HSTS Policy Deletion .....................................31
13. Internationalized Domain Names for Applications (IDNA):
Dependency and Migration ......................................32
7. Server Processing Model ........................................17
7.1. HTTP-over-Secure-Transport Request Type ...................17
7.2. HTTP Request Type .........................................18
8. User Agent Processing Model ....................................18
8.1. Strict-Transport-Security Response Header Field
Processing ................................................19
8.1.1. Noting an HSTS Host - Storage Model ................20
8.2. Known HSTS Host Domain Name Matching ......................20
8.3. URI Loading and Port Mapping ..............................21
8.4. Errors in Secure Transport Establishment ..................22
8.5. HTTP-Equiv <Meta> Element Attribute .......................22
8.6. Missing Strict-Transport-Security Response Header Field ...23
9. Constructing an Effective Request URI ..........................23
9.1. ERU Fundamental Definitions ...............................23
9.2. Determining the Effective Request URI .....................24
9.2.1. Effective Request URI Examples .....................24
10. Domain Name IDNA-Canonicalization .............................25
11. Server Implementation and Deployment Advice ...................26
11.1. Non-Conformant User Agent Considerations .................26
11.2. HSTS Policy Expiration Time Considerations ...............26
11.3. Using HSTS in Conjunction with Self-Signed Public-Key
Certificates .............................................27
11.4. Implications of includeSubDomains ........................28
11.4.1. Considerations for Offering Unsecured HTTP
Services at Alternate Ports or Subdomains of an
HSTS Host ........................................28
11.4.2. Considerations for Offering Web Applications at
Subdomains of an HSTS Host .......................29
12. User Agent Implementation Advice ..............................30
12.1. No User Recourse .........................................30
12.2. User-Declared HSTS Policy ................................30
12.3. HSTS Pre-Loaded List .....................................31
12.4. Disallow Mixed Security Context Loads ....................31
12.5. HSTS Policy Deletion .....................................31
13. Internationalized Domain Names for Applications (IDNA):
Dependency and Migration ......................................32
14. Security Considerations .......................................32
14.1. Underlying Secure Transport Considerations ...............32
14.2. Non-Conformant User Agent Implications ...................33
14.3. Ramifications of HSTS Policy Establishment Only over
Error-Free Secure Transport ..............................33
14.4. The Need for includeSubDomains ...........................34
14.5. Denial of Service ........................................35
14.6. Bootstrap MITM Vulnerability .............................36
14.7. Network Time Attacks .....................................37
14.8. Bogus Root CA Certificate Phish plus DNS Cache
Poisoning Attack .........................................37
14.9. Creative Manipulation of HSTS Policy Store ...............37
14.10. Internationalized Domain Names ..........................38
15. IANA Considerations ...........................................39
16. References ....................................................39
16.1. Normative References .....................................39
16.2. Informative References ...................................40
Appendix A. Design Decision Notes .................................44
Appendix B. Differences between HSTS Policy and Same-Origin
Policy ................................................45
Appendix C. Acknowledgments .......................................46
14. Security Considerations .......................................32
14.1. Underlying Secure Transport Considerations ...............32
14.2. Non-Conformant User Agent Implications ...................33
14.3. Ramifications of HSTS Policy Establishment Only over
Error-Free Secure Transport ..............................33
14.4. The Need for includeSubDomains ...........................34
14.5. Denial of Service ........................................35
14.6. Bootstrap MITM Vulnerability .............................36
14.7. Network Time Attacks .....................................37
14.8. Bogus Root CA Certificate Phish plus DNS Cache
Poisoning Attack .........................................37
14.9. Creative Manipulation of HSTS Policy Store ...............37
14.10. Internationalized Domain Names ..........................38
15. IANA Considerations ...........................................39
16. References ....................................................39
16.1. Normative References .....................................39
16.2. Informative References ...................................40
Appendix A. Design Decision Notes .................................44
Appendix B. Differences between HSTS Policy and Same-Origin
Policy ................................................45
Appendix C. Acknowledgments .......................................46
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).
HTTP[RFC2616]可以在各种传输上使用，通常是传输控制协议（TCP）。但是，TCP不提供通道完整性保护、机密性或安全的主机标识。因此，安全套接字层（SSL）协议[RFC6101]及其后续协议传输层安全性（TLS）[RFC5246]是为了提供面向通道的安全性而开发的，通常在应用程序协议和TCP之间分层。[RFC2818]指定如何将HTTP分层到TLS上，并定义“https”的统一资源标识符（URI）方案（然而，在实践中，HTTP用户代理（UAs）通常使用TLS或SSL3，具体取决于与服务器的协商组合和用户首选项）。
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根据其与web资源交互的特征采用各种本地安全策略，这部分取决于它们是使用HTTP还是HTTP通过安全传输与给定web资源的主机通信。例如，Cookie（[RFC6265]）可能被标记为安全的。UAs只能通过安全传输将此类安全cookie发送到其寻址主机。这与非安全cookie相反，非安全cookie会返回到主机，而不考虑传输（尽管受其他规则的约束）。
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通常会向其用户宣布安全连接建立的任何问题，例如无法验证TLS服务器证书信任链，或者TLS服务器证书过期，或者TLS主机的域名在TLS服务器证书中出现错误（请参阅[RFC2818]第3.1节）。通常，UAs允许用户在遇到此类问题时选择继续与web资源的主机交互。这种行为有时被称为“通过”安全[GoodDhamijaEtAl05][SunshineEgelmanEtAl09]；因此，它可以被描述为“点击通过不安全”。
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.
点击不安全导致的一个关键漏洞是web资源用于管理用户会话的任何cookie泄漏。这里的威胁是攻击者可以获得cookies，然后在模拟用户的同时与合法的web资源进行交互。
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]中提出了一种方法，使web资源能够声明UAs与web资源的任何交互都必须安全地进行，并且与建立安全传输会话有关的任何问题都将被视为致命问题，用户无需直接追索。其目的是防止点击不安全并解决其他潜在威胁。
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]中提出的方法。例如，它没有使用cookie将策略从web资源的主机传送到UA，而是为此定义了HTTP响应头字段。此外，web资源的主机可以声明其策略以应用于以其主机名为根的整个域名子树。这使HTTP严格传输安全性（HSTS）能够保护所谓的“域cookie”，这些cookie应用于给定web资源主机名的所有子域。
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.
本规范还结合了[JacksonBarth2008]的概念，即在“整个主机”的基础上应用策略：它适用于通过发布主机的任何TCP端口的HTTP（仅）。
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.
请注意，本规范定义的策略与“Web源概念”[RFC6454]中定义的“同源策略”明显不同。附录B总结了这些差异。
This specification begins with an overview of the use cases, policy effects, threat models, and requirements for HSTS (in Section 2). Then, Section 3 defines conformance requirements. Section 4 defines terminology relevant to this document. The HSTS mechanism itself is formally specified in Sections 5 through 15.
本规范首先概述了HST的用例、策略影响、威胁模型和需求（第2节）。然后，第3节定义了一致性要求。第4节定义了与本文件相关的术语。第5节至第15节正式规定了HSTS机制本身。
NOTE: This is a note to the reader. These are points that should be expressly kept in mind and/or considered.
注：这是给读者的说明。这些是应明确记住和/或考虑的要点。
This section discusses the use cases, summarizes the HSTS Policy, and continues with a discussion of the threat model, non-addressed threats, and derived requirements.
本节讨论用例，总结HSTS策略，并继续讨论威胁模型、未解决的威胁和衍生需求。
The high-level use case is a combination of:
高级用例是以下各项的组合：
o Web browser user wishes to interact with various web sites (some arbitrary, some known) in a secure fashion.
o Web浏览器用户希望以安全的方式与各种网站（有些是任意的，有些是已知的）进行交互。
o Web site deployer wishes to offer their site in an explicitly secure fashion for their own, as well as their users', benefit.
o 网站部署人员希望以明确安全的方式为自己以及用户提供网站。
The effects of the HSTS Policy, as applied by a conformant UA in interactions with a web resource host wielding such policy (known as an HSTS Host), are summarized as follows:
合规UA在与使用该策略的web资源主机（称为HSTS主机）交互时应用的HSTS策略的影响总结如下：
1. UAs transform insecure URI references to an HSTS Host into secure URI references before dereferencing them.
1. UAs将对HSTS主机的不安全URI引用转换为安全URI引用，然后再解除引用。
2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings.
2. UA在出现任何和所有安全传输错误或警告时终止任何安全传输连接尝试。
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.
HSTS涉及三类威胁：被动网络攻击者、主动网络攻击者和不完善的web开发人员。然而，这显然不是对另外两类威胁的补救措施：网络钓鱼和恶意软件。下面简要讨论已解决的威胁以及未解决的威胁。
Readers may wish to refer to Section 2 of [ForceHTTPS] for details as well as relevant citations.
读者可能希望参考[ForceHTTPS]第2节了解详细信息以及相关引用。
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.
当用户在本地无线网络（例如，基于802.11的无线局域网）上浏览web时，附近的攻击者可能会窃听用户未加密的基于Internet协议的连接，如HTTP，而不管本地无线网络本身是否安全[BecketEW09]。免费提供的无线嗅探工具包（例如[Aircrack ng]）支持此类被动窃听攻击，即使本地无线网络以安全方式运行。使用此类工具的被动网络攻击者可以通过获取包含身份验证凭据[ForceHTTPS]的Cookie来窃取会话标识符/Cookie并劫持用户的web会话。例如，存在广泛可用的工具，如Firesheep（一种web浏览器扩展）[Firesheep]，使其使用者能够为各种web应用程序获取其他本地用户的会话cookie。
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”方案构造的URI发出信号[RFC2818]。这可能会让用户相信，使用安全传输访问此类服务可以保护他们免受被动网络攻击者的攻击。不幸的是，在实际部署中通常不是这样，因为会话标识符通常存储在非安全cookie中，以允许与通过不安全传输提供的服务版本进行互操作（“安全cookie”是指包含“安全”属性[RFC6265]的cookie）。例如，如果网站（比如电子邮件服务）的会话标识符存储在一个不安全的cookie中，那么如果用户的UA向该网站发出一个不安全的HTTP请求，攻击者就可以劫持用户的会话。
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
确定的攻击者可以通过模拟用户的DNS服务器或在无线网络中通过欺骗网络帧或提供类似名称的邪恶孪生接入点来发起主动攻击。如果用户位于无线家庭路由器后面，攻击者可以尝试使用默认密码和其他漏洞重新配置路由器。一些网站，如银行，依靠端到端安全传输来保护自己和用户免受此类主动攻击者的攻击。不幸的是，浏览器允许其用户轻松地选择退出这些保护，以便可用
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).
对于不正确部署安全传输的站点，例如，通过生成自己的证书并对其进行自签名（而不将其证书颁发机构（CA）证书分发给用户的浏览器）。
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.
如果主动攻击者利用一个简单的错误，例如在不安全的连接上加载级联样式表或SWF（Shockwave Flash）电影，则在其他方面统一安全的站点（即，其所有内容通过“https”URI具体化）的安全性可能会完全受损（级联样式表和SWF电影都可以编写嵌入页面的脚本，这让许多web开发人员感到惊讶，另外，当SWF文件通过不安全的连接嵌入时，一些浏览器不会发出所谓的“混合内容警告”）。即使网站开发人员仔细检查其登录页面的“混合内容”，在整个站点的任何位置嵌入一个不安全的内容都会危及其登录页面的安全性，因为攻击者可以通过将代码（例如脚本）注入另一个不安全加载的站点页面来编写（即控制）登录页面。
NOTE: "Mixed content" as used above (see also Section 5.3 in [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed security context" in this specification and should not be confused with the same "mixed content" term used in the context of markup languages such as XML and HTML.
注：上面使用的“混合内容”（另请参见[W3C.REC-wsc-ui-20100812]中的第5.3节）是指本规范中称为“混合安全上下文”的概念，不应与XML和HTML等标记语言上下文中使用的相同“混合内容”术语混淆。
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本身并不是针对网络钓鱼的防御；相反，它通过指示浏览器保护会话完整性和长寿命身份验证令牌[ForceHTTPS]，补充了许多现有的网络钓鱼防御。
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.
由于HSTS是作为浏览器安全机制实现的，因此它依赖于用户系统的可信度来保护会话。无论是否使用HST，在用户系统上执行的恶意代码都可能危害浏览器会话。
This section identifies and enumerates various requirements derived from the use cases and the threats discussed above and also lists the detailed core requirements that HTTP Strict Transport Security addresses, as well as ancillary requirements that are not directly addressed.
本节确定并列举了从上述用例和威胁中衍生出的各种需求，还列出了HTTP严格传输安全解决的详细核心需求，以及未直接解决的辅助需求。
o Minimize, for web browser users and web site deployers, the risks that are derived from passive and active network attackers, web site development and deployment bugs, and insecure user actions.
o 对于web浏览器用户和网站部署人员，最大限度地减少由被动和主动网络攻击者、网站开发和部署错误以及不安全的用户操作引起的风险。
These core requirements are derived from the overall requirement and are addressed by this specification.
这些核心需求源自总体需求，并由本规范解决。
1. Web sites need to be able to declare to UAs that they should be accessed using a strict security policy.
1. 网站需要能够向UAs声明应该使用严格的安全策略访问它们。
2. Web sites need to be able to instruct UAs that contact them insecurely to do so securely.
2. 网站需要能够指示不安全地联系它们的UAs安全地这样做。
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 the "freshest" strict security policy information, in order to allow web sites to update the information.
3. UAs需要在web站点声明的时间范围内保留有关web站点的永久数据，这些数据表示启用了严格的安全策略。此外，UAs需要缓存“最新”的严格安全策略信息，以便允许网站更新信息。
4. 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需要重写所有不安全的UA“http”URI加载，以便为启用安全策略的网站使用“https”安全方案。
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.
5. 网站管理员需要能够向启用了严格安全策略的更高级别域的子域发出严格安全策略应用的信号，UAs需要强制执行此类策略。
For example, both example.com and foo.example.com could set policy for bar.foo.example.com.
例如，example.com和foo.example.com都可以为bar.foo.example.com设置策略。
6. UAs need to disallow security policy application to peer domains, and/or higher-level domains, by domains for which strict security policy is enabled.
6. UAs需要根据启用严格安全策略的域，禁止将安全策略应用到对等域和/或更高级别的域。
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.
例如，bar.foo.example.com和foo.example.com都不能为example.com设置策略，bar.foo.example.com也不能为foo.example.com设置策略。此外，foo.example.com无法为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").
7. UAs需要防止用户“点击”安全警告。在安全传输异常情况下停止连接尝试是可以接受的。另见第12.1节（“无用户追索权”）。
NOTE: A means for uniformly securely meeting the first core requirement above is not specifically addressed by this specification (see Section 14.6 ("Bootstrap MITM Vulnerability")). It may be addressed by a future revision of this specification or some other specification. Note also that there are means by which UA implementations may more fully meet the first core requirement; see Section 12 ("User Agent Implementation Advice").
注：本规范未明确说明统一安全满足上述第一个核心要求的方法（见第14.6节（“引导MITM漏洞”）。可通过本规范或其他规范的未来版本解决。还请注意，UA实现有一些方法可以更充分地满足第一个核心需求；参见第12节（“用户代理实施建议”）。
These ancillary requirements are also derived from the overall requirement. They are not normatively addressed in this specification but could be met by UA implementations at their implementor's discretion, although meeting these requirements may be complex.
这些辅助需求也源自总体需求。虽然满足这些要求可能很复杂，但本规范中并未对其进行规范性说明，但UA实施可根据其实施者的判断满足这些要求。
1. Disallow "mixed security context" loads (see Section 2.3.1.3).
1. 不允许“混合安全上下文”加载（见第2.3.1.3节）。
2. Facilitate user declaration of web sites for which strict security policy is enabled, regardless of whether the sites signal HSTS Policy.
2. 方便用户声明启用了严格安全策略的网站，无论网站是否发出HSTS策略信号。
This specification is written for hosts and user agents.
本规范是为主机和用户代理编写的。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Terminology is defined in this section.
术语定义见本节。
ASCII case-insensitive comparison:
ASCII不区分大小写比较：
means comparing two strings exactly, codepoint for codepoint, except that the characters in the range U+0041 .. U+005A (i.e., LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER Z) and the corresponding characters in the range U+0061 .. U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are considered to also match. See [Unicode] for details.
表示对两个字符串进行精确比较，码点对码点，但U+0041范围内的字符除外。。U+005A（即拉丁文大写字母A到拉丁文大写字母Z）以及范围U+0061中的相应字符。。U+007A（即拉丁小写字母A到拉丁小写字母Z）也被视为匹配。有关详细信息，请参见[Unicode]。
codepoint:
代码点：
is a colloquial contraction of Code Point, which is any value in the Unicode codespace; that is, the range of integers from 0 to 10FFFF(hex) [Unicode].
是代码点的通俗缩写，它是Unicode代码空间中的任何值；也就是说，从0到10FFFF（十六进制）[Unicode]的整数范围。
domain name:
域名：
is also referred to as "DNS name" and is defined in [RFC1035] to be represented outside of the DNS protocol itself (and implementations thereof) as a series of labels separated by dots, e.g., "example.com" or "yet.another.example.org". In the context of this specification, domain names appear in that portion of a URI satisfying the reg-name production in "Appendix A. Collected ABNF for URI" in [RFC3986], and the host component from the Host HTTP header field production in Section 14.23 of [RFC2616].
也称为“DNS名称”，并在[RFC1035]中定义为在DNS协议本身（及其实现）之外表示为一系列由点分隔的标签，例如“example.com”或“yet.other.example.org”。在本规范的上下文中，域名出现在满足[RFC3986]中“附录a.为URI收集的ABNF”中的注册表名生成的URI部分，以及[RFC2616]第14.23节中主机HTTP头字段生成的主机组件中。
NOTE: The domain names appearing in actual URI instances and matching the aforementioned production components may or may not be a fully qualified domain name.
注意：出现在实际URI实例中并与上述生产组件匹配的域名可能是完全限定的域名，也可能不是。
domain name label:
域名标签：
is that portion of a domain name appearing "between the dots",
i.e., consider "foo.example.com": "foo", "example", and "com" are
all domain name labels.
is that portion of a domain name appearing "between the dots",
i.e., consider "foo.example.com": "foo", "example", and "com" are
all domain name labels.
Effective Request URI:
有效请求URI：
is a URI, identifying the target resource, that can be inferred by an HTTP host for any given HTTP request it receives. Such inference is necessary because HTTP requests often do not contain a complete "absolute" URI identifying the target resource. See Section 9 ("Constructing an Effective Request URI").
是一个URI，标识目标资源，HTTP主机可以为其接收的任何给定HTTP请求推断该URI。这种推断是必要的，因为HTTP请求通常不包含标识目标资源的完整“绝对”URI。请参阅第9节（“构建有效的请求URI”）。
HTTP Strict Transport Security:
HTTP严格传输安全：
is the overall name for the combined UA- and server-side security policy defined by this specification.
是本规范定义的UA和服务器端组合安全策略的总称。
HTTP Strict Transport Security Host:
HTTP严格传输安全主机：
is a conformant host implementing the HTTP server aspects of the HSTS Policy. This means that an HSTS Host returns the "Strict-Transport-Security" HTTP response header field in its HTTP response messages sent over secure transport.
是实现HSTS策略的HTTP服务器方面的一致性主机。这意味着HSTS主机在通过安全传输发送的HTTP响应消息中返回“严格传输安全性”HTTP响应头字段。
HTTP Strict Transport Security Policy:
HTTP严格的传输安全策略：
is the name of the combined overall UA- and server-side facets of the behavior defined in this specification.
是本规范中定义的行为的整体UA和服务器端方面的组合名称。
HSTS:
HST：
See HTTP Strict Transport Security.
请参阅HTTP严格传输安全。
HSTS Host:
HSTS主机：
See HTTP Strict Transport Security Host.
请参阅HTTP严格传输安全主机。
HSTS Policy:
HSTS政策：
See HTTP Strict Transport Security Policy.
请参阅HTTP严格传输安全策略。
Known HSTS Host:
已知HSTS主机：
is an HSTS Host for which the UA has an HSTS Policy in effect; i.e., the UA has noted this host as a Known HSTS Host. See Section 8.1.1 ("Noting an HSTS Host - Storage Model") for particulars.
是UA具有有效HSTS策略的HSTS主机；i、 例如，UA已将该主机标记为已知的HSTS主机。详情见第8.1.1节（“注意HSTS主机-存储模型”）。
Local policy:
当地政策：
comprises policy rules that deployers specify and that are often manifested as configuration settings.
包含部署人员指定的策略规则，这些规则通常表现为配置设置。
MITM:
MITM：
is an acronym for "man in the middle". See "man-in-the-middle attack" in [RFC4949].
是“中间人”的缩写。参见[RFC4949]中的“中间人攻击”。
Request URI:
请求URI：
is the URI used to cause a UA to issue an HTTP request message. See also "Effective Request URI".
用于使UA发出HTTP请求消息的URI。另请参见“有效请求URI”。
UA:
UA:
is an acronym for "user agent". For the purposes of this specification, a UA is an HTTP client application typically actively manipulated by a user [RFC2616].
是“用户代理”的首字母缩写。就本规范而言，UA是一种HTTP客户端应用程序，通常由用户主动操作[RFC2616]。
unknown HSTS Host:
未知HSTS主机：
is an HSTS Host that the user agent has not noted.
是用户代理尚未注意到的HSTS主机。
This section provides an overview of the mechanism by which an HSTS Host conveys its HSTS Policy to UAs and how UAs process the HSTS Policies received from HSTS Hosts. The mechanism details are specified in Sections 6 through 15.
本节概述了HSTS主机向UAs传送其HSTS策略的机制，以及UAs如何处理从HSTS主机接收的HSTS策略。第6节至第15节规定了机构详情。
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.
HTTP主机通过向UAs发出HSTS策略来声明自己为HSTS主机，该策略由严格传输安全HTTP响应头字段表示并通过安全传输（例如TLS）传递。在一致UA无错误地接收和处理该报头后，UA将该主机视为已知的HSTS主机。
An HSTS Policy directs UAs to communicate with a Known HSTS Host only over secure transport and specifies policy retention time duration.
HSTS策略指示UAs仅通过安全传输与已知HSTS主机通信，并指定策略保留时间。
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.
HSTS策略明确覆盖UA对URI引用、用户输入（例如，通过“位置栏”）或其他信息的处理，如果没有HSTS策略，这些信息可能会导致UAs与已知HSTS主机进行不安全通信。
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策略可能包含可选指令（includeSubDomains），指定此HSTS策略也适用于域名为已知HSTS主机域名的子域的任何主机。
UAs store and index HSTS Policies based strictly upon the domain names of the issuing HSTS Hosts.
UAs严格根据发布HSTS主机的域名存储和索引HSTS策略。
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.
这意味着UAs将维护任何给定HSTS主机的HSTS策略，与域名为给定HSTS主机域名的超域或子域的任何其他HSTS主机发布的任何HSTS策略分开。只有给定的HSTS主机可以更新或删除其已发布的HSTS策略。它通过向UAs发送具有策略持续时间和子域适用性的新值的严格传输安全HTTP响应头字段来实现这一点。因此，UAs代表HSTS主机缓存“最新”的HSTS策略信息。指定零持续时间表示UA删除该HSTS主机的HSTS策略（包括任何断言的includeSubDomains指令）。有关详细信息，请参阅第8.1节（“严格传输安全响应标头字段处理”）。此外，第6.2节给出了严格传输安全HTTP响应头字段的示例。
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.
在建立与给定主机的HTTP连接时，UA会检查其已知HSTS主机的缓存，以查看是否存在与给定主机域名的超域相同的域名。如果找到任何，并且其中任何一个断言了includeSubDomains指令，则HSTS策略将应用于给定主机。否则，仅当UA知道给定主机本身是HSTS主机时，HSTS策略才适用于给定主机。有关详细信息，请参见第8.3节（“URI加载和端口映射”）。
This section defines the syntax of the Strict-Transport-Security HTTP response header field and its directives, and presents some examples.
本节定义严格传输安全HTTP响应头字段及其指令的语法，并给出一些示例。
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.
第7节（“服务器处理模型”）详细说明了主机如何使用此标头字段声明其HSTS策略，第8节（“用户代理处理模型”）详细说明了用户代理如何处理标头字段并应用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.
严格传输安全HTTP响应标头字段（STS标头字段）向UA指示，它必须对发出包含此标头字段的响应消息的主机强制执行HSTS策略。
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").
STS标头字段的ABNF（增强的Backus Naur表单）语法如下所示。它基于[RFC2616]第2节中定义的通用语法（其中包括“隐含线性空白”的概念，也称为“隐含*LWS”）。
Strict-Transport-Security = "Strict-Transport-Security" ":"
[ directive ] *( ";" [ directive ] )
Strict-Transport-Security = "Strict-Transport-Security" ":"
[ directive ] *( ";" [ directive ] )
directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token | quoted-string
指令=指令名称[“=”指令值]指令名称=令牌指令值=令牌|带引号的字符串
where:
哪里：
token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
The two directives defined in this specification are described below. The overall requirements for directives are:
本规范中定义的两个指令如下所述。指令的总体要求如下：
1. The order of appearance of directives is not significant.
1. 指令的出现顺序并不重要。
2. All directives MUST appear only once in an STS header field. Directives are either optional or required, as stipulated in their definitions.
2. 所有指令在STS标头字段中只能出现一次。指令可以是可选的，也可以是必需的，正如它们的定义中所规定的那样。
3. Directive names are case-insensitive.
3. 指令名称不区分大小写。
4. UAs MUST ignore any STS header field containing directives, or other header field value data, that does not conform to the syntax defined in this specification.
4. UAs必须忽略任何包含指令的STS头字段，或不符合本规范中定义语法的其他头字段值数据。
5. If an STS header field contains directive(s) not recognized by the UA, the UA MUST ignore the unrecognized directives, and if the STS header field otherwise satisfies the above requirements (1 through 4), the UA MUST process the recognized directives.
5. 如果STS标头字段包含UA未识别的指令，UA必须忽略未识别的指令，如果STS标头字段满足上述要求（1至4），UA必须处理已识别的指令。
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头字段语义功能的其他指令可在其他规范中定义，此时可为其定义注册表（具有IETF Review[RFC5226]的IANA策略定义）。
NOTE: Such future directives will be ignored by UAs implementing only this specification, as well as by generally non-conforming UAs. See Section 14.2 ("Non-Conformant User Agent Implications") for further discussion.
注：仅执行本规范的UAs以及通常不符合本规范的UAs将忽略此类未来指令。有关进一步的讨论，请参见第14.2节（“不符合规定的用户代理影响”）。
The REQUIRED "max-age" directive specifies the number of seconds, after the reception of the STS header field, during which the UA regards the host (from whom the message was received) as a Known HSTS Host. See also Section 8.1.1 ("Noting an HSTS Host - Storage Model"). The delta-seconds production is specified in [RFC2616].
所需的“max age”指令指定接收STS报头字段后的秒数，在此期间，UA将主机（接收消息的主机）视为已知的HSTS主机。另见第8.1.1节（“注意HSTS主机-存储模型”）。[RFC2616]中规定了增量秒生产。
The syntax of the max-age directive's REQUIRED value (after quoted-string unescaping, if necessary) is defined as:
max age指令所需值的语法（如有必要，在带引号的字符串取消跳过后）定义为：
max-age-value = delta-seconds
max-age-value = delta-seconds
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>
NOTE: A max-age value of zero (i.e., "max-age=0") signals the UA to cease regarding the host as a Known HSTS Host, including the includeSubDomains directive (if asserted for that HSTS Host). See also Section 8.1 ("Strict-Transport-Security Response Header Field Processing").
注：最大年龄值为零（即，“最大年龄=0”）表示UA停止将主机视为已知HSTS主机，包括includeSubDomains指令（如果针对该HSTS主机断言）。另见第8.1节（“严格传输安全响应标题字段处理”）。
The OPTIONAL "includeSubDomains" directive is a valueless directive which, if present (i.e., it is "asserted"), signals the UA that the HSTS Policy applies to this HSTS Host as well as any subdomains of the host's domain name.
可选的“includeSubDomains”指令是一个无值指令，如果存在（即，它是“断言的”），则向UA发出HSTS策略适用于该HSTS主机以及主机域名的任何子域的信号。
The HSTS header field below stipulates that the HSTS Policy is to remain in effect for one year (there are approximately 31536000 seconds in a year), and the policy applies only to the domain of the HSTS Host issuing it:
下面的HSTS标题字段规定HSTS策略将保持有效一年（一年中大约有31536000秒），并且该策略仅适用于发布该策略的HSTS主机的域：
Strict-Transport-Security: max-age=31536000
严格的运输安全：最大年龄=31536000
The HSTS header field below stipulates that the HSTS Policy is to remain in effect for approximately six months and that the policy applies to the domain of the issuing HSTS Host and all of its subdomains:
下面的HSTS标题字段规定HSTS策略将保持有效约六个月，并且该策略适用于发布HSTS主机的域及其所有子域：
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
The max-age directive value can optionally be quoted:
可以选择引用“最大年龄”指令值：
Strict-Transport-Security: max-age="31536000"
严格的运输安全：最大年龄=“31536000”
The HSTS header field below indicates that the UA must delete the entire HSTS Policy associated with the HSTS Host that sent the header field:
下面的HSTS标头字段表示UA必须删除与发送标头字段的HSTS主机关联的整个HSTS策略：
Strict-Transport-Security: max-age=0
严格的传输安全性：最大年龄=0
The HSTS header field below has exactly the same effect as the one immediately above because the includeSubDomains directive's presence in the HSTS header field is ignored when max-age is zero:
下面的HSTS标头字段与上面的字段具有完全相同的效果，因为当max age为零时，HSTS标头字段中的includeSubDomains指令被忽略：
Strict-Transport-Security: max-age=0; includeSubDomains
Strict-Transport-Security: max-age=0; includeSubDomains
This section describes the processing model that HSTS Hosts implement. The model comprises two facets: the first being the processing rules for HTTP request messages received over a secure transport (TLS [RFC5246] or SSL [RFC6101]; see also Section 14.1 ("Underlying Secure Transport Considerations")), and the second being the processing rules for HTTP request messages received over non-secure transports, such as TCP.
本节描述HSTS主机实现的处理模型。该模型包括两个方面：第一个是通过安全传输（TLS[RFC5246]或SSL[RFC6101]）接收的HTTP请求消息的处理规则；另请参见第14.1节（“基础安全传输注意事项”），第二个是通过非安全传输（如TCP）接收的HTTP请求消息的处理规则。
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.
当回复通过安全传输传输传输的HTTP请求时，HSTS主机应在其响应消息中包含STS标头字段，该字段必须满足上文第6.1节（“严格传输安全HTTP响应标头字段”）中规定的语法。如果包含STS标头字段，则HSTS主机必须仅包含一个此类标头字段。
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").
在给定UA的上下文中，将给定主机建立为已知HSTS主机可以通过HTTP来完成，而HTTP又通过安全传输运行，方法是（根据本规范）正确地向UA返回至少一个有效的STS报头字段。还可以使用其他机制，例如客户端预加载的已知HSTS主机列表；e、 参见第12节（“用户代理实施建议”）。
NOTE: Including the STS header field is stipulated as a "SHOULD" in order to accommodate various server- and network-side caches and load-balancing configurations where it may be difficult to uniformly emit STS header fields on behalf of a given HSTS Host.
注：包括STS标头字段被规定为“应”，以适应各种服务器和网络端缓存和负载平衡配置，其中可能难以代表给定HSTS主机统一发出STS标头字段。
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".
如果HSTS主机通过非安全传输接收HTTP请求消息，则应发送HTTP响应消息，其中包含指示永久重定向的状态代码，如状态代码301（RFC2616的第10.3.2节），以及包含HTTP请求原始有效请求URI（见第9节）的位置标头字段值（“构造有效的请求URI”））根据需要进行更改，以使URI方案为“https”，或根据本地策略生成的URI方案为“https”。
NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:
注：由于以下原因，上述行为是“应该”而不是“必须”：
* Risks in server-side non-secure-to-secure redirects [OWASP-TLSGuide].
* 服务器端非安全到安全重定向[OWASP TLSGuide]的风险。
* Site deployment characteristics. For example, a site that incorporates third-party components may not behave correctly when doing server-side non-secure-to-secure redirects in the case of being accessed over non-secure transport but does behave correctly when accessed uniformly over secure transport. The latter is the case given an HSTS-capable UA that has already noted the site as a Known HSTS Host (by whatever means, e.g., prior interaction or UA configuration).
* 站点部署特征。例如，在通过非安全传输访问服务器端非安全到安全重定向时，包含第三方组件的站点可能无法正常运行，但在通过安全传输统一访问时，该站点可能会正常运行。后者是指具有HSTS能力的UA已将该站点标记为已知HSTS主机（通过任何方式，例如先前的交互或UA配置）的情况。
An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
HSTS主机不得在通过非安全传输传输的HTTP响应中包含STS标头字段。
This section describes the HTTP Strict Transport Security processing model for UAs. There are several facets to the model, enumerated by the following subsections.
本节介绍UAs的HTTP严格传输安全处理模型。模型有几个方面，由以下小节列举。
This processing model assumes that the UA implements IDNA2008 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration"). It also assumes that all domain names manipulated in this specification's context are already IDNA-canonicalized as outlined in Section 10 ("Domain Name IDNA-Canonicalization") prior to the processing specified in this section.
该处理模型假设UA实现IDNA2008[RFC5890]或IDNA2003[RFC3490]，如第13节（“应用程序的国际化域名（IDNA）：依赖和迁移”）所述。它还假设在本规范的上下文中操作的所有域名在本节指定的处理之前已经按照第10节（“域名IDNA规范化”）中的概述进行了IDNA规范化。
NOTE: [RFC3490] is referenced due to its ongoing relevance to actual deployments for the foreseeable future.
注：[RFC3490]因其与可预见未来实际部署的持续相关性而被引用。
The above assumptions mean that this processing model also specifically assumes that appropriate IDNA and Unicode validations and character list testing have occurred on the domain names, in
上述假设意味着，该处理模型还特别假设在以下情况下对域名进行了适当的IDNA和Unicode验证以及字符列表测试：
conjunction with their IDNA-canonicalization, prior to the processing specified in this section. See the IDNA-specific security considerations in Section 14.10 ("Internationalized Domain Names") for rationale and further details.
在本节规定的处理之前，结合其IDNA规范化。有关基本原理和更多详细信息，请参见第14.10节（“国际化域名”）中的IDNA特定安全注意事项。
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:
如果通过安全传输接收的HTTP响应包含符合第6.1节（“严格传输安全HTTP响应头字段”）中规定语法的STS头字段，并且没有潜在的安全传输错误或警告（见第8.4节），UA必须：
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")),
o 如果尚未注明，则注明主机为已知HSTS主机（见第8.1.1节（“注明HSTS主机-存储型号”），
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.
o 如果max age和includeSubDomains标头字段值令牌中的一个或两个正在传输与UA已维护的信息不同的信息，则更新已知HSTS主机的UA缓存信息。
The max-age value is essentially a "time to live" value relative to the reception time of the STS header field.
max age值基本上是相对于STS报头字段的接收时间的“生存时间”值。
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.
如果max age header field value token的值为零，则如果HSTS主机已知，UA必须删除其缓存的HSTS策略信息（如果断言，则包括includeSubDomains指令），或者如果尚未知道，UA不得记录该HSTS主机。
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.
如果UA通过安全传输在HTTP响应消息中接收到多个STS报头字段，则UA必须仅处理第一个此类报头字段。
Otherwise:
否则：
o If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).
o 如果通过不安全的传输接收HTTP响应，UA必须忽略任何现有的STS报头字段。
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").
o UA必须忽略任何不符合第6.1节（“严格传输安全HTTP响应头字段”）中规定语法的STS头字段。
If the substring matching the host production from the Request-URI (of the message to which the host responded) syntactically matches the IP-literal or IPv4address productions from Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host.
如果与（主机响应的消息的）请求URI中的主机产品相匹配的子字符串在语法上与[RFC3986]第3.2.2节中的IP文本或IPv4address产品相匹配，则UA不得将该主机视为已知HSTS主机。
Otherwise, if the substring does not congruently match a Known HSTS Host's domain name, per the matching procedure specified in Section 8.2 ("Known HSTS Host Domain Name Matching"), then the UA MUST note this host as a Known HSTS Host, caching the HSTS Host's domain name and noting along with it the expiry time of this information, as effectively stipulated per the given max-age value, as well as whether the includeSubDomains directive is asserted or not. See also Section 11.2 ("HSTS Policy Expiration Time Considerations").
否则，如果根据第8.2节（“已知HSTS主机域名匹配”）中规定的匹配程序，子字符串与已知HSTS主机的域名不一致，则UA必须将该主机记录为已知HSTS主机，缓存HSTS主机的域名，并同时记录该信息的到期时间，根据给定的最大年龄值以及是否断言includeSubDomains指令有效地规定。另见第11.2节（“HSTS保单到期时间考虑”）。
The UA MUST NOT modify the expiry time or the includeSubDomains directive of any superdomain matched Known HSTS Host.
UA不得修改任何与已知HSTS主机匹配的超域的到期时间或includeSubDomains指令。
A Known HSTS Host is "expired" if its cache entry has an expiry date in the past. The UA MUST evict all expired Known HSTS Hosts from its cache if, at any time, an expired Known HSTS Host exists in the cache.
如果已知HSTS主机的缓存项在过去有过期日期，则该主机“过期”。如果在任何时候，缓存中存在过期的已知HSTS主机，UA必须从其缓存中逐出所有过期的已知HSTS主机。
A given domain name may match a Known HSTS Host's domain name in one or both of two fashions: a congruent match, or a superdomain match. Alternatively, there may be no match.
给定域名可能以两种方式中的一种或两种方式匹配已知HSTS主机的域名：全等匹配或超域匹配。或者，可能没有对手。
The steps below determine whether there are any matches, and if so, of which fashion:
以下步骤确定是否存在匹配项，如果存在，则确定哪种方式：
Compare the given domain name with the domain name of each of the UA's unexpired Known HSTS Hosts. For each Known HSTS Host's domain name, the comparison is done with the given domain name label-by-label (comparing only labels) using an ASCII case-insensitive comparison beginning with the rightmost label, and continuing right-to-left. See also Section 2.3.2.4 of [RFC5890].
将给定域名与UA的每个未过期已知HSTS主机的域名进行比较。对于每个已知HSTS主机的域名，使用ASCII不区分大小写的比较（从最右边的标签开始，从右到左继续），逐标签与给定的域名标签进行比较（仅比较标签）。另见[RFC5890]第2.3.2.4节。
* Superdomain Match
* 超域匹配
If a label-for-label match between an entire Known HSTS Host's domain name and a right-hand portion of the given domain name is found, then this Known HSTS Host's domain name is a superdomain match for the given domain name. There could be multiple superdomain matches for a given domain name.
如果在整个已知HSTS主机的域名和给定域名的右侧部分之间找到标签匹配的标签，则该已知HSTS主机的域名是给定域名的超域名匹配。给定域名可能有多个超域名匹配项。
For example:
例如：
Given domain name (DN): qaz.bar.foo.example.com
给定域名（DN）：qaz.bar.foo.example.com
Superdomain matched Known HSTS Host DN: bar.foo.example.com
Superdomain匹配已知HSTS主机DN:bar.foo.example.com
Superdomain matched Known HSTS Host DN: foo.example.com
Superdomain匹配已知HSTS主机DN:foo.example.com
* Congruent Match
* 全等匹配
If a label-for-label match between a Known HSTS Host's domain name and the given domain name is found -- i.e., there are no further labels to compare -- then the given domain name congruently matches this Known HSTS Host.
如果在已知HSTS主机的域名和给定域名之间找到标签匹配的标签（即，没有其他标签可比较），则给定域名与该已知HSTS主机完全匹配。
For example:
例如：
Given domain name: foo.example.com
给定域名：foo.example.com
Congruently matched Known HSTS Host DN: foo.example.com
一致匹配的已知HSTS主机DN:foo.example.com
* Otherwise, if no matches are found, the given domain name does not represent a Known HSTS Host.
* 否则，如果未找到匹配项，则给定的域名不代表已知的HSTS主机。
Whenever the UA prepares to "load" (also known as "dereference") any "http" URI [RFC3986] (including when following HTTP redirects [RFC2616]), the UA MUST first determine whether a domain name is given in the URI and whether it matches a Known HSTS Host, using these steps:
每当UA准备“加载”（也称为“取消引用”）任何“http”URI[RFC3986]（包括在执行http重定向[RFC2616]时），UA必须首先使用以下步骤确定URI中是否给出了域名，以及该域名是否与已知HSTS主机匹配：
1. Extract from the URI any substring described by the host component of the authority component of the URI.
1. 从URI中提取URI的授权组件的主机组件所描述的任何子字符串。
2. If the substring is null, then there is no match with any Known HSTS Host.
2. 如果子字符串为null，则与任何已知HSTS主机都不匹配。
3. Else, if the substring is non-null and syntactically matches the IP-literal or IPv4address productions from Section 3.2.2 of [RFC3986], then there is no match with any Known HSTS Host.
3. 否则，如果子字符串为非空且语法上与[RFC3986]第3.2.2节中的IP文字或IPv4address产品匹配，则与任何已知HSTS主机都不匹配。
4. Otherwise, the substring is a given domain name, which MUST be matched against the UA's Known HSTS Hosts using the procedure in Section 8.2 ("Known HSTS Host Domain Name Matching").
4. 否则，子字符串是给定域名，必须使用第8.2节（“已知HSTS主机域名匹配”）中的程序与UA的已知HSTS主机进行匹配。
5. If, when performing domain name matching any superdomain match with an asserted includeSubDomains directive is found, or, if no superdomain matches with asserted includeSubDomains directives are found and a congruent match is found (with or without an asserted includeSubDomains directive), then before proceeding with the load:
5. 如果在执行域名匹配时发现与断言的includeSubDomains指令匹配的任何超域，或者如果未找到与断言的includeSubDomains指令匹配的超域，并且发现一致匹配（有或没有断言的includeSubDomains指令），则在继续加载之前：
The UA MUST replace the URI scheme with "https" [RFC2818], and
UA必须用“https”[RFC2818]替换URI方案，并且
if the URI contains an explicit port component of "80", then the UA MUST convert the port component to be "443", or
如果URI包含显式端口组件“80”，则UA必须将端口组件转换为“443”，或
if the URI contains an explicit port component that is not equal to "80", the port component value MUST be preserved; otherwise,
如果URI包含不等于“80”的显式端口组件，则必须保留端口组件值；否则
if the URI does not contain an explicit port component, the UA MUST NOT add one.
如果URI不包含显式端口组件，则UA不得添加显式端口组件。
NOTE: These steps ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS Host.
注意：这些步骤确保HSTS策略通过HSTS主机的任何TCP端口应用于HTTP。
NOTE: In the case where an explicit port is provided (and to a lesser extent with subdomains), it is reasonably likely that there is actually an HTTP (i.e., non-secure) server running on the specified port and that an HTTPS request will thus fail (see item 6 in Appendix A ("Design Decision Notes")).
注：如果提供了显式端口（在较小程度上是子域），则很可能在指定端口上实际运行HTTP（即非安全）服务器，因此HTTPS请求将失败（见附录a中的第6项（“设计决策说明”）。
When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125].
当连接到已知HSTS主机时，如果存在任何错误（无论是“警告”或“致命”或任何其他错误级别），UA必须终止与底层安全传输的连接（另请参见第12节（“用户代理实施建议”）。例如，这包括在UAs采用的证书有效性检查中发现的任何错误，例如通过证书吊销列表（CRL）[RFC5280]，或通过在线证书状态协议（OCSP）[RFC2560]，以及通过TLS服务器身份检查[RFC6125]。
UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute settings on <meta> elements [W3C.REC-html401-19991224] in received content.
UAs不得注意接收内容中<meta>元素[W3C.REC-html401-19991224]的http equiv=“Strict Transport Security”属性设置。
If a UA receives HTTP responses from a Known HSTS Host over a secure channel but the responses are missing the STS header field, the UA MUST continue to treat the host as a Known HSTS Host until the max-age value for the knowledge of that Known HSTS Host is reached. Note that the max-age value could be effectively infinite for a given Known HSTS Host. For example, this would be the case if the Known HSTS Host is part of a pre-configured list that is implemented such that the list entries never "age out".
如果UA通过安全通道接收到来自已知HSTS主机的HTTP响应，但响应缺少STS标头字段，则UA必须继续将主机视为已知HSTS主机，直到达到已知HSTS主机知识的最大年限值。请注意，对于给定的已知HSTS主机，“最大年龄”值实际上可能是无限的。例如，如果已知的HSTS主机是预先配置的列表的一部分，该列表的实现使得列表条目永远不会“过时”，则会出现这种情况。
This section specifies how an HSTS Host must construct the Effective Request URI for a received HTTP request.
本节指定HSTS主机必须如何为接收到的HTTP请求构造有效的请求URI。
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.
HTTP请求通常不携带目标资源的绝对URI；相反，需要从请求URI、主机头字段和连接上下文（[RFC2616]，第3.2.1、5.1.2和5.2节）推断URI。此过程的结果称为“有效请求URI（ERU）”。“目标资源”是由有效请求URI标识的资源。
The first line of an HTTP request message, Request-Line, is specified by the following ABNF from [RFC2616], Section 5.1:
HTTP请求消息的第一行，请求行，由[RFC2616]第5.1节中的以下ABNF指定：
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
请求行=方法SP请求URI SP HTTP版本CRLF
The Request-URI, within the Request-Line, is specified by the following ABNF from [RFC2616], Section 5.1.2:
请求行内的请求URI由[RFC2616]第5.1.2节中的以下ABNF指定：
Request-URI = "*" | absoluteURI | abs_path | authority
请求URI=“*”|绝对URI |绝对路径|权限
The Host request header field is specified by the following ABNF from [RFC2616], Section 14.23:
主机请求头字段由[RFC2616]第14.23节中的以下ABNF指定：
Host = "Host" ":" host [ ":" port ]
Host = "Host" ":" host [ ":" port ]
If the Request-URI is an absoluteURI, then the effective request URI is the Request-URI.
如果请求URI是绝对URI，那么有效的请求URI就是请求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:
如果请求URI使用abs_路径形式或星号形式，并且存在主机头字段，则通过连接以下内容来构造有效的请求URI：
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 方案名称：如果通过不安全的TCP连接接收请求，则为“http”；如果通过TLS/SSL安全的TCP连接接收请求，则为“https”；以及
o the octet sequence "://", and
o 八位组序列“//”，以及
o the host, and the port (if present), from the Host header field, and
o 主机标题字段中的主机和端口（如果存在），以及
o the Request-URI obtained from the Request-Line, unless the Request-URI is just the asterisk "*".
o 从请求行获得的请求URI，除非请求URI只是星号“*”。
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.
如果请求URI使用abs_路径形式或星号形式，并且主机头字段不存在，则有效请求URI未定义。
Otherwise, when Request-URI uses the authority form, the effective request URI is undefined.
否则，当请求URI使用授权表单时，有效的请求URI未定义。
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 "/".
使用[RFC2616]第3.2.3节中描述的规则比较有效请求URI，但空路径组件不得视为等同于“/”的绝对路径。
Example 1: the effective request URI for the message
示例1：消息的有效请求URI
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus the request-target "/pub/WWW/TheProject.html". Thus, it is "http://www.example.org:8080/pub/WWW/TheProject.html".
（通过不安全的TCP连接接收）是“http”，加上“：/”，再加上权限组件“www.example.org:8080”，再加上请求目标“/pub/www/TheProject.html”。因此，它是“http://www.example.org:8080/pub/WWW/TheProject.html".
Example 2: the effective request URI for the message
示例2：消息的有效请求URI
OPTIONS * HTTP/1.1 Host: www.example.org
选项*HTTP/1.1主机：www.example.org
(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org". Thus, it is "https://www.example.org".
（通过SSL/TLS安全TCP连接接收）是“https”，加上“：/”，再加上授权组件“www.example.org”。因此，它是“https://www.example.org".
An IDNA-canonicalized domain name is the output string generated by the following steps. The input is a putative domain name string ostensibly composed of any combination of "A-labels", "U-labels", and "NR-LDH labels" (see Section 2 of [RFC5890]) concatenated using some separator character (typically ".").
IDNA规范化域名是通过以下步骤生成的输出字符串。输入是一个假定的域名字符串，表面上由“a标签”、“U标签”和“NR-LDH标签”的任意组合（见[RFC5890]第2节）组成，并使用一些分隔符（通常为“.”）连接起来。
1. Convert the input putative domain name string to an order-preserving sequence of individual label strings.
1. 将输入的假定域名字符串转换为单个标签字符串的保序序列。
2. When implementing IDNA2008, convert, validate, and test each A-label and U-label found among the sequence of individual label strings, using the procedures defined in Sections 5.3 through 5.5 of [RFC5891].
2. 实施IDNA2008时，使用[RFC5891]第5.3节至第5.5节中定义的程序，转换、验证和测试单个标签字符串序列中的每个A标签和U标签。
Otherwise, when implementing IDNA2003, convert each label using the "ToASCII" conversion in Section 4 of [RFC3490] (see also the definition of "equivalence of labels" in Section 2 of [RFC3490]).
否则，在实施IDNA2003时，使用[RFC3490]第4节中的“ToASCII”转换转换每个标签（另请参见[RFC3490]第2节中的“标签等效性”定义）。
3. If no errors occurred during the foregoing step, concatenate all the labels in the sequence, in order, into a string, separating each label from the next with a %x2E (".") character. The resulting string, known as an IDNA-canonicalized domain name, is appropriate for use in the context of Section 8 ("User Agent Processing Model").
3. 如果在上述步骤中没有发生错误，请按顺序将序列中的所有标签连接成一个字符串，并用%x2E（“.”）字符将每个标签与下一个标签分开。生成的字符串称为IDNA规范化域名，适合在第8节（“用户代理处理模型”）的上下文中使用。
Otherwise, errors occurred. The input putative domain name string was not successfully IDNA-canonicalized. Invokers of this procedure should attempt appropriate error recovery.
否则，就会出现错误。输入的假定域名字符串未成功进行IDNA规范化。此过程的调用程序应尝试进行适当的错误恢复。
See also Sections 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration") and 14.10 ("Internationalized Domain Names") of this specification for further details and considerations.
有关更多详细信息和注意事项，请参见本规范第13节（“应用程序的国际化域名（IDNA）：依赖关系和迁移”）和第14.10节（“国际化域名”）。
This section is non-normative.
本节是非规范性的。
Non-conformant UAs ignore the Strict-Transport-Security header field; thus, non-conformant user agents do not address the threats described in Section 2.3.1 ("Threats Addressed"). Please refer to Section 14.2 ("Non-Conformant User Agent Implications") for further discussion.
不一致的UAs忽略严格的传输安全标头字段；因此，非一致用户代理不解决第2.3.1节（“已解决的威胁”）中描述的威胁。有关进一步讨论，请参考第14.2节（“不符合规定的用户代理影响”）。
Server implementations and deploying web sites need to consider whether they are setting an expiry time that is a constant value into the future, or whether they are setting an expiry time that is a fixed point in time.
服务器实现和部署Web站点需要考虑它们是否设置了未来的常量值的到期时间，或者它们是否设置了固定时间点的过期时间。
The "constant value into the future" approach can be accomplished by constantly sending the same max-age value to UAs.
通过不断向UAs发送相同的最大年限值，可以实现“未来定值”方法。
For example, a max-age value of 7776000 seconds is 90 days:
例如，7776000秒的最大年限值为90天：
Strict-Transport-Security: max-age=7776000
严格的运输安全：最大年龄=7776000
Note that each receipt of this header by a UA will require the UA to update its notion of when it must delete its knowledge of this Known HSTS Host.
请注意，UA收到该报头后，需要UA更新其何时必须删除其对该已知HSTS主机的了解的概念。
The "fixed point in time" approach can be accomplished by sending max-age values that represent the remaining time until the desired expiry time. This would require the HSTS Host to send a newly calculated max-age value in each HTTP response.
“固定时间点”方法可以通过发送表示到所需到期时间的剩余时间的最大年龄值来实现。这将要求HSTS主机在每个HTTP响应中发送一个新计算的最大年龄值。
A consideration here is whether a deployer wishes to have the signaled HSTS Policy expiry time match that for the web site's domain certificate.
这里需要考虑的是，部署人员是否希望发出信号的HSTS策略到期时间与网站的域证书的到期时间相匹配。
Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems. This will require deployers to willfully set max-age in order to have UAs enforce the HSTS Policy for their host and will protect them from inadvertently enabling HSTS with some arbitrary non-zero duration.
此外，服务器实现者应该考虑在部署配置系统中使用默认的最大年龄值为零。这将要求部署人员故意设置最大使用年限，以便让UAs为其主机强制实施HSTS策略，并防止他们无意中启用具有任意非零持续时间的HST。
11.3. Using HSTS in Conjunction with Self-Signed Public-Key Certificates
11.3. 将HST与自签名公钥证书结合使用
If all four of the following conditions are true...
如果以下四个条件均为真。。。
o a web site/organization/enterprise is generating its own secure transport public-key certificates for web sites, and
o 网站/组织/企业正在为网站生成自己的安全传输公钥证书，以及
o that organization's root certification authority (CA) certificate is not typically embedded by default in browser and/or operating system CA certificate stores, and
o 默认情况下，该组织的根证书颁发机构（CA）证书通常不会嵌入到浏览器和/或操作系统CA证书存储中，并且
o HSTS Policy is enabled on a host identifying itself using a certificate signed by the organization's CA (i.e., a "self-signed certificate"), and
o HSTS策略在主机上启用，该主机使用组织CA签署的证书（即“自签名证书”）标识自身，以及
o this certificate does not match a usable TLS certificate association (as defined by Section 4 of the TLSA protocol specification [RFC6698]),
o 此证书与可用的TLS证书关联不匹配（如TLSA协议规范[RFC6698]第4节所定义），
...then secure connections to that site will fail, per the HSTS design. This is to protect against various active attacks, as discussed above.
…然后，根据HSTS设计，与该站点的安全连接将失败。如上所述，这是为了防止各种主动攻击。
However, if said organization wishes to employ its own CA, and self-signed certificates, in concert with HSTS, it can do so by deploying its root CA certificate to its users' browsers or operating system CA root certificate stores. It can also, in addition or instead, distribute to its users' browsers the end-entity certificate(s) for specific hosts. There are various ways in which this can be accomplished (details are out of scope for this specification). Once its root CA certificate is installed in the browsers, it may employ HSTS Policy on its site(s).
然而，如果所述组织希望与HST一起使用其自己的CA和自签名证书，则其可以通过将其根CA证书部署到其用户的浏览器或操作系统CA根证书存储中来实现。此外，它还可以将特定主机的最终实体证书分发给用户的浏览器。有多种方法可以实现这一点（细节超出本规范的范围）。一旦其根CA证书安装在浏览器中，它可以在其站点上使用HSTS策略。
Alternatively, that organization can deploy the TLSA protocol; all browsers that also use TLSA will then be able to trust the certificates identified by usable TLS certificate associations as denoted via TLSA.
或者，该组织可以部署TLSA协议；所有也使用TLSA的浏览器将能够信任由可用TLS证书关联标识的证书，如TLSA所示。
NOTE: Interactively distributing root CA certificates to users, e.g., via email, and having the users install them, is arguably training the users to be susceptible to a possible form of phishing attack. See Section 14.8 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack"). Thus, care should be taken in the manner in which such certificates are distributed and installed on users' systems and browsers.
注意：以交互方式（例如通过电子邮件）向用户分发根CA证书，并让用户安装证书，可以说是在训练用户易受可能形式的网络钓鱼攻击。请参阅第14.8节（“伪造根CA证书钓鱼加DNS缓存中毒攻击”）。因此，应注意在用户系统和浏览器上分发和安装此类证书的方式。
The includeSubDomains directive has practical implications meriting careful consideration; two example scenarios are:
includeSubDomains指令具有值得仔细考虑的实际含义；两个示例场景是：
o An HSTS Host offers unsecured HTTP-based services on alternate ports or at various subdomains of its HSTS Host domain name.
o HSTS主机在备用端口或其HSTS主机域名的各个子域上提供基于HTTP的不安全服务。
o Distinct web applications are offered at distinct subdomains of an HSTS Host, such that UAs often interact directly with these subdomain web applications without having necessarily interacted with a web application offered at the HSTS Host's domain name (if any).
o 在HSTS主机的不同子域上提供不同的web应用程序，因此UAs通常直接与这些子域web应用程序交互，而不必与HSTS主机域名（如果有）上提供的web应用程序交互。
The sections below discuss each of these scenarios in turn.
以下各节依次讨论这些场景。
11.4.1. Considerations for Offering Unsecured HTTP Services at Alternate Ports or Subdomains of an HSTS Host
11.4.1. 在HSTS主机的备用端口或子域上提供不安全HTTP服务的注意事项
For example, certification authorities often offer their CRL distribution and OCSP services [RFC2560] over plain HTTP, and sometimes at a subdomain of a publicly available web application that may be secured by TLS/SSL. For example, <https://ca.example.com/> is a publicly available web application for "Example CA", a certification authority. Customers use this web application to register their public keys and obtain certificates. "Example CA" generates certificates for customers containing <http://crl-and-ocsp.ca.example.com/> as the value for the "CRL Distribution Points" and "Authority Information Access:OCSP" certificate fields.
例如，认证机构通常通过普通HTTP提供其CRL分发和OCSP服务[RFC2560]，有时在公共可用web应用程序的子域中提供，该应用程序可能由TLS/SSL保护。比如说,<https://ca.example.com/>是证书颁发机构“示例CA”的公开web应用程序。客户使用此web应用程序注册其公钥并获取证书。“示例CA”为包含以下内容的客户生成证书<http://crl-and-ocsp.ca.example.com/>作为“CRL分发点”和“权限信息访问：OCSP”证书字段的值。
If ca.example.com were to issue an HSTS Policy with the includeSubDomains directive, then HTTP-based user agents implementing HSTS that have interacted with the ca.example.com web application would fail to retrieve CRLs and fail to check OCSP for certificates, because these services are offered over plain HTTP.
如果ca.example.com发布带有includeSubDomains指令的HSTS策略，那么实现与ca.example.com web应用程序交互的HST的基于HTTP的用户代理将无法检索CRL，也无法检查OCSP的证书，因为这些服务是通过普通HTTP提供的。
In this case, Example CA can either:
在这种情况下，示例CA可以：
o not use the includeSubDomains directive, or
o 不使用includeSubDomains指令，或
o ensure that HTTP-based services offered at subdomains of ca.example.com are also uniformly offered over TLS/SSL, or
o 确保在ca.example.com的子域上提供的基于HTTP的服务也通过TLS/SSL统一提供，或
o offer plain HTTP-based services at a different domain name, e.g., crl-and-ocsp.ca.example.NET, or
o 在不同的域名（如crl-and-ocsp.ca.example.NET）上提供基于HTTP的普通服务，或
o utilize an alternative approach to distributing certificate status information, obviating the need to offer CRL distribution and OCSP services over plain HTTP (e.g., the "Certificate Status Request" TLS extension [RFC6066], often colloquially referred to as "OCSP Stapling").
o 利用另一种分发证书状态信息的方法，无需通过普通HTTP（例如，“证书状态请求”TLS扩展[RFC6066]，通常通俗地称为“OCSP绑定”）提供CRL分发和OCSP服务。
NOTE: The above points are expressly only an example and do not purport to address all the involved complexities. For instance, there are many considerations -- on the part of CAs, certificate deployers, and applications (e.g., browsers) -- involved in deploying an approach such as "OCSP Stapling". Such issues are out of scope for this specification.
注：以上几点仅为一个示例，并不旨在解决所有涉及的复杂性。例如，在部署诸如“OCSP装订”之类的方法时，涉及到许多考虑因素——CAs、证书部署人员和应用程序（例如浏览器）。此类问题超出本规范的范围。
11.4.2. Considerations for Offering Web Applications at Subdomains of an HSTS Host
11.4.2. 在HSTS主机的子域中提供Web应用程序的注意事项
In this scenario, an HSTS Host declares an HSTS Policy with an includeSubDomains directive, and there also exist distinct web applications offered at distinct subdomains of the HSTS Host such that UAs often interact directly with these subdomain web applications without having necessarily interacted with the HSTS Host. In such a case, the UAs will not receive or enforce the HSTS Policy.
在此场景中，HSTS主机使用includeSubDomains指令声明HSTS策略，并且在HSTS主机的不同子域中还存在不同的web应用程序，因此UAs通常直接与这些子域web应用程序交互，而不必与HSTS主机交互。在这种情况下，UAs将不会接收或执行HSTS政策。
For example, the HSTS Host is "example.com", and it is configured to emit the STS header field with the includeSubDomains directive. However, example.com's actual web application is addressed at "www.example.com", and example.com simply redirects user agents to "https://www.example.com/".
例如，HSTS主机是“example.com”，它被配置为使用includeSubDomains指令发出STS头字段。然而，example.com的实际web应用程序位于“www.example.com”，example.com只是将用户代理重定向到”https://www.example.com/".
If the STS header field is only emitted by "example.com" but UAs typically bookmark -- and links (from anywhere on the web) are typically established to -- "www.example.com", and "example.com" is not contacted directly by all user agents in some non-zero percentage of interactions, then some number of UAs will not note "example.com" as an HSTS Host, and some number of users of "www.example.com" will be unprotected by HSTS Policy.
如果STS标头字段仅由“example.com”发出，但UAs通常会添加书签，并且链接（从web上的任何位置）通常会建立到--“www.example.com”，并且在某些非零百分比的交互中，所有用户代理都不会直接联系“example.com”，那么一些UAs不会注意到“example.com”作为HSTS主机，“www.example.com”的部分用户将不受HSTS策略的保护。
To address this, HSTS Hosts should be configured such that the STS header field is emitted directly at each HSTS Host domain or subdomain name that constitutes a well-known "entry point" to one's web application(s), whether or not the includeSubDomains directive is employed.
为了解决这一问题，HSTS主机的配置应确保STS头字段直接在每个HSTS主机域或子域名处发出，这些域名或子域名构成了web应用程序的众所周知的“入口点”，无论是否使用includeSubDomains指令。
Thus, in our example, if the STS header field is emitted from both "example.com" and "www.example.com", this issue will be addressed. Also, if there are any other well-known entry points to web applications offered by "example.com", such as "foo.example.com", they should also be configured to emit the STS header field.
因此，在我们的示例中，如果STS头字段同时从“example.com”和“www.example.com”发出，那么这个问题将得到解决。此外，如果“example.com”提供的web应用程序还有任何其他众所周知的入口点，例如“foo.example.com”，那么它们也应该配置为发出STS头字段。
This section is non-normative.
本节是非规范性的。
In order to provide users and web sites more effective protection, as well as controls for managing their UA's caching of HSTS Policy, UA implementers should consider including features such as the following:
为了向用户和网站提供更有效的保护，以及管理UA对HSTS策略的缓存的控制，UA实施者应考虑包括以下特征：
Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry.
任何警告或错误（根据第8.4节（“安全传输建立中的错误”）导致安全连接建立失败，应在“无用户追索权”的情况下完成。这意味着不应该向用户显示一个对话框，让她选择继续。相反，它应该被类似于服务器错误来处理，在服务器错误中，除了等待和重试之外，用户在与目标web应用程序交互方面不能做任何其他事情。
Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment.
本质上，“任何警告或错误”意味着任何可能导致UA实现向用户宣布连接建立不完全正确的事情。
Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves.
不这样做，即允许用户求助，如“点击警告/错误对话框”，是中间人攻击的秘诀。如果web应用程序发布HSTS策略，那么它会隐式地选择“无用户追索权”方法，即所有证书错误或警告都会导致连接终止，而没有机会“欺骗”用户做出错误的决定并损害他们自己。
A user-declared HSTS Policy is the ability for users to explicitly declare a given domain name as representing an HSTS Host, thus seeding it as a Known HSTS Host before any actual interaction with it. This would help protect against the bootstrap MITM vulnerability as discussed in Section 14.6 ("Bootstrap MITM Vulnerability").
用户声明的HSTS策略是指用户能够显式地将给定域名声明为代表HSTS主机，从而在与HSTS主机进行任何实际交互之前将其作为已知HSTS主机进行种子设定。这将有助于防止第14.6节（“引导MITM漏洞”）中讨论的引导MITM漏洞。
NOTE: Such a feature is difficult to get right on a per-site basis. See the discussion of "rewrite rules" in Section 5.5 of [ForceHTTPS]. For example, arbitrary web sites may not materialize all their URIs using the "https" scheme and thus could "break" if a UA were to attempt to access the site exclusively using such URIs. Also note that this feature would complement, but is independent of, an "HSTS pre-loaded list" feature (see Section 12.3).
注意：在每个站点的基础上，这样的功能很难正确实现。参见[ForceHTTPS]第5.5节中“重写规则”的讨论。例如，任意网站可能无法使用“https”方案实现其所有URI，因此，如果UA试图仅使用此类URI访问该网站，则可能会“中断”。还要注意，该功能将补充但独立于“HSTS预加载列表”功能（见第12.3节）。
An HSTS pre-loaded list is a facility whereby web site administrators can have UAs pre-configured with HSTS Policy for their site(s) by the UA vendor(s) -- a so-called "pre-loaded list" -- in a manner similar to how root CA certificates are embedded in browsers "at the factory". This would help protect against the bootstrap MITM vulnerability (Section 14.6).
HSTS预加载列表是一种设施，网站管理员可以通过该设施，由UA供应商（即所谓的“预加载列表”）为其网站的UAs预配置HSTS策略，其方式类似于“在工厂”将根CA证书嵌入浏览器中的方式。这将有助于防止启动MITM漏洞（第14.6节）。
NOTE: Such a facility would complement a "user-declared HSTS Policy" feature (Section 12.2).
注：此类设施将补充“用户申报的HSTS政策”功能（第12.2节）。
"Mixed security context" loads happen when a web application resource, fetched by the UA over a secure transport, subsequently causes the fetching of one or more other resources without using secure transport. This is also generally referred to as "mixed content" loads (see Section 5.3 ("Mixed Content") in [W3C.REC-wsc-ui-20100812]) but should not be confused with the same "mixed content" term that is also used in the context of markup languages such as XML and HTML.
当UA通过安全传输获取的web应用程序资源随后导致在不使用安全传输的情况下获取一个或多个其他资源时，会发生“混合安全上下文”加载。这通常也被称为“混合内容”加载（参见[W3C.REC-wsc-ui-20100812]中的第5.3节（“混合内容”），但不应与同样的“混合内容”术语混淆，该术语也用于XML和HTML等标记语言的上下文中。
NOTE: In order to provide behavioral uniformity across UA implementations, the notion of mixed security context will require further standardization work, e.g., to define the term(s) more clearly and to define specific behaviors with respect to it.
注意：为了在UA实现中提供行为一致性，混合安全上下文的概念将需要进一步的标准化工作，例如，更清楚地定义术语并定义与之相关的特定行为。
HSTS Policy deletion is the ability to delete a UA's cached HSTS Policy on a per-HSTS Host basis.
HSTS策略删除是在每个HSTS主机的基础上删除UA缓存的HSTS策略的能力。
NOTE: Adding such a feature should be done very carefully in both the user interface and security senses. Deleting a cache entry for a Known HSTS Host should be a very deliberate and well-considered act -- it shouldn't be something that users get used to doing as a matter of course: e.g., just "clicking
注意：在用户界面和安全性方面都应该非常小心地添加这样的功能。删除已知HSTS主机的缓存项应该是一个非常慎重且经过深思熟虑的行为——用户不应该理所当然地习惯这样做：例如，只是“单击”
through" in order to get work done. Also, implementations need to guard against allowing an attacker to inject code, e.g., ECMAscript, into the UA that silently and programmatically removes entries from the UA's cache of Known HSTS Hosts.
为了完成工作，实现需要防止攻击者将代码（如ECMAscript）注入UA，从而以静默和编程方式从已知HSTS主机的UA缓存中删除条目。
13. Internationalized Domain Names for Applications (IDNA): Dependency and Migration
13. 应用程序国际化域名（IDNA）：依赖关系和迁移
Textual domain names on the modern Internet may contain one or more "internationalized" domain name labels. Such domain names are referred to as "internationalized domain names" (IDNs). The specification suites defining IDNs and the protocols for their use are named "Internationalized Domain Names for Applications (IDNA)". At this time, there are two such specification suites: IDNA2008 [RFC5890] and its predecessor IDNA2003 [RFC3490].
现代互联网上的文本域名可能包含一个或多个“国际化”域名标签。这些域名被称为“国际化域名”（IDN）。定义IDN的规范套件及其使用的协议被命名为“应用程序的国际化域名（IDNA）”。目前，有两个这样的规范套件：IDNA2008[RFC5890]及其前身IDNA2003[RFC3490]。
IDNA2008 obsoletes IDNA2003, but there are differences between the two specifications, and thus there can be differences in processing (e.g., converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. In order to facilitate their IDNA transition, user agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46]. If a user agent does not implement IDNA2008, the user agent MUST implement IDNA2003.
IDNA2008淘汰了IDNA2003，但这两个规范之间存在差异，因此在处理（例如，转换）已在其中一个规范下注册的域名标签与在另一个规范下注册的域名标签方面可能存在差异。将有一段时间的过渡期，在此期间，基于IDNA2003的域名标签将在野外存在。为了促进其IDNA转换，用户代理应实现IDNA2008[RFC5890]，并可实现[RFC5895]（另请参见[RFC5894]第7节）或[UTS46]。如果用户代理未实现IDNA2008，则该用户代理必须实现IDNA2003。
This specification concerns the expression, conveyance, and enforcement of the HSTS Policy. The overall HSTS Policy threat model, including addressed and unaddressed threats, is given in Section 2.3 ("Threat Model").
本规范涉及HSTS策略的表达、传递和实施。第2.3节（“威胁模型”）给出了整个HSTS策略威胁模型，包括已解决和未解决的威胁。
Additionally, the sections below discuss operational ramifications of the HSTS Policy, provide feature rationale, discuss potential HSTS Policy misuse, and highlight some known vulnerabilities in the HSTS Policy regime.
此外，以下各节讨论了HSTS政策的操作后果，提供了功能原理，讨论了潜在的HSTS政策滥用，并强调了HSTS政策制度中的一些已知漏洞。
This specification is fashioned to be independent of the secure transport underlying HTTP. However, the threat analysis and requirements in Section 2 ("Overview") in fact presume TLS or SSL as the underlying secure transport. Thus, employment of HSTS in the context of HTTP running over some other secure transport protocol would require assessment of that secure transport protocol's security
此规范独立于HTTP底层的安全传输。然而，第2节（“概述”）中的威胁分析和要求实际上假定TLS或SSL是底层安全传输。因此，在HTTP在其他安全传输协议上运行的情况下使用HST需要评估该安全传输协议的安全性
model in conjunction with the specifics of how HTTP is layered over it in order to assess HSTS's subsequent security properties in that context.
模型结合HTTP如何在其上分层的细节，以便评估HST在该上下文中的后续安全属性。
Non-conformant user agents ignore the Strict-Transport-Security header field; thus, non-conformant user agents do not address the threats described in Section 2.3.1 ("Threats Addressed").
不一致的用户代理忽略严格的传输安全头字段；因此，非一致用户代理不解决第2.3.1节（“已解决的威胁”）中描述的威胁。
This means that the web application and its users wielding non-conformant UAs will be vulnerable to both of the following:
这意味着web应用程序及其使用非一致性UAs的用户将容易受到以下两种情况的攻击：
o Passive network attacks due to web site development and deployment bugs:
o 网站开发和部署错误导致的被动网络攻击：
For example, if the web application contains any insecure references (e.g., "http") to the web application server, and if not all of its cookies are flagged as "Secure", then its cookies will be vulnerable to passive network sniffing and, potentially, subsequent misuse of user credentials.
例如，如果web应用程序包含对web应用程序服务器的任何不安全引用（例如，“http”），并且如果并非其所有cookie都标记为“安全”，则其cookie将容易受到被动网络嗅探的攻击，并可能随后误用用户凭据。
o Active network attacks:
o 主动网络攻击：
For example, if an attacker is able to place a "man in the middle", secure transport connection attempts will likely yield warnings to the user, but without HSTS Policy being enforced, the present common practice is to allow the user to "click through" and proceed. This renders the user and possibly the web application open to abuse by such an attacker.
例如，如果攻击者能够将“人放在中间”，则安全传输连接尝试可能会向用户发出警告，但在不强制实施HSTS策略的情况下，目前的常见做法是允许用户“点击”并继续。这使得用户和可能的web应用程序容易被此类攻击者滥用。
This is essentially the status quo for all web applications and their users in the absence of HSTS Policy. Since web application providers typically do not control the type or version of UAs their web applications interact with, the implication is that HSTS Host deployers must generally exercise the same level of care to avoid web site development and deployment bugs (see Section 2.3.1.3) as they would if they were not asserting HSTS Policy.
在缺乏HSTS政策的情况下，所有web应用程序及其用户基本上都是这样。由于web应用程序提供商通常不控制其web应用程序与之交互的UAs的类型或版本，这意味着HSTS主机部署人员通常必须采取与未声明HSTS策略时相同的谨慎措施来避免网站开发和部署错误（见第2.3.1.3节）。
14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport
14.3. HSTS策略建立仅对无错误安全传输的影响
The user agent processing model defined in Section 8 ("User Agent Processing Model") stipulates that a host is initially noted as a Known HSTS Host, or that updates are made to a Known HSTS Host's cached information, only if the UA receives the STS header field over a secure transport connection having no underlying secure transport errors or warnings.
第8节（“用户代理处理模型”）中定义的用户代理处理模型规定，主机最初被标记为已知HSTS主机，或者对已知HSTS主机的缓存信息进行更新，仅当UA通过安全传输连接接收到STS标头字段时，该连接没有潜在的安全传输错误或警告。
The rationale behind this is that if there is a "man in the middle" (MITM) -- whether a legitimately deployed proxy or an illegitimate entity -- it could cause various mischief (see also Appendix A ("Design Decision Notes") item 3, as well as Section 14.6 ("Bootstrap MITM Vulnerability")); for example:
这背后的理由是，如果存在“中间人”（MITM）——无论是合法部署的代理还是非法实体——可能会造成各种危害（另请参见附录a（“设计决策说明”）第3项，以及第14.6节（“引导MITM漏洞”）；例如：
o Unauthorized notation of the host as a Known HSTS Host, potentially leading to a denial-of-service situation if the host does not uniformly offer its services over secure transport (see also Section 14.5 ("Denial of Service")).
o 未经授权将主机标记为已知HSTS主机，如果主机未通过安全传输统一提供服务，则可能导致拒绝服务情况（另请参见第14.5节（“拒绝服务”））。
o Resetting the time to live for the host's designation as a Known HSTS Host by manipulating the max-age header field parameter value that is returned to the UA. If max-age is returned as zero, this will cause the host to cease being regarded as a Known HSTS Host by the UA, leading to either insecure connections to the host or possibly denial of service if the host delivers its services only over secure transport.
o 通过操作返回给UA的最大年龄标头字段参数值，重置主机指定为已知HSTS主机的生存时间。如果max age返回为零，这将导致主机不再被UA视为已知的HSTS主机，从而导致与主机的连接不安全，或者如果主机仅通过安全传输提供服务，则可能导致拒绝服务。
However, this means that if a UA is "behind" a MITM non-transparent TLS proxy -- within a corporate intranet, for example -- and interacts with an unknown HSTS Host beyond the proxy, the user could possibly be presented with the legacy secure connection error dialogs. Even if the risk is accepted and the user "clicks through", the host will not be noted as an HSTS Host. Thus, as long as the UA is behind such a proxy, the user will be vulnerable and will possibly be presented with the legacy secure connection error dialogs for as-yet unknown HSTS Hosts.
然而，这意味着，如果UA“位于”MITM不透明TLS代理之后（例如，在公司内部网内），并且与代理之外的未知HSTS主机进行交互，则用户可能会看到传统的安全连接错误对话框。即使风险被接受且用户“点击通过”，主机也不会被视为HSTS主机。因此，只要UA在这样一个代理之后，用户就会容易受到攻击，并且可能会出现未知HSTS主机的传统安全连接错误对话框。
Once the UA successfully connects to an unknown HSTS Host over error-free secure transport, the host will be noted as a Known HSTS Host. This will result in the failure of subsequent connection attempts from behind interfering proxies.
一旦UA通过无错误安全传输成功连接到未知HSTS主机，该主机将被标记为已知HSTS主机。这将导致来自干扰代理后面的后续连接尝试失败。
The above discussion relates to the recommendation in Section 12 ("User Agent Implementation Advice") that the secure connection be terminated with "no user recourse" whenever there are warnings and errors and the host is a Known HSTS Host. Such a posture protects users from "clicking through" security warnings and putting themselves at risk.
上述讨论涉及第12节（“用户代理实施建议”）中的建议，即每当出现警告和错误且主机为已知HSTS主机时，应在“无用户追索权”的情况下终止安全连接。这样的姿态可以保护用户免受“点击”安全警告和风险。
Without the includeSubDomains directive, a web application would not be able to adequately protect so-called "domain cookies" (even if these cookies have their "Secure" flag set and thus are conveyed only on secure channels). These are cookies the web application expects UAs to return to any and all subdomains of the web application.
如果没有includeSubDomains指令，web应用程序将无法充分保护所谓的“域cookie”（即使这些cookie设置了“安全”标志，因此只能在安全通道上传输）。这些是web应用程序希望UAs返回到web应用程序的任何和所有子域的cookie。
For example, suppose example.com represents the top-level DNS name for a web application. Further suppose that this cookie is set for the entire example.com domain, i.e., it is a "domain cookie", and it has its Secure flag set. Suppose example.com is a Known HSTS Host for this UA, but the includeSubDomains directive is not set.
例如，假设example.com代表web应用程序的顶级DNS名称。进一步假设该cookie是为整个example.com域设置的，即它是一个“域cookie”，并且它设置了安全标志。假设example.com是该UA的已知HSTS主机，但未设置includeSubDomains指令。
Now, if an attacker causes the UA to request a subdomain name that is unlikely to already exist in the web application, such as "https://uxdhbpahpdsf.example.com/", but that the attacker has managed to register in the DNS and point at an HTTP server under the attacker's control, then:
现在，如果攻击者导致UA请求web应用程序中不太可能已经存在的子域名，例如“https://uxdhbpahpdsf.example.com/，但如果攻击者已成功在DNS中注册并指向攻击者控制下的HTTP服务器，则：
1. The UA is unlikely to already have an HSTS Policy established for "uxdhbpahpdsf.example.com".
1. UA不太可能已经为“uxdhbpahpdsf.example.com”制定了HSTS政策。
2. The HTTP request sent to uxdhbpahpdsf.example.com will include the Secure-flagged domain cookie.
2. 发送到uxdhbpahpdsf.example.com的HTTP请求将包括安全标记的域cookie。
3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS establishment, and the user "clicks through" any warning that might be presented (it is possible, but not certain, that one may obtain a requisite certificate for such a domain name such that a warning may or may not appear), then the attacker can obtain the Secure-flagged domain cookie that's ostensibly being protected.
3. 如果“uxdhbpahpdsf.example.com”在TLS建立期间返回证书，并且用户“点击”可能出现的任何警告（可能，但不确定，用户可能会获得此类域名的必要证书，从而出现或不出现警告），然后，攻击者可以获得表面上受到保护的安全标记域cookie。
Without the "includeSubDomains" directive, HSTS is unable to protect such Secure-flagged domain cookies.
如果没有“includeSubDomains”指令，HSTS将无法保护此类安全标记的域cookie。
HSTS could be used to mount certain forms of Denial-of-Service (DoS) attacks against web sites. A DoS attack is an attack in which one or more network entities target a victim entity and attempt to prevent the victim from doing useful work. This section discusses such scenarios in terms of HSTS, though this list is not exhaustive. See also [RFC4732] for a discussion of overall Internet DoS considerations.
HST可用于对网站发起某种形式的拒绝服务（DoS）攻击。DoS攻击是一种攻击，其中一个或多个网络实体以受害者实体为目标，试图阻止受害者进行有用的工作。本节将从HST的角度讨论此类场景，尽管此列表并不详尽。另请参见[RFC4732]，了解有关Internet DoS总体考虑事项的讨论。
o Web applications available over HTTP
o 通过HTTP提供的Web应用程序
There is an opportunity for perpetrating DoS attacks with web applications (or critical portions of them) that are available only over HTTP without secure transport, if attackers can cause UAs to set HSTS Policy for such web applications' host(s).
如果攻击者可以导致UAs为此类web应用程序的主机设置HSTS策略，则有可能对仅通过HTTP而不进行安全传输的web应用程序（或其关键部分）实施DoS攻击。
This is because once the HSTS Policy is set for a web application's host in a UA, the UA will only use secure transport to communicate with the host. If the host is not using secure
这是因为一旦在UA中为web应用程序的主机设置了HSTS策略，UA将仅使用安全传输与主机通信。如果主机未使用安全
transport or is not using it for critical portions of its web application, then the web application will be rendered unusable for the UA's user.
传输或未将其用于其web应用程序的关键部分，则该web应用程序将对UA的用户不可用。
NOTE: This is a use case for UAs to offer an "HSTS Policy deletion" feature as noted in Section 12.5 ("HSTS Policy Deletion").
注：这是UAs提供“HSTS策略删除”功能的用例，如第12.5节（“HSTS策略删除”）所述。
An HSTS Policy can be set for a victim host in various ways:
可以通过多种方式为受害主机设置HSTS策略：
* If the web application has an HTTP response splitting vulnerability [CWE-113] (which can be abused in order to facilitate "HTTP header injection").
* 如果web应用程序具有HTTP响应拆分漏洞[CWE-113]（可滥用该漏洞以促进“HTTP标头注入”）。
* If an attacker can spoof a redirect from an insecure victim site, e.g., <http://example.com/> to <https://example.com/>, where the latter is attacker-controlled and has an apparently valid certificate. In this situation, the attacker can then set an HSTS Policy for example.com and also for all subdomains of example.com.
* 如果攻击者可以从不安全的受害者站点欺骗重定向，例如<http://example.com/>到<https://example.com/>，其中后者受攻击者控制，并且具有明显有效的证书。在这种情况下，攻击者可以为example.com以及example.com的所有子域设置HSTS策略。
* If an attacker can convince users to manually configure HSTS Policy for a victim host. This assumes that their UAs offer such a capability (see Section 12 ("User Agent Implementation Advice")). Alternatively, if such UA configuration is scriptable, then an attacker can cause UAs to execute his script and set HSTS Policies for whichever desired domains.
* 如果攻击者能够说服用户为受害主机手动配置HSTS策略。这假设他们的UAs提供这种能力（见第12节（“用户代理实施建议”）。或者，如果这种UA配置是可编写脚本的，则攻击者可以让UAs执行其脚本，并为任何所需的域设置HSTS策略。
o Inadvertent use of includeSubDomains
o 意外使用includeSubDomains
The includeSubDomains directive instructs UAs to automatically regard all subdomains of the given HSTS Host as Known HSTS Hosts. If any such subdomains do not support properly configured secure transport, then they will be rendered unreachable from such UAs.
includeSubDomains指令指示UAs自动将给定HSTS主机的所有子域视为已知HSTS主机。如果任何这样的子域不支持正确配置的安全传输，那么它们将无法从这样的UAs访问。
Bootstrap MITM (man-in-the-middle) vulnerability is a vulnerability that users and HSTS Hosts encounter in the situation where the user manually enters, or follows a link, to an unknown HSTS Host using an "http" URI rather than an "https" URI. Because the UA uses an insecure channel in the initial attempt to interact with the specified server, such an initial interaction is vulnerable to various attacks (see Section 5.3 of [ForceHTTPS]).
Bootstrap MITM（中间人）漏洞是用户和HSTS主机在用户使用“http”URI而不是“https”URI手动输入或链接到未知HSTS主机时遇到的漏洞。由于UA在与指定服务器交互的初始尝试中使用了不安全通道，因此这种初始交互容易受到各种攻击（请参见[ForceHTTPS]第5.3节）。
NOTE: There are various features/facilities that UA implementations may employ in order to mitigate this vulnerability. Please see Section 12 ("User Agent Implementation Advice").
注意：UA实施可能采用各种功能/设施来缓解此漏洞。请参阅第12节（“用户代理实施建议”）。
Active network attacks can subvert network time protocols (such as the Network Time Protocol (NTP) [RFC5905]) -- making HSTS less effective against clients that trust NTP or lack a real time clock. Network time attacks are beyond the scope of this specification. Note that modern operating systems use NTP by default. See also Section 2.10 of [RFC4732].
主动网络攻击可以破坏网络时间协议（如网络时间协议（NTP）[RFC5905]）——使HST对信任NTP或缺少实时时钟的客户端的效率降低。网络时间攻击超出了本规范的范围。请注意，现代操作系统默认使用NTP。另见[RFC4732]第2.10节。
An attacker could conceivably obtain users' login credentials belonging to a victim HSTS-protected web application via a bogus root CA certificate phish plus DNS cache poisoning attack.
攻击者可以通过伪造的根CA证书钓鱼加DNS缓存中毒攻击获得属于受HSTS保护的受害者web应用程序的用户登录凭据。
For example, the attacker could first convince users of a victim web application (which is protected by HSTS Policy) to install the attacker's version of a root CA certificate purporting (falsely) to represent the CA of the victim web application. This might be accomplished by sending the users a phishing email message with a link to such a certificate, which their browsers may offer to install if clicked on.
例如，攻击者可以首先说服受害者web应用程序（受HSTS策略保护）的用户安装攻击者版本的根CA证书，声称（错误地）代表受害者web应用程序的CA。这可以通过向用户发送一封带有此类证书链接的网络钓鱼电子邮件来实现，如果点击，他们的浏览器可能会提供安装该证书的链接。
Then, if the attacker can perform an attack on the users' DNS servers, (e.g., via cache poisoning) and turn on HSTS Policy for their fake web application, the affected users' browsers would access the attacker's web application rather than the legitimate web application.
然后，如果攻击者可以对用户的DNS服务器执行攻击（例如，通过缓存中毒）并为其伪造的web应用程序启用HSTS策略，则受影响用户的浏览器将访问攻击者的web应用程序，而不是合法的web应用程序。
This type of attack leverages vectors that are outside of the scope of HSTS. However, the feasibility of such threats can be mitigated by including in a web application's overall deployment approach appropriate employment, in addition to HSTS, of security facilities such as DNS Security Extensions [RFC4033], plus techniques to block email phishing and fake certificate injection.
这种类型的攻击利用HST范围之外的向量。然而，这种威胁的可行性可以通过在web应用程序的总体部署方法中包括除HST外适当使用DNS安全扩展[RFC4033]等安全设施，以及阻止电子邮件钓鱼和伪证书注入的技术来缓解。
Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains).
由于HSTS主机可以选择自己的主机名及其子域，并且该信息被缓存在符合UAs的HSTS策略存储中，控制一个或多个HSTS主机的人可以将信息编码到他们控制的域名中，并使这些UAs在记录HSTS主机的过程中理所当然地缓存这些信息。其他主机可以通过巧妙构造和加载的web资源来检索这些信息，从而使UA向编码域名发送查询（变体）。此类查询可以揭示UA之前是否访问过原始HSTS主机（和子域）。
Such a technique could potentially be abused as yet another form of "web tracking" [WebTracking].
这种技术可能被滥用，成为另一种形式的“网络跟踪”[网络跟踪]。
Internet security relies in part on the DNS and the domain names it hosts. Domain names are used by users to identify and connect to Internet hosts and other network resources. For example, Internet security is compromised if a user entering an internationalized domain name (IDN) is connected to different hosts based on different interpretations of the IDN.
互联网安全部分依赖于DNS及其承载的域名。域名被用户用来识别并连接到Internet主机和其他网络资源。例如，如果输入国际化域名（IDN）的用户基于对IDN的不同解释连接到不同的主机，则会危及互联网安全。
The processing models specified in this specification assume that the domain names they manipulate are IDNA-canonicalized, and that the canonicalization process correctly performed all appropriate IDNA and Unicode validations and character list testing per the requisite specifications (e.g., as noted in Section 10 ("Domain Name IDNA-Canonicalization")). These steps are necessary in order to avoid various potentially compromising situations.
本规范中规定的处理模型假设他们操作的域名是IDNA规范化的，并且规范化过程根据必要的规范正确执行了所有适当的IDNA和Unicode验证以及字符列表测试（如第10节所述）(“域名IDNA规范化”）。这些步骤是必要的，以避免各种潜在的危害情况。
In brief, examples of issues that could stem from lack of careful and consistent Unicode and IDNA validations include unexpected processing exceptions, truncation errors, and buffer overflows, as well as false-positive and/or false-negative domain name matching results. Any of the foregoing issues could possibly be leveraged by attackers in various ways.
简言之，缺乏仔细一致的Unicode和IDNA验证可能导致的问题示例包括意外的处理异常、截断错误和缓冲区溢出，以及假阳性和/或假阴性域名匹配结果。攻击者可能以各种方式利用上述任何问题。
Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in terms of disallowed characters and character mapping conventions. This situation can also lead to false-positive and/or false-negative domain name matching results, resulting in, for example, users possibly communicating with unintended hosts or not being able to reach intended hosts.
此外，IDNA2008[RFC5890]与IDNA2003[RFC3490]在不允许的字符和字符映射约定方面有所不同。这种情况还可能导致域名匹配结果出现假阳性和/或假阴性，例如，用户可能与非预期主机通信或无法访问预期主机。
For details, refer to the Security Considerations sections of [RFC5890], [RFC5891], and [RFC3490], as well as the specifications they normatively reference. Additionally, [RFC5894] provides detailed background and rationale for IDNA2008 in particular, as well as IDNA and its issues in general, and should be consulted in conjunction with the former specifications.
有关详细信息，请参阅[RFC5890]、[RFC5891]和[RFC3490]的安全注意事项部分，以及它们通常引用的规范。此外，[RFC5894]特别提供了IDNA2008的详细背景和基本原理，以及IDNA及其一般问题，应结合以前的规范进行咨询。
Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864].
以下是互联网分配号码管理局（IANA）根据[RFC3864]提供的永久消息头字段注册信息。
Header field name: Strict-Transport-Security
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document(s): this one
Header field name: Strict-Transport-Security
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document(s): this one
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, September 2010.
[RFC5895]Resnick，P.和P.Hoffman，“应用程序中国际化域名的映射字符（IDNA）2008”，RFC 58952010年9月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月。
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility Processing", Unicode Technical Standard #46, <http://unicode.org/reports/tr46/>.
[UTS46]Davis，M.和M.Suignard，“Unicode IDNA兼容性处理”，Unicode技术标准#46<http://unicode.org/reports/tr46/>.
[Unicode] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[Unicode]Unicode联盟，“Unicode标准”<http://www.unicode.org/versions/latest/>.
[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224/>.
[W3C.REC-html401-19991224]Raggett，D.，Le Hors，A.和I.Jacobs，“HTML 4.01规范”，万维网联盟建议REC-html401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224/>.
[Aircrack-ng] d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, <http://www.aircrack-ng.org/>.
[Aircrack ng]d'Otreppe，T.，“Aircrack ng”，查阅日期：2010年7月11日<http://www.aircrack-ng.org/>.
[BeckTews09] Beck, M. and E. Tews, "Practical Attacks Against WEP and WPA", Second ACM Conference on Wireless Network Security Zurich, Switzerland, 2009, <http://dl.acm.org/citation.cfm?id=1514286>.
[BeckTews09]Beck，M.和E.Tews，“针对WEP和WPA的实际攻击”，第二届ACM无线网络安全会议，瑞士苏黎世，2009年<http://dl.acm.org/citation.cfm?id=1514286>.
[CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')", Common Weakness Enumeration <http://cwe.mitre.org/>, The Mitre Corporation <http://www.mitre.org/>, <http://cwe.mitre.org/data/definitions/113.html>.
[CWE-113]“CWE-113:HTTP头中CRLF序列的不正确中和（'HTTP响应拆分'）”，常见弱点枚举<http://cwe.mitre.org/>，米特公司<http://www.mitre.org/>, <http://cwe.mitre.org/data/definitions/113.html>.
[Firesheep] Various, "Firesheep", Wikipedia Online, ongoing, <https:// secure.wikimedia.org/wikipedia/en/w/ index.php?title=Firesheep&oldid=517474182>.
[Firesheep]各种，“Firesheep”，维基百科在线，正在进行，<https://secure.wikimedia.org/Wikipedia/en/w/index.php？title=Firesheep&oldid=5174182>。
[ForceHTTPS] Jackson, C. and A. Barth, "ForceHTTPS: Protecting High-Security Web Sites from Network Attacks", In Proceedings of the 17th International World Wide Web Conference (WWW2008) , 2008, <https://crypto.stanford.edu/forcehttps/>.
[ForceHTTPS]Jackson，C.和A.Barth，“ForceHTTPS：保护高安全性网站免受网络攻击”，2008年第17届国际万维网会议记录（WWW2008）<https://crypto.stanford.edu/forcehttps/>.
[GoodDhamijaEtAl05] Good, N., Dhamija, R., Grossklags, J., Thaw, D., Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping Spyware at the Gate: A User Study of Privacy, Notice and Spyware", In Proceedings of Symposium On Usable Privacy and Security (SOUPS) Pittsburgh, PA, USA, July 2005, <http://www.law.berkeley.edu/files/ Spyware_at_the_Gate.pdf>.
[GoodDhamijaEtAl05]Good，N.，Dhamija，R.，Grossklags，J.，Thaw，D.，Aronowitz，S.，Mulligan，D.，和J.Konstan，“在大门前阻止间谍软件：隐私、通知和间谍软件的用户研究”，《可用隐私和安全研讨会论文集》，美国宾夕法尼亚州匹兹堡，2005年7月， <http://www.law.berkeley.edu/files/ 间谍软件在门上。
[HTTP1_1-UPD] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", Work in Progress, October 2012.
[HTTP1_1-UPD]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，正在进行的工作，2012年10月。
[JacksonBarth2008] Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", Web 2.0 Security and Privacy Workshop, Oakland, CA, USA, 2008, <http://seclab.stanford.edu/websec/origins/fgo.pdf>.
[JacksonBarth2008]Jackson，C.和A.Barth，“小心更细粒度的起源”，Web2.0安全和隐私研讨会，美国加利福尼亚州奥克兰，2008年<http://seclab.stanford.edu/websec/origins/fgo.pdf>.
[OWASP-TLSGuide] Coates, M., Wichers, D., Boberski, M., and T. Reguly, "Transport Layer Protection Cheat Sheet", Accessed: 11-Jul-2010, <http://www.owasp.org/index.php/ Transport_Layer_Protection_Cheat_Sheet>.
[OWASP TLSGuide]Coates，M.，Wichers，D.，Boberski，M.，和T.Reguly，“传输层保护备忘单”，查阅日期：2010年7月11日<http://www.owasp.org/index.php/ 传输\u层\u保护\u备忘单>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894]Klensin，J.“应用程序的国际化域名（IDNA）：背景、解释和基本原理”，RFC 58942010年8月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]Mills，D.，Martin，J.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011.
[RFC6101]Freier，A.，Karlton，P.，和P.Kocher，“安全套接字层（SSL）协议版本3.0”，RFC 61012011年8月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月。
[SunshineEgelmanEtAl09] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", In Proceedings of 18th USENIX Security Symposium Montreal, Canada, August 2009, <http:// www.usenix.org/events/sec09/tech/full_papers/ sunshine.pdf>.
[SunshineEgelmanEtAl09]Sunshine，J.，Egelman，S.，Almuhimedi，H.，Atri，N.，和L.Cranor，“狼来了：SSL警告有效性的实证研究”，载于加拿大蒙特利尔第18届USENIX安全研讨会论文集，2009年8月，<http://www.USENIX.org/events/sec09/tech/full_papers/Sunshine.pdf>。
[W3C.REC-wsc-ui-20100812] Roessler, T. and A. Saldhana, "Web Security Context: User Interface Guidelines", World Wide Web Consortium Recommendation REC-wsc-ui-20100812, August 2010, <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.
[W3C.REC-wsc-ui-20100812]Roessler，T.和A.Saldhana，“网络安全环境：用户界面指南”，万维网联盟建议REC-wsc-ui-20100812，2010年8月<http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.
[WebTracking] Schmucker, N., "Web Tracking", SNET2 Seminar Paper - Summer Term, 2011, <http://www.snet.tu-berlin.de/ fileadmin/fg220/courses/SS11/snet-project/ web-tracking_schmuecker.pdf>.
[网络追踪]Schmucker，N.，“网络追踪”，SNET2研讨会论文-夏季学期，2011年<http://www.snet.tu-berlin.de/ fileadmin/fg220/courses/SS11/snet project/web-tracking\u schmuecker.pdf>。
This appendix documents various design decisions.
本附录记录了各种设计决策。
1. Cookies aren't appropriate for HSTS Policy expression, as they are potentially mutable (while stored in the UA); therefore, an HTTP header field is employed.
1. Cookie不适合HSTS策略表达式，因为它们可能是可变的（存储在UA中）；因此，采用了HTTP头字段。
2. We chose to not attempt to specify how "mixed security context loads" (also known as "mixed content loads") are handled, due to UA implementation considerations as well as classification difficulties.
2. 由于UA实现方面的考虑以及分类方面的困难，我们选择不尝试指定如何处理“混合安全上下文负载”（也称为“混合内容负载”）。
3. An HSTS Host may update UA notions of HSTS Policy via new HSTS header field parameter values. We chose to have UAs honor the "freshest" information received from a server because there is the chance of a web site sending out an erroneous HSTS Policy, such as a multi-year max-age value, and/or an incorrect includeSubDomains directive. If the HSTS Host couldn't correct such errors over protocol, it would require some form of annunciation to users and manual intervention on the users' part, which could be a non-trivial problem for both web application providers and their users.
3. HSTS主机可以通过新的HSTS头字段参数值更新HSTS策略的UA概念。我们选择让UAs尊重从服务器收到的“最新”信息，因为网站有可能发送错误的HSTS策略，例如多年最大年限值和/或错误的includeSubDomains指令。如果HSTS主机无法通过协议纠正此类错误，则需要向用户发出某种形式的通知，并由用户进行手动干预，这对于web应用程序提供商及其用户来说都是一个非常重要的问题。
4. HSTS Hosts are identified only via domain names -- explicit IP address identification of all forms is excluded. This is for simplification and also is in recognition of various issues with using direct IP address identification in concert with PKI-based security.
4. HSTS主机仅通过域名标识——所有形式的显式IP地址标识均不包括在内。这是为了简化，也是为了认识到与基于PKI的安全性配合使用直接IP地址标识的各种问题。
5. The max-age approach of having the HSTS Host provide a simple integer number of seconds for a cached HSTS Policy time-to-live value, as opposed to an approach of stating an expiration time in the future, was chosen for various reasons. Amongst the reasons are no need for clock synchronization, no need to define date and time value syntaxes (specification simplicity), and implementation simplicity.
5. 出于各种原因，选择了让HSTS主机为缓存的HSTS策略生存时间值提供简单整数秒的最长期限方法，而不是在将来声明过期时间的方法。其中的原因是不需要时钟同步，不需要定义日期和时间值语法（规范的简单性），以及实现的简单性。
6. In determining whether port mapping was to be employed, the option of merely refusing to dereference any URL with an explicit port was considered. It was felt, though, that the possibility that the URI to be dereferenced is incorrect (and there is indeed a valid HTTPS server at that port) is worth the small cost of possibly wasted HTTPS fetches to HTTP servers.
6. 在确定是否使用端口映射时，考虑了仅拒绝使用显式端口取消引用任何URL的选项。不过，有人认为，要取消引用的URI可能不正确（并且该端口上确实存在有效的HTTPS服务器）值得为可能浪费的HTTPS获取HTTP服务器付出少量代价。
HSTS Policy has the following primary characteristics:
HSTS政策具有以下主要特征：
HSTS Policy stipulates requirements for the security characteristics of UA-to-host connection establishment, on a per-host basis.
HSTS政策规定了基于每台主机的UA到主机连接建立的安全特性要求。
Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are obliged to implement hosts' declared HSTS Policies.
主机向UAs明确声明HSTS策略。合规UAs有义务实施主机声明的HSTS策略。
HSTS Policy is conveyed over protocol from the host to the UA.
HSTS策略通过协议从主机传输到UA。
The UA maintains a cache of Known HSTS Hosts.
UA维护已知HSTS主机的缓存。
UAs apply HSTS Policy whenever making an HTTP connection to a Known HSTS Host, regardless of host port number; i.e., it applies to all ports on a Known HSTS Host. Hosts are unable to affect this aspect of HSTS Policy.
UAs在与已知HSTS主机进行HTTP连接时应用HSTS策略，无论主机端口号为何；i、 例如，它适用于已知HSTS主机上的所有端口。主机无法影响HSTS策略的这一方面。
Hosts may optionally declare that their HSTS Policy applies to all subdomains of their host domain name.
主机可以选择性地声明其HSTS策略适用于其主机域名的所有子域。
In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following primary characteristics:
相比之下，同一原产地政策（SOP）[RFC6454]具有以下主要特征：
An origin is the scheme, host, and port of a URI identifying a resource.
来源是标识资源的URI的方案、主机和端口。
A UA may dereference a URI, thus loading a representation of the resource the URI identifies. UAs label resource representations with their origins, which are derived from their URIs.
UA可以解除对URI的引用，从而加载URI标识的资源的表示。UAs标记资源表示及其来源，这些来源是从其URI派生的。
The SOP refers to a collection of principles, implemented within UAs, governing the isolation of and communication between resource representations within the UA, as well as resource representations' access to network resources.
SOP是指在UA内实施的一系列原则，这些原则管理UA内资源表示的隔离和通信，以及资源表示对网络资源的访问。
In summary, although both HSTS Policy and SOP are enforced by UAs, HSTS Policy is optionally declared by hosts and is not origin-based, while the SOP applies to all resource representations loaded from all hosts by conformant UAs.
总之，尽管HSTS策略和SOP都是由UAs强制执行的，但HSTS策略可以选择由主机声明，并且不是基于源站的，而SOP适用于由一致的UAs从所有主机加载的所有资源表示。
The authors thank Devdatta Akhawe, Michael Barrett, Ben Campbell, Tobias Gondrom, Paul Hoffman, Murray Kucherawy, Barry Leiba, James Manger, Alexey Melnikov, Haevard Molland, Yoav Nir, Yngve N. Pettersen, Laksh Raghavan, Marsh Ray, Julian Reschke, Eric Rescorla, Tom Ritter, Peter Saint-Andre, Brian Smith, Robert Sparks, Maciej Stachowiak, Sid Stamm, Andy Steingrubl, Brandon Sterne, Martin Thomson, Daniel Veditz, and Jan Wrobel, as well as all the websec working group participants and others for their various reviews and helpful contributions.
作者感谢德夫达塔·阿克哈、迈克尔·巴雷特、本·坎贝尔、托比亚斯·冈德罗姆、保罗·霍夫曼、默里·库奇拉维、巴里·莱巴、詹姆斯·马格尔、阿列克谢·梅尔尼科夫、海瓦德·莫兰、约阿夫·尼尔、伊格维·佩特森、拉什·拉格万、马什·雷、朱利安·雷什克、埃里克·雷斯考拉、汤姆·里特、彼得·圣安德烈、布莱恩·史密斯、罗伯特·斯帕克斯、麦基·斯塔乔克、，Sid Stamm、Andy Steingrubl、Brandon Sterne、Martin Thomson、Daniel Veditz和Jan Wrobel，以及所有websec工作组参与者和其他人，感谢他们的各种评论和有益贡献。
Thanks to Julian Reschke for his elegant rewriting of the effective request URI text, which he did when incorporating the ERU notion into the updates to HTTP/1.1 [HTTP1_1-UPD]. Subsequently, the ERU text in this spec was lifted from Julian's work in the updated HTTP/1.1 (part 1) specification and adapted to the [RFC2616] ABNF.
感谢Julian Reschke优雅地重写了有效的请求URI文本，他在将ERU概念合并到HTTP/1.1[HTTP1_1-UPD]的更新中时做到了这一点。随后，本规范中的ERU文本从Julian在更新的HTTP/1.1（第1部分）规范中的工作中删除，并改编为[RFC2616]ABNF。
Authors' Addresses
作者地址
Jeff Hodges PayPal 2211 North First Street San Jose, California 95131 US
杰夫·霍奇斯·贝宝美国加利福尼亚州圣何塞北第一街2211号95131
EMail: Jeff.Hodges@PayPal.com
EMail: Jeff.Hodges@PayPal.com
Collin Jackson Carnegie Mellon University
柯林·杰克逊卡内基梅隆大学
EMail: collin.jackson@sv.cmu.edu
EMail: collin.jackson@sv.cmu.edu
Adam Barth Google, Inc.
亚当·巴特谷歌公司。
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/