2、TLS握手协议：交互流程与关键参数
说起TLS握手，很多人第一反应就是"慢"。确实，一次握手要多出几个RTT，但你要想清楚——没有握手，后面所有加密通信都建立在沙滩上。我手头维护过一个支付网关，每天几百万笔交易，握手哪怕多花1毫秒，对整个系统都是压力。但即便如此，我从不敢在握手参数上偷懒。说白了，握手是TLS的根基，根基不稳，上面再漂亮的优化都是白搭。
2.1 握手到底干了什么事？
一次TLS握手，核心就三件事：
- 身份验证——确保对面是你想通信的那个人，不是中间人。
- 密钥协商——双方安全地算出一个只有你俩知道的会话密钥。
- 参数协商——商量好用什么版本、什么加密算法、什么哈希算法。
我刚开始做安全这块时，觉得"身份验证不就是看看证书吗"，后来在项目里遇到一次攻击模拟，才发现证书链验证稍微松一点，中间人就能钻进来。从那时起，我对握手协议的每一个参数都格外小心。
2.2 TLS 1.2 握手——一步步拆给你看
下面这张图是我自己梳理的TLS 1.2完整握手流程。左边是客户端，右边是服务器。箭头方向表示谁先发起。你看完这张图，再往下读细节，思路会清楚很多。
好，图看完了，我来拆开细说。
第一步：ClientHello。客户端发一个明文消息，告诉服务器：我支持哪些TLS版本、哪些密码套件、以及一个客户端随机数。说白了，就是"我来了，这些是我会的，你挑一个吧"。
第二步：ServerHello + 证书。服务器从客户端列表里选一套参数，发回自己的证书。证书里包含公钥。客户端拿到证书后要验证——是不是可信CA签发、域名对不对、有没有过期。我在项目中遇到过证书链不完整的情况，服务器只发了叶子证书，没发中间CA，导致Android客户端死活连不上。排查了半天，最后发现是服务器配置漏了中间证书。
第三步：ClientKeyExchange。客户端用服务器的公钥加密一个预主密钥（Pre-Master Secret）发过去。双方再用客户端随机数、服务器随机数、预主密钥一起算出会话密钥。这一步是握手的安全核心。
第四步：ChangeCipherSpec + Finished（客户端）。客户端告诉服务器："我要切到加密模式了"。然后发一个Finished消息，里面是之前所有握手消息的哈希值，用协商好的密钥加密。服务器解密验证，确保握手过程没被篡改。
第五步：ChangeCipherSpec + Finished（服务器）。服务器也做同样的事，切到加密模式，发Finished让客户端验证。
第六步：加密通信。双方拿着协商好的会话密钥和参数，正式开始加密传输应用数据。这一步用的就是对称加密了，速度快得多。
2.3 关键参数一览
握手过程中，有几个参数直接影响安全性和兼容性。我整理成一个表格，方便你对照检查。
| 参数 | 出现在哪个消息 | 说明 |
|---|---|---|
| 协议版本 | ClientHello / ServerHello | 双方协商最终使用的TLS版本（如1.2、1.3）。低版本兼容但不安全。 |
| 密码套件 | ClientHello / ServerHello | 决定密钥交换、认证、加密、哈希的算法组合。比如 ECDHE-RSA-AES256-GCM-SHA384。 |
| 随机数 | ClientHello / ServerHello | 客户端和服务器各生成一个32字节随机数，参与会话密钥推导，防止重放攻击。 |
| 会话ID | ClientHello / ServerHello | 用于会话复用，避免每次都要完整握手。老版本用的多，TLS 1.3改用PSK。 |
| 证书 | Certificate | 携带服务器公钥和身份信息。必须由可信CA签发，且域名匹配。 |
| 签名算法 | CertificateVerify / ServerKeyExchange | 用于验证数据来源的完整性。常见的有 RSA、ECDSA。 |
| 密钥交换参数 | ClientKeyExchange / ServerKeyExchange | 包含 DH 或 ECDH 的公开参数，用于计算预主密钥。 |
2.4 握手中的常见坑
握手虽然流程固定，但坑不少。下面几个我基本都踩过。
- 证书链不完整。我曾经排查过一个生产故障：客户端报"证书验证失败"，但浏览器访问又是绿的。最后发现服务器只配了叶子证书，没配中间CA。老旧客户端不自动下载中间证书，直接拒绝连接。解法：在服务器上配全整条证书链。
- 密码套件不匹配。有些老旧客户端只支持RSA + CBC模式，但服务器只配了ECDHE。两边谈不拢，握手失败。我建议你在服务器上保留一套"安全但兼容"的降级套件，保证最低能连上。
- 时钟不同步。证书有有效期，客户端如果系统时间跑到证书有效期之外，握手直接失败。IoT设备特别容易出这个问题。我曾经在嵌入式项目里遇到设备时间漂了两年，所有TLS连接都挂了。解决方案：用NTP强制校时。
- 握手超时太短。微服务架构下，服务之间调用链路长，如果握手超时设成2秒，遇到网络抖动就疯狂断连。我在一个K8s集群里踩过这个坑，最后把超时从3秒调到8秒，问题解决。
--insecure 直接写进生产脚本——这种操作在合规审计里是要吃红牌的。
2.5 几个优化思路
握手确实有开销，但优化空间也不小。我分享两个常用的手段。
会话复用。第一次完整握手后，服务端生成一个会话ID或会话票证（Session Ticket），客户端存下来。下次连接时直接复用之前的会话参数，省掉证书交换和密钥协商。我在一个日活千万的API网关项目里开了会话复用，握手比例从100%降到了不到20%，CPU负载直接掉了15%。
调整密码套件优先级。把性能好的套件放前面，可以减少握手阶段的协商时间。比如把 ECDHE + AES-GCM 放在 RSA + CBC 前面。服务器收到 ClientHello 后，从上往下匹配，第一个能用的就是选中结果。你想想看，如果不排序，让服务器去匹配一个性能差的套件，每次握手都多花几毫秒，累积起来很可观。