TLS 1.3：0-RTT、Early Data、セッション再開

TLS 1.3（RFC 8446、2018年）は、遅延を減らし、古い不要な要素を取り除くためにTLSハンドシェイクを再設計しました。TLS 1.3の完全なハンドシェイクは1-RTTで完了します。クライアントは最初のフライトで、サポートするkey_shares（一時的なECDH公開鍵）を含むClientHelloを送信します。サーバーは、ServerHello、自身のkey_share、暗号化された拡張機能、証明書、Finishedをすべて1回の応答で返します。クライアントはFinishedを送信し、直ちにアプリケーションデータを送信できます。TLS 1.2の2-RTTハンドシェイクと比べると、新しいセッションの接続確立時間を半分にできます。

TLS 1.3は、構造化された鍵スケジュールとHKDF（HMAC-based Key Derivation Function）を使用します。ECDHE鍵交換の後、共有秘密は階層的に処理されます。Extract(early_secret, DHE) -> handshake_secret、続いてExtract(handshake_secret, 0) -> master_secretとなります。これらを基に、HKDF-Expand-Labelがクライアントとサーバーのハンドシェイクトラフィック、アプリケーショントラフィック、再開用にそれぞれ別の鍵を導出します。この明確な分離により、ある層の鍵が漏えいしても他の層に影響しません。これは、より場当たり的だったTLS 1.2のPRFベースの鍵導出から大きく改善された点です。

TLS 1.3のセッション再開では、以前のセッションから導出した事前共有鍵（PSK）を使用します。ハンドシェイクが完了すると、サーバーはPSK identityとチケット値（再開用秘密を格納した暗号化済みのデータ）を含むNewSessionTicketメッセージを送信します。再接続時、クライアントはClientHelloにPSK identityを含めます。サーバーがそれを認識すると、双方はPSKと新しいECDHEから新しいセッション鍵を導出し、前方秘匿性を備えた1-RTTのセッション再開を実現します。チケットには設定可能な有効期間（通常は24時間）があり、ローテーションするサーバー側の鍵で暗号化する必要があります。

TLS 1.3では、再開されたセッションで0-RTT早期データを使用できます。クライアントは以前のセッションのPSKを使って、サーバーからの確認を受ける前に、最初のフライトで送信するアプリケーションデータを暗号化します。これにより、以前に接続したサーバーへの接続でラウンドトリップを1回省略でき、再接続時の遅延をほぼゼロにできます。サーバーは、max_early_data_sizeを伴うearly_data拡張機能をNewSessionTicketに含めることで、0-RTTのサポートを通知します。サーバーには0-RTTデータを受け入れるか拒否する仕組みが必要で、受け入れた場合はEncryptedExtensionsで通知します。

0-RTTデータには、リプレイ攻撃に対して脆弱であるという根本的なセキュリティ上の制限があります。経路上の攻撃者が最初のフライトを取得すると、それをサーバーに再送して、サーバーに早期データを再度処理させることができます。これは、サーバーがまだどのメッセージも送信しておらず、サーバーが提供する新鮮性が存在しないために避けられません。緩和策は次のとおりです。(1) 使い捨てチケット（サーバーは、memcached/Redisのような分散キャッシュを使い、最初の使用後にチケットを無効化します）。(2) 時間制限付きチケット（例として5秒など、短い期間を過ぎた0-RTTを拒否します）。(3) アプリケーションレベルの冪等性（安全なGET相当の操作にのみ0-RTTを許可します）。

0-RTTに対する最も堅牢なリプレイ対策は、使い捨てセッションチケットです。サーバーは「used ticket」ストア（複数サーバー構成では分散キャッシュ）を管理します。0-RTTデータが到着すると、サーバーはそのチケットが以前に使用されたかを確認します。使用済みであれば早期データを拒否し、1-RTTにフォールバックします。未使用であれば、チケットを使用済みとして記録し、早期データを処理します。正しく動作させるには、クラスター内のすべてのサーバーが使用済みチケットのキャッシュを共有する必要があります。チケットの有効期間に合わせた短いTTLを設定したRedisが一般的な実装です。この仕組みがなければ、支払いのような非冪等操作に0-RTTを使用するのは安全ではありません。

