最熟悉的陌生人——基于共享证书的HTTPS上下文混淆攻击实证研究（一）

论文题目：Talking with Familiar Strangers: An Empirical Study on HTTPS Context Confusion Attacks （本文为ACM CCS 2020录用）

论文作者：张明明, 郑晓峰（并列一作）, 沈凯文, 孔子乔, 陆超逸, 王郁, 段海新, 郝双, 刘保君, 杨珉

作者单位：清华大学，奇安信技术研究院，德州大学，复旦大学

HTTPS是为保护“端到端”安全通信而设计的协议，用于保障数据的隐私性、完整性和可靠性，而本文证实了HTTPS加密通信的又一个严重的安全威胁——共享证书会导致Web PKI生态缺陷。

在Web PKI生态中，TLS证书可对多个域名有效或被多台服务器共享。这些域名与服务器之间未必存在业务联系，甚至可能属于不同主体，但是它们会因为共享了同一张TLS证书而产生安全关联，所以本文将它们比喻为“最熟悉的陌生人”。共享证书的域名之间存在的安全依赖关系，会使它们整体的安全性出现“木桶效应”，即任何一台服务器上的配置缺陷都有可能影响其他关联网站的安全。

基于共享证书导致的生态缺陷，攻击者可以绕过HTTPS的相关安全防护，破坏HTTPS通信过程的安全性。针对这类新型的攻击方法，本文对Alexa Top主流网站展开了测量与实证研究，发现很多流行应用可被劫持，包括在线支付、第三方登录、邮件服务和文件下载等。目前，我们已经将发现的漏洞报告给受影响的厂商，并提出了降低风险的解决方案。

在2015年Antoine Delignat-Lavaud等人提出，当两个虚拟主机（virtual-host）使用相同TLS证书、共享TLS Session缓存或共享密钥时，攻击者可在一个Origin加载另一个另一个域下的资源，造成Origin混淆。本文所研究的攻击均基于共享TLS证书的场景，利用共享证书的不同主体间策略配置的不一致性，将其中一台服务器的缺陷配置引向另一个安全的服务器，从而绕过后者的安全配置。

这个过程除了会导致服务端加载资源的Origin混淆，也会造成客户端的浏览上下文混淆，即攻击可发生在用户和应用程序所认为的“安全上下文”中，实现透明的、过程间的HTTPS劫持。在本文中，我们将此类攻击概括为HTTPS Context Confusion Attack，简称SCC攻击。

SCC攻击假设

在SCC攻击中，我们作出如下假设：

（1）TLS协议本身是安全的，SCC攻击不利用协议本身的漏洞或缺陷；

（2）客户端接收的TLS证书是合法有效的，即在通信初始的证书验证环节可顺利通过，客户端可以接收到服务端返回的合法、有效和可信的TLS证书。

谁可以成为SCC攻击者？

在本文的攻击模型中，我们假设攻击者是网络中间人的身份，仅能拦截加密流量并进行路由重定向，或篡改明文数据，而无法解密加密流量。

（1） 最典型的攻击者与受害者处于相同局域网（LAN）。例如，攻击者能够在本地Wi-Fi或以太网对通信进行拦截，如家用路由器。类似地，攻击者也可以控制防护较弱的开放的Wi-Fi网络，例如当用户连接机场或咖啡厅的免费Wi-Fi时，其网络通信便有可能被中间人拦截和窃听。

（2） 恶意的网络中间件，例如被攻破的网关，或使客户端使用恶意的代理服务器等。

（3） 被攻破或被恶意利用的ISP路由节点等。

SCC攻击模型

图1. 攻击模型

如图1所示，本文的攻击模型主要包含四个组成部分：（1）Client：通过浏览器浏览网站的受害者；

（2）攻击者：能对加密流量进行路由重定向的网络中间人；

（3）ServerA：用户访问的网站，该网站部署了安全策略的最佳实践，例如HSTS策略等；

（4） ServerB：与ServerA共享TLS证书的网站，该网站存在安全策略配置缺陷，例如存在HTTP响应头部误配置等。

