HPACK头部压缩可能被用于侧信道攻击推断敏感信息，原理是攻击者通过构造试探性请求并观察响应头大小变化，利用动态字典匹配推断Cookie或Authorization等字段内容，已有CVE案例（如CVE-2016-6581）证实其真实风险。
开启 http2 指令后，Nginx 会启用 HPACK 头部压缩，这在提升传输效率的同时，也引入了真实存在的安全风险——不是理论隐患，而是已有 CVE 案例支撑的侧信道信息泄露可能。
HPACK 压缩如何被用于信息推断
HTTP/2 的头部压缩依赖动态字典缓存重复字段。攻击者可构造大量带试探性字符串的请求（如 Cookie: session=abc... + 变长填充），观察响应头大小或响应时间变化。当压缩率异常升高，说明试探字符串与服务端真实敏感字段（如 Cookie 值、Authorization token）出现高频匹配。这种原理类似 CRIME 攻击，在 TLS 层之上叠加了压缩层，形成新的旁路通道。
典型表现包括：
- 同一连接内，多个请求共享动态字典，导致本不该互通的上下文发生“压缩耦合”
- 服务端未对高敏感字段（如
Set-Cookie、Authorization）做压缩屏蔽，使其参与字典索引 - 客户端支持不一致（如旧版 nghttp2）导致 HPACK 解压实现存在边界处理缺陷
Nginx 层可落地的压缩防护配置
Nginx 本身不提供“禁用某字段压缩”的开关，但可通过间接方式降低风险面：
- 强制使用 TLS 1.3：消除 TLS 1.2 下的压缩+加密组合漏洞（如 BREACH 的变种利用）
- 设置
http2_max_field_size 4k（虽已废弃，但在 1.21.5 及更早版本仍生效）或统一改用large_client_header_buffers 4 8k，限制单个字段长度，削弱攻击者构造精准试探载荷的能力 - 避免在响应中回显用户可控输入到 Header（如自定义
X-Debug、X-Forwarded-For），防止其进入 HPACK 动态表 - 定期更新 Nginx 与 OpenSSL/nghttp2 库，修复已知 HPACK 实现问题（如 CVE-2021-3711、CVE-2023-44487 相关补丁）
不能只靠 Nginx 的原因
HPACK 是协议层机制，Nginx 仅负责解析解压后的明文头部。这意味着：
- 压缩过程发生在 TCP 连接建立后的帧级处理，Nginx 无法干预压缩逻辑本身
- 若后端应用（如 Node.js、Go HTTP/2 server）自行解析原始帧或复用连接上下文，可能绕过 Nginx 的缓冲限制
- 真实攻击链往往跨组件：前端 JS 控制请求节奏 + 中间 Nginx 解压 + 后端日志记录响应大小 → 形成完整反馈闭环
验证是否受控的有效方法
不依赖日志猜测，直接用可控请求验证防护效果：
- 发送两个结构相同但 Cookie 值仅差 1 字符的 HTTP/2 请求，用
nghttp -v观察HEADERS帧长度是否显著不同 - 用
curl --http2 -w "%{size_header}\n" -s -o /dev/null -H "X-Test: $(printf a%.0s {1..6000})" https://site/测试是否稳定返回 431，确认头部截断机制已就位 - 检查响应头中是否含
content-encoding: gzip与敏感 header 同时存在——这类组合会放大压缩侧信道风险，应禁止
