套件选择规则
套件选择规则在 TLS 1.2 与 1.3 中完全不同。1.2 由客户端提交套件列表，服务端可通过偏好开关决定优先级，因此加固时要显式排除 CBC、RC4 等旧组合；1.3 只保留少数 AEAD 套件，顺序以客户端偏好为准，服务端无法自定义组合，证书认证改由签名算法协商。把这个差异分清，才能解释「配置写了却不生效」这类现象。
基本信息
| TLS 1.2 | 客户端列表加服务端偏好，需显式排除旧组合 |
|---|---|
| TLS 1.3 | 套件固定为 AES-GCM 与 ChaCha20 系列 |
| nginx | ssl_ciphers 只作用于 1.2 套件 |
| 验证工具 | openssl ciphers 看语义，s_client 看实际协商 |
典型使用场景
- 加固配置：编写套件白名单前先在本地验证表达式是否合法
- 兼容性排查：客户端握手失败时对比双方可用套件
- 性能优化：缺少 AES 硬件加速时优先 ChaCha20 组合
- 合规检查：确认服务端不再协商 CBC、3DES 等旧组合
- 版本差异确认：核对 1.2 与 1.3 的实际协商结果
查看与限定套件
查看与限定套件
openssl ciphers -v 'ECDHE+AESGCM:ECDHE+CHACHA20' | head -10 # 验证表达式
openssl list -cipher-algorithms | grep -i '^TLS_AES' | head # 枚举 1.3 套件
openssl ciphers -v 'DEFAULT' | grep -c 'CBC' # 统计旧组合数量
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>&1 | grep -i cipher两个版本的分工
| 项目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 套件数量 | 组合众多 | 仅少数 AEAD 套件 |
| 选择权 | 服务端可配偏好 | 以客户端顺序为准 |
| 密钥交换 | 写在套件名中 | 由支持组单独协商 |
| 认证算法 | 写在套件名中 | 由签名算法列表协商 |
把配置拆成两层理解：1.2 的白名单受套件指令控制，1.3 交给协议默认集合与客户端顺序，排查时就不会困惑为什么写了套件名却不生效。
加固落地步骤
- 先用 ciphers 命令在本地验证目标表达式能解析
- 再写入服务端配置并用 s_client 验证实际协商结果
- 统计日志中的协议与套件分布，评估旧客户端占比
- 按分布结果分批关闭旧组合，保留可回退的配置版本
关闭全部 CBC 组合前必须先看访问日志中的客户端分布，老旧设备与内嵌系统常只能协商旧组合，一次性关闭会造成批量连接失败。