论文题目：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连接仍可受到可信的、有效的证书保护。因此，攻击不会触发浏览器的证书验证错误等警报，浏览器很难检测到此攻击的发生，可以做到对用户透明。
三、SCC攻击场景：HTTPS安全策略绕过
基于图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的情况下，更难保证所有域名均加入了预加载列表。
四、现实网络环境中攻击的技术挑战
现有的SSL Stripping等攻击只能在初始的明文请求处实现对SSL的剥离，而在本文的攻击模型中，攻击者可以在连接的任意时刻实施攻击：既可以在TLS握手阶段进行劫持，也可以拦截一个已经建立完成的TLS连接，做到HTTPS通信“过程间”的劫持，这使HTTPS劫持具备更高的可行性。
为了实现在任意时刻劫持HTTPS通信，攻击者将面临以下三个挑战：第一，如何找准攻击时机，准确定位待劫持的目标请求？第二，如果目标请求和其他资源请求复用一个已经成功建立的TLS连接，如何悄悄将连接打断，而不影响网站的其他正常功能？第三，如何保证整个劫持过程对用户透明，使攻击更具备欺骗性？下面我们将介绍能够克服这些挑战的技术方法。
攻击时机（Timing of Attacks）
在实际应用中，攻击者想要劫持的敏感请求（例如付款操作）可能处在不同连接状态下：
（1）该请求资源由一个独立的域名提供服务；
（2）该请求资源与其他资源托管在同一域名的不同路径下，但每次的资源请求占用一个独立的连接；
（3）该请求资源与其他资源复用相同连接，例如连接是在keep-alive状态下。
在情况（2）（3）中，如果攻击者将指向目标域名的连接都拦截，会影响其他资源加载，导致网站正常功能被破坏，很容易被用户察觉。
在攻击之前，攻击者首先需要准确判断待劫持的目标请求是在何种连接状态下，然后采取相应行动，将目标请求重定向到第三方服务器（图1中的ServerB）。图3中展示了在不同连接状态下的劫持时机：
图3. HTTPS请求劫持的时机
Case A: 如果目标请求资源托管于一个独立的域名，那么攻击者可以直接通过DNS污染等方式，将该域名的解析指向ServerB （IPB）。因此，当用户访问https://a.example.com时，浏览器实际是在与ServerB建立TLS连接进行通信。如果ServerB返回不安全的3xx跳转或存在缺陷配置的STS头部，便可被攻击者利用，绕过对ServerA的HTTPS通信。
Case B: 如果目标资源与其他资源托管于同一域名，只通过不同路径来作区分，并且每个请求都发生于独立连接，那么攻击者首先需要在加密流量中识别到指向目标路径的连接（HTTPS Path Leaks），然后通过TCP重定向的方式将该请求发往ServerB。
Case C: 如果目标资源的请求与其他资源复用相同连接（在长连接中），那么攻击者需要在加密流量中识别到关键请求后中断现有连接，并通过一定方法促使浏览器重新发起合法的TLS握手（TLS re-handshake）。在重握手阶段，攻击者便可以将请求重定向至ServerB，使客户端与ServerB建立起连接。
在加密流量中泄露请求路径（HTTPS Path Leaks）
在上文Case B和Case C中，攻击者均需在加密流量中寻找针对关键路径的请求包，需要泄露请求路径。在2018年Chen等人提出了一种通过侧信道泄漏HTTPS路径的方式，其利用了cookie机制中有一个缺陷——在HTTP会话下为目标域名和路径设置的cookie同样会携带至HTTPS连接中，因此通过向特定路径注入超长cookie的方法，就可以在TLS层根据TLS record size检测到目标请求包。这种方法同样适用本文的SCC攻击场景，攻击者可以向待劫持的目标路径注入长cookie，在TLS层检测到超大的包（目标请求包）时，中断当前连接、触发重握手并重定向新请求。
触发合法的TLS重握手（TLS Re-handshake）
在一个已建立的连接中实施HTTPS劫持，攻击者需要在打断当前连接后促使浏览器发起新的TLS握手（此处我们称为TLS重握手），以便于重定向TLS请求。经过检测，我们发现在现有连接中，当连接Timeout或接收到TCP RST包时，浏览器会主动重新发起新的TLS握手。与TLS安全重协商不同，重协商时的握手信息是加密的，攻击者无法监视协商过程；而重握手是浏览器为了继续发送长连接中的请求而主动发起的新连接，其握手过程与正常过程无差别。
五、SCC攻击中浏览器的行为检测
在本节中，我们将介绍浏览器是否存在可能检测到SCC攻击的风险提示机制或拦截措施。
在HTTPS降级攻击中，浏览器会发出怎样的安全提示？
现今主流浏览器会对网络连接状态、通信安全状态做出风险提示和安全警报，例如地址栏的安全锁、盾牌等，以及证书错误等警示页面。本文中，我们对不同场景下的SCC降级攻击的浏览器提示进行了测量分析，根据攻击目标与过程，我们可以将降级攻击分为以下三类：
第一，直接降级“输入地址栏”或“点击超链接”时发出的HTTPS请求。在这类请求中，浏览器会在一个全新的上下文中请求和加载资源，因此地址栏会跟随请求的跳转。如果服务端返回302跳转至HTTP连接，地址栏也会显示HTTP不安全连接状态。
图4. 恢复上下文的过程
第二，降级HTTPS请求并实施攻击后，再将上下文恢复至HTTPS状态。如图4所示，攻击者首先可以利用共享证书的Server B降级HTTPS请求（过程①）；然后拦截HTTP请求，通过伪造HTTP响应，促使客户端跟随一系列伪造的302跳转（过程②）；最后再利用一次302重定向使浏览器跳转回HTTPS请求，将连接恢复至HTTPS状态（过程③）。
在①和②的这些中间跳转过程中，客户端只接收到Response header 而无Response body，属于非渲染响应。我们发现浏览器（包括Chrome, Firefox, Safari, IE）地址栏和网页无任何跳转变化，仍旧停留在原始状态。只有当③过程结束后，浏览器的才会显示https://a.bank.com?orderid=b这个HTTPS页面。对于用户而言，他只看到网页加载一次，且连接状态安全，浏览器显示并无异常，而地址栏参数的变化在正常请求中也很常见，因此用户很难察觉攻击行为的发生。
在这种攻击中，攻击者可在②中完成cookie的注入，也可以在③中完成对请求参数的篡改，例如替换用户支付的订单信息。此外，如果用户在①中要请求一个非渲染资源（例如软件安装包、邮件附件），攻击者可在①②后将请求引向一个下载恶意程序的地址，而在整个下载过程，浏览器的地址栏和网页无任何变化。
第三，降级网页中加载被动资源的HTTPS请求。如果攻击者欲劫持网页中的被动子资源（passive content），在实施降级后，我们发现iOS版本的Firefox仍旧显示安全小锁， Chrome会将安全锁转换为叹号标识，而Safari和IE只显示URL、不再显示任何安全标识。
各浏览器是否会在接收到RST后主动发起TLS重握手？
为了验证2.3中提到的通过触发TLS重握手实施HTTPS劫持的可行性，我们对不同操作系统中主流浏览器的处理行为进行了检测。检测结果显示，各操作系统下的的Chrome、Firefox、Edge、Safari均会在接收到TCP RST后立即启动TLS重握手来完成长连接中未完成的请求。其中，Chrome会在重握手结束后正常从ServerB加载资源，而Firefox会发出报警提示。
六、大规模测量与结果分析
测量方法和数据集
图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证书的规范管理。
