CCS 2020: Talking with Familiar Strangers: An Empirical Study on HTTPS Context Confusion Attacks

Abstract & Introduction

多个域共享的TLS证书使HTTPS劫持攻击再次成为可能，即使网站部署了security practices。
以下把基于共享TLS证书的HTTPS MITM攻击称作 HTTPS Context Confusion Attack (SCC Attack)

Try to explain:

何种情况下存在潜在威胁
如何发现易受攻击的对象
SCC攻击对现实有多大影响？现在有多少网站易受攻击

我们的工作：

3 建模分析：攻击者，用户，共享证书的Server A、Server B
4.1 攻击者通过HTTP标头不一致来发动攻击，以绕过先进的HTTPS安全策略（如HSTS）
4.2 攻击者如何在复杂的连接环境中破坏受HTTPS保护的用户操作。即使客户端和服务器安全连接，依然有可能HTTPS劫持
4.3 测试SCC攻击期间的浏览器通知和行为
为了评估对现实的影响：
5.1 提出了基于主动扫描发现易受SCC攻击的服务器的办法
5.2 对流行的Web服务器测量研究，显示威胁规模

结果表明：证书共享很普遍，顶级域更是存在大量共享证书，因此影响最严重。
此外，一台服务器有缺陷的实现，会影响多方的安全。
本文贡献如下：

实证分析，看看怎么降级HTTPS，典型攻击场景
从客户端评估，测试浏览器在SCC攻击下的弱点，提出缓解方案
提出怎么发现易受攻击网站的方法

Background

HTTPS

Certificate:
    Data:
        Version:3(0x2)
        Issuer:CUS,0DigiCert Inc,CDigiCert SHA2 SecureServerCA
        Validity
            Not Before:Nov2800:00:002018GMT
            Not After:Dec212:00:002020GMT       
        Subject: CNm*.example.com，.
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:a.example.com,   DNS:b.example.com, DNS:coxample.com

共享TLS证书使用SAN扩展(Subject Alternative Name)来支持多个名称或地址。如果名称不匹配或出现其他无效原因，用户代理向用户显示警告。相反，如果通过验证，就可以建立信任关系之后传输数据。
为了增强HTTPS安全性，浏览器和网站使用HTTP Security Headers。Headers是由服务器生命的指令，在浏览器中执行安全策略。但是由于客户端服务端的实现问题，header不能完全保证安全。

SSL-Stripping-Based Attacks

中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。

MITM攻击是SSL/TLS的主要对手。最具代表性的攻击就是SSL-Stripping Attacks。这种攻击尝试绕过SSL/TLS。攻击者需要在用户第一次访问网站时拦截初始 HTTP 连接，然后将请求传送到远程服务器。当他收到指向 HTTPS URL 的 301/302 重定向时，他可以将服务器返回的安全链接替换为纯文本链接，并保留更改的映射。通过这种方式，他可以控制特定的安全页面并将 HTTPS 降级为 HTTP。因此，攻击者可以从中间观察用户的敏感数据。

这种攻击还可以加强：Leonardo开发了一种结合SSL剥离和恶意DNS工具的工具，使得攻击者可以部分绕过HSTS策略，进行增强的SSL Stripping Attack。

其基本思路是在前端使用XSS脚本把HTTPS改为HTTP。Chen等人的工作也说：代理可以将脚本请求重定向到不安全的站点。

这些SSL剥离攻击中，需要篡改不安全的初始请求。同时，远程服务器没有提供受信任的 TLS 证书来保护流量。因此，细心的用户可能会注意到浏览器中证书的异常验证状态。此外，在提出更新的安全策略 HTTP 严格传输安全（HSTS）后，攻击者几乎无法发起 SSL 剥离攻击。

Threat Analysis

若多个域共享TLS证书，由于origin confusion issues（源混淆问题），攻击者可以将页面从其他源加载到另一个源。但是，共享证书中的域并不总是实施相同的security practices，其中有一些是配置错误的，尤其是在HTTP安全表头中。通过将 HTTPS 请求重新路由到有缺陷的服务器，攻击者可以将其弱策略邀请到安全源，并绕过安全服务器的安全策略。除了服务器端的源混淆外，客户端的程序和用户也存在安全浏览上下文混淆。这是因为浏览器将指令视为由访问的源返回，并在安全上下文中采取不安全的操作。

