SSLCompression必须关闭，因其不节省带宽且必然引入CRIME攻击风险；它是TLS 1.0/1.1中加密前的LZ77压缩机制，现代环境已默认禁用，手动启用会打开确定性安全漏洞。
SSLCompression 必须关闭，不存在带宽与安全的“平衡”——它不节省带宽，只增加被 CRIME 攻击的风险。
为什么 SSLCompression 不能开
SSLCompression 是 TLS 1.0/1.1 中可选的加密前压缩机制（RFC 3749），用 LZ77 压缩明文再加密。但 CRIME 攻击（2012 年公开）利用压缩率变化+密文长度差异，能逐步还原 Cookie 等敏感内容。现代 OpenSSL（≥1.0.0）、主流浏览器和 Apache 2.4.8+ 已默认禁用，但它若被手动启用，就会打开确定性攻击面。
- 实测中几乎从未观察到开启后有可测量的带宽下降（尤其在 HTTPS 下，TLS 层压缩对已压缩资源如 JPEG、gzip 响应体无效）
- 它与 HTTP 层的 mod_deflate 完全无关——后者压缩的是明文响应体，是安全且推荐的
- Qualys SSL Labs 等评测工具将开启 SSLCompression 直接判为“A-”或更低，并标记“CRIME vulnerability”
如何确认并彻底关闭 SSLCompression
别只看配置文件，运行时状态才真实。三步验证+关闭：
- 执行
openssl s_client -connect your-domain.com:443 -tls1_2 2>/dev/null | grep Compression，若输出含Compression: zlib或类似字样，说明已启用 - 在 Apache 主配置（如
/etc/apache2/mods-available/ssl.conf）或对应<VirtualHost>块内添加：SSLCompression off
注意：该指令仅允许出现在服务器级或虚拟主机级，.htaccess中无效 - 重启服务后复测：
apachectl configtest && systemctl reload apache2，再运行上面的 openssl 命令，确认Compression:行消失
别把 mod_deflate 和 SSLCompression 搞混
mod_deflate 是 HTTP 层压缩（作用于响应正文明文），对带宽优化有效，但需谨慎使用：
- HTTPS 站点上，避免对含
Set-Cookie的响应启用 gzip（例如登录页、API 接口），以防潜在的 BREACH 变种风险 - 检查配置中是否无差别启用：
AddOutputFilterByType DEFLATE text/html application/json——建议排除敏感路径或响应头 - 用
curl -I https://yoursite.com/login查看是否有Content-Encoding: gzip，如有，确认该压缩不覆盖含 Cookie 的响应
配套必须做的安全加固
单关 SSLCompression 不够，还需同步收紧 TLS 基础策略：
- 禁用老旧协议：
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 - 强制服务端套件排序：
SSLHonorCipherOrder on - 限定高强度套件：
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 - 启用 HSTS：
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
