HTTP/3服务器遭遇Qpack放大攻击：新威胁解析

引言

Hacker News上近期出现了一篇关于Qpack放大攻击的讨论，标题为“Qpack amplification attacks against HTTP/3 servers”。该帖子获得了11个点数，虽然评论不多，但揭示了一个针对新兴HTTP/3协议的安全威胁。

HTTP/3作为基于QUIC的新一代HTTP协议，旨在提升速度和安全性，但Qpack（QPACK）作为其头部压缩机制，可能被滥用于放大攻击。本文将深入分析这一攻击向量，探讨其原理、潜在影响及防御策略。

什么是Qpack？

QPACK是HTTP/3中用于头部压缩的算法，类似于HTTP/2的HPACK。它通过维护动态表和静态表来减少头部大小，从而提高传输效率。然而，QPACK的设计允许服务器和客户端动态更新表，这为攻击者提供了可乘之机。

攻击者可能利用QPACK的头部压缩特性，构造恶意请求，导致服务器响应被放大，从而消耗大量带宽和资源。这种放大攻击类似于DNS放大攻击，但针对的是HTTP/3服务器。

HPACK 与 QPACK 的关键差异

HPACK 是 HTTP/2 的头部压缩方案，运行在可靠的 TCP 连接上，头部块严格按序到达，因此可以使用单一的动态表并依赖有序性。QPACK 则运行在 QUIC 之上，而 QUIC 的多个流可能乱序到达，若直接沿用 HPACK 会造成队头阻塞。为此 QPACK 引入了"编码器流"与"解码器流"两条单向控制流，用绝对索引和相对索引区分对动态表的引用，并通过"已知接收计数"（Known Received Count）等机制协调表状态。

这一设计带来一个安全相关的副作用：动态表的容量由 SETTINGS 参数协商，两端都必须为表预留内存；当引用尚未被确认时，编码方还需限制"被阻塞流"的数量。攻击者正是可能利用这些上限未收紧的窗口，诱导对端在解码阶段做大量工作或维持过大的表状态。理解 QPACK 与 HPACK 在流控和状态同步上的差异，是判断放大攻击可行性的前提。

Qpack放大攻击的原理

放大攻击的核心在于攻击者发送小请求，触发服务器产生大响应。在QPACK场景中，攻击者可能通过操纵头部压缩表，迫使服务器在响应中包含大量头部信息，或者利用动态表的更新机制，导致响应膨胀。

具体而言，攻击者可以发送精心构造的请求，使得服务器在解码头部时消耗过多资源，或者响应中包含冗余的头部字段。由于HTTP/3基于UDP，攻击者还可以伪造源IP地址，将放大后的流量引向受害者。

UDP 反射放大与源地址伪造

放大攻击（amplification attack）通常包含两个要素：一是响应体积显著大于请求体积的"放大系数"，二是源地址可伪造，使响应被反射到第三方受害者。DNS、NTP、Memcached 等 UDP 协议上都出现过经典案例，放大系数可达数十倍甚至数万倍。

QUIC 虽然基于 UDP，但其握手阶段包含源地址验证机制（如 Retry 包与地址验证令牌），理论上能缓解纯反射型滥用。然而，一旦连接建立完成，攻击者若已持有有效连接，就可以在同一连接内反复触发高开销响应；而在连接尚未完全验证的窗口，若服务端实现允许携带较大头部块的 Initial 或 0-RTT 数据，仍可能形成有限的放大面。因此评估 QPACK 放大攻击时，关键在于确认服务端是否在地址验证完成前就处理了重量级的头部解码与响应构造。

潜在影响与风险

HTTP/3服务器如果未对QPACK头部大小进行限制，可能面临严重的放大攻击风险。攻击者可以轻易利用这一漏洞，发起分布式拒绝服务（DDoS）攻击，导致服务不可用。

此外，由于HTTP/3的部署日益广泛，尤其是大型互联网公司已开始采用，这种攻击的潜在影响范围较大。安全研究人员需要关注QPACK的实现细节，确保服务器能够抵御此类攻击。

防御措施与建议

为了缓解Qpack放大攻击，服务器实现应采取以下措施：

• 限制头部字段的大小和数量，避免响应膨胀。
• 对动态表的大小进行严格限制，防止攻击者滥用。
• 实施速率限制和连接数控制，减少攻击面。
• 监控异常流量模式，及时发现放大攻击行为。

此外，开发者和运维团队应关注HTTP/3协议的安全更新，及时应用补丁。

结论

Qpack放大攻击是针对HTTP/3服务器的一种新兴威胁，虽然目前讨论热度不高，但其潜在风险不容忽视。随着HTTP/3的普及，安全社区需要持续关注此类攻击向量，并采取有效的防御措施。

对于企业和开发者而言，理解QPACK的工作原理并实施严格的安全配置，是确保HTTP/3部署安全的关键。