Skip to main content

2. Overview (概述)

本节讨论使用场景, 总结HSTS策略, 并继续讨论威胁模型、未解决的威胁和衍生需求.

2.1 Use Cases (使用场景)​

高层次的使用场景是以下内容的组合:

  • Web浏览器用户希望以安全的方式与各种网站 (一些是任意的, 一些是已知的) 交互.

  • 网站部署者希望以明确安全的方式提供其网站, 为自己和用户带来益处.

2.2 HTTP Strict Transport Security Policy Effects (HTTP严格传输安全策略效果)​

HSTS策略在符合HSTS的UA与实施此类策略的Web资源主机 (称为HSTS主机 (HSTS Host)) 的交互中应用时, 其效果总结如下:

  1. UAs在解引用 (dereferencing) 之前将对HSTS主机的不安全URI引用转换为安全URI引用.

  2. UA在遇到任何和所有安全传输错误或警告时终止安全传输连接尝试.

2.3 Threat Model (威胁模型)​

HSTS关注三类威胁: 被动网络攻击者 (passive network attackers)、主动网络攻击者 (active network attackers) 和不完善的Web开发者 (imperfect web developers). 但是, 它明确不是针对另外两类威胁的补救措施: 钓鱼 (phishing) 和恶意软件 (malware). 下面简要讨论已解决的威胁以及未解决的威胁.

读者可能希望参考 [ForceHTTPS] 第2节了解详细信息和相关引用.

2.3.1 Threats Addressed (已解决的威胁)​

2.3.1.1 Passive Network Attackers (被动网络攻击者)​

当用户在本地无线网络 (例如, 基于802.11的无线局域网) 上浏览Web时, 附近的攻击者可能能够窃听用户未加密的基于互联网协议的连接, 例如HTTP, 无论本地无线网络本身是否受到保护 [BeckTews09]. 免费提供的无线嗅探工具包 (例如, [Aircrack-ng]) 使此类被动窃听攻击成为可能, 即使本地无线网络以安全方式运行. 使用此类工具的被动网络攻击者可以窃取会话标识符/Cookie, 并通过获取包含身份验证凭据的Cookie来劫持用户的Web会话 [ForceHTTPS]. 例如, 存在广泛可用的工具, 例如Firesheep (一个Web浏览器扩展) [Firesheep], 使其使用者能够获取其他本地用户针对各种Web应用程序的会话Cookie.

为了缓解此类威胁, 一些网站支持 (但通常不强制) 使用端到端安全传输进行访问 - 例如, 通过使用"https"方案 [RFC2818] 构造的URI发出信号. 这可能导致用户认为使用安全传输访问此类服务可以保护他们免受被动网络攻击者的攻击. 不幸的是, 在实际部署中, 这通常不是这种情况, 因为会话标识符通常存储在非Secure Cookie中, 以允许与通过不安全传输提供的服务版本互操作 ("Secure Cookie"是指包含"Secure"属性的Cookie [RFC6265]). 例如, 如果网站 (例如电子邮件服务) 的会话标识符存储在非Secure Cookie中, 则如果用户的UA向该网站发出单个不安全的HTTP请求, 它允许攻击者劫持用户的会话.

2.3.1.2 Active Network Attackers (主动网络攻击者)​

坚定的攻击者可以发起主动攻击, 通过冒充用户的DNS服务器, 或在无线网络中, 通过欺骗网络帧或提供类似命名的双恶AP (evil twin access point). 如果用户位于无线家庭路由器后面, 攻击者可以尝试使用默认密码和其他漏洞重新配置路由器. 一些网站, 例如银行, 依靠端到端安全传输来保护自己和用户免受此类主动攻击者的攻击. 不幸的是, 浏览器允许其用户轻松选择退出这些保护, 以便可用于错误地部署安全传输的网站, 例如通过生成和自签名他们自己的证书 (而不是还将其证书颁发机构 (Certification Authority, CA) 证书分发给其用户的浏览器).

2.3.1.3 Web Site Development and Deployment Bugs (网站开发和部署错误)​

