4. TLS握手协议概述与角色归纳总结
TLS握手协议是整个安全通道的「开场白」。它决定通信双方怎么认、用什么密码、如何生成密钥。很多工程师觉得握手很慢、很复杂，其实拆开了就那几步。我当年调试一个HTTPS性能问题时，花了两天才发现是对端不支持会话复用，白白多了一次完整握手。那次之后，我对握手里每个角色和消息序列就格外敏感了。
4.1 握手协议到底做了什么
说白了，握手协议要回答三个问题：
- 你是谁？——身份验证，通常靠证书链
- 我们用什么加密？——密码套件谈判
- 共享密钥怎么来？——密钥交换算法（如ECDHE）
这三个问题解决了，记录层就能拿对称密钥干活了。握手本身不加密应用数据，但它决定后续所有加密参数。
重点：握手协议属于TLS的「控制面」，记录协议是「数据面」。握手的成败直接影响后续所有数据传输的安全性。
4.2 握手中的主要角色
别看握手消息很多，角色其实就这几个：
| 角色 | 职责 | 出现阶段 |
|---|---|---|
| 客户端 | 发起握手、提供密码套件偏好、生成密钥对（可选） | ClientHello、KeyExchange、Finished |
| 服务端 | 选择密码套件、提供证书、完成密钥协商 | ServerHello、Certificate、KeyExchange |
| CA（证书颁发机构） | 签署服务端证书（不参与在线握手） | 离线，但证书链验证时隐含存在 |
| TLS记录层 | 封装握手消息，提供分片、压缩（已废弃）、加密 | 整个握手过程都在记录层之上 |
我习惯把CA看成「人肉背书人」——它不在现场，但它签名过的证书决定了客户端信不信服务端。曾经有个客户为了省CA费用，自签名证书直接拖了两个月项目验收。
4.3 宏观流程：一次完整的TLS握手
以TLS 1.2最典型的完整握手为例，消息顺序大致如下：
- ClientHello：客户端发版本、随机数、密码套件列表
- ServerHello：服务端选版本、套件、发自己的随机数
- Certificate：服务端发证书链（公钥在内）
- ServerKeyExchange：如果使用DHE/ECDHE，发临时公钥和签名
- ServerHelloDone：服务端说自己发完了
- ClientKeyExchange：客户端发公钥或预主密钥（RSA）
- ChangeCipherSpec：通知对方后续用协商的密钥加密
- Finished：验证整个握手消息的完整性
TLS 1.3把握手压缩到1个RTT（完整握手），但角色基本不变，只是消息合并了。
4.4 角色职责归纳
把角色和关键属性整理成一张表，方便你以后排查问题时对照：
| 角色 | 必备动作 | 可选动作 | 常见坑 |
|---|---|---|---|
| 客户端 | 提供密码套件偏好、生成随机数 | 发送SNI、ALPN扩展 | 不支持TLS 1.3却声明了1.3导致协商失败 |
| 服务端 | 选择套件、发送证书 | 请求客户端证书（mTLS） | 证书链不完整、过期 |
| CA | 签署证书（离线） | 吊销检查（OCSP/CRL） | 中间证书缺失导致验证失败 |
| TLS记录层 | 封装、分片、加密 | 记录填充、压缩（废弃） | 记录大小超过MTU导致分片丢包 |
曾经我吃过一次亏：服务端发了完整的证书链，但中间证书过期了一天，客户端直接拒绝连接。那天正好是周日，我紧急联系运维替换证书。从那以后我养成了证书过期监控——提前30天告警，绝不等到最后一刻。
4.5 误解与避坑
- 「握手是双向加密」？不，握手过程中只有Finished消息是加密的，其余ClientHello、Certificate等都是明文或部分保护。
- 「证书里直接有加密密钥」？证书只包含公钥，签名用于验证身份。真正的会话密钥是通过密钥交换算法独立生成的。
- 「ChangeCipherSpec是握手消息」？严格来说它是记录层的一个协议（ContentType 20），不属于握手协议本身，但标记了加密状态的切换。
4.6 知识框架：一张图看懂角色与流程
上图展示了TLS 1.2典型完整握手的核心消息流动。TLS 1.3将①②合并为一次飞过（1-RTT），但角色依旧是客户端和服务端两方，CA仍然只提供离线背书。理解这个基础框架后，分析任何版本的握手都能快速定位问题阶段。
4.7 总结
握手协议的核心就是：身份验证 + 参数协商 + 密钥生成。角色只有三个半（客户端、服务端、CA、记录层），但消息交互必须严格按序。我曾经在生产环境遇到过由于中间件擅自修改ClientHello顺序导致握手失败——当时查包查了一下午，最后发现是反向代理自作聪明重组了Hello消息。从那以后，我对握手的消息顺序和角色职责就有了「肌肉记忆」。你早晚也会遇到类似的坑，提前理清角色，故障定位至少快一倍。