如何通过配置Nginx ssl_prefer_server_ciphers防御TLS协议降级攻击？

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

ssl_prefer_server_ciphers on 本身不能单独防御TLS降级攻击，它只是配置之一；要真正生效，必须与 ssl_ciphers、ssl_protocols 以及证书、密钥交换方式等配置协同一致，否则可能形同虚设。

为什么 ssl_prefer_server_ciphers on 容易被误用

很多人以为只要加上这行就“安全了”，但实际中常见错误包括：

• 配置了 ssl_prefer_server_ciphers on，但 ssl_ciphers 里仍保留 RC4、DES-CBC3-SHA、MD5 等已知弱套件
• 未禁用 TLSv1.0 和 TLSv1.1，导致客户端可强制协商旧协议并绕过服务端 cipher 优先级
• 在 Nginx 1.11.0+ 上设为 on 却未意识到：该指令对 TLSv1.3 无效，且会干扰其默认安全行为（TLSv1.3 不协商 cipher，ssl_ciphers 和此指令均被忽略）
• 未验证最终协商结果，仅凭配置存在就认为生效

如何正确配置以阻断降级路径

降级攻击的核心是让连接回落到不安全的协议或 cipher 组合。要切断所有常见降级路径，需同时控制三个层面：

• 协议层：只允许 TLSv1.2 和 TLSv1.3，明确禁用 TLSv1.0 和 TLSv1.1：
  ssl_protocols TLSv1.2 TLSv1.3;
• cipher 层：只保留支持前向保密（PFS）+ AEAD 加密的套件，显式剔除所有含 RC4、DES、3DES、MD5、SHA1、NULL、EXPORT 的套件：
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
• 协商控制层：启用服务端 cipher 优先级，确保 TLSv1.2 连接严格按上述列表顺序选择：
  ssl_prefer_server_ciphers on;

验证是否真能防住降级

光改配置没用，必须实测协商结果。常用方法：

• 用 OpenSSL 强制指定 TLSv1.2 并查看实际协商出的 cipher：
  openssl s_client -connect example.com:443 -tls1_2 -cipher 'ALL:COMPLEMENTOFALL' 2>/dev/null | grep Cipher
  确认输出中不含 RC4、DES、SHA1 等关键词，且 cipher 名称与你配置的完全匹配
• 用 SSL Labs Test（https://www.ssllabs.com/ssltest/）跑完整扫描，重点看 “Handshake Simulation” 表格中各客户端（尤其是老版本 IE、Android 4.4）是否都协商到了强套件；若某客户端仍落到 ECDHE-RSA-RC4-SHA，说明你的 ssl_ciphers 或 ssl_prefer_server_ciphers 没生效
• 检查 Nginx 错误日志是否有 no suitable signature algorithm 或 SSL_do_handshake() failed，这类报错常意味着 ssl_ciphers 过于激进，或 ECDSA 证书缺失对应曲线支持（此时需补 ssl_ecdh_curve secp384r1:prime256v1;）

最易被忽略的是：TLSv1.3 虽然自身免疫降级，但它依赖底层 OpenSSL 版本（≥1.1.1）和 Nginx（≥1.13.0）；如果环境不满足，ssl_protocols TLSv1.2 TLSv1.3 实际只启用了 TLSv1.2，此时 ssl_prefer_server_ciphers on 就成了唯一防线——而它又极易因 cipher 配置不当而失效。