一、概述

TLS 重新协商漏洞（TLS Renegotiation Vulnerability，CVE-2009-3555），又称为 插入式重新协商攻击（Insertion Renegotiation Attack），是 TLS 协议设计中的一个严重安全缺陷。该漏洞允许中间人攻击者（MITM）在加密会话中注入恶意数据，而服务器无法区分这些数据是否来自原始客户端。

漏洞信息概览：

二、什么是 TLS 重新协商？

在 TLS 连接建立后，客户端或服务器可以在不中断现有连接的前提下，重新执行握手过程以更改加密参数或添加身份验证（如客户端证书）。这种机制被称为“重新协商”（Renegotiation）。

典型应用场景包括：

• 客户端请求更强的加密算法。
• 服务器要求客户端提供证书进行双向认证。
• 切换密钥材料（key material）以增强安全性。

三、漏洞原理详解

1. 漏洞核心问题

TLS 协议没有绑定重新协商前的数据流与当前会话的身份上下文。

这意味着攻击者可以在客户端发起重新协商之前，向加密通道中注入任意明文数据，而服务器无法判断这些数据是否属于合法客户端。

2. 攻击流程图解

[攻击者]                   [客户端]                     [服务器]
    |                           |                            |
    | ←→ 握手建立初始连接 → |
    |      加密通道建立完成     |
    |← 注入恶意请求（明文）→   |
    |        （此时未触发重新协商）                      |
    |                           | ← 触发重新协商 → |
    |                           | ←→ 重新协商握手 → |
    |                           |                        |
    |                           | ← 发送正常请求 → |
    |← 服务器将恶意请求与正常请求合并处理 →|

攻击步骤解析：

1. 建立加密连接：

   • 客户端与服务器通过 TLS 握手建立加密连接。

2. 攻击者注入恶意请求：

   • 攻击者处于中间位置，在不破坏加密连接的情况下发送恶意 HTTP 请求（如 GET /delete-account）。

3. 客户端发起重新协商：

   • 客户端主动请求重新协商（例如为了启用客户端证书）。

4. 服务器接受重新协商但未验证历史请求来源：

   • 服务器执行新的握手过程，但不会检查之前的请求是否属于当前会话。

5. 服务器执行攻击者的请求：

   • 最终，服务器将攻击者注入的请求与客户端的真实请求一起处理，导致潜在危害。

四、实际攻击示例

假设某银行网站支持重新协商，并且未启用 Secure Renegotiation：

1. 用户访问 https://bank.com/login 并登录。
2. 攻击者拦截流量并在加密连接中插入以下请求：

   GET /transfer?to=attacker&amount=10000000
   

3. 然后用户点击“查看账户余额”，触发重新协商。
4. 服务器收到请求后，先处理攻击者的转账请求，再处理用户的余额请求。
5. 用户无感知地完成了转账操作。

五、修复方法：RFC 5746（Secure Renegotiation）

为了解决这个问题，IETF 在 2010 年发布了 RFC 5746，引入了 Secure Renegotiation Extension。

核心机制：

• 新增 TLS 扩展：renegotiation_info。
• 该扩展包含上一次握手的 verify_data 哈希值。
• 在每次重新协商时，双方必须交换这个哈希值作为身份标识。
• 如果服务器发现哈希值不匹配，则拒绝重新协商。

示例流程：

[客户端]                       [服务器]
    |                             |
    | → ClientHello (ext: renegotiation_info = hash1) → |
    | ← ServerHello (ext: renegotiation_info = hash1) ← |
    |                             |
    | → ClientHello (re-negotiate, ext: renegotiation_info = hash2) → |
    | ← ServerHello (ext: renegotiation_info = hash2) ← |

这样就确保了只有原始通信方才能发起重新协商。

六、如何检测系统是否受影响？

方法一：使用 OpenSSL 命令行工具

openssl s_client -connect yourdomain.com:443 -renegotiate

如果输出中有类似如下内容，表示已启用 Secure Renegotiation：

Secure Renegotiation IS supported

否则，可能存在风险。

方法二：使用在线工具检测

• SSL Labs SSL Test：ssllabs.com/ssltest
• 检查报告中的 “Secure Renegotiation” 是否为 “Supported”。

七、主流软件支持情况（截至2025年）

八、总结

九、推荐防御措施

1. 升级 TLS 库至最新版本，确保支持 RFC 5746。
2. 禁用不安全的旧版 TLS 版本（如 TLS 1.0 和 1.1）。
3. 定期使用 SSL Labs 或其他工具扫描服务安全性。
4. 在应用层实现请求边界检查，防止多个请求被合并处理。
5. 对关键业务接口增加身份验证和请求签名机制。