mod_log_config仅能记录TLS握手成功后的会话级信息,如%{SSL_PROTOCOL}x、%{SSL_CIPHER}x等;无法记录ClientHello、失败原因或独立密钥交换算法,需用tcpdump、OpenSSL调试或TLS代理实现完整审计。

Apache 的 mod_log_config 本身不能直接记录密钥交换算法(如 ECDHE、RSA、DHE),也不能在握手失败时记录 TLS 版本;它只能在 TLS 握手成功、HTTP 请求进入处理流程后,记录 OpenSSL 提供的会话级变量。因此,“记录特定 TLS 版本”是可行的,但“记录密钥交换算法”不可行——该信息不在 OpenSSL 暴露给 Apache 的日志变量范围内。
能记录的 TLS 版本相关字段
启用 mod_ssl 后,可在 LogFormat 中使用以下 %{}x 变量:
-
%{SSL_PROTOCOL}x:实际协商成功的协议版本,例如
TLSv1.2或TLSv1.3 -
%{SSL_CIPHER}x:完整密码套件名称,例如
ECDHE-ECDSA-AES256-GCM-SHA384(注意:这里包含密钥交换部分的名称,但只是字符串拼接结果,并非独立可解析的“密钥交换算法”字段) -
%{SSL_CIPHER_USEKEYSIZE}x:对称加密密钥有效位数(如
256),间接反映强度
配置示例:在访问日志中分离 TLS 版本与密码套件
编辑 Apache 配置(如 /etc/httpd/conf.d/ssl.conf),添加或修改日志格式:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x" ssl_combined然后在虚拟主机中启用:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
CustomLog logs/ssl_access.log ssl_combined
重启服务后,日志行类似:
192.168.1.100 - - [27/Apr/2026:21:30:15 +0000] "GET / HTTP/1.1" 200 1234 "-" "curl/8.10.1" TLSv1.3 TLS_AES_256_GCM_SHA384
为什么无法可靠记录密钥交换算法
OpenSSL 不向 Apache 提供独立的密钥交换算法变量(如 %{SSL_KEX}x)。虽然 %{SSL_CIPHER}x 字符串中包含 ECDHE 或 DHE 等前缀,但它:
- 在 TLS 1.3 中已无实际意义(密钥交换机制被重构,不再体现在密码套件名中)
- 不是结构化字段,无法用于条件日志或自动化解析
- 若客户端降级到 TLS 1.2,同一套件名可能对应不同实现细节
如需审计密钥交换或原始握手过程,应换用其他工具
mod_log_config 不适合深度 TLS 审计。替代方案包括:
-
tcpdump + tshark:捕获 ClientHello,提取
tls.handshake.type==1和tls.handshake.extensions_server_name - OpenSSL s_client -debug:人工调试连接,查看完整握手交互
- TLS 代理工具(如 mitmproxy、sslproxy):解密并记录完整握手事件(需部署中间证书)
-
Apache 的 SSLStrictSNIVHostCheck + 自定义 error log:配合
ErrorLogFormat记录握手失败原因(如不支持的协议),但仅限错误上下文










