要約

  • TLS 1.3の0-RTTは再開接続の遅延を減らせるが、受理されたEarly Dataが攻撃者に再送されることを本質的には防がない。
  • 説明可能な制御には、トランスポートの受理を、要求の意味、アプリケーションの冪等性、現在の認可、実際に確定した副作用へ結び付ける証跡が必要である。

既知のクライアントがTLSセッションを再開し、振込命令をEarly Dataとして送れる決済サービスを考える。あるエッジは新しいハンドシェイクが終わる前に要求を復号して転送する。同じ再開チケットを受理できる時間枠のうちに、リプレイされたコピーが別のエッジへ届く。どちらも「有効なEarly Data」を記録し、台帳には二つの命令が入る。トランスポートは約束どおりに働いた。アプリケーションが、存在しない約束まで読み込んだのである。

1往復を省いても、安全境界は残る

RFC 8446は、事前共有鍵で接続を再開するクライアントが、新たなハンドシェイクの完了前に0-RTTアプリケーションデータを送ることを認めている。繰り返しても害のない読み出しや、応答時間が重要な処理には明確な価値がある。

一方で安全上の境界も明記されている。TLSは0-RTTデータに固有のリプレイ防止を提供しない。最初のフライトを記録した攻撃者は、ClientHelloと対応するデータを再送できる。サーバーは再開コンテキストを正しく認証し、バイト列を復号できる場合がある。したがって暗号学的な受理が証明するのは、データが受理可能なEarly Dataコンテキストに合致したことまでであり、一意の配送や一度だけの実行ではない。

監視画面はこの差を隠しやすい。有効なチケット、0-RTT受理、成功応答がすべて緑でも、同じ命令が別プロセス、別リージョン、再試行経路に届いたかは分からない。成功したTLSイベントは、「業務結果が正確に一度だけ生じた」という主張よりはるかに狭い。

アンチリプレイは運用システムであり、チェック項目ではない

RFC 8446は、使い切りチケット、ClientHelloの記録、チケット年齢と観測時刻による鮮度確認など、露出を抑える方法を説明する。どれにも運用上の依存関係がある。使い切り判断は失われず、複数拠点で食い違ってはならない。ClientHelloの記録には容量を制御した可用なデータベースが要る。鮮度確認は時計、許容差、残存リスク時間の選択に依存する。

分散エッジでは、局所判断は全体の証明にならない。二つの拠点が共通の使い切り判断なしに同じ再開材料を受理できるなら、一方の「未観測」は全サービスの未観測を意味しない。アンチリプレイ状態が失われたときも可用性を優先して受理するなら、実行可能な面を広げたことになる。その判断自体は合理的でも、単なる「0-RTT受理」というラベルの陰に隠してはならない。

Early Dataを拒否しても、アプリケーションの責任は消えない。クライアントはハンドシェイク後に再送する可能性がある。拒否が見える前に最初の要求がアプリケーション境界を越えていれば、自動再試行が副作用を重ね得る。証跡は受理、拒否、転送、再試行、最終確定まで追跡する必要がある。

HTTPは欠けているアプリケーション判断を表面化する

RFC 8470はHTTPでEarly Dataを扱う際の、クライアント、中継、オリジンサーバーそれぞれの責任を示す。クライアントは安全でない操作を安易にEarly Dataへ入れるべきではない。中継は要求が早期に届いたという情報を保持する必要がある。処理リスクを負いたくないサーバーは425 Too Earlyを返し、通常のハンドシェイク後に再試行させられる。

このステータスは制御の引き渡しであり、受理した要求がすべて無害だという宣言ではない。メソッド名だけでも足りない。見かけ上安全な読み出しが課金、希少枠の消費、監査記録を生む場合がある。名目上冪等な書き込みも、キーが欠けていたりリージョンごとにスコープが違ったりすれば冪等ではない。リプレイ安全性は、現在の状態で実装された操作の性質で決まる。

QUICでも同じ境界が実行経路になる。RFC 9001はTLSのEarly DataをQUICへ組み込み、サーバーが0-RTTを拒否できること、クライアントがその結果を処理する必要があることを定める。そこで生じる再送は、アプリケーション実行グラフの一部である。受理したQUICパケットだけ数えても、業務命令が一度だけ適用されたとは証明できない。

Early Dataの判定記録を残す

長期に検証できる証拠は、Early Dataの判定記録である。再開チケットのフィンガープリントと発行後の経過時間、ClientHelloまたはハンドシェイク参照、受理エッジ、アンチリプレイ方式、適用されたリプレイ許容ウィンドウ、要求フィンガープリント、メソッドと副作用分類、アプリケーション冪等キー、主体と認可ポリシー世代、転送結果、再試行履歴、確定した効果、判断時刻を結び付ける。

不確実性も残さなければならない。単一拠点での一意性は全拠点の一意性を証明しない。有効なチケットは現在の業務権限を証明しない。隠れたヘッダー、アカウント状態、地域スコープが変われば、同じ要求ハッシュでも意味が同じとは限らない。トランスポート拒否は、下流が最初の試行を見なかった証明にもならない。

この分離によって、性能判断を統治できる。繰り返しが無害な操作だけ0-RTTを許可する、限定的な書き込みには全拠点で強制する冪等キーを要求する、現在の認可や不可逆な効果を安全に判断できない場合はEarly Dataを拒否する、といった選択が可能になる。見るべき指標は高速化したハンドシェイクの割合ではなく、実行履歴を説明できるEarly Data操作の割合である。

情報源