4、主流密码套件详解：ECDHE-RSA-AES256-GCM-SHA384、TLS_AES_128_GCM_SHA256 等典型套件分析
聊到密码套件，很多刚入行的朋友容易把它当成一个黑盒。说白了，就是浏览器和服务器握手时，双方商量好的一套加密组合拳。我这些年排查过不少兼容性问题，发现很多坑都出在对套件细节的理解上。今天咱们就把几个最常用的套件拆开看看。
4.1 密码套件的命名规则
先看一个典型例子：ECDHE-RSA-AES256-GCM-SHA384。这个字符串其实分四段，每段代表一个算法组件。
| 组件位置 | 示例值 | 含义 |
|---|---|---|
| 密钥交换 | ECDHE | 椭圆曲线临时 Diffie-Hellman |
| 身份认证 | RSA | RSA 签名验证 |
| 对称加密 + 模式 | AES256-GCM | 256 位 AES，GCM 模式 |
| 消息认证码/哈希 | SHA384 | SHA-384 用于 PRF 和 HMAC |
嗯，这里要注意：TLS 1.3 的套件命名方式变了。比如 TLS_AES_128_GCM_SHA256，它不再显式写密钥交换和签名算法，因为 TLS 1.3 把这些协商过程独立出去了。我第一次看到这个格式时也愣了一下，后来才明白这是协议设计上的进步。
4.2 ECDHE-RSA-AES256-GCM-SHA384 深度拆解
这个套件在 TLS 1.2 时代非常流行，我自己的服务器也用了好几年。咱们逐个环节看。
4.2.1 密钥交换：ECDHE
ECDHE 的核心价值在于「前向安全性」。什么意思？就算攻击者以后拿到了服务器的私钥，也无法解密之前记录的会话流量。因为每次握手都会生成临时密钥对，用完就丢。
我在项目中遇到过这样一个案例：客户要求所有流量必须支持 PFS（Perfect Forward Secrecy），结果发现他们负载均衡器上配的证书是 1024 位 RSA，而 ECDHE 需要椭圆曲线参数。后来我们统一升级到 X9.62 标准的 P-256 曲线，问题才解决。
4.2.2 身份认证：RSA
ECDHE 只负责协商对称密钥，那怎么确认对方身份？靠 RSA 签名。服务器用私钥对 ECDHE 参数签名，客户端用证书里的公钥验签。
这里有个容易踩的坑：RSA 密钥长度。我曾经帮一个金融客户做渗透测试，发现他们还在用 2048 位 RSA 证书。虽然 2048 位目前还算安全，但 NIST 已经建议 2030 年前迁移到 3072 位。如果你现在部署新系统，直接上 3072 位或者干脆换 ECDSA 证书会更省心。
4.2.3 对称加密：AES256-GCM
AES256 提供 256 位密钥强度，GCM 模式同时提供加密和完整性校验。GCM 是 AEAD（Authenticated Encryption with Associated Data）的一种实现，加密的同时生成认证标签，不需要额外计算 HMAC。
我个人的习惯是：能上 GCM 就上 GCM。CBC 模式需要处理填充 oracle 攻击，而 GCM 天然免疫这类问题。不过要注意，GCM 对随机数（nonce）的生成质量要求很高，重复使用 nonce 会导致密钥泄露。
4.2.4 哈希算法：SHA384
SHA384 在这里有两个作用：一是作为 PRF（伪随机函数）派生密钥材料，二是用于 Finished 消息的校验。SHA384 是 SHA-2 家族的一员，输出 384 位摘要，比 SHA256 更安全，但计算量也更大。
4.3 TLS_AES_128_GCM_SHA256 深度拆解
这是 TLS 1.3 的标配套件之一。TLS 1.3 大幅简化了套件设计，只保留 5 个套件，而且全部使用 AEAD 加密。
4.3.1 为什么是 AES128 而不是 AES256？
很多人觉得 AES256 一定比 AES128 安全，其实在 GCM 模式下，AES128 已经足够。因为 GCM 的安全性上限受限于 2^32 次加密操作，超过这个量级 nonce 就可能碰撞。而 AES256 的密钥强度在这个场景下并没有带来额外收益。
我记得有一次和某云厂商的架构师讨论，他们内部做过压测：AES128-GCM 比 AES256-GCM 快大约 40%，在移动端差距更明显。所以 TLS 1.3 选择 AES128 作为默认套件，是安全与性能的平衡。
4.3.2 密钥交换和签名去哪了？
TLS 1.3 的套件名称里不包含密钥交换和签名算法，因为这些是在握手阶段通过 supported_groups 和 signature_algorithms 扩展单独协商的。这样设计的好处是：套件数量从几十个减少到几个，配置更简单，也避免了套件降级攻击。
核心区别：
- TLS 1.2 套件：固定了密钥交换、认证、加密、哈希全部组件
- TLS 1.3 套件：只指定对称加密和哈希，其余部分独立协商
4.4 典型套件对比
下面这张表是我自己整理的核心对比，方便你快速选型。
| 特性 | ECDHE-RSA-AES256-GCM-SHA384 | TLS_AES_128_GCM_SHA256 | ECDHE-ECDSA-AES128-GCM-SHA256 |
|---|---|---|---|
| TLS 版本 | 1.2 | 1.3 | 1.2 |
| 前向安全性 | 是 | 是 | 是 |
| 证书类型 | RSA | RSA 或 ECDSA | ECDSA |
| 加密强度 | 256 位 | 128 位 | 128 位 |
| 握手轮次 | 2-RTT | 1-RTT (0-RTT 可选) | 2-RTT |
| 性能 | 中等 | 高 | 高 |
| 推荐场景 | 合规要求高的金融系统 | 通用 Web 服务 | 移动端/物联网 |
4.5 套件选择的核心逻辑
说了这么多，到底怎么选？我总结三条原则：
- 能用 TLS 1.3 就用 TLS 1.3。握手快、配置简单、安全性高。目前主流浏览器和服务器都支持。
- 优先选 AEAD 套件。GCM 或 ChaCha20-Poly1305，别碰 CBC 模式。
- 证书类型匹配套件。如果你用 ECDSA 证书，就别配 RSA 套件，反之亦然。
4.6 知识体系结构图
下面这张 SVG 图展示了主流密码套件的核心组件和关系，方便你建立整体认知。
4.7 实战中的避坑指南
最后分享几个我踩过的坑，希望能帮你少走弯路。
- 套件顺序很重要：服务器配置的套件列表顺序决定了协商优先级。我曾经把
TLS_AES_256_GCM_SHA384放在TLS_AES_128_GCM_SHA256前面，结果导致部分老旧客户端握手失败。后来我按照「TLS 1.3 优先，TLS 1.2 降级」的原则重新排序，问题解决。 - 不要迷信 AES256：在 GCM 模式下，AES128 和 AES256 的安全边界其实差不多。AES256 的计算开销更大，对移动端不友好。除非有合规要求，否则 AES128 是更务实的选择。
- ECDSA 证书的兼容性：ECDSA 证书比 RSA 证书小，握手更快，但部分老旧系统（比如 Windows XP、Java 6）不支持。如果你需要兼容这些环境，建议保留 RSA 证书作为降级方案。