白话SSL/TLS默认重协商漏洞原理与安全重协商对抗机制

SSL/TLS协议是现代互联网安全的基础，任何网上银行、电子商务、电子政务、电子医疗等等互联网重要应用，都要基于SSL/TLS提供的安全、保密、可信机制才能正常运行。所以，任何SSL/TLS的安全漏洞都值得我们深入研究并理解。

什么是重协商？

在SSL/TLS协议中，协商是指通信双方客户端和服务器，选取相同算法、传递数字证书、互验对方身份、交换共享密钥等一系列的动作。重协商（即，重新协商）是指在已经协商好的SSL/TLS TCP连接上重新协商，用以更换算法、更换数字证书、重新验证对方身份、更新共享密钥等等。SSL/TLS协议本身支持重协商，且RFC文档建议SSL/TLS实现（指OPENSSL等库）也应该默认支持重协商。

重协商包括两种方式，分别如图A和图B所示：

图A是客户端主动发出ClientHello2进行重协商。

图B是服务器通过发出Hello Request消息，请求客户端发起重协商。如果客户端同意重协商，则才会发起ClientHello2。

不管是哪一方发起的重协商，如果接收方不同意的话，都会通过SSL Alert响应以拒绝重协商。

几年之前，美国某安全公司的研究人员发现SSL/TLS协议重协商机制有严重的安全漏洞，中间人可以利用这个漏洞，将自己的数据注入到客户端与服务器的SSL/TLS“安全连接”之中。该漏洞被发现的第二年，通过RFC 5746引入新的“安全重协商”机制，来解决这个漏洞。本文先介绍一下默认重协商机制的安全漏洞的原理，再介绍一下安全重协商机制是如何对抗这个漏洞的。

什么是中间人？

所谓中间人，通常可能有如下三种形式。

第一种是通过伪造ARP消息，对局域网内用户流量进行重定向，令其所有流量都通过中间人中转，从而中间人有机会对流量的内容进行监视或篡改。

第二种是通过伪造DNS消息，对互联网用户访问指定网站的流量重定向，令其与该网站之间的流量都通过中间人中转，从而中间人有机会对该网站相关的流量内容进行监视或篡改。

第三种是企业网关、企业防火墙、电信运营商GGSN/PGW网关设备等，用户的流量必须经过这些设备才能正常上网，这些设备天生就可以从“转发者”转变为“中间人”从而对流经的流量进行监视或篡改。

普通用户可能通常不会遇到前两种情况，但是第三种情况很有可能发生。所以，作为客户端和服务器的软件开发者、以及SSL/TLS库的开发者，出于为用户的安全着想，应该确保拒绝不安全的重协商，或者只支持安全的重协商。

重协商的安全漏洞原理

 客户端首先发出一个ClientHello1，客户端期待进行首次协商。（注意：客户端认为ClientHello1是首次协商）

 中间人收到ClientHello1之后，按理说它应该将其转发给服务器。但是中间人这时决定“作恶”，将ClientHello1缓存起来暂不转发。中间人自己构造一个ClientHello2，对服务器发起首次协商，协商好后中间人将精心伪造的数据发送给服务器。（注意：服务器认为ClientHello2是首次协商）

 服务器收到这些数据，会认为这是正常的数据。因为服务器的APP程序通常需要处理粘包，所以中间人如果了解APP协议（如HTTPS）的话，则会精心构造不完整的数据，让服务器的APP程序认为发生粘包，将数据暂缓不处理，继续等待后续的数据上来。

 这时，中间人调出之前暂缓的ClientHello1，将其在同一个SSL/TLS TCP连接中，发送给服务器。（注意：ClientHello1消息本身是加密的，因为其是在ClientHello2协商好后的加密SSL/TLS连接中传输）

 服务器收到ClientHello1后，认为这是一次重协商，协商好后，客户端发送真正的数据给服务器。

 服务器的APP程序，收到客户端的真正数据后，将其与之前缓存的中间人精心构造的数据粘合起来，进行业务处理。

从而，中间人在不需要劫持、解密SSL/TLS连接的情况下，成功地将自己伪造的数据插入到用户真正数据之前。这个安全漏洞可以让心机卓绝的中间人做好多事情，比如伪造一个HTTP GET消息，然后用HTTP的IGNORE字段屏蔽掉真正数据的HTTP GET头，但是却保留了用户的Cookie信息，从而利用用户的Cookie去访问网站内容，比如可能利用此法删掉用户之前发的帖子等。

这个漏洞成因在于，客户端认为的首次协商却被服务器认为是重协商，以及首次协商和重协商之间缺少关联性。RFC 5746引入明确首次协商与重协商的方法，以及确认首次协商和重协商的关联性校验，从而确保中间人的攻击行为可以被识别并拒绝，保证重协商安全。

客户端发起ClientHello1。

中间人缓存ClientHello1，精心构造ClientHello2，与服务器进行首次协商。这里假设中间人在ClientHello2中不携带安全重协商标识。

中间人与服务器协商成功，发送伪造的数据给服务器。

中间人将之前缓存的ClientHello1发送给服务器。

如果服务器禁止重协商，则这时看到ClientHello1，会认为发生了重协商，不允许，所以中断连接。

如果服务器禁止不安全的重协商、但允许安全的重协商，则因为之前中间人构造的首次协商消息ClientHello2中指示不支持安全重协商，所以现在收到ClientHello1认为发生了不安全的重协商，所以中断连接。

因此，这种情况以及各种子情景都没有问题，不会有安全漏洞。

客户端发起ClientHello1。

中间人缓存ClientHello1，精心构造ClientHello2，与服务器进行首次协商。这里假设中间人在ClientHello2中携带支持安全重协商标识。

中间人与服务器协商成功，发送伪造的数据给服务器。在这时，因为双方都支持安全重协商，所以服务器会要求中间人将服务器发送的Finish消息中的首次协商会话摘要信息记录下来，以便重协商时再带给服务器；当然，服务器自己也会将这个首次协商会话摘要信息记录到自己的内存中）

中间人将之前缓存的ClientHello1发送给服务器。

如果服务器禁止不安全的重协商、但是允许安全的重协商，且如果ClientHello1中支持安全重协商，则按照RFC 5746是不合理的，只有首次协商ClientHello才允许带有支持安全重协商标识，重协商阶段的ClientHello是不允许携带该标识的。所以，服务器认为可能是遇到攻击，中断连接。

如果服务器禁止不安全的重协商、但是允许安全的重协商，且如果ClientHello1中不携带支持安全重协商标识，则服务器会认为这是正常的重协商。然后，服务器会提取出前边第3步中记录的首次协商会话摘要信息，按照RFC 5746，ClientHello1中应该带有相同的这个首次协商会话摘要信息。但是，一方面客户端的ClientHello1是不可能带有这个信息的，所以服务器校验失败；另一方面，如果中间人将这个信息插入给ClientHello1，那么虽然服务器现在校验成功，但是后续服务器校验协商会话完整性时还是会失败。

总而言之，安全重协商机制会补上重协商的漏洞隐患，让中间人攻击无机可乘。

参考文献：

1. RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2

2. RFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension

--------------------- 

原文：https://blog.csdn.net/o4dc8ojo7zl6/article/details/78537550