通信协议TLS会话协商和压缩禁用目的

“ 本篇文章主要讲解了TLS通讯协议，为什么要禁用会话协商和压缩功能”

禁用TLS会话重协商和TLS压缩功能的主要目的是为了提高安全性，防止潜在的安全漏洞被利用。

01 禁用TLS会话重协商

1  禁用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，那么虽然服务器现在校验成功，但是后续服务器校验协商会话完整性时还是会失败。
总而言之，安全重协商机制会补上重协商的漏洞隐患，让中间人攻击无机可乘。

如何防止 SSL 重协商攻击？

以下是阻止 SSL 重新协商攻击对网站和访客造成危害的五种方法：

1. 实施严格的 TLS 版本控制：配置服务器，使其只支持 TLS 协议的最新版本，如TLS 1.2 或 TLS 1.3。旧版本的 TLS 存在已知漏洞，攻击者可加以利用。

2. 禁用 SSL 重新协商：完全禁用 SSL 重新协商或将其使用范围限制在受信任的客户端。攻击者可以滥用它，注入有效载荷或破坏通信。禁用或严格控制重新谈判可以降低这种风险。

3.使用完美前向保密 (PFS)：启用 “完美前向保密“功能，以确保用于加密的每个会话密钥都是唯一的，并且不是从服务器的私人密钥中提取的。即使攻击者将来侵入了服务器的私钥，也无法解密过去的通信。PFS 增加了一个额外的保护层，防止 SSL 重新协商攻击。

4.实施速率限制和监控：设置速率限制机制，以检测和减少过多的 SSL 重新协商请求。监控 TLS 流量，以发现表明攻击正在进行的异常情况和意外模式。您可以主动监控 SSL 重新协商活动，实时识别并阻止潜在威胁。

5.定期更新 SSL 库并打补丁：例如，如果您使用的是OpenSSL，请确保您运行的是最新版本，如 OpenSSL 3.0，并应用 OpenSSL 项目提供的补丁来解决任何已发现的漏洞。同样，如果你的应用程序依赖于特定的 SSL/TLS 库（如 LibreSSL 或 BoringSSL），请定期检查更新并应用其各自维护者发布的补丁。

02 禁用TLS压缩

1. 禁用TLS压缩：

防止CRIME攻击：TLS压缩存在安全漏洞，可以通过CRIME攻击窃取启用数据压缩特性的HTTPS或SPDY协议传输的cookie。因此，在TLS 1.3中删除了该特性以增强安全性。

TLS 1.3协议好在哪？

安全强化，TLS1.3依循极简主义的设计哲学，移除并修复了旧版本协议中的坏味道，将密钥交换、对称加解密、压缩等环节中可能存在的安全隐患剔除，防范于未然。
性能提升，TLS1.3在提高效率方面进行了大量改进，特别是对SSL握手过程进行了重新设计，将握手交互延时从2-RTT降低至1-RTT甚至是0-RTT。在网络环境较差或节点距离较远的情况下，这种优化能节省几百毫秒的时间。这几百毫秒往往就能决定用户下一步的行为是继续浏览网页还是关闭网页。

TLS 1.2与TLS 1.3对比总结

相比TLSv1.2，TLSv1.3主要的优势如下：

性能提升：完全握手场景下，TLSv1.3握手消耗1-RTT；会话复用的场景，TLSv1.3握手消耗0-RTT；均比TLSv1.2少一个RTT。安全提升：TLSv1.3完全支持PFS（即完全前向安全）的密钥交换算法；禁用有安全漏洞的加密套件；对ServerHello消息之后的握手信息加密。

防止信息泄露：启用TLS压缩可能导致敏感信息的泄露，而这些信息如果不进行压缩就不会泄露。禁用压缩功能可以减少这种风险。

使用压缩

压缩可以使攻击者在与攻击者控制下的数据相同的上下文中对其进行压缩时恢复秘密数据。HTTP/2 可以压缩头字段；以下注意事项也适用于 HTTP 压缩内容编码的使用([RFC7231])。

研究表明，压缩攻击利用了网络的特征(例如 [BREACH])。攻击者会诱使多个请求包含不同的明文，并观察每个明文中得到的密文的长度，当对密文的猜测正确时，会暴露出较短的长度。

在安全通道上进行通信的实现方不得压缩包含加密数据和攻击者控制的数据的内容，除非为每个数据源搭配使用单独的压缩字典。如果不能可靠地确定数据源，则不得使用压缩。通用 stream 流压缩(例如 TLS 提供的压缩)不得与 HTTP/2 一起使用。在 [COMPRESSION] 中描述了有关头字段压缩的其他注意事项。

03 小结

禁用TLS会话重协商和TLS压缩功能是为了防止各种类型的攻击，包括拒绝服务攻击、中间人攻击以及信息泄露，从而确保通信的安全性和可靠性。

因此，安全通信协议建议为 TLS1.2或以上版本，TLS1.3更有优。