1. Introduction (简介)

HTTP 可以运行在多种 transport 上, 最常见的是 TCP. 但 TCP 不提供 channel integrity protection, confidentiality 或安全的 host identification. 因此 SSL 及其后继者 TLS 被设计出来, 通常位于应用协议和 TCP 之间, 为 HTTP 等协议提供面向通道的安全性. RFC 2818 定义了 HTTP 如何运行在 TLS 之上, 并定义了 https URI scheme.

User Agent (UA) 与 Web resource 交互时会应用本地安全策略. 这些策略往往取决于通信是通过普通 HTTP 还是通过 secure transport 进行. 例如带有 Secure attribute 的 cookie 只能经 secure transport 发送, 而非 Secure cookie 可能在普通 HTTP 请求中暴露.

UA 通常会把 TLS certificate chain 无法验证, certificate 过期或 hostname 不匹配等问题告知用户. 许多 UA 允许用户继续访问, 这种行为常被称为 "click-through security", 实际上会造成 "click-through insecurity". 攻击者可利用这种行为窃取 session cookie, 然后冒充用户访问合法站点.

HSTS 的思想是让 Web resource 声明: UA 与该 host 的后续交互必须使用 secure transport, 并且建立 secure transport 时遇到错误必须视为 fatal, 不能让用户直接绕过. RFC 6797 将这一机制规范化, 使用 Strict-Transport-Security HTTP response header field 向 UA 传达 policy.

HSTS policy 可按 entire-host basis 应用, 即适用于发布该 policy 的 host 上任意 TCP port 的 HTTP 访问. Host 还可以声明 policy 覆盖其 domain name subtree, 从而保护适用于子域的 domain cookie. HSTS policy 与 same-origin policy 不同, 二者差异见 Appendix B.

1.1 Organization of This Specification (规范组织)

本文档先概述 HSTS 的使用场景, policy 效果, threat model 和需求. 第 3 章定义一致性标准, 第 4 章定义术语, 第 5 至 15 章正式规定 HSTS 机制.

1.2 Document Conventions (文档约定)

文中的 "NOTE" 用于提醒读者注意需要记住或纳入考虑的事项.