TLS 重协商与缓解
TLS 1.2 允许在握手完成后重新协商参数（包括由客户端发起），历史上出现过前缀注入类问题，现代实现默认启用 RFC 5746 定义的安全重协商扩展加以缓解。TLS 1.3 则彻底取消了重协商，改用 KeyUpdate 更新密钥、用握手后认证处理需要再认证的场景。因此「我的服务是否还有重协商」这个问题，答案取决于协议版本与底层实现的安全默认值。
基本信息
| TLS 1.2 | 支持重协商；OpenSSL 1.0.1 及以上默认启用 RFC 5746 安全重协商标记 |
|---|---|
| TLS 1.3 | 无重协商概念，改用 KeyUpdate 与握手后认证 |
| 主要风险 | 客户端发起的重协商带来 CPU 放大与历史注入类问题 |
| 缓解方向 | 升级底层库与服务端软件，协议收敛到 1.2 以上 |
| 兼容顾虑 | 少数老旧设备依赖在已建立连接上再做客户端认证 |
典型使用场景
- 评估协议基线时确认是否还残留客户端可发起的重协商
- 排查 CPU 异常升高：可能与重协商风暴或被利用有关
- 升级 nginx 与 OpenSSL 后验证重协商行为的变化
- 老设备兼容评估：确认哪些流程依赖重协商
- 安全测评中回答「是否支持不安全重协商」这类问题
确认库版本与协议基线
确认库版本与协议基线
openssl version # 确认底层库版本
nginx -V 2>&1 | grep -o 'OpenSSL [0-9.]*[a-z]*' # nginx 实际链接的库
# 服务端协议基线建议（nginx）：
# ssl_protocols TLSv1.2 TLSv1.3;
# 抓包观察是否有新的 ClientHello 出现在同一连接上：
# tshark -i eth0 -Y 'tls.handshake.type == 1' -c 20版本差异对照
| 版本 | 重协商支持 | 替代机制 |
|---|---|---|
| TLS 1.2 | 支持，需 RFC 5746 缓解 | 无，仍依赖重协商 |
| TLS 1.3 | 不支持 | KeyUpdate 与握手后认证 |
| 现实残留 | 少量老设备依赖 | 单独入口或升级客户端 |
| 排查重点 | CPU 与连接行为异常 | 结合抓包判断 |
少数老旧设备依赖重协商，例如在已建立连接上再做客户端证书认证的应用。升级到 TLS 1.3 前要先验证这些流程，它们往往是升级受阻的真实原因，而不是证书或套件问题。