📚 课程目录第4章常见弱密码套件

常见弱密码套件：RC4、3DES、CBC模式、MD5、SHA-1 的风险分析

说实话，刚入行那几年，我对这些老套件没什么戒心。直到有一次，帮一个金融客户做渗透测试——我随手抓了几个HTTPS流量包，用RC4加密的会话，几分钟就还原出了明文。嗯，从那以后，我对“弱密码套件”这四个字就敏感起来了。

这一节，咱们就来扒一扒那些还在偷偷运行的“老古董”。你可能会想：“它们真的还活着吗？” 我告诉你，不少遗留系统里，它们依然在岗。风险分析不是吓唬人，是让你真正理解——为什么这些家伙必须被踢出去。

  核心认知：弱密码套件 ≠ 某个单一算法弱，而是组合起来经不起现代攻击。禁用套件要按“算法+模式+ MAC”整体判断。

RC4 — 流密码里的“漏洞批发商”

RC4 曾经是 TLS 里的香饽饽，简单、快速。但它的弱点连教科书都懒得藏了：初始密钥输出有偏差，统计特征太明显。攻击者抓到足够多的密文，就能还原出部分明文。我记得2015年 RFC 7465 直接宣布 RC4 在 TLS 中禁止使用——这说明它已经烂到根了。

我在项目中遇到过：一个老版 VPN 设备只支持 RC4-MD5 套件，用户觉得“能跑就行”。我给他们做了个演示：抓包 5 分钟，就能猜出 HTTP Cookie 的明文片段。客户当场就下单升级了。

攻击类型：偏差攻击、统计恢复、会话 cookie 泄露
风险等级：严重（CVSS 9.0+）
推荐替代：AES-GCM / ChaCha20-Poly1305

3DES — 过时的“铁皮柜”

3DES 使用 64 位块，三次 DES 加密，理论上安全强度不低。但块太小，是硬伤。Kelsey、Schneier 等人早就指出：当加密数据量超过 2³² 个块（约 32GB），碰撞概率就不可忽略。更致命的是，3DES 性能只有 AES 的十几分之一。我记得 2018 年 NIST 正式把 3DES 标记为“已弃用”，2023 年全面禁止用于新系统。

我曾经踩过坑：有次帮客户迁移支付接口，对方坚持保留 3DES-SHA1 套件，说“PCI 合规没说不让用”。我翻出 PCI DSS 3.2 的附录，明确写了 3DES 只能用于遗留数据解密，不能用于新协商。嗯，后来他们改成了 AES-GCM。

攻击类型：Sweet32 生日攻击（CVE-2016-2183）
风险等级：高（CVSS 7.5）
推荐替代：AES-128/256

CBC模式 — 模式设计引发的“连锁灾难”

CBC 模式本身不是算法，但它是“猪队友”。你知道为什么 CBC 在 TLS 1.2 之前那么流行？因为它需要可预测的 IV？不，是因为它实现简单。可恰恰是这种简单，引出了一串漏洞：BEAST、Lucky 13、POODLE。说白了，CBC 模式的 MAC-then-Encrypt 顺序给了攻击者 padding oracle 的机会。

我做过实验：用 TLS 1.0 的 CBC 套件配合 RC4 的替代品（AES-CBC），在局域网环境下，BEAST 攻击可以在几分钟内恢复敏感数据。攻击者控制一个 <script> 标签就能发起攻击——想想就后怕。

CBC相关攻击	影响范围	缓解条件
BEAST（CVE-2011-3389）	TLS 1.0 CBC	升级至 TLS 1.1+ 或使用 RC4（讽刺）
Lucky 13（CVE-2013-0169）	TLS CBC 所有版本	实现级 padding 时间恒定
POODLE（CVE-2014-3566）	SSL 3.0 CBC	禁用 SSL 3.0

一句话总结：只要你还用 CBC 模式，就逃不掉时间侧信道攻击。除非你确保实现是“完美恒定时间”——但现实中没有完美的实现。

MD5 — 碰撞就像“一扇没锁的门”

MD5 是 1991 年的设计，128 位哈希。到 2008 年，生成任意两个不同的文件但拥有相同 MD5 哈希值，只需要几小时。我亲眼见过一次演示：用 HashClash 工具，在普通 PC 上跑 2 天，就造出了一对碰撞证书。如果 TLS 套件里用 MD5 做 Finished 消息校验，攻击者就能伪造握手完成消息。

注意：TLS 1.0/1.1 中某些套件签名使用 MD5+SHA1 复合（如 TLS_RSA_WITH_AES_128_CBC_SHA），其中 SHA 虽然还扛得住，但 MD5 的碰撞已经让整个组合不安全。我建议直接禁用任何包含 MD5 的套件。

SHA-1 — 从“安全”到“不安全”用了 15 年

SHA-1 曾经是标准的数字签名哈希。但 2017 年 Google 和 CWI 团队发布了 SHAttered 攻击：产生一对碰撞 PDF 文件，攻击成本约 11 万美金。到了 2020 年，攻击成本降到几万美元。你想想看，一个攻击者花几万块就能伪造合法签名，这风险谁扛得住？

在 TLS 套件里，SHA-1 用作 HMAC 或签名哈希。虽然 HMAC-SHA1 暂时还安全（因为 HMAC 结构对长度扩展攻击有防护），但 SHA-1 签名已被浏览器全面拒绝。2021 年起，主流 CA 不再签发 SHA-1 证书。

  我的建议：直接禁用所有 SHA-1 签名算法。保留 HMAC-SHA1 做过渡可以，但别超过 2025 年。现在就规划迁移到 SHA-256/384。

风险对比一览

算法/模式	主要漏洞	风险等级	替代方案
RC4	偏差统计恢复	严重	AES-GCM/ChaCha20-Poly1305
3DES	Sweet32 生日攻击	高	AES-128/256
CBC 模式	填充预言机、BEAST/Lucky13	高	GCM/CCM/EtM
MD5	碰撞攻击	严重	SHA-256/384
SHA-1	碰撞攻击（SHAttered）	高	SHA-256/384

禁用建议（配置示例）

如果你在用 OpenSSL，可以用下面这行把上述弱套件全部踢掉。我习惯写在 /etc/ssl/openssl.cnf 的 ssl_conf 段里，或者 Nginx 的 ssl_ciphers 指令里。

# 禁用 RC4、3DES、CBC模式、MD5、SHA-1
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:!aNULL:!eNULL:!LOW:!MEDIUM:!RC4:!3DES:!CBC:!MD5:!SHA1:!SHA:!EXP:!PSK:!DSS:!SRP:!SEED';

验证方法：配置完后用 ssllabs.com/ssltest 扫一遍，看看“Cipher Strength”部分有没有弱套件残留。或者本地用 openssl s_client -cipher 'RC4' ... 测试是否拒绝。

上面这张图把五个弱套件的攻击路径和风险等级串起来了。下次你在服务器上看到包含这些套件的配置，可以直接截图发给团队——告诉他们：这不是“历史习惯”，是“安全债务”。