SSLCompression 是 TLS 早期压缩机制，因 CRIME 攻击可窃取 Cookie，必须关闭；它无实际性能收益，只引入确定性风险，现代环境默认禁用，Apache 应显式配置 SSLCompression off。
SSLCompression 是什么，为什么必须关
SSLCompression 是 TLS 协议早期支持的压缩机制（RFC 3749），它会在加密前对应用层数据做 LZ77 压缩，本意是节省带宽。但 CRIME 攻击（2012 年公开）证明：攻击者可利用压缩率差异，通过观察密文长度推测加密 Cookie 中的字符，从而窃取会话凭证。现代浏览器和 OpenSSL 自 1.0.0 版本起默认禁用该功能，但 Apache 的旧配置或手动启用仍可能打开它。
关键结论：必须关闭 SSLCompression，不存在“权衡”余地——它不带来实际性能收益，只引入确定性风险。
如何确认 Apache 是否启用了 SSLCompression
直接检查运行时状态比翻配置更可靠，因为模块加载、SSLEngine 开关、虚拟主机继承都可能影响最终行为：
- 执行
openssl s_client -connect your-domain.com:443 -tls1_2，查看输出中是否含Compression: zlib或类似字样（有即为开启） - 在 Apache 配置中全局搜索
SSLCompression、Deflate、mod_deflate与 SSL 段的混用（常见误配） - 检查
httpd -M | grep ssl确认ssl_module已加载，再查openssl version—— 若低于1.0.1，需升级 OpenSSL 而非仅调配置
正确关闭 SSLCompression 的三步操作
Apache 2.4.8+ 默认已禁用，但显式关闭更稳妥。注意：该指令只能出现在服务器级或虚拟主机级上下文，不能放在 .htaccess 中：
- 在主配置（如
/etc/apache2/mods-available/ssl.conf）或对应<virtualhost></virtualhost>块内添加：SSLCompression off
- 若使用的是旧版 Apache（SSLProtocol 后追加
-COMPRESS（如SSLProtocol all -SSLv3 -TLSv1 -COMPRESS） - 重启服务后验证：
apachectl configtest && systemctl reload apache2，再用openssl s_client复测，确认输出中Compression:行消失
别把 mod_deflate 和 SSLCompression 搞混
mod_deflate 是 HTTP 层压缩（作用于响应体明文），与 TLS 压缩完全无关。但它若在 HTTPS 站点上错误启用，可能引发 Content-Encoding 与 Transfer-Encoding 冲突，导致某些客户端解析异常。安全做法是：
- HTTPS 站点上，禁用
mod_deflate对敏感路径（如/login、/api）的压缩，或至少排除Set-Cookie响应头 - 检查配置中是否有类似
SetOutputFilter DEFLATE无条件应用到所有application/json或text/html的规则 - 用
curl -I https://yoursite.com查看响应头是否含Content-Encoding: gzip—— 若有，确认该压缩未覆盖含敏感 Cookie 的响应
真正需要权衡的从来不是 SSLCompression（它只该关），而是 HTTP 层压缩策略与敏感数据边界的对齐。这点常被忽略，却直接影响 CRIME 类攻击的实际利用面。
