3. 密码套件命名规范解析
在 TLS 握手过程中，客户端与服务器最终要协商出一套“密码套件”（Cipher Suite）。它并不是单一算法，而是一组算法的组合约定，规定了握手阶段如何认证、如何协商密钥，以及记录层如何加密和校验数据。理解密码套件的命名结构，是读懂抓包结果、排查握手失败、编写安全配置的前提。
以最常见的 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 为例，这个字符串由下划线分隔成若干字段，整体遵循 IANA 定义的命名规则。它的结构可以概括为：
TLS_<密钥交换>_<认证>_WITH_<加密算法>_<密钥长度>_<工作模式>_<PRF哈希>下面逐段拆解这个命名。
一、协议前缀与握手算法部分
开头的 TLS 表示该套件属于 TLS 协议族。在 TLS 1.3 之前，套件名以 TLS_ 开头；更早的 SSL 套件则以 SSL_ 开头，如今基本被淘汰。紧随其后的 ECDHE_RSA 描述的是握手阶段的算法组合，用下划线连接两个角色：
- ECDHE：密钥交换算法，即椭圆曲线 Diffie-Hellman 临时密钥交换（Ephemeral）。它用于在握手时协商出共享的预主密钥，具备前向保密性（Forward Secrecy）——即使服务器长期私钥泄露，也无法解密此前抓取的会话流量。
- RSA：认证算法，即服务器用 RSA 证书和私钥对握手消息签名，向客户端证明自己的身份。注意这里的 RSA 只负责“签名认证”，不负责密钥交换，这是与旧式
TLS_RSA_WITH_...套件的关键区别。
中间的 WITH 是一个固定连接词，用于分隔“握手算法”和“记录层算法”两部分，本身没有算法含义。
二、记录层算法部分
WITH 之后是 AES_128_GCM_SHA256，描述应用数据如何被保护：
- AES：对称加密算法，负责对记录层数据加密。
- 128：密钥长度，单位是比特。AES 支持 128、192、256 三种长度，128 位在性能与安全之间较为均衡。
- GCM：工作模式，即 Galois/Counter Mode。它是一种 AEAD（带关联数据的认证加密）模式，在加密的同时完成完整性校验，因此套件名中不再单独出现 HMAC 或 SHA 校验字段。
- SHA256：在 TLS 1.2 中，它表示 PRF（伪随机函数）使用的哈希算法，用于密钥派生；在 TLS 1.3 中，它同时用于 HKDF 密钥派生和握手消息的 Transcript Hash。
三、命名结构可视化
下图把该套件名的各字段与它在 TLS 握手中的职责对应起来，帮助建立“名字—功能”的映射关系。
四、IANA 命名规则与常见变体
IANA 在 TLS Cipher Suite Registry 中为每个套件分配一个两字节的数值标识，例如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 对应 0xC02F。抓包工具（如 Wireshark）通常同时显示名称和十六进制值，两者一一对应。命名规则本身是“结构化拼接”，因此同一族套件会呈现规律性变体：
| 套件名 | 密钥交换 | 认证 | 加密/模式 | 哈希 | 特点 |
|---|---|---|---|---|---|
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDHE | RSA | AES-128-GCM | SHA256 | 前向保密，AEAD |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ECDHE | ECDSA | AES-128-GCM | SHA256 | 认证改用 ECC 证书 |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ECDHE | RSA | AES-256-GCM | SHA384 | 更长密钥与哈希 |
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ECDHE | RSA | ChaCha20-Poly1305 | SHA256 | 移动端性能友好 |
| TLS_RSA_WITH_AES_128_CBC_SHA | RSA | RSA | AES-128-CBC | SHA1 | 无前向保密，已不推荐 |
从表中可以看出几个规律：认证算法由服务器证书类型决定——RSA 证书配 RSA，ECC 证书配 ECDSA；加密模式从 CBC 演进到 GCM、ChaCha20-Poly1305，后者属于 AEAD，安全性更好；哈希从 SHA1 升级到 SHA256/SHA384。旧式 TLS_RSA_WITH_... 中 RSA 同时承担密钥交换和认证，不具备前向保密，现代配置应优先选择 ECDHE 系列。
五、TLS 1.3 的命名简化
TLS 1.3 对套件命名做了大幅精简。由于密钥交换统一由扩展协商、认证与握手分离，套件名只保留记录层算法，例如 TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256。也就是说，TLS 1.3 的套件名不再包含 ECDHE、RSA 等握手字段，看到这种“短名字”即可判断是 TLS 1.3 套件。
ssl_ciphers 只作用于 TLS 1.2 及以下，TLS 1.3 套件需用 ssl_conf_command Ciphersuites 单独指定，否则会出现“配置了却未生效”的情况。六、实际判读示例
假设用 OpenSSL 连接一台服务器并观察协商结果：
openssl s_client -connect example.com:443 -tls1_2
...
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
...输出中的 ECDHE-RSA-AES128-GCM-SHA256 是 OpenSSL 的简写形式，与 IANA 名 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 指同一套件。判读时依次确认：密钥交换是 ECDHE（有前向保密）、认证是 RSA、加密是 AES-128-GCM（AEAD）、哈希是 SHA256。若看到 AES128-SHA 这类不含 GCM 且哈希为 SHA1 的结果，说明协商到了较弱的旧套件，应检查服务端配置并禁用。
掌握命名结构后，无论是阅读抓包、审查服务器配置，还是编写安全基线，都能从套件名本身快速判断其安全属性，而不必逐个查阅文档。