如何通过调整 ssl_prefer_server_ciphers 参数有效抵御针对旧版加密协议的降级攻击策略？

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

开启 `ssl_prefer_server_ciphers on` 可以降低防御加密级别，但这是在 TLS 1.2 及以下协议中防止商家使用弱加密套件的关键控制点——即它必须与协议限制和密码套件精确定义一起使用。

明确禁用不安全的协议版本

降级攻击（如 POODLE、FREAK、BEAST）大多依赖客户端或中间设备诱使服务端回退到 TLS 1.0、TLS 1.1 或 SSL 3.0。这些旧协议本身存在设计缺陷，无法靠单个指令修复。

• 必须显式关闭不安全协议：ssl_protocols TLSv1.2 TLSv1.3;
• 禁止写 TLSv1（等价于 TLSv1.0）、TLSv1.1 或模糊的 SSLv3 等表述
• TLS 1.3 自动忽略 ssl_ciphers 和该指令，所以它的安全性不依赖于此；但 TLS 1.2 协商仍需你严格把关

配置强且有序的 cipher list

ssl_prefer_server_ciphers on 的作用是让 Nginx 按你写的顺序选套件，而不是迁就客户端提出的弱选项。但如果列表里还混着 RC4、3DES、SHA1、CBC 类套件，它照样会选出来。

• 推荐只保留前向保密（PFS）+ AEAD 模式的组合，例如：
  ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
• 避免使用 HIGH、!aNULL:!MD5 这类宽泛表达——它们无法排除 SHA1 签名或非 PFS 套件
• 确保 3DES、DES、RC4、MD5、EXPORT、NULL、CBC-SHA 等已知风险套件完全不在列表中

确认服务器主导权真正生效

该指令只有在 server 块中与 ssl_ciphers、ssl_protocols 同时存在才起作用。常见失效场景包括：

• 在 http 块全局启用 ssl_prefer_server_ciphers on，却在某个 server 块漏配 ssl_ciphers → 该站点会回退到 OpenSSL 默认弱套件
• 多个域名共用一台 Nginx，但未为每个 server 块独立配置 cipher 策略 → 安全策略被最宽松的站点拖累
• 未验证实际协商结果：reload 后仅凭语法检查不够，要用工具确认真实握手行为

验证是否真正阻断降级路径

改完配置后，务必通过实测确认攻击面已被切断：

• 用 OpenSSL 测试 TLS 1.2 握手：
  openssl s_client -connect example.com:443 -tls1_2 | grep "Cipher is"
  输出应是你 ssl_ciphers 列表中最靠前的强套件（如 ECDHE-RSA-AES128-GCM-SHA256）
• 用 SSL Labs 的 SSL Server Test 全面扫描，重点关注 “Handshake Simulation” 中老旧客户端（如 Win7 IE11、Android 4.4.2）是否仍能协商出 TLS 1.0/CBC 套件
• 若扫描显示 “Weak key exchange” 或 “Weak cipher” 警告，说明某处配置未闭环，需回溯检查