📚 课程目录第2章密码套件概念与组成

2. 密码套件概念与组成

你可能经常在抓包时看到一串像 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 的字符串，这就是密码套件。说白了，它就是四种算法的组合：密钥交换算法 + 认证算法 + 对称加密算法 + MAC 算法。每一个握手套件，都是在告诉自己“我要用哪种方式换钥匙、怎么证明身份、怎么加密数据、怎么保证没人篡改”。

我自己在分析降级攻击时，最烦的就是客户只看加密算法强度，忽略了前两步。其实密钥交换和认证才是攻击者的主攻方向。不信你去翻那些 CVE 漏洞，几乎都是在这两个环节装傻。

2.1 四个组成部分分别干什么

咱们一个一个说清楚。记住这个口诀：换钥、验身、加锁、防改。

组件	作用	常见算法举例
密钥交换	协商出一个临时对称密钥，防止被中间人窃听	ECDHE、DHE、RSA key exchange
认证	证明服务器（或客户端）的身份是不是真的	RSA、ECDSA、DSS
对称加密	真正加密传输的数据	AES_256_GCM、ChaCha20、AES_128_CBC
MAC	检测消息是否被篡改，保证完整性	SHA384、SHA256、Poly1305

一个小技巧： 我在排查降级事件时，会先看名字中的第一个词——比如 ECDHE 后置的 RSA 是认证，AES 是加密，GCM 自带 MAC 校验。如果你发现名字里没有 AEAD（如 CBC+HMAC），多半是过时套件，得警惕。

2.2 密钥交换：谁在玩“丢手绢”？

密钥交换决定了对称密钥能不能安全传到对方手里。以前 RSA 密钥交换直接把公钥发过去，客户端用公钥加密 premaster secret 传给服务器——如果私钥泄漏，整条会话都能被解密。现在主流都是用 ECDHE（椭圆曲线 Diffie-Hellman 临时密钥），每次连接生成临时密钥对，即使私钥泄漏也破不了之前的会话。

嗯，这里要注意：降级攻击最喜欢拿掉 ECDHE，让你退到 RSA 交换。我在做渗透测试时就遇到过，一台老路由器只支持 DHE 1024-bit，攻击者把它进一步降级成 512-bit，不到一小时就破解了。

避坑： 我曾经排查过一个银行客户端降级案例，发现对方的密钥交换被限制在了 RSA，原因是防火墙上的 TLS 策略只允许 RSA 证书认证一套套件。后来改用了 ECDHE 并放开策略，所有问题才消失。记住——政策不能阉割安全。

2.3 认证算法：证明“你不是骗子”

认证算法通常就是证书签名的算法。RSA 最常见，ECDSA 越来越火（短签名、匹配椭圆曲线更快）。但降级攻击的坑在于：许多老旧客户端只认 RSA 1024 位签名，攻击者可以伪造一个 512 位的弱证书绕过验证。说白了，认证算法的强度必须等于或高于会话安全强度。

我自己的习惯是，在生产环境强制使用 RSA 2048 以上或 ECDSA P-256。你在 Nginx 配置里写 ssl_prefer_server_ciphers on 时，要同时卡死认证算法的长度。

2.4 对称加密：数据能不能被偷看

对称加密这块，CBC 模式已经可以不用想了。AES-GCM 和 ChaCha20-Poly1305 是当今主力。GCM 内置了 AEAD（同时提供加密和完整性校验），但如果在服务端只开着 AES_128_CBC，攻击者可以走 BEAST 攻击降级。为什么？因为 CBC 需要单独加上 HMAC 做完整性，但降级攻击可以替换掉 HMAC 算法，留下纯 CBC 模式。

  关键点： GCM/CCM 这种 AEAD 模式自带 MAC，所以密码套件名字里不会出现 "_SHA" 后缀。如果你看到 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA，那它的 MAC 就是独立的 SHA-1，这是降级攻击的黄金目标。

2.5 MAC 算法：防篡改的最后一堵墙

MAC（消息认证码）用来确保数据在传输中没被改过。SHA-256 和 SHA-384 是主流，SHA-1 已经被 Chrome 和 Firefox 标记为不安全。但很多老设备还在沿用 HMAC-SHA1，攻击者可以拿它做 padding oracle 攻击。再说个实例：我接过一个工控系统项目，他们的 PLC 只支持 MD5 做 MAC，结果中间人可以直接修改报文并重新计算校验值——因为 MD5 的碰撞已经被攻破好多年了。

现在讲究的套件都会用 AEAD 模式，把 MAC 任务直接交给加密算法自己处理。比如 AES_128_GCM，GCM 内部已经做好认证标签。这样少了一个攻击面。

2.6 密码套件命名规则：看名字你就知道谁在降级

密码套件的命名其实很有规律。以 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 为例：

TLS 协议
ECDHE 密钥交换
RSA 认证
AES_256_GCM 加密模式（AEAD，自带 MAC）
因为 AEAD 已经包了完整性，最后一节 SHA384 其实是 PRF（伪随机函数）用的哈希算法，不是单独的 MAC。这点很多人搞混。

我经常跟团队成员说：只要看到名字里有 CBC 和 SHA 的套件，基本就是降级攻击的入口。为什么？因为 CBC 模式必须依赖 HMAC 做完整性，而 HMAC-SHA1 已经可以在某些场景下被绕过。反过来，GCM 套件的最后一个哈希只跑 PRF，对降级不太敏感。

动手检查： 你用 OpenSSL 测试自己的服务器：openssl ciphers -V 'ALL:COMPLEMENTOFALL' 会列出所有支持的套件。重点关注密钥交换是 ECDHE 还是 RSA，加密是 GCM 还是 CBC。如果出现 RSA 交换 + CBC 模式 + SHA1，赶紧把它禁掉。

2.7 套件组合的完整逻辑流程

为了让你更直观地理解这四个组件在握手时怎么合作，我画了一个流程图：

2.8 为什么降级攻击专挑这些组合？

攻击者做降级，不是随机挑一个套件。他们有明确的“狩猎清单”：

密钥交换是 RSA 而不是 ECDHE → 可以截获 premaster secret（如果私钥被偷）
对称加密是 CBC 模式 → 可以走 padding oracle 或 BEAST 攻击
MAC 是 HMAC-SHA1 甚至 MD5 → 可以碰撞或伪造校验
认证算法强度低（RSA 512 位、DSS 512 位）→ 可以伪造证书

在真实环境中，降级攻击经常隐藏在 ClientHello 和 ServerHello 的中间。攻击者把 ClientHello 里的强套件列表删掉，只留下几个过时套件；服务器如果配置不当（比如允许降级），就会选一个弱套件。我在一次金融系统渗透测试中就用类似手法，把 TLS 1.2 降到了 TLS 1.0 的 CBC 加 SHA1，成功执行了 padding oracle。

再强调一遍： 检测降级，不仅要看最终使用的加密算法，更要看密钥交换和 MAC 算法是否都被拉到了安全红线以下。我曾经见过一个套件 TLS_RSA_WITH_AES_256_CBC_SHA——加密看起来很强（256 位），但密钥交换是静态 RSA，MAC 是 SHA1。攻击者只要拿到服务器私钥，整条会话数据都是明文。

好了，这一章的核心就是让您真正理解密码套件是怎么拼装的，以及每个组件在降级攻击中的角色。记清楚这四个字母：K 密钥交换、A 认证、E 加密、M MAC，以后看到任何套件名字，你就能心里有数了。