摘要

  • TLS 1.2 的 Finished 用协商得到的秘密验证当前握手 transcript；重协商之前传输的应用数据并不会因此自动进入这份证明。
  • RFC 5746 用上一轮客户端与服务器的 verify_data 把新握手绑定到旧连接。主体切换、请求归属、授权、提交与外部结果仍需各自回执。

一条连接里出现了两种权威

连接已经在传输受保护数据，新的 ClientHello 又到来。服务器可能在第二轮要求客户端证书，双方协商新密钥，新的 Finished 顺利通过。TLS 层没有报警，运维记录显示成功。

Finished 到底证明了什么？RFC 5246 让 verify_data 取决于主秘密和双方看到的握手消息。验证成功说明双方同意这一轮协商 transcript 与密钥状态。这是一份强证据，但其对象不是整条应用对话。普通应用数据不属于握手 transcript。

原始重协商设计还缺少另一条关系：第二轮握手没有用密码学方式证明自己接续的是哪一条先前连接。中间方可以先与服务器建立 TLS、发送一段应用前缀，再把受害者的新握手接进来。服务器看到的是一次有效的后续认证，却可能把中间方的前缀和受害者后续字节拼成一个请求。

各个局部事件都可能是真的。错误发生在系统把它们编成了同一段故事。

套接字连续不等于身份连续

TLS 1.2 区分当前状态与待生效状态。握手准备算法、密钥与秘密；ChangeCipherSpec 把待生效状态复制为当前状态；Finished 则在新保护下检验协商结果。

这条状态机能回答“接下来的记录由哪套密钥保护”，却不能回答“之前缓冲的半条命令属于哪个主体”。套接字描述符没有变化，只能证明传输容器相同，不能证明容器内的权限从未变化。

应用解析器可能在匿名阶段读到请求头的一半，在证书认证后读到另一半。如果 TLS 终止层只把最新主体传给上游，旧缓冲区就可能继承新身份。密码学状态正确，应用授权却发生了时间错配。

RFC 5746 把推断变成回连校验

Secure Renegotiation 更新增加了 renegotiation_info 扩展和 TLS_EMPTY_RENEGOTIATION_INFO_SCSV。初始握手用空的重协商连接值声明支持；后续重协商则在扩展中携带上一轮客户端与服务器 Finished 的 verify_data。

新握手必须知道旧握手产生的值。若扩展中的值与端点持有的旧连接不符，重协商就应失败。连续性不再靠“它们碰巧在同一个 socket 上”来猜，而由两轮握手之间可验证的密码学关系来证明。

这个修复也反向说明原 Finished 的边界。如果当前 Finished 本来就包含旧连接，就没有必要再传上一轮值。

然而，支持扩展不等于执行过安全重协商。库可以识别扩展而策略禁止重协商；客户端可以发送 SCSV 而从未进行第二轮握手。审计必须分开记录实现能力、加载策略、线上信号、对端响应、实际重协商和旧值比对结果。

修好的通道仍有应用接缝

RFC 5746 连接两轮 TLS 握手，却不规定应用如何处理跨边界请求。匿名主体开始的命令，在证书主体出现后应被丢弃、按旧主体完成，还是重新开始？不同协议可能有不同正确答案。

因此，每个完成解析的请求都应带有安全代次和主体。主体发生变化时，系统需要显式策略：拒绝正在形成的消息，冻结旧身份直至消息结束，或清空缓冲重新定界。不能因为 Finished 成功就默认升级旧字节的权限。

RFC 5929 的 channel binding 可以让上层认证引用 TLS 通道属性，但生成 binding 和应用实际使用、核验 binding 仍是两份证据。应用协议必须亲自完成后一部分。

EMS 修复的是另一条绑定

RFC 7627 的 Extended Master Secret 用握手 transcript 的 hash 派生主秘密，解决 session hash、triple handshake 等问题。它和 RFC 5746 都谈“绑定”，连接的对象却不同。

EMS 把主秘密绑定到本轮握手；Secure Renegotiation 用上一轮 Finished 把新握手绑定到先前连接。把两者压成一个“TLS 已加固”开关，就无法判断哪条关系真的成立。

运行记录应分别保存 EMS 是否协商、安全重协商是否声明并执行、回连值是否正确、证书路径如何变化，以及应用最终生成哪个主体。细分不是合规装饰，而是故障定位所需的因果链。

TLS 1.3 移除了接缝，但没有自动清空旧资产

TLS 1.3 不再支持重协商，因而取消了连接内第二轮握手这条特殊路径。启用 TLS 1.3 并不能证明 TLS 1.2 已退出生产。终端可能同时接受两个版本，代理的外侧可能是 TLS 1.3，内侧仍然是 TLS 1.2。

RFC 9851 冻结 TLS 1.2 的常规新功能工作，也不会替运营者关闭 listener。真正的迁移需要终端清单、实际加载策略、观测到的协商、依赖负责人和沿同一路径运行的业务 canary。

只要重协商仍存在，就应保存一条会话账本：初始握手与 Finished；该代次收到的应用字节范围；重协商触发；安全声明；旧值比对；新证书与身份；状态激活；新 Finished；主体映射；请求边界；授权；提交；外部结果。

这份账本是 BTW 的运营分析，并非 RFC 5246 规定的日志格式。它只坚持一条原则：一份强密码学回执不能替自己从未观察的应用决定签字。

来源