TLS 1.3の「0-RTT」という甘い罠：リプレイ攻撃の脅威と実務的防衛策
エンジニアの諸君、お疲れ様。今日もセキュアな設計に頭を悩ませていることだろう。
今回は、TLS 1.3で導入された「0-RTT（Zero Round-Trip Time）」という機能について話したい。HTTP/2やHTTP/3の普及に伴い、Webの高速化は至上命令だ。0-RTTはハンドシェイクを省略して初手からデータを送信できるため、パフォーマンス向上には劇的な効果がある。
しかし、セキュリティの現場に身を置く者から言わせれば、「利便性は常に攻撃対象を広げる」という鉄則がある。0-RTTは、設計を理解せずに使えば、システムを致命的なリプレイ攻撃に晒すことになる。今回は、この技術の裏側と、泥臭い防衛戦術について深掘りしよう。
—
1. なぜ0-RTTは「諸刃の剣」なのか？
通常のTLS 1.3ハンドシェイクは、サーバーとクライアント間でセッションを確立してからデータを送る。0-RTTは、過去に接続した際のセッション情報（PSK: Pre-Shared Key）を再利用し、最初のパケットにアプリケーションデータ（HTTPリクエストなど）を詰め込んで送りつける。
問題はここだ。「一度送信されたパケットを攻撃者が傍受し、そのままサーバーに再送（リプレイ）できてしまう」という特性がある。
例えば、POST /api/transfer?amount=1000 のようなリクエストを0-RTTで送った場合、攻撃者はこのパケットを何度も送りつけることで、残高を不正に操作できてしまう可能性がある。TLSの暗号層では「このパケットが新しいか古いか」を完全に保証できないのだ。
—
2. 攻撃の構図：PoCの考え方
攻撃者は、ネットワークの末端やプロキシでパケットをキャプチャする。これを再送するだけで、サーバーは「正規のクライアントからの再接続だ」と誤認してリクエストを処理してしまう。
特に、GETメソッドであっても、検索条件の変更やデータベースの更新処理を伴う設計になっている場合、このリプレイ攻撃の影響は甚大だ。
—
3. 防御の鉄則：アプリケーション層で「べき等性」を担保せよ
TLS層での対策（Nginx側の設定など）は重要だが、それだけで万全とは言えない。結局のところ、「同じリクエストが複数回届いてもシステムが破綻しないこと（べき等性）」をアプリケーション側で担保するのが最も堅牢だ。
実装サンプル：べき等トークンによるガード
PHP（Laravelなどのフレームワークを想定）での実装例だ。リクエストごとに使い捨ての「リプレイ防止トークン」を要求し、一度処理したトークンは無効化する。
<?php
// リクエストの処理（例：銀行振込API）
function processTransfer($request) {
$nonce = $request->header('X-Replay-Nonce');
// 1. Redis等でトークンの存在確認と排他制御
if (Cache::has("nonce:{$nonce}")) {
// 二重送信を検知
throw new Exception("リプレイ攻撃を検知しました。");
}
// 2. トークンを保存（有効期限を短く設定）
Cache::put("nonce:{$nonce}", true, now()->addMinutes(5));
// 3. 本来のビジネスロジックを実行
// ... 決済処理 ...
}このアプローチの肝は、処理の実行前に必ず状態をチェックし、アトミックにロックすることだ。
—
4. インフラ側での防御設定
アプリケーションの改修が間に合わない、あるいは緊急の応急処置が必要な場合、Webサーバー（Nginx）側で0-RTTの挙動を制限することも可能だ。
Nginxで0-RTTを許可する場合、「安全なリクエスト（GETなど）」に限定し、更新系（POST/PUT/DELETE）は拒否するのが鉄則だ。
# Nginx 設定ファイル
ssl_early_data on; # 0-RTTを有効化
location / {
# 0-RTT経由の更新系メソッドを排除する設定
if ($ssl_early_data = 1) {
# GET/HEAD以外なら、フルハンドシェイクを強制するためにエラーを返す
if ($request_method !~ ^(GET|HEAD)$) {
return 425; # Too Early
}
}
...
}この 425 Too Early ステータスコードは、クライアントに対して「0-RTTではなく、正規のTLSハンドシェイクで再送せよ」と指示する標準的な手法だ。モダンなブラウザやライブラリは、これを受け取ると自動的に再送を行ってくれる。
—
最後に：エンジニアとしての心構え
0-RTTは魅力的だが、セキュリティ担当者としては「デフォルトでOFFにする」か、「GETリクエスト以外は徹底して弾く設定」を強く推奨する。
「速さ」はユーザー体験（UX）を向上させるが、「セキュリティの欠如」はユーザーの信頼を一瞬で崩壊させる。インフラエンジニアはNginxの設定でガードを固め、アプリケーションエンジニアはべき等なAPI設計を徹底する。この両輪が揃って初めて、現代のWebインフラは安全に運用できる。
現場で「なぜ0-RTTを制限するのか？」と問われたら、この記事のことを思い出してほしい。技術の原理を知り、最悪のシナリオを想定して実装を積み重ねる。それがプロフェッショナルの仕事だ。
何か不安な実装があれば、またいつでも相談してくれ。堅牢なシステムを共に作っていこう。
コメント