TLS 1.2 vs TLS 1.3：有哪些变化，该如何配置

TLS 1.2 与 TLS 1.3 已经不是两个平起平坐的选项。TLS 1.2（RFC 5246，2008年）在限定为 ECDHE 密钥交换和 AEAD 密码套件时是安全的；TLS 1.3（2018年的 RFC 8446，2026年7月修订为 RFC 9846）把这变成了唯一的选项，加密了握手中更多的部分，而且是唯一提供后量子混合密钥交换和加密 ClientHello 的版本。

概览

握手过程

TLS 1.2 先协商，后交换密钥：客户端列出密码套件，服务器选定一个并发送自己的证书和密钥交换参数，客户端发送自己的密钥共享（key share），然后双方完成握手。应用数据开始传输之前要经过两次往返，而且证书以明文传输。使用静态 RSA 套件时，客户端用服务器证书的密钥加密预主密钥，因此日后获得该密钥的任何人，都能解密此前记录下来的每一个会话。

TLS 1.3 则采用猜测策略：客户端在第一条消息中就为自己首选的组发送密钥共享，服务器回复自己的密钥共享，并紧接着发送经过加密的扩展、证书、CertificateVerify 和 Finished，客户端经过一次往返即可发送数据。恢复的会话甚至可以携带 0-RTT 早期数据，代价是这部分数据失去重放保护。

下面的脚本于2026年10月20日用 OpenSSL 3.6.5 对一台公共服务器运行，展示同一个客户端分别强制使用两个版本时的实际结果。

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

这里的 TLS 1.2 连接是安全的，因为服务器只允许 ECDHE 搭配 AEAD，但它只能使用经典的 X25519；TLS 1.3 连接则协商出了后量子混合方案。

TLS 1.3 移除了什么，为什么

2010年代几乎所有著名的 TLS 攻击，利用的都是 TLS 1.2 时代、后来被 TLS 1.3 删除的某项功能：

• CBC 模式与先 MAC 后加密（BEAST、Lucky Thirteen、POODLE）：只保留 AEAD 加密算法。
• RC4（统计偏差）和 3DES（SWEET32）：已移除。
• RSA 密钥传输（Bleichenbacher 填充预言攻击、ROBOT；没有前向保密）：已移除。
• 出口级和任意有限域群（FREAK、Logjam）：只保留命名组。
• 重新协商和压缩（三重握手攻击、CRIME）：已移除。
• 只覆盖部分握手记录的签名（TLS 1.2 的 ServerKeyExchange 只对参数签名）：CertificateVerify 对整个握手记录签名。
• 签名中的 SHA-1 和 MD5：已移除。

RFC 9846 还收紧了对 TLS 1.2 实现的要求；RFC 9325 列出了 TLS 1.2 的安全子集：ECDHE 或 DHE 搭配 AEAD、扩展主密钥（RFC 7627）以及安全重新协商。

只有 TLS 1.3 提供的功能

• 后量子混合密钥交换（X25519MLKEM768，RFC 10024），主流浏览器自2024年底起、OpenSSL 自 3.5 起默认协商。
• 加密 ClientHello（RFC 9849），配合 DNS HTTPS 记录使用时，可以对网络隐藏服务器名称。
• 证书压缩（RFC 8879）和委托凭证（RFC 9345）。
• QUIC，它内嵌了 TLS 1.3 握手，是 HTTP/3 的传输协议。

合规与政策

• 美国联邦系统：NIST SP 800-52 Rev. 2 要求政府 TLS 服务器在2024年1月1日前支持 TLS 1.3，并允许使用核准套件的 TLS 1.2。
• 支付卡环境：自2018年6月30日起，PCI DSS 禁止使用 SSL 和早期 TLS（1.0）；TLS 1.2 和 1.3 都可以接受。
• IETF：RFC 8996 于2021年弃用了 TLS 1.0 和 1.1；浏览器则在2020年移除了它们。
• 后量子规划：NIST IR 8547（草案）和 CNSA 2.0 都以混合或后量子密钥建立为前提，而这只有 TLS 1.3 才能提供。

如何选择

• 公共网站和 API：优先使用 TLS 1.3，以采用安全子集的 TLS 1.2 作为后备。
• 内部服务、服务网格、mTLS：只用 TLS 1.3。
• 旧版客户端（旧版 Android、嵌入式设备、较旧的 Java 和 Windows 版本）：使用 ECDHE 和 AEAD 的 TLS 1.2，并规划淘汰这些客户端。
• 检查流量的中间设备：应预期它们需要更新，以支持 TLS 1.3、ECH 和较大的后量子 ClientHello，而不是让服务器迁就它们。
• 任何需要后量子机密性的场景：使用混合组的 TLS 1.3。

迁移说明

1. 升级 TLS 库：TLS 1.3 需要 OpenSSL 1.1.1 或更高版本，默认后量子组需要 3.5 或更高版本；或者当前版本的 BoringSSL 和 Go、Java 11 或更高版本、Windows Server 2022 或更高版本。
2. 在 1.2 之外启用 TLS 1.3，然后把 1.2 精简为 ECDHE 和 AEAD 套件；在 nginx 中使用 ssl_protocols TLSv1.2 TLSv1.3; 并配上简短的 ssl_ciphers 列表，因为 TLS 1.3 套件是单独配置的。
3. 检查证书和密钥：RSA 证书可以用于 TLS 1.3，因为握手签名使用同一密钥做 PSS 签名；ECDSA 证书无需任何改动即可使用。
4. 决定是否启用 0-RTT：除非应用能够安全地处理早期请求的重放，否则保持关闭。
5. 测量剩余的 TLS 1.2 流量，在流量降到零的地方设定停用日期。TLS 配置生成器可以为常见服务器生成配置，批量域名检测会报告你的主机接受哪些版本。

参考资料

• RFC 9846：TLS 1.3（§1.3 与 TLS 1.2 的差异，§1.4 影响 TLS 1.2 的更新）
• RFC 5246：TLS 1.2
• RFC 9325：安全使用 TLS 和 DTLS 的建议
• RFC 8996：弃用 TLS 1.0 和 TLS 1.1
• RFC 10024：TLS 1.3 的混合 ML-KEM 密钥协商
• RFC 9849：TLS 加密 ClientHello
• NIST SP 800-52 Rev. 2
• PCI SSC：从 SSL 和早期 TLS 迁移