一般面接：HTTP 425 Too Early と 0-RTT リプレイ安全性の解説

プロンプトとコンテキスト

この HTTP およびセキュリティの基礎に関する質問は、バックエンド、プラットフォーム、SRE、インフラストラクチャの職種に適しています。想定されるシナリオは、TLS 1.3 0-RTT リクエストがゲートウェイに到達するケースです。early data はハンドシェイクの待機時間を短縮しますが、リプレイされる可能性があります。優れた回答では、425 のセマンティクス、ビジネスの冪等性、ホップバイホップのポリシーを関連付けて説明します。

面接官が見ているポイント

0-RTT のパフォーマンス上の利点とリプレイリスクの理解。
425、429、503、408 の間の明確な境界。
冪等性キー、重複排除台帳、副作用に対するステータス確認の使用。
ゲートウェイ、オリジン、インスタンス間での一貫した early-data ポリシー。

明確化のための質問

まず、early data の証拠があるか、操作に副作用があるか、ゲートウェイが Early-Data を保持しているか、クライアントが完全なハンドシェイク後にリトライできるかを確認します。次に、冪等性キー、一意性制約、重複排除レコード、およびインスタンス間での共有状態について質問します。GET であってもビジネス上の副作用を持つ可能性があるため、メソッド名だけでは安全性の証明になりません。

30秒の回答フレームワーク

TLS 1.3 0-RTT を使用すると、クライアントはハンドシェイクが完了する前に early data を送信できますが、そのデータはリプレイされる可能性があります。リクエストの処理が安全であると証明されていない場合、サーバーは 425 Too Early を返し、ハンドシェイク後にリトライするようクライアントに要求します。そのリトライでは再び early data を使用してはなりません。early data は、重複排除を備えたリプレイ安全かつ冪等な操作に対してのみ受け入れます。ゲートウェイとオリジンはリトライの増幅を監視しながら、Early-Data: 1 について合意しておく必要があります。

ステップバイステップの詳細解説

リスクを述べる。 0-RTT early data は依然として暗号化されていますが、攻撃者が有効なリクエストをコピーしてリプレイする可能性があります。中心的なリスクは機密性の直接的な喪失ではなく、重複した副作用です。
425 を定義する。 early-data フェーズ中の処理が安全でない場合に 425 を返します。サーバーは early data の証拠がない場合に 425 を発行すべきではありません。このレスポンスはデフォルトではキャッシュ不可です。
操作を分類する。 読み取りであっても実際の副作用を確認します。決済、発送、クォータ変更などは通常、完全なハンドシェイクを待つ必要があります。early data を受け入れる場合は、冪等性キー、一意性制約、または重複排除台帳を必須とします。
リトライを指定する。 early data を送信したクライアントは完全なハンドシェイク後にリトライし、そのリトライは early data として送信されてはなりません。リトライ回数と合計時間を制限します。
ホップ間の一貫性を保つ。 信頼できる仲介者は Early-Data: 1 を追加または転送できます。ゲートウェイ、ロードバランサー、オリジンは同一の信頼境界を必要とします。そうでなければ、あるインスタンスが待機している間、別のインスタンスが副作用を実行してしまう可能性があります。
増幅を制御する。 過負荷時には、425 レスポンスとハンドシェイクリトライによってトラフィックが増幅する可能性があります。early-data のサイズと並行性を制限し、425 の比率、リトライ率、重複ビジネスキー、ハンドシェイクレイテンシを監視します。

模範解答

私は Early-Data: 1 を通常確認されたリクエストとしてではなく、リプレイリスクのシグナルとして扱います：

http

POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123

決済操作がリプレイセーフであると証明されていない場合、私は 425 Too Early を返し、同じ冪等性キーでリトライする前にクライアントに TLS ハンドシェイクを完了させます。リトライで再び early data を使用してはなりません。リプレイセーフな操作であっても、重複実行を防ぐために一意性制約または重複排除台帳を使用します。425 はレート制限 (429)、広範な一時的利用不可 (503)、クライアントタイムアウト (408) とは異なります。リトライによって過負荷が増幅しないよう、ゲートウェイとオリジンは単一のポリシーを共有し、リクエスト ID、early-data マーカー、リトライ回数、重複キーをログに記録します。

よくある間違い

「0-RTT は暗号化されていない」と言う → TLS は依然としてそれを暗号化しています → リスクはリプレイです。
425 の後に変更せず 0-RTT を再送する → リスクが残ります → 完全なハンドシェイク後にリトライします。
すべての POST に対して 425 を返す → 一部の書き込みには信頼性の高い重複排除があります → 副作用と証拠を判断してください。
425 を 429 として扱う → 425 は early data を処理し、429 はレート制限を示します → 個別のバックオフとアラートを使用してください。
ゲートウェイでのみチェックする → オリジンで一貫性のない実行が発生する可能性があります → 信頼境界と状態を共有してください。

フォローアップの質問

425 と 503 をどのように区別しますか？

425 は early-data フェーズ中のリプレイリスクに対処するものです。503 はサービスが一時的にリクエストを処理できないことを意味します。early data の証拠が存在し、ポリシーによりハンドシェイクを待つ必要がある場合にのみ 425 を選択します。

なぜ GET のみ許可としないのですか？

HTTP メソッド名はビジネス上の副作用がないことを保証しません。一部の GET リクエストはカウンター、プリフェッチ、または状態変更をトリガーするため、実際の影響と重複排除を評価します。

ゲートウェイはどのように early-data 情報を渡すべきですか？

信頼できる仲介者は Early-Data: 1 を追加または転送できますが、信頼できないクライアントがシグナルを偽造するのを防ぎ、マーカーがどこから来たのか、どのポリシーが適用されるかをオリジンに伝える必要があります。

請求が二重に発生しないことをどのように証明しますか？

一意な挿入または重複排除台帳に同じ冪等性キーを使用し、最終状態を記録し、リトライする前にクエリを実行し、事後に決済イベントをビジネス注文と照合します。