要約

  • Rapid ResetはHTTP/2要求を開いて直ちに取り消し、同時実行枠を返却させながら、プロキシやバックエンドに開始済みの仕事を残した。
  • 永続的な防御はキャンセル機能の廃止ではない。接続全体の有用性と負荷を測り、共有キューが埋まる前に悪用接続を終了させることである。

ストリームは閉じても仕事は戻らない

HTTP/2は一つのトランスポート接続上で複数のストリームを多重化する。ブラウザは画像やスクリプトを並列に取得し、資源ごとにTCPとTLSをやり直さずに済む。サーバーはSETTINGS_MAX_CONCURRENT_STREAMSで、相手が同時に維持できるストリーム数を通知できる。

数えられるのはopenまたはhalf-closedのストリームである。RST_STREAMを受ければclosedとなり、同時実行枠から外れる。これは通常の利用にも不可欠だ。利用者が別ページへ移り、タイムアウトが来て、不要になった資源だけを取り消す際、接続全体まで壊す必要はない。

Rapid Resetは論理状態と資源状態の時間差を使った。攻撃者はHEADERSを送り、すぐにリセットする。状態機械は枠を空けるため、同じ接続は応答や往復時間を待たず次の要求を開ける。

受信側では、ストリーム構造の確保、ヘッダー伸長、顧客ポリシーの読込み、経路選択、上流サービスへのディスパッチが既に始まっている場合がある。リバースプロキシが取消しを認識しても、バックエンドのキューや実行中タスクが同時に消えるとは限らない。送信側は小さなフレームだけを払い、受信側が生成、転送、通知、破棄の費用を負った。

TLSの破壊でも、応答の偽造でも、常時同時実行上限を超える攻撃でもない。閉じた枠を高速に再利用したのである。Googleは、要求率が往復時間ではなく主に利用可能帯域に制約されるようになったと説明した。

三社のピークは別々に読む

Google、Cloudflare、AWSは2023年8月下旬に攻撃を検出し、HTTP/2実装者と調整して開示した。10月10日、CVE-2023-44487として公表された。

Googleのピークは毎秒3億9800万要求を超えた。Cloudflareは約2万台のボットから毎秒2億100万超を観測した。AWSは8月28日から29日にCloudFrontで毎秒1億5500万超の異常を報告した。

これは一つの共同測定ではなく、合計してはならない。各社のネットワーク、顧客面、計測方法は違う。証明されるのは手法の効率であって、全サーバーに最大値の吸収を要求する基準ではない。

Googleは最大の攻撃をエッジでほぼ止め、停止は生じなかったと述べた。Cloudflareは初期に全体の約1％が影響を受け、最も深刻な時間には一部データセンターで数秒間約12％に達したと公表した。結果の差は防御位置と構成を示す。

同時実行数は別のものを守っていた

同時実行上限が守るのは、ある瞬間に生きているストリームの在庫である。Rapid Resetが作ったのは、短命なストリームから成る高速な仕事の流れだ。各要求は一度数えられても、すぐ帳簿から消え、資源だけが後に残る。

したがって上限値を下げるだけでは止まらない。Cloudflareは対応中に最大値を64へ下げたが、多くの正当なクライアントがサーバーのSETTINGSを待たず100本を想定して送信することを発見した。超過分をサーバーがリセットすると、以前からのリセット回数防御がそのパターンを悪用と判断し、正常な接続まで閉じた。ページ全体が読み込めない例が生じ、値は100へ戻された。

重要なのは64か100かではない。局所的に安全に見える数値も、配備済みクライアントと組み合わせれば可用性を損なう。実用的な境界は、実際の分布で検証され、正常動作を保ちながら共有キューの前で増幅を止める値である。

判断の単位は接続になった

Googleは個別要求の遮断だけでは不十分とした。接続ごとの開設速度、取消し率、有用な応答、繰り返される違反を観察し、悪用なら制約付きGOAWAYまたは即時切断を行う。

クライアントは一つの応答を不要と伝える権利を保つ。しかし取消しで無限の仕事を作りながら接続の継続まで要求する権利はない。仕事の受入れと機械の予算は受信側が所有する。

Cloudflareはクライアント発のRST_STREAMを検出対象にし、フレーム処理、取消し伝達、キュー、スケジューリングを改善し、防御をTLSプロキシへ前倒しした。また一部502が通常の分析を生成する業務ロジックプロキシより前で生じていたため、接続単位の記録も強化した。ダッシュボードに出ない障害も障害である。

三社が同じ閾値を使う必要はない。共通する境界は、費用を負う実装が局所的に上限を持ち、敵対的仕事が共有サービスを奪う前に実行することだ。

標準が閉じたのは状態であり負債ではない

RFC 9113は多重化、同時実行、RST_STREAM、GOAWAYを定義する。共通状態機械が相互運用を可能にし、リセット後のストリームが数えられないことも明確にした。

しかし既に送られた仕事を巻き戻すことはできない。2023年の個人Internet-Draftはこの欠落を記録し、ストリーム作成に累積クレジットを提案した。有用な設計資料だが、採択済み標準でもIETFコンセンサスでもない。

Heng Luの最低限の初期仕様は役割を分ける。共通層はフレームと正当な取消しを守る。将来の資源判断は、費用を負う実行系に残す。複数の実装が稼働コードで安全な予算を証明し、経験が成熟した後に共通規則を検討できる。

パッチ済み一覧に必要な証拠

「HTTP/2有効」は露出評価ではなく、「CVE対応済み」も継続性の証明ではない。CDN、ロードバランサー、Ingress、サービスメッシュ、リバースプロキシ、アプリケーションサーバーの各終端と、最初に高価な状態を作る地点を特定する必要がある。

記録には正確な版、パッチの由来、接続予算、共有キュー、取消しが届く範囲を含める。試験は通常ページ、正当な取消し、敵対的な開設—リセットを混在させる。正常要求が進み、悪用接続が終わり、理由が計測に残ることが合格条件だ。

安全な更新がない場合、HTTP/2停止は緊急措置になり得る。ただし所有者、限定範囲、期限、復帰証明が必要だ。恒久化すれば、仕事会計の欠陥を直さなかった事実を隠す。

証拠の限界

公開記録は全対象、全実装、全損失を示さない。各社ピークは同一条件のベンチマークではない。大規模エッジの防御力を単独サーバーへ外挿できず、修正版の公開日を全配布先の導入日とも扱えない。

確実な結論は限定的である。プロトコル上の物体を閉じても、それが発生させた仕事は自動回収されない。形式的に正しい操作が資源悪用へ変わったとき、受信側には関係を終了する権限が必要だ。

情報源