【科普】实行和防止SSL剥离

上个月末，我们了解到了一个新的攻击，这个攻击展示了所有当代WiFi网络加密协议的一个严重弱点。KRACK攻击有效地允许在由WPA2协议保护的无线网络上拦截流量。尽管防止该攻击的方法可以简单地通过安装补丁解决，安全更新很少有及时安装的。

在此漏洞发生之前，并不存在易受拦截攻击的无线网络。一些无线网络继续使用过时的安全协议（称为WEP），这种协议显然是“完全不安全”的;其他无线网络（例如咖啡店和机场中的那些）仍然完全开放，并且不认证用户。一旦攻击者获得对网络的访问权限，他们就可以作为一个中间人（Man-in-the-Middle）来拦截网络上的连接（使用称为ARP缓存中毒和DNS劫持的策略）。是的，这些拦截策略可以很容易地部署在有线网络，并通过以太网端口访问。

毫无疑问，盲目信任连接用户和互联网的媒介是不安全的。HTTPS正式为了允许HTTP流量以加密形式传输而创建的。然而，KRACK攻击的作者通过视频展示了如何在某知名约会网站（使用HTTPS）上实行完全剥离的全过程。本文将介绍如何进行SSL剥离以及缓解这种情况的机制。

HTTP over TLS

互联网是建立在标准拼凑的基础上的，组件被重构和重建为新的公布标准。当一个标准被发现是有缺陷的，它后来被修补或被一个新的标准取代。当 一个标准被篡改，取而代之的是一个更好的标准，整个互联网变得更好。

HTTP协议最初被指定为通过互联网清楚地传输数据。在正式引入HTTP 1.0之前，HTTP的第一个记录版本被称为HTTP V0.9，并于1991年发布。Netscape首先认识到需要通过互联网提供更高的安全保证，并在1994年中期在其浏览器中首度使用了HTTPS。为了实现更大的安全保证，创建了一种名为SSL（安全套接字层）的技术。

由于一些安全问题和缺陷，SSL 1.0比较短命，并没有被标准化。该协议在SSL 2.0和SSL 3.0中逐步更新;然后由TLS（传输层安全）标准取代。

每个版本都有不同的安全限制，支持因浏览器而异。另外，所使用的加密密码可以在一定程度上独立于上面的协议来配置。因此，确保启用HTTPS的Web服务器设置为使用优化的配置来平衡浏览器支持与安全性至关重要。

从更高层次解读，使用TLS的HTTP的最终结果是：当通过https：//而不是http：//请求站点时，连接以加密方式完成。这一过程提供了对隐私和完整度的合理保证。换句话说，我们不止加密了发出的信息，还确保了收到的信息不被更改。建立安全连接后，网络浏览器可以通过点亮浏览器栏来向用户显示此信息。

由于SSL证书本身由CA签署，因此需要进行一定程度的域名验证。CA确保他们只给能合法修改网站的网站拥有者颁发证书。如此，证书就不会发给攻击者。如果证书的签发出错，就需要根据证书撤销列表来撤回。这样的列表由操作系统自动下载，以确保当无效证书被提供时，它在浏览器中被标记为不安全。能颁发证书的机构超过一百家，因此可以通过配置CAA DNS记录来将哪些证书颁发机构颁发给给定域的证书。

在使用HTTPS时，重要的是通过HTTPS加载网站的全部内容，而不仅仅是登录页面。过去，网站通常通过安全的加密连接来呈现登录页面，然后当用户登录时，它们会将连接降级回HTTP。一旦登录到网站，会话cookie就存储在本地浏览器上，以允许网站确保用户登录。

2010年，Eric Butler通过构建一个名为FireSheep的简单拦截工具来演示这种不安全性。通过窃听无线连接，FireSheep展现了捕获常见网站的登录会话的过程。虽然攻击者不一定能够捕获网站的密码，但他们将能够捕获登录会话并在网站上执行行为，就像登录一样。他们也可以在用户登录时拦截流量。

当使用SSL连接到网站时，第一个请求通常应该将用户重定向到网站的安全版本。例如：当你访问sslchina.com时，HTTP将重定向至HTTPS版本https://www.sslchina.com/

那么问题来了，如果有人能够截获对该网站HTTP版本的未加密请求，是不是就意味着他们可以剥离加密并响应未加密的网站给用户了？这是一个由Moxie Marlinspike提出的问题，而后HSTS被创建。

HTTP严格传输安全（HSTS）

在2009年的Blackhat DC上，Moxie Marlinspike提出了一个名为SSLStrip的工具。这个工具会拦截HTTP流量，当它发现重定向或使用HTTPS的站点链接时，它会透明地将它们剥离。受害者并不直接与网站相连，而是连接到攻击者发来的连接。这也就是大众熟知的中间人攻击。