在SCC攻击中，攻击者的主要目的就是利用第三方服务器（ServerB）的配置缺陷来劫持客户端与已经安全部署的ServerA间的HTTPS通信过程。当用户访问ServerA时，他首先需要拦截Client发往ServerA的HTTPS请求（①），并在TCP和IP层将请求重路由至ServerB（②），使Client与ServerB建立TLS连接。但是，浏览器仍会将此时的上下文视为与ServerA建立起的连接。一旦ServerB未严格检查Host，向客户端返回存在安全缺陷的响应头部配置（③），浏览器就会将这种缺陷策略（④）部署给ServerA，从而降低ServerA的安全等级（例如将HTTPS降级为HTTP），以便攻击者的进一步利用。

为了保证攻击的透明性和欺骗性，攻击者需要准确定位待攻击的请求，进行有针对性的拦截，实施攻击（如替换部分资源或窃取用户数据）后，再将上下文恢复至原始状态下，让用户以为自己仍旧在原始的受到HTTPS加密保护的上下文中执行操作，做到用户操作的上下文混淆。

为什么客户端能与ServerB建立连接？

（1）TLS不保护下层（TCP和IP层）数据，应用层也无法感知到下层IP地址的切换。在现实网络中，由于负载均衡、CDN部署等原因，IP地址的切换也很常见，因此浏览器无法根据目标IP或端口的切换而察觉到攻击行为。

（2）ServerB提供与ServerA共享的TLS证书，浏览器对证书的校验也能够通过，即ServerB可以通过浏览器的身份验证。

（3）在现实环境中，出于提高容错性、改善用户体验、增加收益或促进商业合作等多方面的考虑，很多服务器并不会直接拒绝Host不匹配的请求，因为用户可能由于手误输入错域名。相反，一些服务器会将所有Host不匹配的请求交由一个默认的虚拟服务器（default virtual host）处理，而通常这类缺省服务器配置比较简单，例如统一将请求重定向至一个URL。服务端也可能实现了域名映射（domain aliasing），例如将发往不同域名的请求重定向至同一个后端服务器，这个方法同样也是为了避免用户经常在浏览器地址栏输错地址带来的浏览问题。此外，服务端也可能存在Host宽松检查的问题，例如未检查或未严格检查Host头，如此便可接受Host为相同base domain下的其他子域名的请求。

与现有的SSL Stripping系列攻击的区别

与SSL Stripping及各类变形攻击相比，SCC攻击具有一定的特殊性：

（1）即使待劫持的目标网站部署了安全策略的最佳实践，SCC攻击也能够正常发起，因为攻击者可以用第三方服务器的配置缺陷来绕过原本安全的策略。

（2）SCC攻击不依赖于初始的HTTP明文请求，攻击者可以在TLS握手阶段完成对HTTPS请求的劫持。因此，现有的HSTS策略、CSP策略等无法直接防御此类攻击。进一步地，SCC攻击可以适用于已经建立起的安全的TLS连接，因为攻击者能够通过触发重握手的方式在安全上下文中做到过程间的劫持。

（3）客户端无需安装攻击者提供的根证书，此时的TLS连接仍可受到可信的、有效的证书保护。因此，攻击不会触发浏览器的证书验证错误等警报，浏览器很难检测到此攻击的发生，可以做到对用户透明。

基于图1中的攻击模型，SCC攻击者可以利用共享证书的ServerA与ServerB之间响应头的不一致发起攻击。经过系统地分析，我们发现有两种响应头部可以被用来绕过HTTPS的保护，从而使用户陷入被攻击的威胁，具体利用场景如下。

场景1: 利用不安全的Location header实现HTTPS到HTTP的降级攻击

在实际应用中，网站服务器可以通过配置3xx跳转，默认地将所有HTTP请求重定向至HTTPS连接，从而实现HTTPS的加密保护。然而，如果Location字段设置的是不安全链接（HTTP URL），这种3xx跳转便会将通信暴露于明文环境下。在本文的攻击模型中，SCC攻击者便可以利用ServerB返回的不安全3xx跳转，将HTTPS请求降级至HTTP状态，我们将这类攻击称为HTTPS Downgrading Attack。

