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

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

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

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

现有的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攻击的风险提示机制或拦截措施。

在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会发出报警提示。

（未完待续……）