TLS 1.3实战：握手优化、Nginx配置与报错排查

1. 为什么都2024年了，网上还到处都是SSL/TLS的报错

1.1 先把概念掰扯清楚：SSL、TLS、TLS 1.3到底是什么关系

有一次帮人排查测试环境的问题，看到他的文档目录里写着"8.2.1 安全->SSL TLS 1.3"，那一瞬间我特别有共鸣。这种编号格式在企业的知识库、培训资料里到处都是，但绝大多数文档只写了概念，没写怎么落地。

先花30秒把概念理清楚。SSL（Secure Sockets Layer）最早是网景公司搞出来的，从SSL 1.0到SSL 3.0，后来IETF接手，改名成TLS（Transport Layer Security），所以TLS 1.0其实就是SSL 3.1，TLS 1.1是SSL 3.2，TLS 1.2是SSL 3.3。市面上说的"SSL证书"，严格来说该叫"TLS证书"，因为证书本身并没有绑定协议版本，一张证书既能配在TLS 1.2上，也能配在TLS 1.3上。理解了这层关系，你就能明白一个常见误区——不少人以为"换了TLS 1.3就得重新买证书"，其实完全不搭界。

TLS 1.3是RFC 8446定义的，2018年8月正式发布。距离TLS 1.2（RFC 5246，2008年）整整过去了10年。这10年间，协议本身经历了BEAST、CRIME、Heartbleed、POODLE等一堆安全事件，密码学界对"如何设计一个安全的握手协议"有了更成熟的认识。TLS 1.3不是小修小补，而是把整个握手机制推倒重来。从实际运维的角度看，它最直观的变化就两件事：握手变快了，加密变得更严格了。

1.2 TLS 1.2到1.3这十年，协议层到底改了什么

我见过太多人以为TLS 1.3只是"TLS 1.2的升级补丁"，改几个配置就能用。这里面的差异其实非常大，我挑几个对日常运维有直接影响的点讲。

第一个是握手往返次数。TLS 1.2完成一次完整握手需要2个RTT（Round Trip Time），TLS 1.3把非恢复场景压到1个RTT，恢复场景直接砍到0-RTT。别小看这一个往返，跨地域访问的场景下RTT动不动就几十上百毫秒，一次完整的HTTPS请求下来，握手延迟可能比数据传输本身还高。对移动端、API网关这种高频短连接的场景，这个优化是体感级别的。

第二个是密码套件体系的全面收缩。TLS 1.2时代，OpenSSL里数得出来的密码套件有37个，名字还特别长，什么ECDHE-RSA-AES128-GCM-SHA256、DHE-RSA-AES256-SHA，普通人看一眼就头大。TLS 1.3把这个生态砍到只剩5个，而且全部要求具备前向保密能力。RSA密钥交换被直接移除，CBC模式的密码套件全部淘汰，SHA-1相关的签名算法也不再作为协商项。以前那些"配置一个老密码套件给老客户端用"的操作，在TLS 1.3里连机会都没有。

第三个是握手消息的简化。TLS 1.3把之前需要分两轮才能协商完的参数（协议版本、密码套件、密钥交换参数、证书、签名）几乎全部塞进了第一条ClientHello里，服务端收到后直接根据客户端支持的能力生成回应。少了来回探询的过程，也就少了中间人做版本降级攻击的空间。

1.3 一个好消息和一个坏消息：兼容性与性能

先说好消息：TLS 1.3向下兼容TLS 1.2。规范里有非常明确的兼容机制，客户端发ClientHello的时候，会通过supported_versions扩展告诉服务端"我支持哪些版本"，服务端再从中挑一个双方都支持的。哪怕配置写的是"TLSv1.2 TLSv1.3"同时启用，老客户端连上来依然能走TLS 1.2，新客户端就自动协商到1.3。

坏消息是：TLS 1.3的密钥交换机制（(EC)DHE）要求服务端必须支持特定的椭圆曲线组。默认配置下，OpenSSL 1.1.1会选择X25519作为优先曲线，但有些老设备、老库不支持。如果服务端和客户端在曲线选择上谈不拢，你会发现TLS 1.2能连上，TLS 1.3死活握不了手，而且报错信息还很含糊，最常见的就是"ssl recv: 服务器断开连接"或者"unexpected eof while reading"。

所以我的建议是：除非你有十足的把握终端环境全部新，否则别一上来就只开TLS 1.3。稳妥的做法是TLS 1.2和TLS 1.3共存一段时间，观察业务日志里握手失败率、老客户端占比，再决定是否彻底关掉TLS 1.2。我在生产环境这么干过好几轮，基本两周的灰度数据就能看出问题了。

2. TLS 1.3的握手流程拆解：从两次握手变一次，密码套件从37个砍到5个

2.1 新握手的消息流程与性能收益

很多人理解TLS 1.3的握手，只知道"变快了"，但不知道快在哪一步。这里展开讲一下。

TLS 1.2的完整握手是这样的：

1. 客户端发ClientHello（告诉服务器支持的协议版本、密码套件、随机数）
2. 服务器回ServerHello（选定版本和密码套件）
3. 服务器发Certificate（自己的证书链）、ServerKeyExchange（密钥交换参数）、ServerHelloDone，客户端收到后还要再回一个ClientKeyExchange
4. 双方各自算出预备主密钥，交换ChangeCipherSpec，然后客户端发Finished，服务器也回Finished

注意第3步有个致命问题——服务器的密钥交换参数和证书，要等客户端的第一条Hello之后才发，而且发完还不能立刻开始传数据，因为客户端要再回一条消息确认自己拿到了。这就导致完整握手至少需要2个RTT。

TLS 1.3的握手则完全不同：

1. 客户端发ClientHello，里面直接带上：支持的版本列表、密码套件列表、key_share（客户端自己生成的密钥交换参数）、甚至扩展里的early_data（如果要走0-RTT的话）
2. 服务器回ServerHello，选定版本和密码套件，同时回自己的key_sha