4. TLS/SSL协议深度解析：TLS握手协议、TLS记录协议、TLS 1.2 vs 1.3、密码套件选择、双向认证（mTLS）

聊到边缘网关的安全，TLS 是绕不开的基础设施。很多人觉得 TLS 就是“加个证书，走 HTTPS”，其实没那么简单。我在做边缘项目时，就遇到过因为 TLS 版本不匹配，导致网关跟云端握手失败，现场工程师排查了整整两天。

说白了，TLS 是两个协议的组合：握手协议负责“打招呼、验身份、定密钥”，记录协议负责“用商定好的密钥加密传输”。今天咱们就把这两层掰开揉碎讲清楚。

4.1 TLS 握手协议：从“你是谁”到“用啥加密”

握手协议是 TLS 最复杂的部分。我习惯把它拆成四个阶段来理解：

1. 阶段一：ClientHello + ServerHello —— 双方打招呼，交换支持的版本、密码套件、随机数。
2. 阶段二：证书交换 + 密钥协商 —— 服务器发证书，客户端验证；然后通过 DH 或 RSA 协商出预主密钥。
3. 阶段三：ChangeCipherSpec —— 双方通知对方“我要开始用商定好的密钥加密了”。
4. 阶段四：Finished —— 双方发送加密后的握手摘要，确认握手没有被篡改。

嗯，这里要注意：ChangeCipherSpec 本身不是握手协议的一部分，它是单独的一个记录协议类型。但实际流程中它卡在中间，很多人容易搞混。

4.2 TLS 记录协议：真正的“搬运工”

握手完成后，记录协议就开始干活了。它的工作流程很简单：

• 把应用层数据切成 16KB 的片段
• 可选压缩（现在基本不用了）
• 加上 MAC（消息认证码）
• 用对称密钥加密
• 加上记录头（内容类型、版本、长度）

你想想看，记录协议其实不关心数据是什么，它只负责“加密 + 完整性校验”。我在调试一个网关时，发现数据偶尔被截断，最后定位到是记录协议的分片逻辑跟底层 TCP 缓冲区没配合好。

4.3 TLS 1.2 vs 1.3：到底差在哪？

这是面试常考题，也是实际选型的关键。我直接列个表对比：

我个人习惯是：新项目直接上 TLS 1.3。少一次握手，在边缘网络里能省 100-200 毫秒，这对电池供电的设备很关键。

4.4 密码套件选择：别用默认配置

密码套件长这样：TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。拆开看就是：

• 密钥交换： ECDHE（椭圆曲线 Diffie-Hellman 临时密钥）
• 身份认证： RSA（用 RSA 签名验证证书）
• 对称加密： AES-128-GCM（带 Galois 认证模式的 AES）
• 哈希： SHA-256（用于 PRF 和 Finished 消息）

在边缘网关上，我推荐以下套件（按优先级排序）：

1. TLS_AES_128_GCM_SHA256（TLS 1.3 标配）
2. TLS_CHACHA20_POLY1305_SHA256（没有 AES 硬件加速时首选）
3. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256（TLS 1.2 兼容）

为什么不用 AES-256？在边缘设备上，AES-256 比 AES-128 慢 30-40%，但安全增益微乎其微。128 位密钥在可预见的未来足够安全。

4.5 双向认证（mTLS）：不只是“服务器验客户端”

常规 TLS 只验证服务器证书。mTLS 要求客户端也出示证书，服务器同样验证。这在边缘网关场景里非常常见——网关要确认连接的设备是合法的，而不是被冒充的。

mTLS 的握手流程比单向多两步：

1. 服务器发完自己的证书后，发送 CertificateRequest 消息
2. 客户端收到后，发送自己的 Certificate + CertificateVerify（用客户端私钥签名握手摘要）

我在部署 mTLS 时踩过一个坑：客户端证书的 CN（Common Name）跟设备 ID 绑定。一开始我用随机字符串做 CN，结果审计时发现无法追溯设备。后来改成“设备类型-序列号”的格式，运维才满意。

ssl_client_certificate /etc/nginx/ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;

4.6 本章知识体系总览

下面这张图把 TLS 的核心逻辑串起来了。我画的时候特意把握手和记录协议分开，方便你对照理解。