4、密码套件与安全配置：常见密码套件、弱密码识别、推荐配置
聊到 TLS，绕不开密码套件。每个搞安全的工程师，都至少和它打过几年交道。说实话，这是一把双刃剑——配置好了是护盾，配置错了就是筛子。
我在项目中遇到过很多客户，他们的 TLS 配置看起来“标准”，但仔细一查，问题不少。今天我们就掰开揉碎了聊聊这东西。
4.1 什么是密码套件？说白了就是加密配方
密码套件其实就是一段约定的字符串。它告诉服务器和客户端：“我们用什么算法来握手、加密、验证完整性”。
一个典型的套件长这样：
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384我来拆开给你看：
- TLS：协议类型
- ECDHE：密钥交换算法（临时椭圆曲线 Diffie-Hellman）
- RSA：身份验证算法
- AES_256_GCM：对称加密算法和模式
- SHA384：消息认证码（HMAC）算法
你想想看，这就像一道菜的“食材清单”。只要其中一个环节是弱项，整道菜就废了。
核心要点：安全强度取决于密码套件中最薄弱的那个环节。
4.2 常见密码套件一览
市面上常用的套件分几大类。我习惯把它们按安全等级排个序：
| 安全等级 | 典型套件 | 特点 |
|---|---|---|
| 推荐（强） | TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 |
AEAD 认证加密，支持前向安全 |
| 可接受（中） | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | 兼容性好，但密钥长度稍短 |
| 不推荐（弱） | TLS_RSA_WITH_AES_128_CBC_SHA | 没有 PFS，CBC 模式易受 Padding Oracle 攻击 |
| 禁止（极弱） | TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA |
RC4 已破，3DES 太慢且不安全 |
实际做审计时，我会先扫一遍服务器的密码套件列表。嗯，这里要注意：TLS 1.3 只支持 5 个套件，选起来反而简单。麻烦的是 TLS 1.2 及其以下的版本，套件列表动不动就好几十个。
4.3 弱密码识别：别让这些家伙混进来
识别弱密码套件，我有三条铁律：
- 不支持前向安全的，一律是弱项。 说白了就是没有 ECDHE 或 DHE 的套件。
- 使用 CBC 模式的，尽早淘汰。 Lucky13、Padding Oracle 这些攻击，专门盯着它。
- 密钥长度不够的，直接拉黑。 比如单重 DES、RC4、3DES。
我曾经在审计中发现，某客户的负载均衡器上还挂着 TLS_RSA_WITH_RC4_128_SHA。客户说“没人用这个版本了吧”？我让他开了抓包工具，十分钟后抓到好几个移动端旧设备在尝试。嗯，这些东西只要开着，就是风险。
警告：即使你的服务器只接受强套件，只要弱套件 没有被禁掉，攻击者依然可以尝试降级攻击。要么全禁，要么别用。
4.4 推荐配置：我常用的几套组合
这些年总结下来，我一般按“场景”来配密码套件。没有万能方案，但有保守方案。
场景1：全 HTTPS 业务站点（现代浏览器 + API）
# Nginx 示例
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;场景2：需要兼容旧客户端（比如 IoT 设备或老旧系统）
我建议对这种场景做一个“隔离 TLS 终结点”。给旧客户端走单独的监听端口，限制访问范围，而不是把弱套件混在主站上。
场景3：内部微服务通讯（mTLS）
内部通讯安全要求通常更高：
# 内部 mTLS，强制最高等级
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;实践经验：配置完密码套件后，一定要用 openssl ciphers -v '你的字符串' | sort 查看实际生效的列表。我还见过因为空格或大小写错误，导致整个配置被忽略的案例——你配了个寂寞。
4.5 密码套件审计的思维框架
我在每次审计 TLS 配置时，脑子里都会过一遍这张图：
这个流程我用了很多年。你想想看，每一步如果不通过，判断逻辑就很简单：要么禁掉，要么升级。
4.6 避坑指南
- 别把“兼容性”当挡箭牌。我曾经在金融项目中见过，为了兼容一台十年前的 ATM 前置机，直接降级到 TLS 1.0 + RC4。最后被监管通报整改。我的建议是：如果系统太老，就走独立 TTL 通道，不要污染全局。
- 默认配置往往不够安全。Nginx 和 Apache 的默认密码套件列表，包含了大量 CBC 套件。要去主动裁剪。
- 定期复查。每隔半年，用
testssl.sh或Qualys SSL Labs扫一遍。因为新的攻击向量每年都有变化——你三年前配的“强套件”，现在可能已经是“可接受”等级了。
密码套件这东西，说难不难，说简单也不能掉以轻心。记住一条原则：少即是多。你允许的套件越少，攻击面就越窄。这比你在 WAF 上写的任何规则都管用。