TLS 1.3 是什么
TLS 1.3 是 RFC 8446 定义的现代版本，把握手压缩到一次往返：客户端在 ClientHello 里直接带上 key_share，服务端回复 ServerHello 后双方即可计算握手密钥，之后的证书与完成确认都在加密信道内传输。它强制使用前向保密的 (EC)DHE 或 PSK，只保留 AEAD 加密套件，并把静态 RSA 密钥传输、CBC、RC4、压缩与重协商全部移除。
基本信息
| 标准 | RFC 8446（2018） |
|---|---|
| 握手轮次 | 1-RTT；会话恢复可选 0-RTT |
| 密钥交换 | 仅 (EC)DHE 或 PSK，强制前向保密 |
| 加密算法 | 仅 AEAD：AES-GCM、ChaCha20-Poly1305、AES-CCM |
| 密钥派生 | HKDF（早期密钥、握手密钥、主密钥分层派生） |
| 已移除项 | 静态 RSA、CBC、RC4、压缩、重协商、自定义 DH 组 |
| 协议标识 | 记录层版本号仍写 0x0303，需靠 supported_versions 扩展区分 |
典型使用场景
- 新建站点与反向代理：默认开启 1.3，兼顾安全与首字节延迟
- 移动端与弱网业务：少一次往返的握手对高延迟链路收益明显
- 内部服务与网关：公共库支持好，配合 mTLS 可直接落地
- 需要长期留存流量的场景：默认前向保密让历史会话不被私钥泄漏牵连
- 老客户端兼容场景：与 TLS 1.2 并存配置，按客户端能力自动协商
测试与套件查看
测试与套件查看
# 指定单一 1.3 套件测试，观察协商结果
openssl s_client -connect example.com:443 -tls1_3 -ciphersuites TLS_AES_128_GCM_SHA256 </dev/null | grep -E 'Protocol|Cipher'
# 查看本机 nginx 是否带 TLS 1.3 支持（编译参数里有 TLSv1.3）
nginx -V 2>&1 | grep -o 'TLSv1.3'
# 查看 OpenSSL 版本与支持的套件划分
openssl version -a
openssl ciphers -v 'ECDHE+AESGCM' | head -5
# 观察握手消息（1.3 中 ClientHello 之后即为加密记录）
openssl s_client -connect example.com:443 -tls1_3 -msg </dev/null 2>&1 | head -40三个标准套件
| 套件 | 结构 | 何时优先 |
|---|---|---|
| TLS_AES_128_GCM_SHA256 | AES-128-GCM + SHA-256 | 有 AES-NI 的平台，兼顾性能与强度 |
| TLS_AES_256_GCM_SHA384 | AES-256-GCM + SHA-384 | 合规要求更高强度或数据长期保护 |
| TLS_CHACHA20_POLY1305_SHA256 | ChaCha20-Poly1305 + SHA-256 | 无 AES 硬件加速的终端或移动端 |
0-RTT early data 允许客户端在首个包里携带业务数据，代价是存在重放风险：攻击者可以复制该数据包重复提交。只对幂等请求（查询类、静态资源）开放，写操作与支付类接口应禁用 early data。
部分老防火墙、负载均衡与 DPI 设备只认识 TLS 1.2 的明文握手结构，遇到 1.3 会挂起或误判。若线上出现「握手卡住、换 1.2 就正常」，优先怀疑中间设备，可临时启用兼容模式或升级设备。
TLS 1.3 中除 ServerHello 之外的握手消息（含证书）都已加密，抓包分析不再能看到证书明文。排障手段要改为 openssl s_client、服务端密钥日志（SSLKEYLOGFILE，仅调试环境）或应用日志。
部署与迁移要点
- 与 TLS 1.2 并存一段时间，先统计客户端分布再决定是否收紧版本
- 会话票据密钥要定期轮换，否则会话恢复路径会削弱前向保密的实际效果
- 0-RTT 只对幂等接口开放，并限制 early data 的体积上限
- 升级后回归老客户端：早期 Java 运行时、老款安卓与部分 IoT 库对 1.3 支持不完整
- 用 openssl s_client 与在线扫描工具双向确认协商结果，不要只看配置文件
- 监控握手失败率与密钥交换组分布，HelloRetryRequest 比例异常往往说明曲线组配置与服务端偏好不匹配
曲线组配置会直接影响延迟：服务端若只支持客户端未提供 key_share 的曲线，就会触发 HelloRetryRequest，多出一次往返，弱网下体感明显。把 X25519 与 P-256 放在优先位置并保证两端都支持，是压低 1.3 首包延迟的实用做法；反之若只保留冷门曲线，会同时损失兼容性与延迟。