摘要

  • HTTP/2 Rapid Reset 利用了流的快速创建与取消之间的成本不对称，使服务器在活动流数量看似有限时仍可能承担大量工作。
  • IETF 的规范讨论、厂商发布、发行版回移补丁、运营者配置和独立测量分别解决责任链上的不同环节；其中任何一环都不能单独证明风险已经关闭。

一个允许的行为如何变成系统性暴露

HTTP/2 的核心优势之一，是在一条连接上复用多个流。客户端可以创建流，也可以通过 RST_STREAM 帧取消流。RFC 9113 对这些帧与流状态作出规范化描述，但该规范早于 CVE-2023-44487 的公开披露，并未针对后来被称为 Rapid Reset 的攻击模式给出完整的事后缓解方案。协议规范

这一区别很重要。规范描述的是通信行为，不是某个厂商产品在特定版本中的安全结论。问题的关键机制在于，攻击者可以快速发起请求并立即取消对应流。Google、Cloudflare 和 Akamai 对这一模式的描述都指向同一个成本不对称：客户端发送取消信号的成本较低，而服务器可能已经为流创建、请求解析、调度和取消处理付出了更多资源。不同服务商的流量规模、检测方法和缓解效果只代表其自身网络观察，不能直接外推到整个互联网。Google Cloud Cloudflare Akamai

CVE-2023-44487 将这一问题标识为影响 HTTP/2 实现的拒绝服务条件。CVE 记录、NVD 条目和 CERT/CC 公告共同说明，反复快速重置流可能导致资源耗尽，并且影响范围跨越多个实现，而非某一个孤立产品。NVD CVE 记录 CERT/CC

因此，不能把“HTTP/2 允许 RST_STREAM”直接写成“HTTP/2 本身必然不安全”。更准确的判断是：一种规范允许的行为，在特定实现的资源管理方式、请求处理路径和防护边界组合下，形成了可被放大的服务端成本。漏洞名称指向的是这种组合后的安全后果，而不是简单地指向一个单独的协议字段。

披露不是修复，修复也不是部署

Rapid Reset 的公开披露把问题从单个运营者的异常流量提升为跨实现的协调修复事件。CERT/CC 的记录显示，协调披露连接了受影响厂商与缓解建议；Google 的公开说明则将协议机制、现实攻击活动与生态系统协同联系起来。CERT/CC Google Security Blog

但协调披露只证明问题进入了共同响应流程，并不证明每个受影响系统已经完成修复。它至少要经过四个不同层面：

  1. 检测与确认。 研究人员、服务商或运营者必须识别异常的流创建与重置模式，并确认其与资源消耗之间存在因果联系。
  2. 协调与审查。 受影响参与者需要比较实现差异、确定公开时间、评估缓解方法，并决定哪些问题适合进入协议层讨论。
  3. 实现与发布。 厂商和开源项目必须把修复或控制措施写入代码、配置和发行说明；下游发行版还可能通过回移补丁修复旧版本。
  4. 运营与验证。 运营者必须识别自己实际运行的产品、版本和封装方式，安装正确更新，启用适当控制，并通过监控或测试确认效果。

这四层的证据类型不同。一个 GitHub issue 可以证明工作组讨论过某个方案，却不能证明方案成为最终 RFC；一个版本说明可以证明某个发行版包含修复，却不能证明所有使用该版本的运营者已经升级；一次服务商观察可以证明该网络检测到攻击，却不能证明其他网络的剩余暴露比例。HTTPbis 草案 HTTP 工作组讨论

IETF 能控制什么，不能控制什么

HTTPbis 草案和工作组 issue 提供了重要的制度证据：公开披露之后，协议文本和可能的规范性响应进入了正式技术讨论。这个过程能够澄清哪些行为属于协议表面，哪些缓解属于实现选择，也能留下提案、分歧与取舍的记录。HTTPbis 草案 HTTP 工作组讨论

但 IETF 的协调权不是对所有部署系统的直接控制权。IETF 可以通过工作组程序、审查和发布机制形成技术规范；实现者决定如何把规范写成代码；厂商决定何时发布安全版本与公告；发行版维护者决定如何打包和回移补丁；运营者决定何时升级、如何配置，以及是否持续监测异常行为。

这正是 IETF-W3C 关系在本案中的现实边界：标准机构的合法性来自公开、可审查的技术协调，而不是来自对每个产品或网络的行政命令。把标准修订等同于全网修复，会掩盖真正掌握部署控制权的参与者；反过来，把未完成部署归咎于标准机构，也会把实现与运营责任错误地集中到规范制定者身上。

产品版本才是运营者面对的控制面

公开材料显示，补救状态必须在实现、产品、软件包和发布分支层面核对。Envoy 的版本历史说明了受影响版本线中的修复与配置变化；NGINX 的厂商材料按产品范围给出影响与缓解；Red Hat 的记录则说明，发行版可能通过回移补丁处理漏洞，因此表面上的上游主版本号并不一定足以判断是否已修复。Envoy NGINX Red Hat