（1）单级降级攻击（One-shot Downgrading Attack, Down-1）

如图1所示，如果共享证书的ServerB直接返回3xx到HTTP URL的跳转，那么攻击者通过一次路由重定向，就可以将HTTPS请求降级。首先，当用户请求https://a.example.com（Host为a.example.com）时，攻击者需要拦截该请求并将其重路由至ServerB （IPB）。如果ServerB返回一个到HTTP URL的3xx跳转，那么在浏览器跟随跳转后，请求的上下文便会被降级至明文状态，攻击者就可以篡改明文数据并进一步实现攻击（如钓鱼、资源替换等）。

（2）多级降级攻击（Multi-hops Downgrading Attack, Down-2）

如果与ServerA共享证书的所有服务器均不会返回不安全的3xx跳转，只有个别服务器会返回302到HTTPS的安全跳转，那么仅通过单级跳转是无法成功降级的。此时，攻击者可以将一系列3xx跳转串连起来的方式，通过多级跳转完成降级攻击。

图2. 多级降级攻击实例

在图2这个例子中，每对服务器（一黄一蓝）相互共享TLS证书。当攻击者将发往黄色服务器的HTTPS请求重路由至共享证书的蓝色服务器时，后者会返回301/302跳转至第三方域。攻击者构造的跳转链中，只要有一个域名可以被降级，那么整条链上所有域名的HTTPS请求就都可以被降级。

场景2: 利用Strict-Transport-Security header的缺陷配置绕过HSTS策略

在实际应用中，网站服务器通过Strict-Transport-Security (STS)头部字段来部署HSTS策略，让浏览器在策略生存期内会强制使用HTTPS与该网站通信。但是，该头部字段属性的误配置可能使HSTS策略失效。

与降级攻击类似，我们仍旧假设待攻击的ServerA已经部署了HSTS策略的最佳实践，而ServerB存在HSTS配置缺陷。下面我们来介绍利用ServerB的STS误配置来绕过ServerA的HSTS保护的三种情况：

第一，利用ServerB清除ServerA的HSTS策略缓存（HSTS-1）：如果ServerB给客户端返回STS: max-age=0，而浏览器又把它当作是ServerA的响应，就会清空ServerA的HSTS策略配置。

第二，利用ServerB取消对ServerA子域名的HSTS保护（HSTS-2）：在中间人重定向之后，如果ServerB给客户端返回的STS域缺少includeSubDomain指令，除非ServerA的子域名单独配置过HSTS策略，否则浏览器会更新HSTS配置，不再对ServerA的子域名提供HSTS保护。另外，如果ServerB返回STS: max-age=0; includeSubDomains，则includeSubDomain指令会被浏览器忽略。此时，浏览器会清空ServerA的HSTS策略，同时也不会再为它的子域名提供HSTS保护。

第三，利用ServerB降低Server的HSTS策略缓存期（HSTS-3）：如果ServerB返回的STS header的max-age比ServerA的小，那么通过路由重定向，浏览器中ServerA的HSTS策略将会被更新，使缓存期缩短。如果用户在这很短的max-age（一天）内没有访问ServerA，一天后浏览器中关于ServerA的HSTS缓存就会失效，这意味着在很短的时间后用户再次访问ServerA时，浏览器便会再次发出初始HTTP请求，使明文请求被攻击者拦截的可能性增高。

小结：场景1是利用不安全的3xx跳转将HTTPS降级至HTTP，场景2是利用误配置的STS header来绕过HSTS策略保护，二者均使HTTP明文请求在原本安全的HTTPS上下文保护下得以发出，给攻击者提供拦截和篡改的机会。但是，如果共享证书的所有域名全都安全部署了HSTS，且加入HSTS预加载列表（preload list），上述问题便可以避免。然而，HSTS预加载列表是一个自愿加入的项目，在各域名尚且未全部完美部署HSTS的情况下，更难保证所有域名均加入了预加载列表。

（未完待续……）