1. Introduction (简介)

HTTP [RFC2616] 可以在各种传输层上使用, 通常是传输控制协议 (Transmission Control Protocol, TCP). 然而, TCP不提供通道完整性保护 (channel integrity protection)、机密性 (confidentiality) 或安全主机标识 (secure host identification). 因此, 开发了安全套接字层 (Secure Sockets Layer, SSL) 协议 [RFC6101] 及其后续版本传输层安全 (Transport Layer Security, TLS) [RFC5246] 来提供面向通道的安全性, 它们通常被分层在应用协议和TCP之间. [RFC2818] 规定了HTTP如何分层在TLS之上, 并定义了"https"统一资源标识符 (Uniform Resource Identifier, URI) 方案 (实际上, HTTP用户代理 (User Agents, UAs) 通常使用TLS或SSL3, 具体取决于与服务器协商和用户偏好的组合).

UAs在与Web资源交互时采用各种本地安全策略, 这些策略的特性部分取决于它们是使用HTTP还是HTTP-over-Secure-Transport与给定Web资源的主机通信. 例如, Cookie ([RFC6265]) 可以被标记为Secure. UAs必须仅通过安全传输将此类Secure Cookie发送到其目标主机. 这与非Secure Cookie形成对比, 后者无论传输方式如何都会返回给主机 (尽管受其他规则约束).

UAs通常会向用户通告安全连接建立时的任何问题, 例如无法验证TLS服务器证书信任链、TLS服务器证书过期, 或TLS主机的域名在TLS服务器证书中显示不正确 (参见 [RFC2818] 第3.1节). 通常, UAs允许用户选择在面对此类问题时继续与Web资源的主机交互. 这种行为有时被称为"点击通过 (clicking through)" 安全 [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09], 因此可以被描述为"点击通过不安全 (click-through insecurity)".

点击通过不安全导致的一个关键漏洞是泄露Web资源可能用于管理用户会话的任何Cookie. 这里的威胁是攻击者可以获取Cookie, 然后在冒充用户的同时与合法Web资源交互.

Jackson和Barth在 [ForceHTTPS] 中提出了一种方法, 使Web资源能够声明与UA的任何交互都必须安全地进行, 并且建立安全传输会话时的任何问题都应被视为致命的, 用户无法直接绕过. 其目的是防止点击通过不安全并应对其他潜在威胁.

本规范体现并完善了 [ForceHTTPS] 中提出的方法. 例如, 它定义了一个HTTP响应头字段来实现此目的, 而不是使用Cookie从Web资源的主机向UA传达策略. 此外, Web资源的主机可以声明其策略适用于以其主机名为根的整个域名子树. 这使得HTTP严格传输安全 (HTTP Strict Transport Security, HSTS) 能够保护所谓的"域Cookie (domain cookies)", 它们适用于给定Web资源主机名的所有子域.

本规范还融合了 [JacksonBarth2008] 中的概念, 即策略是在"整个主机 (entire-host)" 基础上应用的: 它适用于颁发主机的任何TCP端口上的HTTP (仅限HTTP).

请注意, 本规范定义的策略与"Web来源概念 (The Web Origin Concept)" [RFC6454] 中定义的"同源策略 (same-origin policy)" 截然不同. 这些差异在附录B中进行了总结.

1.1 Organization of This Specification (本规范的组织)

本规范首先概述HSTS的使用场景、策略效果、威胁模型和需求 (在第2节中). 然后, 第3节定义一致性要求. 第4节定义与本文档相关的术语. HSTS机制本身在第5节到第15节中正式规定.

1.2 Document Conventions (文档约定)

注意 (NOTE): 这是给读者的注释. 这些是应该明确记住和/或考虑的要点.