📚 课程目录第3章 TLS密码套件

3、TLS密码套件：对称加密与非对称加密、哈希算法与HMAC、常见密码套件分析、弱密码套件识别

密码套件，说白了就是 TLS 握手的「武器库」。服务器和客户端能聊什么加密算法、用什么方式交换密钥、怎么保证数据没被篡改，全由它决定。我见过太多安全事件，根子就出在选错了套件上。

这一节，我们把这套武器库拆开看。你搞懂了它，审计 TLS 配置时心里就有底了。

3.1 密码套件的组成结构

一个密码套件长什么样？看个例子：

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

拆开来看，它包含四个核心部分：

密钥交换算法：ECDHE（椭圆曲线 Diffie-Hellman 临时密钥）
身份验证算法：RSA（用 RSA 证书签名验证身份）
对称加密算法：AES_256_GCM（256 位 AES，GCM 模式）
消息认证码（MAC）：SHA384（HMAC 使用 SHA-384 哈希）

嗯，这里要注意。TLS 1.3 简化了套件格式，只保留对称加密和哈希部分，因为密钥交换和身份验证在握手阶段已经固定了。但 TLS 1.2 及以下版本，这四个部分一个都不能少。

3.2 对称加密与非对称加密

3.2.1 非对称加密：握手时的「保险箱」

非对称加密，说白了就是一对钥匙——公钥加密，私钥解密。我习惯把它比作一个保险箱：你把公钥发给全世界，谁都能往里面塞东西（加密数据），但只有你有私钥能打开。

在 TLS 握手中，非对称加密干两件事：

身份验证：服务器用私钥签名证书，客户端用公钥验证签名。我在项目中遇到过有人把私钥权限开得太大，结果被运维误操作泄露了——嗯，权限最小化原则在这里同样适用。
密钥交换：用 RSA 或 DH 系列算法，安全地协商出对称密钥。

常见的非对称算法有：

算法	用途	安全强度（等效 RSA 位数）	现状
RSA	密钥交换、签名	2048 位 ≈ 112 位安全	仍广泛使用，但前向安全性差
ECDHE	密钥交换	256 位曲线 ≈ 128 位安全	推荐，支持前向安全
DHE	密钥交换	2048 位 ≈ 112 位安全	安全但性能较差
Ed25519	签名	≈ 128 位安全	现代、高效，推荐

我的经验：ECDHE 是目前最推荐的密钥交换算法。它支持前向安全（PFS），就算服务器私钥泄露，之前的会话也无法被解密。我曾经审计过一个金融系统，他们还在用静态 RSA 密钥交换——我直接标了高危。

3.2.2 对称加密：数据传输的「防弹玻璃」

对称加密，加密和解密用同一个密钥。速度快，适合大量数据。TLS 握手完成后，真正的应用数据就用对称加密来保护。

常见的对称加密算法：

AES：目前最主流。128 位密钥足够安全，256 位更保险。GCM 模式（Galois/Counter Mode）同时提供加密和完整性校验，我强烈推荐。
CHACHA20：Google 设计的流密码，在移动设备上性能极佳。没有 AES 硬件加速的设备上，它比 AES 快得多。
3DES：老古董了。块大小只有 64 位，容易受到 Sweet32 攻击。我在 2022 年还见过一个政府网站开着 3DES——直接建议下线。
RC4：已死。多种攻击方法，不要再用了。

避坑指南：我曾经审计过一个电商平台，他们的 TLS 配置里同时开了 AES-GCM 和 AES-CBC。CBC 模式需要正确的填充和 MAC 校验顺序，否则容易受到 Padding Oracle 攻击。我的建议是：只用 GCM 或 ChaCha20-Poly1305，别给自己找麻烦。

3.3 哈希算法与 HMAC

3.3.1 哈希算法：数据的「指纹」

哈希算法把任意长度的数据变成固定长度的摘要。在 TLS 里，它用来做消息认证和伪随机函数（PRF）。

常见的哈希算法：

算法	摘要长度	安全状态
MD5	128 位	已破解，禁止使用
SHA-1	160 位	已破解（SHAttered 攻击），禁止使用
SHA-256	256 位	安全，推荐
SHA-384	384 位	安全，推荐
SHA-512	512 位	安全，但性能开销较大

你想想看，为什么 TLS 1.3 只保留了 SHA-256 和 SHA-384？因为够用，而且少即是多。减少攻击面，这是安全设计的基本原则。

