2. TLS握手协议：握手流程详解，密钥交换与认证过程

讲TLS，绕不开握手协议。这玩意儿是整个TLS安全体系的奠基仪式。说白了，客户端和服务端在正式传输数据之前，得先互相打个招呼、亮明身份、商量好怎么加密——这个过程就叫握手。

我个人习惯把握手分成三个阶段来看：Hello阶段、密钥交换阶段、握手完成阶段。咱们一个一个拆。

2.1 第一回合：ClientHello与ServerHello

1. 客户端先开口：ClientHello
2. 服务端回应：ServerHello，附带证书链和密钥交换参数

客户端发起的ClientHello里包含什么？我列个大概：

• 客户端支持的TLS版本列表（比如TLS 1.2、1.3）
• 客户端支持的密码套件列表（一个长长的候选清单）
• 一个随机数client_random（32字节，用于后续生成主密钥）
• Session ID（用于会话复用，但TLS 1.3基本不用这套了）

服务端收到后，会挑一个双方都支持的版本和套件。别以为这个选择是随便来的，我在项目中遇到过因为服务端配置了过时套件导致握手失败——客户端只支持更安全的套件，服务端却硬要降级使用RC4。结果客户端直接断开。

// 典型ClientHello报文结构（示意）
// Protobuf风格描述
message ClientHello {
    uint16 version = 1;           // 最高支持的TLS版本
    bytes random = 2;              // 32字节随机数
    bytes session_id = 3;          // 可选会话ID
    CipherSuite cipher_suites = 4; // 密码套件列表
    Extension extensions = 5;      // 扩展字段
}

2.2 第二回合：密钥交换，核心难点

Hello阶段之后，客户端和服务端已经互相知道了对方的存在。接下来就是最关键的环节——协商出一个只有双方知道的对称密钥。

这里分两条路：RSA密钥交换（老版本，已不推荐）和Diffie-Hellman密钥交换（现代方案）。

我个人的建议：永远别用RSA密钥交换。你想想看，如果攻击者现在录下你今天的TLS会话流量，等几年后破解了你的服务端私钥，那么今天的会话就可以被解密。这就是没有前向安全性的代价。而ECDHE交换的临时密钥是一次性的，私钥泄露只影响当前会话，不影响历史。

2.3 第三回合：证书验证与Finished确认

密钥交换过程中，服务端会把它的数字证书发过来。客户端收到后要做几件事：

1. 验证证书链是否完整（根CA→中间CA→服务端证书）
2. 检查证书有效期
3. 验证证书签名（用CA公钥解签名）
4. 确认域名是否匹配

证书验证通过后，客户端会生成预主密钥pre_master_secret（48字节），然后通过DH协商出的共享密钥或者RSA加密的方式传给服务端。双方都拿到后，各自用client_random、server_random和pre_master_secret计算出主密钥。

嗯，这里要注意一个细节：Change Cipher Spec。在TLS 1.2中，每次密码套件切换时，双方要发一个空消息来通知对方“我准备切换加密方式了”。TLS 1.3把这个去掉了，因为1.3的握手是全程加密的，不需要再显式通知。

2.4 常见密码套件及其选择

密码套件决定了握手过程中用什么算法来做签名、密钥交换和对称加密。我整理了几个常见的：

第三行是TLS 1.3的套件写法，简化了很多。因为1.3把密钥交换算法从套件名里剥离了，统一用DH，所以套件只描述对称加密和哈希算法。

我个人偏好：生产环境优先用TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384（TLS 1.2）或TLS_AES_256_GCM_SHA384（TLS 1.3）。256位密钥在当前安全强度下足够，GCM模式又提供认证加密，性能也不错。

2.5 握手流程全景图

整个握手流程其实挺清晰的。我画了个流程图，把TLS 1.2和1.3的差异也标出来了：

2.6 握手协议的核心价值

说到这，你可能会问：握手协议到底保护了什么？

• 身份真实性：服务端证书验证确保了你不连到一个山寨服务器
• 密钥安全性：DH交换过程即使被中间人监听，也无法推导出最终密钥
• 完整性保护：Finished消息里的HMAC验证了整个握手过程没有被篡改

说白了，没有握手协议，后面的加密数据传输就是空中楼阁。我在生产环境见过因为握手阶段证书链不完整导致的连接中断，客户端报certificate verify failed。排查到最后发现是中间CA证书没安装。