TLS 压缩与 CRIME 风险
TLS 层压缩（DEFLATE）会因压缩率随明文变化而泄露信息，CRIME 类攻击正是通过观察压缩后的长度推断出令牌等内容。TLS 1.3 已移除压缩，TLS 1.2 也应保持禁用。要注意 HTTP 层的 gzip 与 brotli 属于另一个层面的压缩，同样可能引出 BREACH 类问题，两者的排查不能互相替代。
基本信息
| 现状 | TLS 1.3 不提供压缩；主流服务端默认不启用 TLS 压缩 |
|---|---|
| 历史 | TLS 1.0 与 1.1 时代存在压缩扩展，因 CRIME 被广泛关闭 |
| HTTP 层 | gzip 与 brotli 仍可能引发 BREACH 类问题，属于不同层面 |
| 缓解思路 | 含敏感反射内容的响应避免压缩，或做随机化处理 |
| 验证方式 | 用 s_client 观察 Compression 字段 |
典型使用场景
- 安全测评中确认 TLS 压缩已关闭
- 排查 BREACH 类风险：响应压缩与反射内容同时存在
- 评估为性能开启压缩的收益与风险
- 检查老服务端配置模板是否仍保留压缩选项
- 分析抓包中出现的压缩相关扩展
检查两个层面的压缩
检查两个层面的压缩
# TLS 层（TLS 1.2 及以下）
openssl s_client -connect example.com:443 -tls1_2 </dev/null 2>&1 | grep -i 'Compression'
# HTTP 层压缩
curl -sI -H 'Accept-Encoding: gzip' https://example.com/ | grep -i 'content-encoding'
# 同一次响应里同时观察两者的组合情况两类压缩对比
| 层面 | 机制 | 风险 |
|---|---|---|
| TLS 压缩 | 握手协商的压缩扩展 | CRIME 类攻击 |
| HTTP 压缩 | gzip 或 brotli 编码 | BREACH 类攻击 |
| 触发前提 | 明文可被攻击者部分控制 | 需存在反射内容与敏感信息 |
| 缓解方向 | 关闭压缩 | 分级处理与随机化 |
排查 BREACH 类风险时关注三点：响应是否压缩、是否包含攻击者可注入并反射的内容、是否包含 CSRF 令牌等敏感片段。三者同时具备才构成可利用链路，缓解措施可以按这个前提逐项处理，而不必全局关闭压缩。
补充：压缩策略可以按响应内容分级——静态资源照常压缩，包含令牌或用户输入反射的动态页面关闭压缩。这种分级做法在多数业务上能兼顾带宽与风险，但前提是先明确哪些路径属于敏感响应，并把清单维护起来。