3.3.2 HMAC：带密钥的哈希

HMAC（Hash-based Message Authentication Code）是哈希算法的升级版。它引入了一个密钥，只有知道密钥的人才能验证消息的完整性。

公式很简单：

HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))

其中：

K 是密钥
m 是消息
H 是哈希函数
opad、ipad 是固定的填充值

HMAC 在 TLS 里无处不在。记录协议用 HMAC 校验数据完整性，密钥推导过程也用 HMAC 做伪随机函数。我在项目中遇到过有人直接用 SHA-256 裸哈希做消息认证——这是典型的错误。没有密钥的保护，攻击者可以伪造消息。

3.4 常见密码套件分析

我们来看几个真实场景中常见的套件：

套件名称	特点	推荐度
TLS_AES_128_GCM_SHA256	TLS 1.3 默认套件，安全高效	⭐⭐⭐⭐⭐
TLS_AES_256_GCM_SHA384	更高安全强度，性能略低	⭐⭐⭐⭐
TLS_CHACHA20_POLY1305_SHA256	移动端友好，无硬件加速时更快	⭐⭐⭐⭐⭐
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	TLS 1.2 经典组合，广泛支持	⭐⭐⭐⭐
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	使用 ECDSA 证书，更高效	⭐⭐⭐⭐
TLS_RSA_WITH_AES_128_CBC_SHA	无前向安全，CBC 模式有风险	⭐⭐

  核心原则：优先使用 TLS 1.3 套件。如果必须兼容 TLS 1.2，选择 ECDHE + AES-GCM 或 ChaCha20-Poly1305 的组合。

3.5 弱密码套件识别

这部分是实战重点。我每次做 TLS 审计，都会按以下清单排查弱套件：

使用 RC4 的套件：全部标记为高危。RC4 有严重的偏差攻击，可以在合理时间内恢复明文。
使用 CBC 模式的套件：如果没有正确的 MAC-then-Encrypt 顺序，容易受到 Padding Oracle 攻击。TLS 1.2 中虽然修复了部分问题，但最好还是用 GCM。
使用 3DES 的套件：64 位块大小，Sweet32 攻击可以恢复会话 Cookie。我在一次银行审计中发现了这个漏洞，对方一开始还不信，直到我演示了攻击过程。
使用 RSA 密钥交换的套件：没有前向安全性。如果服务器私钥泄露，所有历史会话都可以被解密。
使用 MD5 或 SHA-1 的套件：哈希碰撞已成现实，不能再用于安全场景。
使用 EXPORT 级套件：故意弱化的密码，用于绕过历史出口管制。现在看到就是漏洞。
使用 NULL 加密或 NULL 认证的套件：不加密或不验证身份，等于裸奔。

我曾经踩过的坑：有一次我扫描一个客户的服务器，发现它支持 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA。客户说「这是为了兼容老设备」。我追问下去，发现那台「老设备」其实三年前就退役了，配置却一直没更新。所以我的建议是：定期清理密码套件列表，别让历史遗留问题变成安全漏洞。

3.6 密码套件选择的知识图谱

下面这张图，是我自己总结的密码套件选择逻辑。你照着这个流程走，基本不会出错。

3.7 实战：如何检查服务器支持的密码套件

我习惯用 OpenSSL 和 Nmap 来做快速检查。给你几个常用命令：

# 查看服务器支持的套件（TLS 1.2）
openssl s_client -connect example.com:443 -tls1_2

# 列出所有支持的套件
nmap --script ssl-enum-ciphers -p 443 example.com

# 测试特定套件是否被支持
openssl s_client -connect example.com:443 -cipher "ECDHE-RSA-AES128-GCM-SHA256"

拿到结果后，对照我们上面说的弱套件清单，一条一条过。我一般会生成一个报告，把弱套件标红，然后给出替换建议。

小技巧：用 sslscan 工具可以快速扫描并分级。它会把套件标记为 Accepted、Weak 或 Rejected，一目了然。我每次做渗透测试，第一件事就是跑 sslscan。

好了，密码套件这块就聊到这儿。你记住一个核心原则：少即是多。只保留最安全的几个套件，别为了兼容性开一堆过时的算法。安全审计时，弱套件就是低 hanging fruit，先把它摘了，你的 TLS 配置就及格了。