TLS 协议概述与密码套件基础

说起 TLS，很多人第一反应就是「那把锁」。但说真的，要是只把它当成一个锁，那你在排查线上问题时八成要翻车。TLS 的全称是 Transport Layer Security，传输层安全协议。它工作在 TCP 之上，为应用层提供加密、身份认证和完整性保护。咱们平时用的 HTTPS、SMTPS、FTPS，底层走的全是 TLS。

我刚入行那会儿，以为 TLS 就是 SSL 换了个名字。后来踩过坑才明白——SSL 3.0 之后直接跳到了 TLS 1.0，而且两者不能直接互操作。现在 SSL 3.0 已经被彻底废弃了，你想想看，还有多少老旧设备在用它？当年我在一个银行项目中，就发现他们的负载均衡器还支持 SSL 3.0，吓得我赶紧建议他们关掉。

TLS 发展简史

版本	发布年份	状态	主要变化
SSL 3.0	1996	已废弃	POODLE 漏洞，不再使用
TLS 1.0	1999	已废弃	基于 SSL 3.0，但不同
TLS 1.1	2006	已废弃	增加 CBC 防御
TLS 1.2	2008	主流	AEAD 支持，GCM 引入
TLS 1.3	2018	推荐	握手缩减，移除不安全套件

我个人的习惯是，只要业务允许，直接上 TLS 1.3。握手从 2-RTT 降到 1-RTT，性能提升很明显。但有些老系统还在死守 1.2，你也别着急，至少把那些古老的密码套件给禁了。

密码套件到底是什么？

密码套件（Cipher Suite）是 TLS 握手中协商的一套算法组合。它决定了用什么方式交换密钥、用什么算法验证身份、用什么密码加密数据、以及用什么方式校验完整性。说白了，就是四个核心要素：

• 密钥交换算法 —— 比如 ECDHE、DHE、RSA
• 身份认证算法 —— 比如 RSA、ECDSA
• 对称加密算法 —— 比如 AES_256_GCM、ChaCha20_Poly1305
• 消息认证码（MAC） —— 比如 SHA384、Poly1305（AEAD 自带）

举个例子，常见的套件 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 拆开看：

• ECDHE —— 椭圆曲线迪菲-赫尔曼（临时密钥交换）
• RSA —— 数字签名认证（服务端证书签名）
• AES_256_GCM —— 对称加密，256位密钥，GCM模式（同时提供加密和完整性）
• SHA384 —— 伪随机函数（PRF）用的哈希

嗯，这里要注意：AEAD 模式（如 GCM、ChaCha20-Poly1305）本身就结合了加密和 MAC，所以不会出现单独的 HMAC。而老旧的 CBC 模式则需要独立的 HMAC（比如 SHA1）。

密码套件命名规范

TLS 套件的命名是有格式的，虽然有点长，但读懂了就很容易判断安全性。

TLS_[密钥交换]_[认证]_WITH_[加密]_[哈希/PRF]

我建议在配置 Nginx 或 OpenSSL 时，直接写全称，别用 OpenSSL 那种简写（比如 ECDHE-RSA-AES256-GCM-SHA384），因为不同版本解析可能有出入。有一次我就因为混用了 OpenSSL 简写和 IANA 标准写法，结果某云厂商的 CDN 识别报错，排查了整整半天。

密码套件选择的原则

1. 优先使用 AEAD 套件（GCM、ChaCha20-Poly1305）—— 避免 CBC 相关的 padding oracle 攻击。
2. 避免使用 RSA 密钥交换（不具备前向安全性），用 ECDHE 或 DHE 替代。
3. 禁用弱哈希（SHA1、MD5），使用 SHA256 或以上。
4. 密钥长度满足当前安全要求：对称密钥 ≥ 128 bit，RSA ≥ 2048 bit，ECC ≥ 256 bit。

我曾经帮一个客户做等保测评，发现他们还在用 TLS_RSA_WITH_AES_128_CBC_SHA。这种套件既不支持前向安全，又用 CBC 模式，简直就是定时炸弹。我当时的建议是立刻更新策略，只保留 ECDHE 开头的 AEAD 套件。

密码套件结构图

下面这张 SVG 图展示了密码套件由四个核心算法模块组成，以及每个模块的典型代表。你在实际巡检变更日志时，重点关注的就是这些模块的增减。

变更日志里看什么？

我们这门课核心就是巡检密码套件的变更日志。日志里最常见的是添加或删除某个套件、调整套件优先级、或者整个密码策略的替换。你拿到一份日志，最先问自己三个问题：

• 这次变更删除了弱套件吗？还是反而加进去了？
• 优先级顺序是否有风险？比如把 CBC 套件放在 AEAD 之前。
• 变更是否与基线策略一致？有没有遗漏的残留套件？

小结