暗号化だけでは再生されたパケットを止められない理由

保護されたパケットは暗号学的に失効しないため、五分前に有効だったパケットは今も有効です。暗号化と整合性の保護はバイトがいつ生成されたかについて何も語らず、トラフィックを捕捉して再送できる攻撃者は暗号を破る必要がありません。だからこそ、まともなトンネルプロトコルは鍵と並べて順序の状態を持ちます。

仕組みは小さく、その故障の仕方はパケット損失と混同しやすいものです。

有効な暗号文は新しい暗号文ではない

認証が答えるのは一つの問いだけです：このバイト列は鍵を持つ者から改変されずに届いたか。受信側が初めて見るものかどうかは答えません。再生されたパケットは一つ目の試験を完璧に通過するので、整合性の検査だけでは再生を止められず、プロトコルには受け入れに関する第二の規則が必要なのです。認証だけを行う受信側には、記録を持つ攻撃者に対する防御がありません。

この規則は実装も表明も安上がりで、与えられた保護パケットを、与えられた鍵の下で一度だけ受け入れるというものです。この分野の他のすべては、実装がその一度をどう追跡するかから導かれます。

再生による破棄を復号の失敗と読むと、まったく見当違いのサブシステムへ送られます。

順序番号とウィンドウ

IPsec ESPは順序番号を運び、受信側は最近受け入れた値のスライディングウィンドウを保ち、ESP仕様は既定のウィンドウサイズとそれを拡張する選択肢を記述しています。WireGuardは鍵ごとのカウンタとそれに対する明示的な検査という別の道を取ります。どちらの設計も、実際のネットワークが順序を入れ替えるため、パケットが順序どおりに届くとは仮定しません。どちらも並べ替えは許容し、どちらも繰り返しは許容しません。

この許容を可能にするのがウィンドウです。見た最大値より少し後ろのパケットは、以前に受け入れられていなければまだ受け入れられますが、大きく後ろのもの、または位置がすでに印を付けられたものは破棄されます。ウィンドウを広げれば、関連ごとの状態を増やす代わりに、より多くの並べ替えを許容します。

診断カウンタは、どの場合にいるのかを示します。再生による破棄は汎用のエラーではなく特定のカウンタを増やすので、そのカウンタを読むことが最初の有用な観察です。

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

状態はホストではなく鍵に属する

カウンタの状態はセキュリティ関連または鍵の世代に結び付くため、鍵を更新すると新しい文脈と独自の順序空間が生まれます。鍵を交換せずにカウンタを消去したり、手動リセット後に同じ関連を再利用したりすると、受信側のウィンドウが依存する前提が崩れます。だからこそ、運用者に見えるリセットボタンではなく、プロトコル主導の鍵更新が存在します。

手動の介入のあとトンネルが不調になったら、その介入が順序の状態に触れたかを問うてください。同じに見える設定でも、継承した状態が期待する状態ではないため、違う振る舞いをすることがあります。

何かを無効にする前に原因を診断する

損失、並べ替え、重複したトラフィック、実装の不具合はすべて再送として現れ、そのうち再生の問題は一つだけです。音を静めるために検査を無効にすると、頼っていた性質が失われ、再送に説明がまったく付かなくなるため、元の原因を探すのが難しくなります。

範囲を限定した証拠とは、関連の識別子、順序番号、カウンタを、ペイロードを除いて記録したものです。これで重複と並べ替えられた到着を区別でき、診断ファイルが利用者のトラフィックの複製になることもありません。

検査が約束しないこと

再生保護は、一つのプロトコル内でのパケット処理の性質です。運用者がログを残さないことや、ウェブサイトがアカウントを認識できないこと、セッションが匿名であることを意味しません。それらは別のシステムについての別の問いであり、強固な再生防止の設計はそのどれにも答えません。

保守されたソフトウェアとサポートされた設定が、利用者にできる実際の制御です。パケットを扱うのはプロトコルであり、それ以外は運用上の判断のままです。