CBC 套件为何退场
TLS 1.2 的 CBC 套件采用「先认证后加密」结构，配合 CBC 的填充校验方式，历史反复被填充与时序类攻击利用（Lucky13、POODLE 类问题）。TLS 1.3 已彻底移除全部 CBC 套件，只保留 AEAD。当下运维做法很明确：即使停留在 TLS 1.2，也只保留 AEAD 组合（AES-GCM、ChaCha20-Poly1305），把协议基线保持在 1.2 及以上。
基本信息
| 问题根源 | MAC-then-Encrypt 结构加 CBC 填充，形成可探测的填充与时序差异 |
|---|---|
| TLS 1.3 处理 | 移除全部 CBC 套件，仅保留 AEAD |
| TLS 1.2 处置 | 套件白名单只保留 ECDHE 与 AEAD 组合 |
| 常见残留 | AES128-SHA、AES256-SHA 等老条目仍留在旧配置模板里 |
| 验证方式 | 用 s_client 逐版本确认实际协商结果 |
典型使用场景
- 安全基线整改：清理沿用多年的 nginx / apache 套件模板
- 等保与合规测评中的「弱套件」整改项销项
- 老客户端兼容评估：确认哪些终端只能走 CBC，单独安排入口
- 上线前回归：逐版本验证协商结果与预期白名单一致
- 事故复盘：结合抓包确认当时的会话是否落在 CBC 套件上
白名单与验证
白名单与验证
# nginx：只保留 ECDHE + AEAD 组合
# ssl_ciphers 'ECDHE+AESGCM:ECDHE+CHACHA20';
# apache：SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20
openssl s_client -connect example.com:443 -tls1_2 </dev/null 2>&1 | grep 'Cipher is'
# 构造只支持 CBC 的客户端，确认服务端已拒绝
openssl s_client -connect example.com:443 -tls1_2 -cipher 'AES128-SHA' </dev/null 2>&1 | grep -iE 'cipher|alert|error' | head -3常见残留与处理
| 残留项 | 风险 | 处理 |
|---|---|---|
| AES128-SHA / AES256-SHA | CBC 加 SHA-1，属弱套件清单 | 从白名单移除 |
| 3DES 套件 | 64 位分组，存在 Sweet32 类问题 | 移除，仅对清单内老终端例外 |
| RC4 套件 | 已被实践攻破 | 立即移除 |
| RSA 密钥传输 | 无前向安全 | 逐步替换为 ECDHE 组合 |
遗留客户端只支持 CBC 时，常见做法是给这些终端单独的域名或入口，并设置限时豁免，而不是让主站整体降级。豁免要有到期时间与复核记录，否则临时措施会长年存在。
基线参考：RFC 8996 已弃用 TLS 1.0 与 1.1，新部署应从 1.2 起步并优先 1.3；1.2 的套件按「ECDHE 密钥交换 + AEAD 加密 + SHA-256 及以上摘要」筛选，即可覆盖绝大多数客户端并避开 CBC 相关攻击面。
排查顺序参考：先用 s_client 试出服务端仍可协商的最弱套件，再核对 nginx 的 ssl_ciphers 与 openssl 版本默认值是否一致；部分 JDK 与老客户端库自身可用套件集合受限，验证时要覆盖真实客户端类型，而不是只用命令行工具。