接下来建立SCC Attack Model：
SCC Attack并不利用TLS协议的漏洞。我们假设证书有效受信任。这个威胁模型中假设攻击者受害者位于同LAN中，能够重新路由加密流量并篡改明文数据。
典型对手：本地wifi/以太网/没有安保的开放wifi网络/由恶意中间设备发起。

SCC Attack 概述：

模型由四个部分组成。

浏览网页的受害者用户
可以恶意重新路由HTTPS流量的中间人攻击者
用户尝试访问的执行严格安全策略（如HSTS）的Server A
另一个安全策略有缺陷的Server B（如配置错误的HTTP安全标头）

注意：Server A和Server B共享TLS证书。

攻击流程：

攻击者首先终止client和Server A的TLS连接（e.g. by connection reset）
将受害者到Server A的HTTPS请求重新路由到服务器B以重新建立TLS连接
浏览器仍将上下文视为和A的连接。Server B的身份验证可通过，因为AB共享一个有效证书。
因此从B收到有缺陷的安全配置后，浏览器将对服务器A执行弱策略。

省流：客户端访问A，但和B建立了TLS连接，没有身份验证错误。

和经典SSL-Stripping-Based Attacks的区别：
由于有证书共享，SCC攻击有一些其他特征之处。

首先，即使在访问的网站上部署了严格的安全策略，SCC 攻击也可以成功。因为实际与客户端通信的是有共享证书的第三方服务器。
其次，它不会利用初始纯文本请求。因此，任何严格的 HTTPS 策略（例如 HSTS 机制中的指令或 CSP 中的 upgrade-insecure-requests）都无法阻止用户受到 SCC 攻击。特别是，SCC 攻击适用于已建立的安全连接。
第三，它不需要向客户端安装根证书，因为连接受受信任且有效的证书保护。因此，Web 浏览器或应用程序无法检测到 SCC 攻击。
最后，Web 浏览器在流量重新路由期间不显示身份验证错误，因此受害者用户几乎不会注意到 SCC 攻击。

SCC ATTACK IN THE REAL WORLD

本节介绍SCC攻击中绕过HTTPS安全策略的场景（4.1），并演示复杂网络环境下攻击的技术方法（4.2）。
如此前建模所述，对于每一次攻击，攻击者都需要恶意地将目标 HTTPS 请求重新路由到证书共享服务器。这可以通过DNS欺骗、IP/端口重定向和ARP欺骗来实现。（有引用参考论文）

Bypassing HTTPS Security Policies 绕过HTTPS安全策略

如此前建模，SCC 攻击者可以利用共享TLS证书的服务器之间的header不一致。
我们分析发现：以下HTTP response headers是可利用的，有安全风险。

场景1 通过不安全的Location Headers将 HTTPS 降级为 HTTP

实际场景中，Web服务器可以默认通过3xx重定向将HTTP连接升级到HTTPS URL，以实现最大的安全性。但如果Location field的字段设置成了不安全的值（e.g. HTTP URL），则3xx重定向可能会使通信面临威胁。这将导致攻击者可以使用来自服务器的不安全的3xx重定向将HTTPS traffic降级为明文。我们称之为HTTPS降级攻击。此思路适用于证书共享场景中的SCC攻击。

One-shot Downgrading Attack（Down-1）：攻击者只需重新路由一次流量即可降级 HTTPS 请求。
如果具有共享证书的ServerB返回3xx重定向到HTTP URL，攻击者就可以发起one-shot一次性降级攻击。

流程：

客户端请求https://a.example.com 时，攻击者应通过 DNS 欺骗或 TCP 重定向等方式将请求重新路由到有缺陷的 ServerB （IPB）。服务器 B 不会拒绝这样的请求：
- 如果它有Host checking issues（e.g., no or incorrect Host checks）并处理主机与默认服务器不匹配的请求;
- 或者，如果它实现了域别名并将请求重定向到一个有效的域，以避免用户在地址栏中输入时频繁的拼写错误。
然后，如果 ServerB 通过默认处理程序返回不安全的 3xx 重定向，则 HTTPS 连接将直接降级。

