SSLCompression 必须关闭，不可权衡；它因CRIME攻击可被利用推断Cookie内容，无性能收益且引入确定性风险，现代环境已全面弃用。

SSLCompression 不是需要权衡的选项，而是必须关闭的安全配置项。它不提升传输效率，只引入可利用的确定性风险——CRIME 攻击能通过密文长度变化推断 Cookie 内容，现代环境已全面弃用该机制。

为什么 SSLCompression 必须关，而不是“权衡”

SSLCompression 是 TLS 1.0/1.1 中的压缩层（RFC 3749），在加密前对明文做 LZ77 压缩。但 CRIME 攻击（2012 年公开）证明：攻击者只需诱导浏览器发起带可控输入的 HTTPS 请求，再比对不同请求产生的密文长度，就能逐字还原出加密的 Cookie 或 Authorization 头。该漏洞无法修补，唯一缓解方式是禁用压缩本身。

• OpenSSL 1.0.0+ 默认禁用 TLS 压缩；Apache 2.4.8+ 默认不启用 SSLCompression
• 实测表明：开启 SSLCompression 对现代 Web 内容（HTML/JS/CSS 已经 gzip 压缩）几乎无带宽节省，反而增加 CPU 开销
• 所有主流浏览器（Chrome、Firefox、Safari）自 2013 年起拒绝协商 TLS 压缩

确认是否已启用 SSLCompression 的可靠方法

不要仅依赖配置文件搜索，运行时状态才真实反映生效行为：

• 执行 openssl s_client -connect your-domain.com:443 -tls1_2，查看输出中是否有 Compression: zlib 或类似字样；有即表示仍开启
• 检查 Apache 是否加载了 ssl_module：httpd -M | grep ssl
• 确认 OpenSSL 版本：openssl version；若低于 1.0.1，需先升级 OpenSSL，单靠配置无效

正确关闭 SSLCompression 的操作步骤

该指令仅允许出现在服务器级或虚拟主机级上下文，不能写在 .htaccess 中：

• 编辑主配置（如 /etc/apache2/mods-available/ssl.conf）或对应 <VirtualHost> 块，在 SSL 相关指令区域添加：SSLCompression off
• 若使用旧版 Apache（2.4.7 及更早），可在 SSLProtocol 行后追加 -COMPRESS，例如：SSLProtocol all -SSLv3 -TLSv1 -COMPRESS
• 重启前验证配置：apachectl configtest；成功后执行 systemctl reload apache2（或 service httpd reload）
• 再次用 openssl s_client 测试，确认输出中 Compression: 行完全消失

别把 mod_deflate 和 SSLCompression 搞混

mod_deflate 是 HTTP 层压缩（作用于响应体明文），与 TLS 压缩无关。但它在 HTTPS 站点上若配置不当，可能引发兼容性问题：

• 避免对含敏感头（如 Set-Cookie）的响应启用 deflate；可用 <LocationMatch "/(login|api|admin)"> SetOutputFilter NONE </LocationMatch> 排除关键路径
• 检查配置中是否无差别启用：AddOutputFilterByType DEFLATE text/html application/json —— 这类规则应配合条件判断，而非全局强制
• 用 curl -I https://yoursite.com 查看响应头，确认 Content-Encoding: gzip 出现在预期位置，且不与 Transfer-Encoding 冲突