上个月中下旬，Wifi首次曝重大安全漏洞，正面临着KRACK攻击攻击风险。KRACK漏洞允许攻击点接入到Wi-Fi和客户端之间的通信过程中，强制客户端重装一个之前使用过的密钥，计数器将被置为0，而且导致密钥对重用。一旦密钥流被重用，那么攻击者可以（很轻松的）解密整个通信过程，窃取信用卡信息、用户密码或者更多资料。
在此漏洞发生之前，网络并不存在易受拦截攻击的无线网络。但部分无线网络仍在使用过时的安全协议（如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版本由于存在较多的安全问题以及缺陷而迅速被淘汰，同时也没有被标准化。接着后期也发布了两个新版本，最终因本身的缺陷被另一种技术TLS（传输层安全）标准取代。
TLS协议的每个版本都有不同的安全限制，其使用支持会因不同浏览器及版本而有所不同。另外，所使用的加密算法在一定程度上可以独立于上面的协议来配置。因此，确保启用HTTPS的Web服务器及相关优化配置是平衡浏览器支持与服务器安全是至关重要。
使用TLS的HTTP的最终结果是：请求站点时，https：//取代http：//，连接以加密方式完成，为客户端和服务端提供了数据隐私和完整度的合理保护。换句话说，当我们访问网站时，输入的信息被加密了，并确保网站终端接收到的信息没有被篡改。建立安全连接后，网络浏览器通过安全标识对用户显示该站点安全状态。
SSL证书是由CA机构进行相关的审核（域名的所有权、申请人信息）后颁发，CA机构仅为合法网站的拥有者颁发证书，拒绝将证书颁发给攻击者。如果证书的签发出错，则证书撤销列表就会收回证书。证书撤销列表由操作系统自动下载，确保浏览器遇到无效证书时，自动将网站标记为不安全。
在使用HTTPS时，通过HTTPS加载网站的全部内容是十分重要的，而不仅是登录页面。以前，很多网站仅仅在登录页面通过安全的加密连接，当用户登录后，它们会将连接降级回HTTP。一旦登录到网站，会话cookie就存储在本地浏览器上，以允许网站确保用户登录。
2010年，Eric Butler通过一个名为FireSheep的简单拦截工具来演示这种设置的不安全性。通过窃听无线连接，FireSheep捕获常见网站的登录会话的过程。虽然攻击者不一定能窃取网站的密码，但他们可看到登录会话以及用户在网站上的执行行为，就像登录一样。他们也可以在用户登录时拦截流量。
当使用SSL连接到网站时，第一个请求是将用户重定向到网站的安全版本。例如：当你访问sslsq.com时，HTTP将重定向至HTTPS版本https://www.sslsq.com/。
随后Moxie Marlinspike提出一个问题，如果攻击者截获网站HTTP明文协议版本请求，是否意味着他们可以剥离加密并响应未加密的网站反馈给用户？为了解决这个问题，因而HSTS被创建。
HTTP严格传输安全（HSTS）
一个名为SSLStrip的工具在2009年被Blackhat DC，Moxie Marlinspike提出，它可拦截HTTP流量，当它发现重定向或使用HTTPS的站点链接时，它可直接将它们剥离。访问者将直接跳到攻击者发来的连接。而这种就是所谓的中间人攻击。
SSL Strip的神奇之处在于，只要发现未加密的HTTP连接上找到指向HTTPS网页的链接，它就可用HTTP代替HTTPS，并且在中间进行拦截连接。拦截器将使加密连接以HTTPS的形式返回到Web服务器，并将流量返回给未加密的站点访问者（在过程中可记录密码或信用卡信息）。
因此，一个名为HTTP Strict Transport Security（HSTS）的协议于2012年应运而生，并在RFC 6797中进行了规定。协议的工作原理是服务器响应头信息Strict-Transport-Security，通知客户端，当他们重新连接到站点时，必须使用HTTPS。该响应包含一个”max-age”字段，字段定义了该规则自从上次被看到以后应该持续多长时间。
HSTS虽可防止拦截攻击，但并不完善，并且还存在一些缺陷。
HSTS预加载
其中，HSTS只对已正确访问过的站点生效，对于首次访问的站点却无法判断链接的正确性。因此HSTS规则不会提醒用户使用HTTTPS，只有在后续连接中，访问者的浏览器才会知道需要通过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加载越来越少。但这一说法在 国内目前并不适用，因为国内跳转到HTTPS的站点占据的份额是少之又少。
在最新发布的谷歌浏览器版本中（Chrome 62），使用不安全链接表单的站点都被标记为“不安全”。即当处于隐身（隐私浏览）模式时，Chrome浏览器会将任何不使用HTTPS的网站全标记为不安全。
这一做法帮助用户在尝试登陆时更有效地识别网站是否使用HTTPS，同时促使更多网站采用HTTPS以提高整个互联网的安全性。
总结
本文讨论了从网站上剥离HTTPS的机制，特别是HSTS如何影响这个机制。但本文并没有提及其他潜在各种HTTPS规则和密码中的攻击载体。
尽管HTTPS提供了Web流量的加密机制，但重要的是要实施诸如HTTP严格传输安全性之类的技术，以确保强制执行，同时建议将站点提交给HSTS预加载列表。随着更多的网站加入，互联网的整体安全性将会得到各大的提升。
