QUIC
HTTP3
アンプ攻撃

QUICの仕様におけるアンプ攻撃対策

HTTP over QUIC (HTTP/3) がUDPベースとなるニュースを見て、いわゆるAmplification攻撃(アンプ攻撃, 増幅攻撃などとも)について気になってる人もいるようなので、初心者ながら簡単に調べる。

なお、トランスポートプロトコルであるQUIC側の機能であり正確にはHTTP3で提供される対策機能ではない。

IETF版QUIC draft-16ベースの説明になります。

QUICについて

手前味噌ですが、前提となるQUICに関する資料は下記を参照

アンプ攻撃とは

そもそもアンプ攻撃とは、送信元アドレスを攻撃対象となる対象のIPに偽装したUDPパケットをサーバに送信することによって、サーバからの応答を攻撃対象のサーバに送信させる攻撃手法である。

特に、サーバに送信したデータ量よりもレスポンスのデータ量が大きくなる場合、攻撃対象に大量のトラフィックを生み出すことができ、攻撃対象者のサービスを妨害することができる(DDoS攻撃)。

このときのトラフィックの増幅率は攻撃手法によっては10倍~100倍のトラフィックを生み出します。

QUICにおけるアンプ攻撃対策

QUICでは届いたパケットが本当にそのIPを持つ相手から送信されているか確かめるAddress Validationという手順があります。これによって偽装されたIPアドレスに大量のトラフィックが流れることはありません。

前提として、最初のコネクション確立時など、サーバ側で届いたパケットの送信元IPが正しいか確証が得られてない段階では、クライアントは1200オクテット以上のパケットしか送信してはいけません(適宜パディングする)。

もしそうでないパケットに対してはサーバは応答しません。こうすることで増幅率が低く抑えられ、アンプ攻撃を緩和します。

Address Validation

コネクション確立時のAddress Validationは、送られて来たパケットの送信元IPアドレスに
サーバが返信し、それが確かにIPアドレスの所持者であるクライアントに届き、処理が続行されることを持ってして確認が行われます。

以下のどちらかによって確認が行われます

  • 暗号ハンドシェイクによって暗黙的に、そのパケットの送信元アドレスを持つ相手と通信できていることが確認されます。サーバからInitialパケットをクライアントがちゃんと受信できていることを確認できます。
  • クライアントからのInitialパケットに対して、Tokenを含むRetryパケットを送り返します。その後クライアントはそのTokenを持って再度ハンドシェイクを行います。これによって、Tokenが正しくクライアントに渡せたことが確認できます。

Path Validation

QUICではコネクションのマイグレーションする機能があります。QUICのコネクションはQUICレイヤで管理されているため、IPアドレスやポート番号が変わってもコネクションを維持することができます。
(ただし輻輳制御のウィンドウサイズ等は小さくなります)

IPアドレスやポートは様々な理由で変わります。キャリア回線からWi-Fi接続への移行に伴う、エンドポイントの意図的な変更や、NATリバインディングや中間装置によるエンドポイントの非意図的な変更などです。

このとき送信元IPアドレスが代わりうるわけですが、そのIPアドレスを攻撃対象者に設定できれば、トラフィックを偽装したIPアドレスに送信させることが来ます。しかし、QUICではコネクションのマイグレーション時にはお互いのインターフェースを含むそのパスの検証(Path Validation)を行い、送信元IPアドレスが偽装されていないことを確認します。

相手のIPアドレスが変わった(コネクションIDと鍵は正しい)場合、ランダムなデータを含むPATH_CHALLENGEフレームを送信し、同じデータを含むPATH_RESPONSEフレームがそのIPアドレスから帰ってきた場合、そのIPアドレスが正しい相手であることが確認できます。

この確認が済むまで新しいIPアドレスへのデータ送信量は制限されます。具体的に仕様で定義されている最小輻輳ウィンドウサイズです(kMinimumWindow)。

おわり

QUICは通信相手がIPアドレスの所持者であることを確認します。

確認できてない場合は、増幅できないようになっているか、サーバから生成するトラフィック量が制限されます。

そのためアンプ攻撃でQUICを使用するのは他のプロトコルより効率的ではないでしょう。