如何通过 $ssl_cipher 审计识别生产环境中使用的不安全加密套件？

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

直接在Nginx日志中记录$ssl_cipher变量，是最轻量级、最实时的生产环境加密套件审核方式。它不依赖外部扫描工具，也不中断服务，能真实反映每个HTTPS请求实际使用的加密算法。

Nginx 日志中捕获实际协商套件

在 http 或 server 块中，定义一条包含 $ssl_cipher 的自定义日志格式：

log_format cipher_audit '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_user_agent" "$ssl_protocol/$ssl_cipher"';

然后在 access_log 指令中启用该格式：

access_log /var/log/nginx/ssl-cipher-audit.log cipher_audit;

重启或重载 Nginx 后，每次 HTTPS 请求都会在日志中留下类似这一行：

203.0.113.42 - - [01/May/2026:04:15:22 +0000] "GET /api/data HTTP/1.1" 200 1248 "Mozilla/5.0..." "TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256"

关键字段是末尾的 TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256 —— 这就是客户端与服务器最终握手选定的协议版本和加密套件。

快速识别不安全连接的筛查方法

从日志中提取并分析 $ssl_cipher 值，重点关注以下几类高风险标识：

• 出现 RC4、MD5、SHA1（在套件名末尾，如 SHA1、SHA）、DES、3DES、EXPORT、NULL、anon
• 协议为 SSLv3、TLSv1.0、TLSv1.1（日志中 $ssl_protocol 字段）
• 套件不含 ECDHE 或 DHE（即无前向保密），例如 RSA-AES128-SHA
• 使用 CBC 模式但无足够防护（如未启用 TLS_FALLBACK_SCSV 或未禁用弱填充）

可用一条 shell 命令快速汇总风险套件：

awk '{print $13}' /var/log/nginx/ssl-cipher-audit.log | \ grep -E '(RC4|MD5|SHA1|DES|3DES|SSLv3|TLSv1.[01]|RSA-AES|CBC.*SHA1)' | \ sort | uniq -c | sort -nr

输出示例：

47 TLSv1.0/RSA-AES128-SHA 12 TLSv1.1/ECDHE-RSA-RC4-SHA 3 SSLv3/DES-CBC3-SHA

这些就是亟需定位并推动客户端升级或服务端策略收紧的具体连接。

配合 ssl_ciphers 配置做闭环验证

日志中出现的套件，必须全部落在你 ssl_ciphers 指令显式声明的范围内。如果发现日志里有 ECDHE-RSA-CHACHA20-POLY1305，但你的 ssl_ciphers 里没写它，说明配置未生效（常见原因：ssl_protocols 未启用 TLSv1.2+、ssl_prefer_server_ciphers off 且客户端优先级更高、OpenSSL 版本太旧不支持该套件）。

建议将 ssl_ciphers 设为明确白名单（如 Mozilla Intermediate 配置），再用日志反查是否真正在用——不是“支持哪些”，而是“正在用哪些”。这才是真实的风险面。

不复杂但容易忽略