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

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

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

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

测量方法和数据集

图5. HTTPS交叉请求

在大规模检测存在SCC威胁的网站的实验中，我们主要采用交叉请求的方法：给定一个域名列表去检测哪些可能受到SCC攻击，首先找到与这些域名共享TLS证书的相关域名（related domains）集合，然后尝试将发往原域名列表的HTTPS请求重路由至存在缺陷的相关域名，来模拟攻击者恶意的路由重定向行为。如图5所示，在将相关域名分组后，我们开始交叉地发送请求，即将每个Host的HTTPS请求分别发往同组中的不同server，例如分别向IP1、IP2、IP3请求https://sub1.example.com。通过比较共享证书的服务器返回的响应差异，就可以判断是否存在第三方服务器可被攻击者利用实施SCC攻击。

我们以Alexa Top 500的域名作为种子域，然后通过解析CT Log中的证书和PassiveDNS共获取到它们的283311个子域名。在交叉请求的不断迭代过程中，我们将新获取的证书以及解析出来的域名也加入到域名列表，最终一共扩展出292227个Alexa Top 500的子域名。基于这个域名列表，我们将每个域名与所有共享证书的域名解析IP进行关联，共得到6765333个domain-ip对，用于HTTPS请求重路由的测量。其中有34317个Top 500的子域名可以收到正常的响应（状态码为2xx或3xx）。所有域名和证书数据集分布情况如表1所示。 

表1. 数据集和受威胁的域名总览 

威胁规模

经过测量，我们发现在Alexa Top 500网站中，有126（25.2%）个网站的子域名会受到SCC攻击威胁，具体影响了2,918（8.5%）的子域名。表1给出了测试域名的排名分布，证书收集情况，以及受各类攻击影响的域名情况。

（1）HTTPS降级攻击

如表1 中C1.1所示，HTTPS降级攻击占据所有威胁中的大多数。通过将HTTPS请求重路由至共享证书的服务器，我们发现Alexa Top 500中114个主域名（apex domain）的2442个子域名的HTTPS请求可以被单级降级，包括知名域名baidu.com, amazon.com和tmall.com的部分子域名。另外，还有27个主域名的587个子域名可以通过多级降级的方式进行攻击，包括office.com, linkedin.com和microsoft.com的部分子域名。

在单级和多级降级攻击中，3xx跳转会给不同域名间引入安全依赖关系。例如，将请求https://a.example.com（ServerA）重路由至共享证书的b.example.com（ServerB）的服务器后，ServerB返回302至http://b.example.com的降级跳转，那么ServerA的安全性就会在一定程度上受ServerB的影响。为了检测由3xx跳转带来的不同域间的依赖情况，我们对所有发生降级现象的测量结果进行了统计，发现有16.56%的HTTPS请求被3xx重定向至相同域名的不同URL，有49.12%的请求被重定向至相同主域名下的不同子域，而其他的跳转均指向了不同的主域名。例如，maps.live.com可以经过多级跳转最终被重定向至www.msn.com。

但是，如果降级跳转的目标域名部署了HSTS，则ServerB的不安全响应无法成功将上下文降级至HTTP。因此，我们在分析降级结果时，进一步过滤掉了目标域部署HSTS的情况，结果如表1的C1.2所示，仍旧有1751个FQDN能够利用共享证书的第三方域名实施降级。

（2）HSTS策略绕过

如表1的C2所示，在Alexa Top 500的域名当中，我们发现有43（8.6%）个主域名的271个子域名可以被第三方不安全配置的STS头部影响，其中HSTS-1、HSTS-2和HSTS-3的数据分别对应第三节中的“清除HSTS策略”、“消除子域名HSTS保护”和“降级HSTS缓存期”三种攻击。

多方主体的安全依赖关系

在现实中，共享TLS证书的域名之间未必存在业务联系，甚至可能属于不同主体，但是在我们的攻击模型中发现，一方（ServerA）的安全策略配置的安全性会受到共享证书的另一方（ServerB）的影响，说明不同实体之间可能直接或间接存在着安全依赖关系。这里提到的“另一方”包括很多种主体。例如，在HTTPS降级场景中，待访问域名的安全性不仅依赖于与其共享证书的域名配置，也依赖于3xx跳转的目标域名的安全策略。也就是说，如果一个域名存在安全缺陷，那么与之关联的其他域名都有可能受到攻击。

（1）FQDN的依赖程度

为了展示证书共用场景下的安全依赖关系，我们提取了如下相关联的域名对：（1）请求的域名（Host）和共享证书的域名；（2）请求的域名和3xx跳转的目标域名。然后将FQDN的依赖关系表示为图结构：

图6. FQDN的安全依赖关系图

我们用A->B表示A依赖于B，即，每个节点的入度表示有多少域名的安全性依赖于该节点对应的域名。如图6所示，汇聚结果形成了明显的簇，很多“中心”域名被成百上千个域名所依赖。据数据统计，我们发现拥有最大入度的节点被900个域名依赖。如果这些中心点的配置存在缺陷，那么将会产生很大的影响规模。

（2）主域名的依赖程度

图7. 主域名的安全依赖关系图（部分）

通过FQDN的依赖关系，我们可以进一步地描绘出主域名甚至不同实体之间的信任关系，图7画出了三个汇聚的簇。根据汇聚结果，我们总结出了这些存在安全依赖的域名和实体之间的关系：