原本统一安全的网站 (即其所有内容都通过"https" URI具体化) 的安全性可能会被主动攻击者利用简单错误而完全破坏, 例如通过不安全连接加载级联样式表 (cascading style sheet) 或SWF (Shockwave Flash) 影片 (级联样式表和SWF影片都可以编写嵌入页面的脚本, 这让许多Web开发者感到惊讶, 此外, 当通过不安全连接嵌入SWF文件时, 某些浏览器不会发出所谓的"混合内容警告"). 即使网站的开发者仔细检查其登录页面的"混合内容", 整个网站上任何地方的单个不安全嵌入都会损害其登录页面的安全性, 因为攻击者可以通过将代码 (例如, 脚本) 注入另一个不安全加载的网站页面来编写 (即控制) 登录页面的脚本.

注意 (NOTE): 上面使用的"混合内容 (Mixed content)" (另请参见 [W3C.REC-wsc-ui-20100812] 第5.3节) 是指本规范中称为"混合安全上下文 (mixed security context)"的概念, 不应与XML和HTML等标记语言上下文中使用的相同"混合内容"术语混淆.

2.3.2 Threats Not Addressed (未解决的威胁)​

2.3.2.1 Phishing (钓鱼)​

当攻击者通过在与真实网站不同的域上托管假网站来向用户索取身份验证凭据时, 就会发生钓鱼攻击, 也许通过在电子邮件中发送链接来将流量引导到假网站. 钓鱼攻击可能非常有效, 因为用户发现很难区分真实网站和假网站. HSTS本身不是对钓鱼的防御; 相反, 它通过指示浏览器保护会话完整性和长期身份验证令牌 [ForceHTTPS] 来补充许多现有的钓鱼防御.

2.3.2.2 Malware and Browser Vulnerabilities (恶意软件和浏览器漏洞)​

由于HSTS被实现为浏览器安全机制, 它依赖于用户系统的可信性来保护会话. 在用户系统上执行的恶意代码可以破坏浏览器会话, 无论是否使用HSTS.

2.4 Requirements (需求)​

本节识别和列举了从上述使用场景和威胁中衍生的各种需求, 并列出了HTTP严格传输安全解决的详细核心需求, 以及未直接解决的辅助需求.

2.4.1 Overall Requirement (总体需求)​

  • 为Web浏览器用户和网站部署者最小化源自被动和主动网络攻击者、网站开发和部署错误以及不安全用户操作的风险.

2.4.1.1 Detailed Core Requirements (详细核心需求)​

这些核心需求源自总体需求, 并由本规范解决.

  1. 网站需要能够向UAs声明应使用严格安全策略访问它们.

  2. 网站需要能够指示不安全地联系它们的UAs安全地这样做.

  3. UAs需要保留有关发出严格安全策略启用信号的网站的持久数据, 持续时间由网站声明. 此外, UAs需要缓存"最新的"严格安全策略信息, 以便允许网站更新信息.

  4. UAs需要将所有不安全的UA "http" URI加载重写为对启用了安全策略的网站使用"https"安全方案.

  5. 网站管理员需要能够向启用了严格安全策略的更高级别域的子域发出严格安全策略应用信号, 并且UAs需要强制执行此类策略.

    例如, example.com和foo.example.com都可以为bar.foo.example.com设置策略.

  6. UAs需要禁止启用了严格安全策略的域对对等域和/或更高级别域的安全策略应用.

    例如, bar.foo.example.com和foo.example.com都不能为example.com设置策略, bar.foo.example.com也不能为foo.example.com设置策略. 此外, foo.example.com不能为sibling.example.com设置策略.

  7. UAs需要防止用户"点击通过"安全警告. 在面对安全传输异常时停止连接尝试是可以接受的. 另请参见第12.1节 ("No User Recourse").

注意 (NOTE): 本规范未专门解决统一安全地满足上述第一个核心需求的方法 (参见第14.6节 ("Bootstrap MITM Vulnerability")). 它可能会在本规范的未来修订版或其他某个规范中得到解决. 还要注意, UA实现可以更充分地满足第一个核心需求的一些方法; 参见第12节 ("User Agent Implementation Advice").

2.4.1.2 Detailed Ancillary Requirements (详细辅助需求)​

这些辅助需求也源自总体需求. 它们在本规范中没有规范性地解决, 但可以由UA实现按其实现者的自行决定来满足, 尽管满足这些需求可能很复杂.

  1. 禁止"混合安全上下文"加载 (参见第2.3.1.3节).

  2. 促进用户声明启用了严格安全策略的网站, 无论网站是否发出HSTS策略信号.

Last updated on