重协商与 KeyUpdate
重协商是在已经建立加密通道的基础上再跑一次握手，用来更换参数或证书。TLS 1.2 及以前允许重协商，RFC 5746 为它补了 renegotiation_info 扩展以防中间人劫持；TLS 1.3 直接取消重协商，改用 KeyUpdate 更新密钥。抓包里的判断信号很直观：应用数据阶段又出现了 ClientHello/ServerHello。
基本信息
| 协议范围 | 1.2 及以前允许重协商；1.3 禁止，只有 KeyUpdate |
|---|---|
| 观察点 | 首次握手之后再现握手消息 |
| 安全要点 | 1.2 需协商 renegotiation_info（RFC 5746） |
| 成本 | 每次重协商 1~2 个额外往返，加上证书校验与 CPU |
典型使用场景
- 会话中途更换证书：虚拟主机切换、SNI 变化触发
- 服务端要求客户端证书时触发，1.2 环境较常见
- 排查连接莫名中断或延迟突增：重协商带来额外往返与超时
- 合规审计：未打补丁的重协商在旧实现上存在历史劫持风险
- 核对服务端策略：部分服务端已禁用重协商，客户端主动请求会失败
过滤与判读
过滤与判读
tshark -r t.pcap -Y "tls.handshake.type==1" -T fields -e frame.number -e ip.src -e tcp.srcport
# 同一 TCP 会话里第一条 ClientHello 之后仍有 ClientHello = 重协商
tshark -r t.pcap -Y "tls.handshake.type==24" -T fields -e frame.number
# 24 是 TLS 1.3 的 KeyUpdate，属正常密钥更新，不是重协商
tshark -r t.pcap -Y "tls.alert_message.desc==100" # no_renegotiation：服务端拒绝重协商现象对照
| 现象 | 协议版本 | 性质 |
|---|---|---|
| 应用数据阶段再现完整握手 | 1.2 | 重协商，需要溯源触发条件 |
| 握手消息类型 24（KeyUpdate） | 1.3 | 正常密钥更新，不是异常 |
| Encrypted Handshake Message 反复出现 | 1.3 未解密 | 可能是 KeyUpdate 或会话票据 |
| 告警 no_renegotiation(100) | 1.2 | 服务端拒绝重协商，客户端请求被挡 |
高频重协商值得追：常见触发条件包括证书轮换、负载均衡重新分配后端、客户端主动重协商。先统计每小时重协商次数，再按后端实例分组，能快速收敛到配置问题。
不要把 TLS 1.3 的 KeyUpdate 当重协商告警。它位于加密记录内，未解密时通常只显示为 Encrypted Handshake Message，看不到类型 24，容易误报。
排查顺序
- 先按 TCP 五元组分流，确认多次 ClientHello 是否落在同一条连接上
- 统计重协商频率与时间分布，看是否与证书轮换、定时任务或发布窗口重合
- 核对服务端是否显式禁用重协商，禁用后客户端请求会收到 no_renegotiation(100)
- 检查是否启用了强制客户端证书，1.2 环境下这一步会触发重协商
- 评估影响面：重协商的额外往返会放大高延迟链路上的首字节时间