摘要

  • TLS 早期重协商缺少把新握手绑定到既有握手的密码学机制，因此攻击者可以先建立连接、发送应用层前缀，再把受害者的握手插入同一连接作为重协商。
  • RFC 5746 通过初始握手中的安全重协商支持信号，以及重协商时携带既有握手 Finished 验证数据，建立了这条绑定；TLS 1.3 进一步取消了重协商，但这些协议改进本身并不等于所有遗留路径都已退出。

从协议缺陷到有限的应用影响

旧式 TLS 重协商问题的核心不是“加密被完全破解”，而是两个握手之间缺少足够的密码学关联。攻击者首先与服务器建立 TLS 连接。连接建立后，攻击者可以发送一段应用层前缀；随后，受害者的握手被服务器视为同一连接上的重协商。若服务器把前后两段应用数据当作连续上下文处理，受害者的认证或请求可能被置于攻击者预先发送的前缀之后。

这是一种有边界的前缀注入影响，而不是对任意后续会话内容的普遍解密。风险取决于服务器如何处理重协商、认证与应用层数据的连接，以及哪些遗留实现仍允许不安全路径。RFC 5746 将问题表述为“安全重协商”需要把初始握手和后续重协商明确关联，而不是仅仅继续允许另一轮握手。

RFC 5746 的修复机制

RFC 5746 使用了两个作用不同的机制。初始握手阶段，端点可以通过 renegotiation_info 扩展或 TLS_EMPTY_RENEGOTIATION_INFO_SCSV 表示对安全重协商的支持。这个信号说明端点理解安全重协商机制，但它本身不是把两轮握手绑定起来的全部证据。

在实际重协商中，新的握手会携带与既有握手相关的 Finished 验证数据。该数据把新的 ClientHello 或 ServerHello 与先前握手的密码学结果联系起来，使服务器能够检测前后握手是否属于同一条安全重协商链。修复的关键不是增加一个抽象的“安全”标记，而是让重协商能够验证其前置握手。

RFC 5746 的意义因此有两个层面：它修复了协议中缺失的绑定，并为实现提供了兼容旧端点的迁移路径。但规范发布只说明了协议应如何工作，并没有列出每个组织已经更新的终端、负载均衡器、TLS 终止设备、库版本或内部服务链路。

TLS 1.3 改变了问题边界

TLS 1.3 不再支持 TLS 1.2 式重协商。协议把后续功能拆分为更窄的机制，例如密钥更新和后握手认证，而不是允许另一轮具有同样语义的重协商。这减少了旧式重协商所带来的状态组合和上下文拼接风险。

但“支持 TLS 1.3”不能自动证明整条业务路径已经不再接触旧式 TLS。一个公共入口可能支持 TLS 1.3，而下游内部跳转仍由旧库、代理或设备终止；某些客户端、专用设备和难以升级的应用路径也可能继续依赖 TLS 1.2。协议版本的改进与部署面的实际状态是两个需要分别验证的问题。

修复之后，运营者还必须证明什么

要把协议修复转化为可审计的风险收尾，运营者至少需要把验证面拆开，而不是只检查一个公共端点：

  • 公共端点：测试实际协商版本、重协商行为和异常握手处理；
  • 内部服务跳转：确认东西向连接没有绕过边界控制；
  • TLS 库或产品：记录版本、配置和默认行为；
  • 终止设备：核对负载均衡器、网关、代理和专用设备的实现；
  • 应用路径：确认认证上下文不会把旧连接中的前缀与新请求错误拼接。

每个面都需要有资产清单、测试结果、例外负责人和退休或升级证据。没有这些记录，组织可以合理地说“标准已经修复”，却不能据此说“所有受影响路径已经关闭”。

证据边界

IETF 的 RFC 5746 描述了安全重协商的缺陷与修复机制；RFC 8446 描述了 TLS 1.3 的握手和不再支持重协商的协议边界；更早的 TLS 规范和安全分析文档说明了旧版本中的重协商与实现风险。它们能够证明协议设计、机制和适用边界，但不能证明某一组织的全部部署已经完成迁移。部署闭环需要组织自己的端点测试、资产盘点、例外记录和退役证据。 RFC 5246 RFC 5746 RFC 7457 RFC 7525 RFC 8446 RFC 9325