SSLStrip的神奇之处在于，只要在未加密的HTTP连接上找到指向HTTPS网页的链接，它就会用HTTP代替HTTPS，并且坐在中间拦截连接。拦截器将使加密的连接以HTTPS方式返回到Web服务器，并将流量返回给未加密的站点访问者（在流程中记录任何有趣的密码或信用卡信息）。

作为响应，一个名为HTTP严格传输安全（HSTS）的协议在2012年创建，并在RFC 6797中进行了规定。协议的工作原理是服务器响应一个名为Strict-Transport-Security的特殊标头，该标头包含一个响应，确保用户在重定向连接到网站时必须使用HTTPS。这个响应包含一个“max-age”字段，它定义了这个规则自从上次被看到以后应该持续多长时间。

虽然HSTS为防止拦截攻击提供了改进，但并不完美，并且还存在一些缺点。

HSTS预加载

HSTS的一个缺点是，它需要之前的一个链接才能知道到底连到哪个站点是正确的。当用户第一次链接到站点是，他们不会收到HSTS规则提醒他们只使用HTTPS。只有在后续连接中，访问者的浏览器才会知道需要通过HTTPS连接的HSTS规则

攻击HSTS的其他机制已经被探索;例如劫持用于同步计算机的时间（NTP）的协议，将来可以将计算机的日期和时间设置为1。这个日期和时间可以被设置为当HSTS规则已经过期并由此绕过HSTS时的值。

HSTS预加载列表是帮助解决这些问题的一个可能的解决方案，它们通过硬编码需要使用HTTPS链接的网站列表来有效地工作。已启用HSTS的网站可以在hstspreload.org上提交到Chrome HSTS预载列表;这也被用作其他浏览器中使用的预加载列表的基础。

在Google Chrome的源代码中，有一个文件，其中包含的一个硬编码的文件列出了预加载列表中所有域的HSTS属性。每个条目都以JSON格式化，如下所示：

即使有预加载，事情还并不完美。 假设某人正在阅读关于书籍的博客，并且在该博客上的链接到在线零售商那里购买一本书。 尽管在线零售商使用HSTS强制执行HTTPS，但用户依旧有几率遭遇中间人攻击，因为提供链接到在线零售商的博客不使用HTTPS。

长路漫漫

Leonardo Nve在一个名为SSLStrip +的新版本中恢复了SSLStrip，能够避免HSTS。当站点通过未加密的HTTP链接连接时，SSLStrip +将查找指向HTTPS站点的链接。一旦找到HTTPS站点的链接，会将其重写为HTTP，并严格地将该域重写为不在HSTS预加载列表中的仿真域。

例如;假设某个网站包含https://example.com/的链接，则可以通过将网址重写为http://example.org/来删除HSTS;攻击者坐在中间，接收来自http://example.org/的流量，并将其代理到https://example.com/。

这种攻击也可以针对重定向进行。假设http://example.net/通过HTTP加载，然后重定向到通过HTTPS加载的https://example.com/。在进行重定向时，合法的受HSTS保护的站点可以被重定向到攻击者用来通过HTTP提供流量并拦截流量的虚假域。

随着越来越多的互联网转移到HTTPS，这种攻击的发生率将变小，因为极少的未加密HTTP流量会被拦截。

在最新发布的谷歌浏览器版本中（62），使用不安全链接表单的站点都被标记为“不安全”。当处于隐身模式（隐私浏览）模式时，Chrome浏览器会将任何不使用HTTPS的网站标记为不安全。

这一做法帮助用户在尝试登陆时更有效地识别网站是否使用HTTPS，同时促使更多网站采用HTTPS以提高整个互联网的安全性。

总结

本文讨论了从网站上剥离HTTPS的机制，特别是HSTS如何影响这个机制。值得注意的是，在各种HTTPS规范和某些密码中还有其他潜在的攻击载体是本文没有涉及的。

尽管HTTPS提供了一种加密Web流量的机制，但重要的是要实施诸如HTTP严格传输安全性之类的技术，确保强制执行，并且最好将你的站点提交给HSTS预加载列表。随着越来越多的网站这样做，整体互联网的安全性将得到提高。

要了解如何在实践中实现HTTPS和HSTS，强烈建议Troy Hunt的博客文章：HTTPS的六步“快乐之路”。他的博客文章介绍了如何在实践中启用强大的HTTPS，另外还介绍了一种本文没有提到的被称为CSP（内容安全策略）的技术。 CSP允许你在通过HTTPS加载页面时自动升级或阻止HTTP请求，因为这会构成另一个攻击媒介。

稿源：Cloudflare

本文原文由Junade Ali于2017年10月20日发布在Cloudflare博客，SSLChina作翻译并进行适量删改。