如何通过限制 ssl_ciphers 彻底禁用含有 3DES:RC4 及 MD5 的过载高危弱加密算法

关键在于白名单式精确控制，即仅保留ECDHE-ECDSA/RSA-AES128/256-GCM-SHA256/384、CHACHA20-POLY1305等PFS+AEAD强套件，禁用3DES、RC4、MD5；配合ssl_protocols TLSv1.2 TLSv1.3和ssl_prefer_server_ciphers off等指令，在TLS握手阶段主动拒绝弱算法协商。

要真正禁用 3DES、RC4 和 MD5 这类高危弱加密算法，关键不是“删掉几个名字”，而是通过 ssl_ciphers 配置实现**白名单式精确控制**——只保留现代强套件，从源头排除所有含这些算法的协商可能。

只保留支持前向保密（PFS）和 AEAD 的强套件

3DES、RC4、MD5 均属于已被标准弃用的算法，Nginx 不会主动过滤它们，除非你明确不列出来。推荐直接使用以下显式白名单（兼容 TLSv1.2，TLSv1.3 自动启用更强默认）：

• 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

这些套件全部满足：ECDHE 密钥交换（保障前向保密）、AES-GCM 或 ChaCha20-Poly1305（AEAD 认证加密）、SHA256/SHA384（安全哈希），且不含任何 3DES、RC4、MD5 字样。

严格配合 ssl_protocols 和其他关键指令

单设 ssl_ciphers 不够，必须协同收紧协议层与协商逻辑：

• ssl_protocols TLSv1.2 TLSv1.3; —— 彻底禁用 TLSv1.0/v1.1 及更早协议（它们天然允许弱套件）
• ssl_prefer_server_ciphers off; —— 现代客户端协商更可靠；设为 on 反而可能干扰 TLSv1.3 协商
• ssl_ecdh_curve secp384r1:secp521r1; —— 避免使用弱椭圆曲线（如 sect163k1）
• ssl_dhparam /etc/nginx/dhparam.pem; —— 若启用 DHE，需提供 ≥3072 位 DH 参数

验证是否真已清除，别信配置文件写了什么

配置重启后，必须实测服务器实际对外暴露的套件：

• 运行 nmap --script ssl-enum-ciphers -p 443 your-domain.com，确认输出中无 3DES、RC4、MD5、SHA（非 SHA256/SHA384）等关键词，且无标记为 weak 或 broken 的条目
• 用 openssl s_client -connect your-domain.com:443 -cipher "3DES" -tls1_2 测试，应返回 handshake failed 或 no ciphers available
• 浏览器打开 DevTools → Security 标签页，查看 Cipher Suite，应显示类似 TLS_AES_128_GCM_SHA256（TLSv1.3）或 ECDHE-RSA-AES128-GCM-SHA256（TLSv1.2）

常见误操作与规避建议

很多团队改完仍被扫描报高危，问题常出在细节：

• 避免用 HIGH:!RC4:!3DES 类模糊写法——HIGH 在不同 OpenSSL 版本含义不同，无法保证清除干净
• 不要混用宏与具体套件，例如 HIGH:ECDHE-RSA-AES128-GCM-SHA256:!RC4 可能因解析顺序意外保留弱套件
• 切勿留空 ssl_ciphers 或设为 DEFAULT——旧版 Nginx 默认含 RC4/3DES，新版虽改进但仍建议显式声明
• 注意 -SHA 默认指 SHA1，ECDHE-RSA-AES128-SHA 就是违规项；只有 -SHA256 或 -SHA384 才合规