TLS 握手过程详解：深入分析TLS 1.2和1.3握手流程

要说TLS SDK里最核心、也最容易出问题的部分，那就是握手过程了。说白了，握手就是客户端和服务器在正式传输数据前，先互相打个招呼、亮个身份、再悄悄约定一个只有他俩知道的“暗号”。我刚开始做SDK接入时，总觉得握手就是几个来回的事，结果线上经常出现连接超时、证书校验失败，查了半天才发现是握手细节没吃透。

这一章，咱们就从头捋一遍TLS 1.2和1.3的握手流程。理解了这些，你写SDK时就能知道在哪埋日志、在哪做超时、在哪拦截错误了。

从“你好”到“暗号”——TLS握手概述

你想象一下这个场景：你去一家高级会所，保安先问你是谁（ClientHello），你亮出身份证（证书），保安核实后给你一个手环（会话凭证），然后你俩约定好以后用对讲机沟通（对称加密）。TLS握手就是干了这么一件事。

握手过程有几个关键产物：

• 会话密钥：后续数据加密用的对称密钥
• 对端身份：通过数字证书验证
• 算法套件：加密、Hash、密钥交换的方式组合
• 会话ID或Ticket：用于会话复用，减少握手次数

在我维护的一个支付SDK里，曾经因为握手阶段默认超时设得太短，导致用户在弱网环境下反复握手失败。后来我改成动态超时策略，结合TLS 1.3的特性，才解决了这个问题。

TLS 1.2握手流程

TLS 1.2是现网中存量最大的版本。它的握手过程相对较重，需要两个RTT（网络往返）才能完成。

TLS 1.2 完整握手步骤

1. ClientHello：客户端发送支持的TLS版本、密码套件列表、随机数（用于后续密钥生成）
2. ServerHello + 证书：服务器选择密码套件，发送自己的数字证书（含公钥），以及服务器随机数
3. ClientKeyExchange：客户端用服务器公钥加密一个“预主密钥”，发送给服务器。此时双方都拿到预主密钥，可以独立计算主密钥和会话密钥
4. ChangeCipherSpec：双方分别告知对方，后续通信开始加密
5. Finished：发送握手消息的哈希，验证完整性

TLS 1.3握手流程

TLS 1.3是2018年发布的版本，核心改进就是“快”。它把握手从两个RTT减少到一个RTT，甚至0-RTT可以复用之前的会话。

为什么能这么快？因为TLS 1.3在ClientHello里就直接带上了密钥协商参数（比如密码学上的DH公钥），服务器收到后就能立即算出密钥，不用再等一个来回。

TLS 1.3 握手步骤

1. ClientHello：包含支持的密码套件、客户端密钥共享（DH公钥）、可能还带之前保存的会话Ticket
2. ServerHello：服务器选择密码套件，返回自己的密钥共享参数，同时发送证书和签名
3. 服务器完成：服务器开始发送加密的应用数据（握手还没完全结束，但数据已可以开始传输）
4. 客户端完成：客户端验证证书，计算密钥，然后发送Finished。之后双方正常加密通信

TLS 1.2 vs TLS 1.3: 核心差异

对比维度	TLS 1.2	TLS 1.3
握手RTT	2个RTT	1个RTT（0-RTT可选）
密码套件	支持多种，如RSA、DH、ECDH	仅支持AEAD + 前向安全性（如AES-GCM、ChaCha20-Poly1305）
密钥交换	RSA可做密钥传输	强制使用DH/ECDH
证书验证	在握手第2步单独发送	合并到ServerHello后的加密扩展中
会话恢复	Session ID或Session Ticket	PSK + Ticket（支持0-RTT）
降级保护	无内置	含降级检测机制（防止中间人降级攻击）

你想想看，TLS 1.3把两步并作一步，不仅减少了延迟，还砍掉了很多不安全的老旧算法。我在一个实时音视频SDK项目里，从TLS 1.2升级到1.3后，连接建立时间从平均180ms降到了90ms，体验提升非常明显。

密钥交换的核心：前向安全性

这也是个常被忽略的点。什么是前向安全性？就是即使服务器私钥泄露了，之前的会话也无法被破解。因为密钥是临时生成的DH参数，用完就丢。

TLS 1.3强制使用ECDHE（椭圆曲线Diffie-Hellman Ephemeral），每个会话的DH密钥都是临时生成的，服务器不会持久保存。而TLS 1.2里如果使用RSA密钥传输，一旦私钥泄露，所有历史会话都能被解密。我前两年审计一个遗留系统时，发现还在用TLS 1.2 + RSA密钥交换，立刻建议升级了。

证书验证与信任链

握手过程中，证书验证是个重头戏。很多SDK都在这里翻车。验证步骤包括：

• 证书是否在有效期内（notBefore / notAfter）
• 证书是否被吊销（CRL或OCSP）
• 证书链是否完整（端证书→中间CA→根CA）
• 域名是否匹配（Common Name 或 Subject Alternative Name）
• 签名是否有效（用父CA的公钥验证子证书的签名）

我踩过的另一种坑是：某些自签名证书在测试环境中可用，但正式环境更换了CA签发的证书后，SDK里的证书固定（Certificate Pinning）没有更新，导致大量用户连接失败。所以，如果你在SDK里做了证书固定，一定要设计好版本管理和热更新机制。

总结一下这章的核心

TLS握手过程并不复杂，但细节决定成败。尤其在做SDK时，你要在代码里处理好超时、降级、证书校验、密码套件优先级这些事。

拿我自己的SDK代码来说，握手模块的代码量其实不大，但错误处理占了将近一半。比如网络超时、证书过期、握手失败、降级重试……每一个分支都要走到。