对称加密算法：TLS手中的四把钥匙
要说 TLS 握完手之后怎么保护数据，核心就靠对称加密。原因很简单，非对称加密太慢了，没法扛住海量应用数据。我刚开始做协议分析时，光看包就发现握手阶段一过，流量就变得“密不透风”——那就是对称加密进场了。
这章我就把四个主角给你捋一遍：AES、DES、3DES、RC4。它们各有过辉煌，也有致命伤。TLS 最终挑了谁，为什么？看完你就清楚了。
4.1 为什么非对称加密不能一直用
你想想看，RSA 2048 签名一次，可能比你传输 1MB 数据还耗时。如果每条应用数据都用私钥加密，用户体验和服务器负载都扛不住。所以 TLS 的策略很简单：
- 握手阶段：非对称 + 证书，解决身份和密钥分发
- 传输阶段：对称加密，保证效率和机密性
对称加密密钥通常只有 128 到 256 位。双方用同一个密钥，加密解密都很快。这密钥从哪来？还记得 ECDHE 密钥交换吗？那个临时会话密钥就成了对称加密的种子。
核心认知：TLS 的安全性之所以均衡，就是因为用非对称加密“护送”对称密钥，再用对称加密“护航”应用数据。
4.2 四个算法的特点与对比
4.2.1 DES — 老得快跑不动的元老
DES 是 1970 年代 IBM 搞出来的，密钥长度 56 位。在当年算不错了，但放到今天，专用 FPGA 几小时就能暴力破解。我在一个旧客户系统里见过还在用 DES 的遗留接口 — 安全组直接标了“高危”。
- 分组大小：64 位
- 密钥长度：56 位（有效）
- TLS 状态：2011 年后所有主流库默认禁用
4.2.2 3DES — 三个 DES 堆出来的补丁
3DES 就是把 DES 做三次。看起来安全一些，但效率极低。密钥长度从 56 位扩到 112 或 168 位，但分组仍然是 64 位。这让它在处理大数据时容易暴露模式。我记得 TLS 1.2 早期还有套件用 3DES，后来 OpenSSL 社区直接把它移出了默认构建。
| 算法 | 密钥长度 | 分组大小 | 软件效率 | TLS 支持 |
|---|---|---|---|---|
| DES | 56 位 | 64 位 | 慢（已淘汰） | TLS 1.0/1.1 已禁用 |
| 3DES | 112 或 168 位 | 64 位 | 非常慢 | TLS 1.2 已弃用 |
| RC4 | 40~2048 位 | 流式（无分组） | 极快（但偏斜） | 全版本禁用 |
| AES | 128 / 192 / 256 位 | 128 位 | 硬件加速良好 | TLS 1.2 / 1.3 主力 |
避坑指南：我曾经帮客户迁移旧系统，发现 F5 负载均衡器上还挂着 3DES 的加密套件。一查日志，很多 TLS 握手还在走那个老路。直接在配置里把3DES从 cipher suite 列表中剔除即可。
4.2.3 RC4 — 快但已彻底失宠
RC4 是流加密，不用分组。在那个没有 AES 硬件加速的年代，RC4 曾经是速度之王。但它的弱点太大了 — 密钥流有偏斜，导致经过一定数据量后攻击者可以恢复明文。我记得 2013 年微软安全响应中心发过公告：RC4 不能再视为安全。
- 致命问题：密钥调度算法不够随机，输出有统计偏斜
- TLS 历程：TLS 1.0/1.1 曾广泛使用 → RFC 7465 在 2015 年正式禁止
- 现状：所有现代浏览器和服务器都已删除 RC4 套件
说实话，我最后一次见到 RC4 流量是在 2018 年一台旧的嵌入式 VPN 设备上。那时我就告诉运维团队：必须升级。
4.2.4 AES — 现代对称加密的基石
AES 是 1997 年 NIST 公开征集，2001 年正式标准化的算法。它替代了 DES 和 3DES，成为 TLS 和几乎所有安全协议的标配。AES 分组固定的 128 位，密钥长度有三种：128、192、256。在 TLS 里最常见的是 AES-128 和 AES-256。
更关键的是它的工作模式。TLS 1.2 时代出镜率最高的是 AES-CBC，但 TLS 1.3 已经彻底转向 AES-GCM。为什么？因为 GCM 同时提供加密和完整性校验，一步到位，安全又高效。我个人习惯在新项目里只选 GCM 模式。
性能提示：如果你用的是现代 x86 CPU，AES-NI 指令集能让 AES 几乎零开销。虚拟机里也要确认 AES-NI 是否透传，否则性能可能掉一半。
4.3 TLS 为什么最终选择了 AES-GCM
原因很直接：
- 安全强度可靠：无已知的有效攻击（针对全轮次 AES）
- 硬件加速广泛：Intel/AMD 芯片内置 AES 指令，ARM 也跟进
- GCM 内置认证：不再需要单独的 HMAC 步骤，简化实现
- 标准成熟：NIST 和 IETF 都强力推荐
TLS 1.3 里固定了 GCM 和 ChaCha20-Poly1305 两个选择。ChaCha20 通常留给没有 AES 加速的低端移动设备。说白了，现在做 TLS 配置，无脑选 ECDHE + AES-256-GCM 就是了。
这里有段 OpenSSL 配置示例，你可以参考：
# 只启用 TLS 1.2/1.3 的 GCM 套件
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY13054.4 对称加密在 TLS 中的完整角色
我画了张框架图，把四个算法在 TLS 中的位置和演变路线梳理一下：
4.5 实际配置中的选型建议
我在实际项目中总结过一条经验：配置 cipher suite 时不要贪多，加得越多反而容易被降级攻击利用。尽量只保留两类套件：
- AES-128-GCM：性能极佳，适合绝大多数场景
- AES-256-GCM：强安全需求，例如支付或政务系统
- ChaCha20-Poly1305：备用选项，覆盖没有 AES 加速的设备
警告：我还见过有人为了兼容老设备保留 RC4 套件。千万别这么做。任何声称“只支持 RC4”的设备都应该直接退市。安全不妥协。
简单总结：AES 是王者，GCM 是模式，两者结合就是 TLS 加密部分的黄金搭档。其他三位 — DES、3DES、RC4，已经在 TLS 标准中被彻底清退。你以后再看 cipher suite 列表，只需关注有没有 ECDHE + AES-GCM 的组合即可，其余基本可以忽略。