TLS 重协商的兴衰
TLS 1.2 允许在同一条已建立的连接里重新协商参数，典型用途是中途要求对方提供客户端证书，或把安全强度提升到更高等级。便利的代价是攻击面：历史上出现过重协商风暴耗尽服务器资源，以及握手中毒一类漏洞，安全重协商扩展正是为了修补这些问题。TLS 1.3 直接移除了这项机制，把中途认证改为握手后认证，把密钥更新抽成专门的密钥更新消息。
基本信息
| 涉及版本 | TLS 1.2 允许，TLS 1.3 已移除 |
|---|---|
| 典型用途 | 中途请求客户端证书、提升安全参数 |
| 主要风险 | 资源耗尽型攻击、握手相关的历史漏洞 |
| 加固手段 | 使用安全重协商扩展，或直接禁用重协商 |
| 1.3 替代 | 握手后认证与密钥更新 |
| 识别方式 | 同一连接内出现第二次客户端问候 |
1.2 与 1.3 对照
| 能力 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 中途变更参数 | 通过重协商完成 | 不再提供该机制 |
| 中途请求客户端证书 | 依赖重协商 | 使用握手后认证 |
| 更新密钥 | 通过重协商 | 专门的密钥更新消息 |
| 抓包特征 | 同一连接出现第二个问候 | 不会出现该特征 |
服务端配置示例
服务端配置示例
# 客户端证书校验的策略需要与重协商行为一起考虑
ssl_verify_client optional;
ssl_verify_depth 2;
ssl_protocols TLSv1.2 TLSv1.3; # 同时保留时注意两者的认证时机差异
# 抓包确认是否存在重协商：同一连接内是否再次出现客户端问候典型使用场景
- 协议升级评估：从 1.2 升到 1.3 前确认客户端证书的请求时机变化
- 老客户端兼容：确认对方是否依赖重协商提交客户端证书
- 安全加固：核对历史漏洞相关的缓解措施是否仍然有效
- 抓包分析：判断会话是否发生多次握从而导致延迟
- 接入链路排障：多层设备都对同一连接提出认证要求时的时序问题
判断是否发生重协商很直观：在抓包结果里看同一条连接内是否出现第二次客户端问候，现代 TLS 1.3 连接不会再有这个现象。如果升级到 1.3 后客户端证书相关的功能失效，方向就在认证时机上，而不是证书本身或密钥配置。