我们通过更改目标 IP 地址（第 5 节）进行了流量重新路由测量。我们发现 28.42% 的响应在 3xx 重定向中成功，即使 Host 不匹配，其中 17.17% 是不安全的重定向。例如，当我们向 MSN 的 IP （13.75.94.74）发送请求 htts://login.live.com 时，服务器会回复 301 重定向，并将 Location 设置为 http://www。msn.com/？。最后，如果用户代理遵循不安全的重定向，攻击者可以篡改明文内容以进行进一步的攻击，例如网络钓鱼、资源替换。

Multi-hops Downgrading Attacks (Down-2) 多跳降级攻击

多跳降配攻击通过链接多个 3xx 重定向来降低 HTTPS 请求。假设我们想用 HTTPS 流量拦截客户端和目标服务器之间的流量。但是，与该域共享 TLS 证书的服务器不会返回不安全的 3xx 重定向，该重定向可用于一次性降级。
但是，我们发现这个域名仍然容易受到 SCC 攻击，因为我们可以用同样的方式链接一系列的 3xx 重定向，最后将请求引导到不安全的 URL。图 3 描述了整个过程的示例。在这种情况下，攻击者恶意将请求（最初指向 https://billing.microsoft.com）重新路由到 168.62.198.20 （Req.1-Resp.1）后，客户端会收到指向 https://commerce.microsoft.com/ 的重定向。然后，攻击者对 https://commerce 重复相同的重新路由操作。 microsoft.com/ 和 https://login.live.com/ （Req.2Resp.3）。当客户端遵循第三个重定向时，它会发送一个明文请求（Req.4），该请求可以被攻击者拦截。

场景2 通过有缺陷的Strict-TransportSecurity Headers绕过 HSTS 安全策略

Web服务器可以通过HTTP响应标头来声明HSTS策略，从而强制浏览器只能以HTTPS访问它们。但由于misconfigurations（误配置）和partial adoptions（部分采用），攻击者可以使用一些方法绕过HSTS策略的保护。这些也适用于SCC攻击。
和情景1一样假设A完全采用HSTS，但B配置不好。SCC攻击者通过Server B上有缺陷的STS标头来绕过Server A的HSTS保护

Clear HSTS Policy for ServerA (HSTS-1). 清除ServerA的HSTS策略

攻击者找到一个与ServerA共享TLS证书的ServerB，并返回一个STS header 把max-age指令设置为0。这样，受害者请求A，被攻击者重定向到B，B的响应为STS：max-age=0，于是浏览器会清除ServerA的HSTS策略，因为它会将有缺陷的header视为被A返回的。之后如果用户再输入域名访问服务器A且不指定协议时，就会发出HTTP请求，该请求可以被攻击者拦截。

Cancel HSTS Policy for ServerA’s Subdomains (HSTS-2). 取消服务器 A 的子域（HSTS-2）的 HSTS 策略。

回想一下，如果域的 STS 标头中没有 includeSubDomains 指令，则默认情况下浏览器不会通过 HSTS 策略保护其子域，除非它们单独设置。
因此，在我们的威胁模型中，中间人可以使用服务器 B 有缺陷的 STS 标头攻击服务器 A （a.example.com）的子域。假设服务器 A 配置了 HSTS 策略，而服务器 B 的 STS 标头不包括 includeSubDomains。将请求重新路由到服务器 B 后，浏览器将更新从服务器 A 收到的 HSTS 策略，默认情况下不会使用 HSTS 策略保护服务器 A 的子域。因此，下次用户通过直接键入域来访问 ServerA 的子域之一时，将发出可篡改的不安全 HTTP 请求。
此外，如果 max-age=0 和 includeSubdomains 都出现在 ServerB 的 STS 标头中，则浏览器会忽略后者。在这种情况下，浏览器将清除 ServerA 的 HSTS 策略，并且不会为其子域设置 HSTS。

缩短服务器 A 的 HSTS 有效期（HSTS-3）。

作为一种危害较小的场景，攻击者可以通过将请求重新路由到服务器 B（其 STS 最大时间小于服务器 A 的 STS 最大时间）来缩短服务器 A 在浏览器中的 HSTS 缓存时间。例如，ServerA 的 HSTS 有效期为 31,536,000 秒（1 年）的标准，而 ServerB 的值仅为 1 天或更短。因此，如果用户在短时间内（例如一天）没有访问服务器 A，则用户代理将在用户下次（例如一天后）访问服务器 A 时发出 HTTP 请求。