这意味着“我们已经升级”不是一个充分的审计结论。可验证的记录至少应回答：运行的是哪一种 HTTP/2 实现；产品的完整版本与发行分支是什么；补丁来自上游、厂商还是操作系统发行版；配置是否启用了额外的并发、速率或重置控制；入口代理和源站是否使用不同实现；更新后是否有日志、指标或测试证明流量行为已经改变。

CERT/CC 明确提醒，推荐的通用限制不能被视为厂商补丁的等价物。限制并发流、请求速率或重置行为可能减少攻击面，但它们的名称、可用性和效果取决于具体实现。对某个边缘服务有效的控制，也不必然适用于直接暴露在互联网的源站。CERT/CC Akamai

“修复完成”需要什么证据

本案最重要的调查结论不是一个普遍的修复百分比，因为现有公共材料并不能建立这样的数字。CISA KEV 目录可用于确认某漏洞被列为已知在野利用，并帮助覆盖范围内的机构确定优先级；但目录收录不是互联网暴露率，也不能证明所有系统都受影响或所有系统都已修复。CISA KEV

同样，Google、Cloudflare 和 Akamai 报告的攻击规模与遥测具有明确的服务商范围。它们能证明攻击真实发生、检测信号具有运营价值以及缓解需要协作，却不能提供整个公共互联网的剩余风险普查。Google Cloud Cloudflare Google Security Blog

更可靠的闭环证据应当是分层的：

  • 规范层： 最终发布的协议文本或明确的规范性指导，而不是仍在讨论中的草案。
  • 实现层： 具体项目的提交、发布说明和测试结果，能够说明修复改变了什么行为。
  • 产品层： 厂商或发行版对确切产品、版本、分支和回移状态的说明。
  • 部署层： 运营者资产清单、更新记录、配置状态和入口到源站的覆盖范围。
  • 效果层： 独立测试、异常流量指标、事件记录和持续监控，能够显示控制措施在实际环境中发挥作用。

缺少其中一层，并不自动证明修复失败；但它会限定结论的强度。例如，有厂商补丁而没有部署记录，只能说“存在可用修复”；有部署记录而没有效果测量，只能说“完成了变更”；有单点测试而没有资产范围，则不能推出组织整体已经闭环。

责任链中的制度性风险

Rapid Reset 说明，互联网基础设施的安全责任并不沿着一条垂直命令链传递。标准文本影响实现，实现在产品中变成依赖，产品通过供应链进入运营网络，而网络中的控制措施又决定攻击者能否把协议行为放大成业务中断。

这种分布式结构有明显优点：技术审查可以由不同组织参与，修复可以在多个实现中并行推进，运营者也可以选择边缘防护、源站补丁或分层控制。但它也制造了可见性断点。标准机构通常看不到每个部署版本；厂商通常看不到客户是否升级；运营者通常无法仅凭协议名称判断下游组件是否已经回移修复；外部观察者则很难估算没有公开数据的剩余暴露。

对 IETF 而言，制度上的可问责性不应被定义为保证每个实现没有缺陷，而应包括：问题是否有可追踪的讨论路径，规范变化是否清楚区分强制要求与建议性控制，审查记录是否保留关键取舍，以及最终文本是否让实现者和运营者能够判断下一步行动。对厂商和运营者而言，问责性则更多体现为版本范围、补丁来源、部署覆盖与验证结果是否可审计。

结论：把“发布”与“关闭”分开记录

HTTP/2 Rapid Reset 的失败—修复路径表明，IETF 可以帮助把一个跨实现的失败信号转化为可审查的协议讨论和技术指导，但它不能替代实现发布、供应链维护、运营者升级或独立测量。CVE 记录了问题，协调披露组织了响应，工作组材料留下了规范层讨论，厂商和发行版材料说明了产品层补救；只有部署与效果证据，才能进一步回答暴露面是否真的收敛。

因此，组织在记录修复时应至少区分三种状态：规范已更新、产品已有修复、实际部署已验证。这三种状态可以同时成立，也可以彼此脱节。把它们压缩成一个“已修复”标签，会让董事会、运营者、监管者和受影响社区看不到最关键的不确定性：谁已经改变了什么，覆盖了哪些系统，还有哪些证据尚未出现。

截至现有公共证据，Rapid Reset 可以被确定为真实的跨实现拒绝服务风险，也可以被确定为一次包含协调披露、协议讨论和多厂商缓解的生态系统响应。但不能据此给出所有 HTTP/2 部署的剩余漏洞比例，也不能把任何单一版本说明当作全网关闭证明。真正耐久的修复，必须在责任链的每一段留下可核验记录。

来源：