如何设置ssl_ciphers以排除弱加密算法，确保Web服务符合国家等级保护合规性要求？
- 内容介绍
- 文章标签
- 相关推荐
本文共计966个文字，预计阅读时间需要4分钟。
为了使Nginx的ssl_ciphers配置满足国家等保三级要求，核心是仅保留支持前向保密（PFS）和认证加密（AEAD）的强加密套件，并排除所有已知不安全的算法。以下是一个具体的配置示例：
必须禁用的弱算法类型
以下关键词一旦出现在 ssl_ciphers 字符串中，即判定为不合规，需全部清除：
-
RC4（如
RC4-SHA、RC4-MD5）——易受 Bar Mitzvah 攻击，等保明令禁止 -
3DES 和 DES（如
ECDHE-RSA-3DES-EDE-CBC-SHA、DES-CBC-SHA）——存在 Sweet32 等碰撞风险，密钥长度不足 -
MD5 或 SHA1 哈希类套件（如含
-MD5的全部套件；-SHA虽未明文禁用，但ECDHE-RSA-AES128-SHA中的 SHA1 已属淘汰，应避免 -
EXPORT 级套件（如
EXP-EDH-RSA-DES-CBC-SHA）——密钥强度低于 40 位，法律层面不可接受 -
NULL、ANONYMOUS、PSK、STATIC RSA 类套件（如
RSA-AES256-SHA）——不支持前向保密，会话密钥可被长期解密 - CAMELLIA、SEED、IDEA 等非国标/非主流算法——缺乏充分审计，等保测评不认可
推荐的合规 ssl_ciphers 配置
以下配置已通过等保三级基线验证，兼顾安全性与主流终端兼容性（Chrome/Firefox/Edge/Safari 最新版，Android 7+、iOS 11+）：
ssl_protocols TLSv1.2 TLSv1.3; 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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers on;
说明：
- TLS 1.3 套件由协议自动协商，无需也不应写入
ssl_ciphers字符串 - 全部套件均基于
ECDHE或DHE，确保每次握手生成临时密钥，实现前向保密 - 加密部分统一使用
AES-GCM或CHACHA20-POLY1305，满足 AEAD 认证加密强制要求 - 未包含任何静态密钥交换（如 RSA 密钥传输）、无哈希降级、无 CBC 模式
配套必须启用的安全机制
仅改 ssl_ciphers 不足以过等保，需同步落实以下基础加固：
-
禁用低版本协议：确认
ssl_protocols仅保留TLSv1.2 TLSv1.3，彻底关闭 SSLv3、TLSv1.0、TLSv1.1 -
强化密钥交换参数：生成并加载 2048 位以上 DH 参数（推荐 2048 或 3072），避免 Logjam 类降级攻击：
ssl_dhparam /etc/nginx/dhparam.pem; -
启用 HSTS 强制 HTTPS：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; -
隐藏服务标识：
server_tokens off;防止泄露 Nginx 版本信息
验证是否真正生效
配置 reload 后，必须实测确认弱算法已被清除，不能依赖主观判断：
- 用
nmap --script ssl-enum-ciphers -p 443 yourdomain.com扫描，输出中不得出现 RC4、3DES、MD5、EXPORT、NULL、ANONYMOUS 等字样 - 在 SSL Labs SSL Test 提交检测，评级至少为 A，且 “Handshake Simulation” 中所有现代客户端（Chrome 120+、Safari 17+ 等）均协商到 GCM 或 CHACHA20 套件
- 检查 Nginx error.log，确认无
no suitable key exchange algorithm或no ciphers报错 - 人工测试旧客户端（如 Windows XP + IE8）应直接失败，而非降级到弱套件——这是等保“不妥协”的关键体现
本文共计966个文字，预计阅读时间需要4分钟。
为了使Nginx的ssl_ciphers配置满足国家等保三级要求，核心是仅保留支持前向保密（PFS）和认证加密（AEAD）的强加密套件，并排除所有已知不安全的算法。以下是一个具体的配置示例：
必须禁用的弱算法类型
以下关键词一旦出现在 ssl_ciphers 字符串中，即判定为不合规，需全部清除：
-
RC4（如
RC4-SHA、RC4-MD5）——易受 Bar Mitzvah 攻击，等保明令禁止 -
3DES 和 DES（如
ECDHE-RSA-3DES-EDE-CBC-SHA、DES-CBC-SHA）——存在 Sweet32 等碰撞风险，密钥长度不足 -
MD5 或 SHA1 哈希类套件（如含
-MD5的全部套件；-SHA虽未明文禁用，但ECDHE-RSA-AES128-SHA中的 SHA1 已属淘汰，应避免 -
EXPORT 级套件（如
EXP-EDH-RSA-DES-CBC-SHA）——密钥强度低于 40 位，法律层面不可接受 -
NULL、ANONYMOUS、PSK、STATIC RSA 类套件（如
RSA-AES256-SHA）——不支持前向保密，会话密钥可被长期解密 - CAMELLIA、SEED、IDEA 等非国标/非主流算法——缺乏充分审计，等保测评不认可
推荐的合规 ssl_ciphers 配置
以下配置已通过等保三级基线验证，兼顾安全性与主流终端兼容性（Chrome/Firefox/Edge/Safari 最新版，Android 7+、iOS 11+）：
ssl_protocols TLSv1.2 TLSv1.3; 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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'; ssl_prefer_server_ciphers on;
说明：
- TLS 1.3 套件由协议自动协商，无需也不应写入
ssl_ciphers字符串 - 全部套件均基于
ECDHE或DHE，确保每次握手生成临时密钥，实现前向保密 - 加密部分统一使用
AES-GCM或CHACHA20-POLY1305，满足 AEAD 认证加密强制要求 - 未包含任何静态密钥交换（如 RSA 密钥传输）、无哈希降级、无 CBC 模式
配套必须启用的安全机制
仅改 ssl_ciphers 不足以过等保，需同步落实以下基础加固：
-
禁用低版本协议：确认
ssl_protocols仅保留TLSv1.2 TLSv1.3，彻底关闭 SSLv3、TLSv1.0、TLSv1.1 -
强化密钥交换参数：生成并加载 2048 位以上 DH 参数（推荐 2048 或 3072），避免 Logjam 类降级攻击：
ssl_dhparam /etc/nginx/dhparam.pem; -
启用 HSTS 强制 HTTPS：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; -
隐藏服务标识：
server_tokens off;防止泄露 Nginx 版本信息
验证是否真正生效
配置 reload 后，必须实测确认弱算法已被清除，不能依赖主观判断：
- 用
nmap --script ssl-enum-ciphers -p 443 yourdomain.com扫描，输出中不得出现 RC4、3DES、MD5、EXPORT、NULL、ANONYMOUS 等字样 - 在 SSL Labs SSL Test 提交检测，评级至少为 A，且 “Handshake Simulation” 中所有现代客户端（Chrome 120+、Safari 17+ 等）均协商到 GCM 或 CHACHA20 套件
- 检查 Nginx error.log，确认无
no suitable key exchange algorithm或no ciphers报错 - 人工测试旧客户端（如 Windows XP + IE8）应直接失败，而非降级到弱套件——这是等保“不妥协”的关键体现