讨论：如果将共享 TLS 证书中的所有域名都添加到预加载列表中，则可以缓解上述问题。但这是一个可选的功能，并非所有的域名都添加进去了。

不同链接状态下的攻击

SCC攻击可以在任意适当时间发起，而SSL Stripping攻击只能在初始请求时成功。
攻击者要成功攻击的技术挑战：

首先，需要精确识别要被劫持的HTTPS请求并找到拦截它的时间
如果连接是keep-alive，他们需要秘密地终止、重新连接。
拦截必须对用户不可见，以便攻击者破坏用户操作。

接下来逐个克服上述技术挑战。

攻击时机

图中caseA和B展示了每个连接一个请求的场景。我们将“对separate domain的请求”的拦截与“对specific path的请求”的拦截区分开来。
在caseA中，一个dedicated domain只提供要被劫持的单个资源：攻击者可以通过毒害DNS缓存来将请求重新路由到ServerB。因此，拦截不会影响对不同域提供的其他资源的请求。
在caseB中，一个域通过不同路径提供多个资源，则需要执行更多步骤来首先识别请求。攻击者不能把该域下所有流量重新路由到serverB，否则用户会注意到网页功能异常。相反，应该通过加密流识别指向目标路径的特定HTTPS请求（HTTPS路径泄露）。
然而攻击者只能在握手过程中拦截流量，因为他们需要通过重新路由请求来让客户端连接到服务器B。
因此，如果已经建立了持久安全连接（caseC），攻击者应该触发TLS握手的合法重启（TLS重新握手），这样就不会在浏览器中显示安全警告。

HTTPS路径泄露

以前的工作表明，注入HTTP会话的cookie将被附加到后续的HTTPS连接中。这个老威胁多年来还在困扰着公众。Chen等人提出了一种新方法来泄露HTTPS路径。我们将此方法应用于我们的威胁模型中：
假设攻击者试图拦截图 4 的案例 C 中 https://a.example.com/n 的请求。在此之前，他可以先通过对 a.example.com 的 HTTP 请求向该路径注入一个长 cookie，这样目标请求包的 TLS 记录大小就可以很大。然后嗅探 TLS 层，识别出他将要劫持的“大数据包”。

TLS 重新握手

假设客户端已经与ServerA建立了TLS连接。将客户端在连接重置后为新连接发起握手的过程称为TLS重新握手。（也可以认为是一次新的握手），是一种新的TLS连接状态。
我们在4.3的测试中发现一些浏览器在超时时试图重新启动剩余请求的握手，这时攻击者就可以在浏览器启动TLS重新握手时拦截HTTPS请求，并重新路由到ServerB。接下来进行进一步攻击等

浏览器对SCC攻击的行为

因为绕过HSTS那种攻击不会直接反映在浏览器行为中，所以我们只讨论HTTPS降级攻击。

HTTPS降级攻击中的浏览器安全提示

一般为了告知用户连接的安全性，主流浏览器在地址栏中显示指示器（例如 lock，shield）。同时，当远程服务器的真实性失效时，它们也会向用户发出警告。

而在HTTPS降级攻击中，浏览器都没有提供任何身份验证警告，且地址栏显示证书为“有效”。地址栏的indicator则在不同场景下略有不同。测试结果如下：

首先，通过地址栏/超链接降级请求。结果：降级攻击后地址栏会直接变成HTTP URL，之后浏览器的外观取决于攻击者对明文请求的处理。
第二种，降级请求，攻击后将连接升级回HTTPS。结果：在中间重定向期间，浏览器外观不会变化。只有在最后请求完成后，URL和页面才会转到此HTTPS内容。由于跳转时间段，且浏览器始终显示安全上下文，用户很难注意到攻击。此外，如果第一个请求发送给非呈现资源，则在②的下载过程中浏览器无任何变化。
第三种，降级对passive contents的请求。结果：不同浏览器显示不同

浏览器对TLS重新握手触发的行为

