如何设置Nginx的ssl_ciphers，在兼顾旧设备兼容性与极致安全之间达到黄金比例？

本文共计1130个文字，预计阅读时间需要5分钟。

直接说结论：

为什么 ssl_ciphers 对 TLS 1.3 完全无效

TLS 1.3 彻底重构了密钥交换与加密套件机制，它只允许五种标准化组合（如 TLS_AES_128_GCM_SHA256），这些由 OpenSSL 内部硬编码实现，ssl_ciphers 指令对其完全不生效。Nginx 启动时若在 ssl_ciphers 中写入 TLS 1.3 套件名（比如带 TLS13- 前缀的），不会报错但也不会被采用；写入旧版套件（如 AES256-SHA）更不会触发 TLS 1.3 回退——协议版本由 ssl_protocols 控制，cipher 只影响 TLS 1.2 协商结果。

常见错误现象：
– SSL Labs 测评显示 TLS 1.3 已启用，但 cipher 列表里全是 TLS 1.2 套件 → 正常，无需修改
– 启用了 TLSv1.3 却仍看到 ECDHE-RSA-AES128-GCM-SHA256 被标为“支持” → 这是 TLS 1.2 的协商结果，和 TLS 1.3 无关

等保三级不可妥协的硬性过滤条件

以下关键词一旦出现在 ssl_ciphers 字符串中，即违反等保三级传输加密要求，必须从列表中彻底剔除：

• SSLv3、TLSv1、TLSv1.1（协议层已禁，但部分旧 cipher 名含这些字样，需一并排除）
• RC4、MD5、SHA1（注意：含 -SHA 但非 -SHA256/-SHA384 的均属 SHA1，如 ECDHE-RSA-AES128-SHA）
• EXPORT、NULL、ANONYMOUS、PSK、SRP
• AES256-SHA、AES128-SHA、DES-CBC3-SHA（静态 RSA 密钥交换，无前向保密）

性能影响：剔除这些后，cipher 列表长度通常缩短 40%～60%，但现代客户端协商速度反而更快（候选集更小、AEAD 解密更高效）；兼容性影响：IE11 on Win7/8.1 仍可连，但 IE11 on Win10 默认倾向 TLS 1.3，实际走的是另一条路径。

面向 IE11 / Android 5–6 的 TLS 1.2 兼容套件取舍

若真实存在必须支持 Windows 7 + IE11、OpenSSL 1.0.2u 固件、Java 8u161- 等环境，只能在 TLS 1.2 框架内加极少量 CBC 套件，且必须满足三个前提：
– ssl_protocols 明确限定为 TLSv1.2 TLSv1.3（禁用 TLS 1.0/1.1）
– ssl_prefer_server_ciphers 保持 off（Nginx 1.11.0+ 默认值）
– 所有 CBC 套件必须使用 SHA256 或 SHA384，禁用任何 -SHA

可谨慎加入的套件（仅限必要）：

• ECDHE-RSA-AES128-SHA256：IE11 on Win7/8.1 默认启用，TLS 1.2 下已规避 POODLE
• ECDHE-RSA-AES256-SHA384：金融/政务类旧系统常见依赖，性能略低但未牺牲安全性
• ECDHE-RSA-CHACHA20-POLY1305：对 Android WebView 和低功耗设备更友好，但 Java 7/8 不支持，慎用

绝对不要加：ECDHE-RSA-AES128-SHA（SHA1）、DHE-RSA-AES128-SHA（DHE 性能差且 SHA1）、AES128-GCM-SHA256（缺少密钥交换前缀，Nginx 解析失败）

最终配置必须验证的三个隐性点

即使 cipher 字符串看起来完美，以下三点疏忽仍会导致“表面合规、实际降级”：

• ssl_ecdh_curve 未显式指定 secp256r1:secp384r1 → IE11 和部分 Java 客户端可能 fallback 到不安全曲线（如 sect163k1），或协商失败
• ssl_dhparam 文件缺失或过期（若保留 DHE 套件）→ Nginx 会自动生成 1024-bit DH 参数，违反等保三级“密钥长度 ≥ 2048-bit”要求
• 未在日志中启用 $ssl_protocol 和 $ssl_cipher 变量 → 无法确认真实连接到底走了 TLS 1.2 还是 TLS 1.3，也无法定位是哪个客户端触发了弱 cipher 回退

最易被忽略的是：cipher 列表再严谨，如果 ssl_protocols 漏写了 TLSv1.3，或者 OpenSSL 运行时版本低于 1.1.1，那所有 TLS 1.3 相关的安全收益就归零——而这个事实，nginx -t 根本不会提示。