DHEを使用しないTLS 1.3のPSK再開では、再開されたセッションに前方秘匿性がありません。PSKが後から漏えいすると、再開されたセッションのすべての通信を復号できてしまいます。前方秘匿性を維持するため、TLS 1.3はPSK-with-DHEをサポートしています。ClientHelloには、PSK identityと新しいkey_shareの両方を含めます。サーバーはPSKとECDHEの出力を組み合わせてセッション鍵を導出します。PSKが漏えいしても、ECDHEの寄与によって過去の通信は保護されます。RFC 8446では、前方秘匿性が必要なすべての再開ケースでPSK-with-DHEを使用することを推奨しています。

TLS 1.2には300を超える暗号スイートの組み合わせがあり、その多くは安全ではありませんでした。TLS 1.3ではこれを5つの暗号スイートに削減し、すべてでAEADを使用します。暗号スイートはTLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_AES_128_CCM_SHA256、TLS_AES_128_CCM_8_SHA256です。鍵交換と認証は、supported_groups拡張機能とsignature_algorithms拡張機能によって個別にネゴシエーションされます。この分離により、TLS 1.2における組み合わせの複雑さが解消され、TLS 1.3のすべての接続で認証付き暗号が使用されます。

実際には、0-RTTは、以前に接続したサーバーに対してクライアントがGETリクエスト（安全かつ冪等）を繰り返し送信するHTTP/2接続で最も役立ちます。ブラウザーは0-RTTを慎重に実装しており、Chromeは安全なHTTPメソッドに対して有効にします。POSTリクエストが0-RTTデータとして送信されることはありません。QUIC上のHTTP/3はTLS 1.3をネイティブに統合しており、QUICの0-RTTはTLS 1.3の仕組みを再利用します。QUICでは、0-RTTによって以前のセッションのトランスポートパラメーター（フロー制御やストリーム上限）も復元されるため、TLS層だけでなく接続確立のオーバーヘッドをさらに削減できます。

TLS 1.3には、バージョンダウングレード攻撃を防ぐ仕組みが組み込まれています。TLS 1.3がネゴシエーションされた場合、ServerHelloのrandomフィールドには識別用の固定値が含まれます。TLS 1.2へのフォールバックでは、最後の8バイトが固定値（0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01）に設定されます。TLS 1.3に対応するクライアントは、サーバーがTLS 1.2をネゴシエーションした際にこの固定値を確認し、能動的なダウングレード攻撃を検出します。さらに、Finishedのトランスクリプトハッシュはバージョンネゴシエーションを含むハンドシェイク全体を対象とするため、改ざんを検出できます。TLS_FALLBACK_SCSVのようなSCSV（Signaling Cipher Suite Values）は、古いTLSバージョン向けに別のダウングレード通知を提供します。

TLS 1.3をデプロイする際は、いくつかの運用上の詳細に注意する必要があります。セッションチケットの暗号化鍵はローテーションし（通常は24時間ごと）、サーバークラスター間で同期して、どのサーバーでもセッションを再開できるようにする必要があります。不要なハンドシェイク失敗を避けるため、古いチケットの復号鍵はチケットの有効期間中保持する必要があります。OCSP staplingは、証明書の状態確認に必要なラウンドトリップが1回少なくなるため、TLS 1.3ではより重要です。ロードバランサーはTLS 1.3のClientHelloを変更せずに通過させる必要があります。古いミドルボックスの中には未知の拡張機能を壊すものがあり、その場合は互換モードが必要です。

TLS 1.3の0-RTT早期データがリプレイ攻撃に対して脆弱なのはなぜですか？

TLS 1.3は、PSKセッションチケットによって1-RTTの完全なハンドシェイクと0-RTTのセッション再開を実現します。鍵導出には構造化されたスケジュールを持つHKDFを使用し、トラフィックの各層に個別の鍵を生成します。0-RTT早期データはラウンドトリップを1回省略できますが、リプレイ攻撃に対して脆弱です。使い捨てチケットの使用と、0-RTTを冪等操作に限定することで緩和できます。PSK-with-DHEにより、セッション再開でも前方秘匿性を維持できます。TLS 1.3は暗号スイートを5つのAEAD方式に限定し、古く安全でない組み合わせを排除しています。ダウングレード防止には、サーバーのrandomフィールドに含まれる固定値が使用されます。