测试现代浏览器在不同OS上如何处理TLS重新握手。测试条件：两台服务器，共享证书。两个服务器都提供两个文件ImageA和ImageB。ServerB是不安全的，接受所有请求而不检查Host报头。接下来持久连接，从serverA请求这些文件。在两个请求之间发送TCP RST或触发Timeout，以检查浏览器是否开始重新握手，若发生则我们把第二个请求重路由到ServerB。

结果：表1打钩的情况下，浏览器在连接重置或超时后立刻TLS重新握手。不同浏览器表现不同。虽然有些浏览器不加载ServerB的ImageB，但如果ServerB返回指向HTTP URL的301/302重定向，它仍然是脆弱的。

如何发现潜在的易受攻击的服务器

Methodology

在我们的威胁模型中，攻击者将会攻击采取完整安全设置的服务器，利用与目标具有安全依赖关系的其他服务器的缺陷。

因此，给定一个域名列表来找易受攻击的域名，首先收集与之共享TLS证书的相关域名，然后给测试域名发HTTPS请求，并把这些请求交错地重定向到会被利用的相关域。

获取相关域名

从TLS证书数据集中解析相关的domain。证书数据集有几个选项：

Active Scan：对ipv4地址空间主动扫描
Passive Dataset：从passive traffic中解析证书，这展示了真实网络环境中正在使用的TLS证书，但成本高效率低。
公共数据集。但包含大量过期证书（冗余数据）

重路由HTTPS请求

流量重路由过程在TCP和IP层完成，因此我们可以考虑TCP 4-tuple。
可以切换服务器IP地址、切换服务器端口号、切换客户端IP地址、考虑CDN。

真实情景的危害分析

为了了解上述问题的影响，我们使用对热门网站进行了系统测量，以发现可利用的服务器。

…若干结果和数据summary

接下来展示证书共享场景中的安全依赖关系，建图描述，如果汇聚节点上的域是脆弱的，那么周围的域都会受到潜在安全威胁。
通过图可以发现一些受影响的顶点域之间的依赖链接样本。可抽取出一些示例关系：同一公司的子域和顶点域、子公司和控股公司、同一企业的跨地区服务、商业合作关系等等。

案例研究

我们发现了数千个易受攻击的域名。本节给出case study展示SCC攻击发生在与生活密切相关的场景中。

通过切换目的ip进行HTTPS降级攻击

案例1：劫持银行支付流程、下载劫持
案例2：虾米音乐安装包替换
案例3：微软/网易网站的网络钓鱼

切换客户端IP的HTTPS降级攻击

案例4：新浪微博

HSTS Bypassing Attack

案例5：清空高德的HSTS策略。将请求重新路由到另一个IP地址，由该IP地址承载的服务器在其报头中返回strict-transport-security:max-age=0。这个报头可以在客户端清除高德的HSTS缓存，因为浏览器将其视为由高德返回。因此，下次用户在没有协议的情况下直接输入域名访问高德网站时，浏览器会首先发起HTTP请求。

Discussion

Root Causes

证书共享
各方之间的安全策略实施存在问题
缺乏维护安全context的策略——需要一个策略来让客户机知道它们正在与之通信的服务器主机名，并采取措施来维护安全context。

Mitigation 减轻

浏览器应增强以下策略来保护浏览内容：

首先，建议浏览器显示有关浏览内容更改的安全指示器。更详细地说，从HTTP连接重定向的HTTPS连接不应该显示为“安全”。此外，我们进一步建议浏览器也应该阻止上下文已更改为“HTTPS>HTTP->HTTPS”的安全下载这是因为通过链接的最终HTTPS请求下载的资源可能是被攻击者替换的恶意资源。
其次，屏蔽所有混合内容。目前mixed passive contents（例如视频/图片，如国内的QR登录/支付码）还没有被所有浏览器屏蔽，只有Google Chrome阻止混合内容确保HTTPS页面不能再加载任何HTTP资源。考虑到安全性，我们建议所有浏览器阻止来自HTTPS上下文的任何不安全请求。

负责任的披露

我们已经提交了xxx，我们联系了xxx，回复，讨论问题和缓解措施

论文阅读24.9.9-24.9.13

CCS 2020: Talking with Familiar Strangers: An Empirical Study on HTTPS Context Confusion Attacks

Abstract & Introduction