摘要

  • 2018 年 8 月发布的 RFC 8446 用 supported_versions 扩展协商 TLS 1.3。旧式 legacy_version 字段保留 0x0303，那是 TLS 1.2 的编号；只看这个字段会误判实际连接。
  • 支持 TLS 1.3 的服务器若协商到 TLS 1.2，须在 ServerHello.random 最后八字节放入 44 4F 57 4E 47 52 44 01；若降到 TLS 1.1 或更低，末字节改为 00。TLS 1.3 客户端看到任一标记，须中止旧版握手。
  • 2015 年的 RFC 7507 处理另一条降级路径：客户端主动用较低版本重试时带上 TLS_FALLBACK_SCSV，支持较高版本的服务器可拒绝不当回退。IANA 登记了该信号与告警。

门口挂着旧号码

只读 ServerHello.legacy_version 的抓包分析员，可能把 TLS 1.3 连接报成 TLS 1.2。RFC 8446 让该字段沿用 0x0303，而把实际协议版本放入 supported_versions。字段名中的 “legacy” 已经说明职责：它维护旧式报文形状，不负责说明双方最终运行了什么。把外壳上的编号当成运行事实，监测系统就可能给新连接贴上错误的安全标签。

为什么要留下这个外壳？网络中已有设备学会检查旧握手的某些形状，遇到不熟悉的内容便让连接失败。RFC 8446 附录 D.4 为此描述兼容模式：客户端可以发送非空会话 ID，握手中可出现用于兼容的虚设 ChangeCipherSpec 消息，让旧中间设备看到熟悉的线索。终端若通过扩展选中了 TLS 1.3，运行的加密协议仍是 TLS 1.3。旧装束是给通道中间的设备看的。

这显示了一种不署名的权力。中间设备没有参与终端的安全承诺，却能靠丢弃陌生流量逼迫新协议改写外观。标准接受了已部署设备在字节外形上的要求，同时把真正的版本决定留给终端读取的扩展。要分清的不是一个字段有无出现，而是哪一处记录承担“已协商版本”的权威。

另一端藏着八个字节

外观兼容之外，还有更恶劣的可能：路径上的攻击者诱使两端谈成较旧版本。TLS 1.3 在支持新版本的服务器生成的 ServerHello.random 尾部设置标记。该服务器若最终协商 TLS 1.2，最后八字节必须是 44 4F 57 4E 47 52 44 01。协商 TLS 1.1 或更低时，必须用相同的前七字节加 00。前七字节按 ASCII 拼出 DOWNGRD；最后一字节区分旧版区间。

TLS 1.3 客户端若收到标称 TLS 1.2 或更低版本的 ServerHello，必须检查这两种尾部字节。命中就以 illegal_parameter 告警中止握手。标记告诉客户端：服务器原本有更新的能力，当前却在更旧的协议上落脚。客户端不能只因旧版握手看起来能完成，就把这个差距当成正常谈判结果。

警报的作用范围有清楚边界。RFC 8446 称之为对 Finished 交换之外的有限附加保护：临时密钥套件下，旧握手中的签名把随机值固定在可验证的交换里；静态 RSA 不提供同样的降级保护。标准也承认，已部署的许多 TLS 1.2 实现不会按新规则产生或检查标记。只有具备相应能力的服务器写入、客户端检查，八字节才成为有效的警报。

客户端重试还有另一道哨兵

2015 年的 RFC 7507 面对的是不同动作。客户端遇到握手失败，有时会为了兼容用较低版本再试一次。能制造失败的攻击者便可能推动这种回退。客户端在较低版本的重试中加入 TLS_FALLBACK_SCSV，若服务器支持更高版本，就以 inappropriate_fallback 拒绝。信号值和告警都见于 IANA TLS 参数登记表。

2015 年的信号由正在重试的客户端提出；2018 年的随机值标记由能运行新版本的服务器提出。它们分别暴露谈判中不同位置的知识。若把两者混为一谈，就看不见是谁在何时知道“其实还有更高版本”。一个最终成功的旧版连接，只能说明旧版连接跑通，不能回答为什么两端没用上共同具备的新版本。

旧外衣归谁管

附录 D.4 记录了已部署设施迫使新协议让步的现场。TLS 1.3 必须像旧握手，才更容易越过认死规矩的设备；随机值尾部的警报则为另一个问题划线：兼容的外观不能悄悄变成同意降级。终端保住了版本选择的权威，也给客户端留下可检查的较低版本选择证据。

官方标准与登记表说明协议规则。要确认某条实际连接是否使用兼容模式并出现标记，还需要带日期的抓包，以及客户端、服务器的实现记录。历史事实已经足够锋利：2018 年，TLS 1.3 把真正的版本藏在扩展里，让旧编号继续挂在门口，同时要求有能力的服务器在退回旧版时于随机值末尾亮灯。