TLS1.3特性解析|HTTP协议篇

不过 TLS1.2 已经是 10 年前（2008 年）的“老”协议了，虽然历经考验，但毕竟“岁月不饶人”，在安全、性能等方面已经跟不上如今的互联网了。

于是经过四年、近 30 个草案的反复打磨，TLS1.3 终于在去年（2018 年）“粉墨登场”，再次确立了信息安全领域的新标准。

在抓包分析握手之前，我们先来快速浏览一下 TLS1.3 的三个主要改进目标：兼容、安全与性能。

原理拆解： TLS 1.3 由 RFC 8446 在 2018 年标准化，它不是单纯增加一个版本号，而是围绕兼容性、安全性和连接时延重新约束协议。兼容性要求新客户端和服务器能够穿过大量按旧版报文编写的网络设备；安全性要求淘汰已经暴露风险或容易误配的旧机制；性能目标则是减少建立安全会话前必须等待的网络往返。三项目标彼此制约，例如改变握手外观可能更干净，却可能被只认识旧格式的中间设备阻断。

最小验证： 输入一个支持 HTTPS 的地址，强制 curl 只使用 TLS 1.3，验证客户端与服务端能否协商该版本，并观察实际协商结果：

url='https://example.com/'
curl --tlsv1.3 --tls-max 1.3 --verbose \
  --output /dev/null "$url" 2>&1 |
  grep -E 'SSL connection using|TLSv1\.3|HTTP/[123]'

--tlsv1.3 设置最低版本，--tls-max 1.3 排除降级到旧版本的可能；预期诊断信息中出现 TLSv1.3，随后出现 HTTP 响应协商或状态信息。命令成功只证明当前客户端、网络路径和目标站点可以使用该版本，不能单独证明其握手次数或算法集合。

边界与排查： 若本机 curl 所链接的 TLS 库不支持 TLS 1.3，命令会在发起有效握手前失败；若服务端仅开放旧版本，则会出现协议版本告警；代理、防火墙或企业中间人也可能改变结果。排查时先运行 curl -V 确认 TLS 后端，再对照不限定版本的请求，并结合抓包区分客户端能力、服务端配置和链路兼容问题。仅凭本段的三个设计目标，不能推导某次连接使用的具体密码套件或恢复方式。

由于 1.1、1.2 等协议已经出现了很多年，很多应用软件、中间代理（官方称为“MiddleBox”）只认老的记录协议格式，更新改造很困难，甚至是不可行（设备僵化）。

在早期的试验中发现，一旦变更了记录头字段里的版本号，也就是由 0x303（TLS1.2）改为 0x304（TLS1.3）的话，大量的代理服务器、网关都无法正确处理，最终导致 TLS 握手失败。

为了保证这些被广泛部署的“老设备”能够继续使用，避免新协议带来的“冲击”，TLS1.3 不得不做出妥协，保持现有的记录格式不变，通过“伪装”来实现兼容，使得 TLS1.3 看上去“像是”TLS1.2。

那么，该怎么区分 1.2 和 1.3 呢？

这要用到一个新的扩展协议（Extension Protocol），它有点“补充条款”的意思，通过在记录末尾添加一系列的“扩展字段”来增加新的功能，老版本的 TLS 不认识它可以直接忽略，这就实现了“后向兼容”。

在记录头的 Version 字段被兼容性“固定”的情况下，只要是 TLS1.3 协议，握手的“Hello”消息后面就必须有“supported_versions”扩展，它标记了 TLS 的版本号，使用它就能区分新旧协议。

其实上一讲 Chrome 在握手时发的就是 TLS1.3 协议，你可以看一下“Client Hello”消息后面的扩展，只是因为服务器不支持 1.3，所以就“后向兼容”降级成了 1.2

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Extension: supported_versions (len=11)
        Supported Version: TLS 1.3 (0x0304)
        Supported Version: TLS 1.2 (0x0303)

TLS1.3 利用扩展实现了许多重要的功能，比如“supported_groups”“key_share”“signature_algorithms”“server_name”等，这些等后面用到的时候再说。