TLS 1.2の技術的限界とRFC 8446策定の動機

トランスポート層セキュリティ（TLS）は、インターネット上の安全な暗号化通信を保証する最重要の基盤プロトコルです。しかし、長年にわたり広く利用されてきたTLS 1.2以前の仕様は、設計上の構造的制約からレイテンシとセキュリティの双方で看過できない課題を抱えていました。TLS 1.2のハンドシェイク往復数は、通常接続かセッション再開かなどの経路によって異なり、高遅延なモバイルネットワークや長距離通信環境においてウェブサイトの表示速度やAPI通信の即応性を損なう大きな要因となっていました。

さらに、TLS 1.2は過去の互換性を維持するために、静的RSA鍵交換、CBCモード暗号、SHA-1などのレガシーで脆弱な暗号スイートを許容し続けていました。特に静的RSA鍵交換では、サーバーの秘密鍵が将来漏洩した場合に、過去に記録されていた暗号化通信トラフィック全体が後から一括して解読されてしまうという重大な危険性（完全前方秘匿性の欠如）が存在していました。これらの課題を抜本的に解決するため、IETFは2018年8月にRFC 8446を公開し、無駄な通信往復を排除して最新の暗号標準のみを強制するTLS 1.3を正式規格として制定しました。

1-RTTおよび0-RTTの仕組みと完全前方秘匿性（PFS）

証明書を使うTLS 1.3の全ハンドシェイクは通常1-RTTです。クライアントはClientHelloに鍵共有候補を含め、サーバーはServerHelloで選んだ鍵共有を返します。提示されたグループをサーバーが受け入れられずHelloRetryRequestを返す場合は、さらに1往復が必要です。したがって1-RTTは通常経路の説明で、全接続への保証ではありません。セッション再開はPSKによる1-RTTでも可能で、任意機能の0-RTTでは最初の送信に早期データを含められます。RFC 8446 §§2.3、4.1.4

0-RTTが短縮できるのは、対象となる早期データを送る前にハンドシェイクの往復完了を待つ時間です。ネットワークの伝播遅延やハンドシェイク全体の完了がなくなるわけではなく、サーバーが早期データを拒否すれば1-RTTに続く場合があります。実際の効果は、再開の成功、サーバーが早期データを受け入れるか、通信経路、アプリケーションの処理に左右されます。RFC 8446 §2.3

TLS 1.3では静的RSA鍵交換が削除されましたが、全接続で前方秘匿性が同じという意味ではありません。証明書方式の(EC)DHEとPSK+(EC)DHEは新しい鍵共有を使います。一方、PSKのみ（psk_ke）では新しい(EC)DHE交換がなく、RFCは0-RTT早期データに完全な前方秘匿性がないと明記しています。「TLS 1.3なら必ず前方秘匿性がある」と一般化せず、交渉された方式とデータの種類を確認してください。RFC 8446 §§4.2.9、E.1.3

サーバー設定と本番環境への導入手順

企業インフラにおけるTLS 1.3の導入は、リバースプロキシ（Nginx、Apache、Envoy）やクラウドCDN（Cloudflare、AWS CloudFront）の設定変更によって円滑に実施できます。たとえばNginxでは、ssl_protocolsディレクティブにTLSv1.3を追加し、AEAD（認証付き暗号）に準拠した最新の暗号スイート（TLS_AES_128_GCM_SHA256やTLS_CHACHA20_POLY1305_SHA256など）を指定します。

TLS 1.3を有効にしても、往復時間が一定割合で短縮されたり、Core Web Vitalsが必ず改善したりするわけではありません。再開接続でサーバーが0-RTTを受け入れた場合、対象のリクエストデータをハンドシェイク完了前に送れますが、効果は再開率、早期データの受け入れ率、経路の遅延、アプリケーション処理によって変わります。導入前後で同じ利用者群と経路を比較し、再開・早期データの動作と実ユーザー指標を分けて観測してください。

0-RTTの安全境界とエンドポイント単位の判断

証明書認証を使うTLS 1.3の通常のハンドシェイクは通常1-RTTですが、HelloRetryRequestがあれば追加の往復が発生します。TLS 1.2もハンドシェイク方式と再開経路で往復数が異なるため、プロトコル版だけで数を断定しないでください。TLS 1.3のPSK再開は1-RTTで行え、0-RTTは最初の送信に早期データを含める選択肢です。

PSKのみの鍵設定（psk_ke）では新しい(EC)DHE交換を行いませんが、psk_dhe_keはPSKと(EC)DHEを組み合わせます。すべてのTLS 1.3接続が同じ前方秘匿性を持つわけではありません。RFC 8446は、0-RTTデータには前方秘匿性も接続間の再送防止保証もないと明記しています。

早期データは同一接続内で二重処理されなくても、別接続で再送される可能性があります。RFC §8のサーバー対策には運用・状態共有上の制約があり、TLS層の防御だけでアプリケーションの重複処理を完全に防げるとは限りません。HTTPメソッド名だけで許可を決めないでください。たとえばGET /account/chargeが決済を実行するなら、GETでも0-RTTに適しません。外部副作用がなく、重複しても許容できる経路だけを候補とし、決済・予約作成・状態変更はハンドシェイク後に処理します。変更処理の重複防止には、リクエスト識別子を状態変更と原子的に記録するアプリケーション側の冪等性を組み合わせられます。

有効化前に、(1)どのTLS終端点がearly dataを受け取るか、(2)候補経路の実際の副作用、(3)サーバー・リージョン間のチケット／再送状態共有、(4)拒否時の1-RTTへの切り替えを確認します。これは点検例であり、サーバーやCDNで実行した結果ではありません。RFC 8446 §§2.2–2.3、4.2.9、8を参照してください。