（1） 同一公司或组织的主域名与子域名之间。如图7(c)，uol.com.br的部分子域名（蓝色）都可以被主域名（棕色）的服务器降级。

（2） 同一公司服务于不同地理区域的域名之间。例如，eBay为不同国家或地区注册不同的主域名来提供服务，包括中国（ebay.cn）、法国（ebay.fr）、日本（ebay.co.jp）等，而这些主域名的子域名配置都依赖于ebay.com的配置。

（3） 子公司与母公司之间。在(b)和(c)中，我们发现Office、MSN和Bing都依赖于Microsoft的域名，而Xiami、Tmall和AliExpress都依赖于Alibaba集团的域名。

（4） 行业合作和投资关系。例如WordPress或KPMG与Microsoft，Merrill Lynch和Bank of America, Umeng和Alibaba集团。

（5） 其他关系，如服务提供商与客户之间的关系。例如，我们发现美国国立卫生研究院（NIH）的域名（www.myitsm.nih.gov）可以被重定向至www.servicenow.com，经过调查我们发现后者负责了NIH的部分开发工作。

在上述关系的基础上，我们发现现实生态中实际存在着安全信任链，例如ebay.com-> office.com-> live.com。这意味着，TLS证书共享的现象在多方主体的生产、业务和合作中具有很高的重要性，一旦某个环节存在安全配置缺陷，都有可能导致大规模的安全威胁。

 攻击场景

在测量中，我们发现了一些实际案例，并将可能发生SCC的攻击场景总结为以下几类：

a. 在线支付劫持
b. 资源下载劫持

c. 登录劫持

d. 网站钓鱼

e. 其他

具体案例的细节信息请参考原文第5.3小节，此处不做详细介绍了。

TLS证书共享

为了提高管理效率和降低成本，多域名和泛域名证书在现实中被共享的情况在现实中普遍存在。一方面，同一张证书可以对多个域名主体有效；另一方面，同一张证书也可以被部署于多台服务器上。例如，在CDN为多个客户实体签发同一证书，同一台服务器为不同虚拟主机部署同一TLS证书，或者存在业务联系的主体之间也有可能共享相同证书。这种共享证书的机制为证书管理提供了很大的便利。然而，被共享的TLS证书也会给不同域名主体之间带来安全依赖关系，造成木桶效应，任何一个存在缺陷的域名配置都有可能拉低整体的安全性，甚至引入SCC等攻击。

不同主体之间的配置的不一致性与缺陷

在整个生态中，配置实践和安全标准之间尚存一定差距，目前并非所有主体都遵循了安全配置的最佳实践。在共享证书的场景下，不同域名所对应的服务器可能分别由其管理员或开发人员人工配置，难免存在配置上的不一致性，甚至有的会存在配置缺陷：首先，服务端可能未严格检查Host头，例如当Host头不匹配对应server的hostname时返回302跳转甚至200 OK；其次，服务端可能没有严格部署HSTS和CSP策略等。正是共享证书的不同域名之间的配置差异与配置缺陷，给SCC攻击提供了可能。

现在没有保持安全上下文的策略

SCC攻击之所以能够成功，是因为（1）HTTPS流量被重定向至第三方服务器，并且（2）第三方服务器存在配置缺陷，而用户代理对服务端的身份认证只停留在证书验证层面，TLS上层根本无法察觉到下层IP地址或端口的切换。这种认证机制在共享证书的场景中是不够的。

因此，为了让客户端更清楚地知道与之通信的服务端究竟是谁，除了验证证书外，还需要一种安全策略，让用户代理检查对方服务器的hostname是不是自己所访问的域名，确保通信的上下文是建立于客户端与待访问的目标服务器之间。

我们认为，各浏览器需要加强以下策略的部署来保护浏览上下文的安全。

首先，需要对所有不安全的上下文切换给出安全提示。在SCC攻击中，尽管攻击者可以让上下文恶意操作后恢复至HTTPS状态（例如HTTPSàHTTPàHTTPS）,但是中间过程会有明文状态发生，浏览器作为用户代理有能力检测出所有这类不安全上下文的跳转，并给用户做出风险提示。具体而言，从HTTP上下文重定向而来的HTTPS连接状态不应被标记为“secure”，尽管该请求受到合法TLS证书的保护。例如，图4中的https://a.bank.com?orderid=b请求应该被标记为“not absolutely safe”等。

其次，需要拦截所有mixed-content，包括active content和passive content。尽管当今主流浏览器已经认为混合加载（在HTTPS页面下通过HTTP加载）active content（如script, XHR请求等）是危险的，并且拦截了所有这类资源，但是passive content（如视频、图片等）仍未被拦截。在本文中，我们发现很多登录、支付的二维码是以图片的形式加载，因此替换图片也存在很严重的安全威胁，如窃取登录信息、替换支付订单等。因此，我们建议浏览器应该拦截网页资源加载过程中可能出现的所有混合内容。

在这篇文章中，我们系统地分析了共享TLS证书所能带来的安全威胁，并对该场景下所能实施的SCC攻击展开了实证研究，分析了其攻击场景、技术挑战、影响规模、根本原因与缓解措施等。我们希望这项研究成果能够进一步推进HTTPS的安全部署和TLS证书的规范管理。