TLS 1.3とは？RFC 8446の仕組みと0-RTTの採否を実装者向けに解説

TLS 1.3は、RFC 8446が2018年8月に定めた版です。往復回数を1-RTTへ縮めた改良版ではなく、暗号スイートの定義も鍵の導き方も作り直されています。この記事では、supported_versionsによる版の識別、key_shareを先に送るハンドシェイク、AEAD5種の暗号スイート、0-RTT（Early Data）が抱えるリプレイの問題、OpenSSLやマネージドロードバランサーでの有効化手順、ポスト量子ハイブリッド鍵交換の現在地までを実装視点で整理しました。0-RTTを見送る条件も示します。

まとめ｜TLS 1.3を既定にする条件と0-RTTを見送る境界

先に結論を置きます。新規に組む通信はTLS 1.3を既定にして構いません。弱い方式が規格側で削られ、暗号スイートを絞り込む設定作業がほぼ消えたためです。

ただし1.3だけに倒してよいのは、通信相手を列挙できる系統に限られます。社内API、自社モバイルアプリ、相手先が特定できるB2B連携。不特定多数が触る公開Webでは、2026年8月時点でもTLS 1.2の併存が現実的です。

0-RTTは別扱いにしてください。既定は無効です。前方秘匿性が無く、送ったデータがそのまま再送信されうる性質を仕様自身が認めており、対策はアプリ側の設計とセットでないと成立しません。線引きを外すと決済や在庫更新が二重に走ります。

TLS 1.3の位置づけとRFC 8446｜版の識別方法と削られた機能

TLS 1.3は1.2の設定をそのまま引き継げる版ではありません。何を置き換え、何を捨てたのかから押さえます。

RFC 8446が2018年8月に置き換えた仕様範囲と現在の位置づけ

中核仕様はRFC 8446（2018年8月・Proposed Standard）で、この1本がRFC 5246（TLS 1.2）、RFC 5077（セッションチケットによる再開）、RFC 6961を廃止しました。SSLとの違い・証明書と認証局を含む全体像を前提に、ここから先は1.3固有の中身へ絞ります。

廃止といっても、TLS 1.2が使用禁止になったわけではありません。RFC 9325（2022年11月・BCP 195）は1.3を勧めつつ1.2の安全な設定条件も示しており、使用禁止扱いはTLS 1.0と1.1（RFC 8996）だけ。ただしメッセージ構造も鍵の導き方もスイートの意味も変わったため、1.2で覚えた設定項目の多くはそのまま通じません。

supported_versionsで版を判定する仕組みと0x0303が残る理由

TLS 1.3のClientHelloは、レコードの legacy_version フィールドに 0x0303（TLS 1.2相当）を入れたまま送ります。実際の版はsupported_versions拡張で伝え、TLS 1.3の値は 0x0304 です。二重表記になっているのは互換のためで、経路上の中間装置が未知のバージョン番号を見て接続を落とす事例が実在したからでした。

この構造は障害調査に効いてきます。パケットキャプチャのバージョン欄だけを見るとTLS 1.2に見えるため、拡張の中身を開かないと版を誤読する。実際に何で確立したかは openssl s_client の出力にある Protocol 行で確認してください。

1-RTTハンドシェイクの流れ｜key_share先出しと暗号化される証明書

1往復で暗号化通信に入れる理由は、クライアントが鍵交換の材料を最初から送りつける点にあります。

ClientHelloがkey_shareを先に送る4ステップの手順

TLS 1.3のフルハンドシェイクは次の順で進みます。

1. クライアントが supported_versions・supported_groups・signature_algorithms に加え、推測したグループの公開鍵を key_share へ載せてClientHelloを送る。
2. サーバがグループと暗号スイートを選び、自分の key_share を入れたServerHelloを返す。この時点で共有秘密が確定する。
3. サーバがEncryptedExtensions・Certificate・CertificateVerify・Finishedを、確立した鍵で暗号化して送る。
4. クライアントが証明書を検証してFinishedを返し、双方がアプリケーションデータへ移る。

TLS 1.2では暗号方式の合意と鍵交換が別々の往復に分かれていました。1.3は「使う可能性が高いグループの鍵を先に出す」賭けを織り込んで2往復を1往復へ畳んでいます。賭けが外れたときの動きは後述します。

EncryptedExtensions以降が暗号化される範囲と経路に残る情報

ServerHelloの直後から、ハンドシェイクの残りは暗号化されます。サーバ証明書もALPNで決まったプロトコル名も秘匿されるため、1.2では平文で見えていた証明書が経路上から読めません。TLS検査を行う中間装置の設計が1.3で変わったのは、この変更が理由です。

秘匿されない部分も残ります。ClientHelloは平文のままで、接続先を示すSNIや宛先IPアドレスは経路上に見える。「TLS 1.3にしたので接続先も隠れる」という説明は誤りで、隠せるのはサーバ側の応答からです。SNIまで隠す仕組みは別の拡張（ECH）が担います。

HelloRetryRequestで2-RTTに戻る条件と鍵共有グループの既定

クライアントが key_share に入れたグループを、サーバが受け付けない場合。サーバはHelloRetryRequestを返し、使いたいグループを指定してClientHelloを送り直させます。この往復が加わると1-RTTの利点は消え、TLS 1.2と同じ2-RTTになります。

発生条件は単純で、クライアントの推測とサーバのsupported_groups設定がずれたときです。多くのクライアントはX25519を第一候補に送るため、サーバ側でX25519を外してsecp384r1のみを許可すると全接続でHelloRetryRequestが起きます。

暗号スイート5種とAEAD必須｜鍵交換と署名がスイートから分離した構造

1.2で管理者を悩ませた暗号スイートの長い一覧は、1.3では姿を消しました。表す内容が変わったためです。

TLS 1.3の暗号スイート5種と実装必須となる1種類の内訳

1.3の暗号スイートは、AEAD方式とハンドシェイクで使うハッシュの組み合わせだけを表します。RFC 8446が定義するのは次の5種です（表では先頭の TLS_ を省略）。

実装必須はTLS_AES_128_GCM_SHA256の1つだけです。AES-NIのようなハードウェア支援が無い端末ではChaCha20-Poly1305のほうが速く動き、CCM系はIoT機器など制約環境向け。既定のまま触らない、が実務の答えになります。

鍵交換と署名アルゴリズムを別々の拡張で指定するサーバ設定の勘所

TLS 1.2のスイート名には鍵交換方式と認証方式まで含まれていました。1.3ではこれが分離され、鍵交換はsupported_groupsとkey_share、サーバ認証はsignature_algorithmsで決まります。RSA鍵輸送と静的ディフィー・ヘルマンは規格から削除され、証明書のRSA鍵は署名専用の役割になりました。署名にはRSASSA-PSSが必須です。

設定ファイル上の落とし穴がここにあります。nginxやApacheの ssl_ciphers 系の指定はTLS 1.2以下にしか効かず、1.3のスイートはOpenSSLの別パラメータ（Ciphersuites）で扱う。1.2向けの許可リストを書き換えても1.3側の挙動は変わりません。クライアント証明書を要求する構成では、相互TLS認証の仕組みとクライアント証明書の運用も同じ制約下に入ります。

HKDFによる鍵スケジュールとKeyUpdateでの鍵更新の実装上の注意

1.3の鍵はHKDF-ExtractとHKDF-Expand-Labelによる鍵スケジュールで導かれ、ハンドシェイク用とアプリケーション用のトラフィック秘密が別々に取り出されます。接続の途中で鍵を入れ替える手段も変わりました。1.2までの再ネゴシエーションは削除され、代わりにKeyUpdateメッセージで一方向ずつ鍵を更新する。古いスタックや自作プロキシがKeyUpdateを解釈できず数時間後に切断する不具合もあるため、長寿命接続を扱う実装では対応可否を確認してください。

0-RTT（Early Data）の仕組みとリプレイ耐性の限界と使いどころ

TLS 1.3で最も判断を要する機能が0-RTTです。速度だけを見て有効化すると、アプリケーション側に穴が開きます。

PSKとticket_ageを使うEarly Data送信の流れと前方秘匿性の欠落

接続を終えたサーバはNewSessionTicketを発行します。クライアントは次回、そのチケットを事前共有鍵（PSK）としてClientHelloに載せ、early_data拡張を付けてアプリケーションデータを同時に送れる。これが0-RTTで、往復1回ぶんの待ち時間が消えます。

代償が2つあります。早期データの鍵は再開用のPSKから導かれるため、その部分だけ前方秘匿性がありません。もう1つがリプレイで、攻撃者は記録したClientHelloと早期データをそのまま再送信でき、サーバから見ると正規の要求と区別がつかない。QUICが同じ0-RTTをトランスポート層へ取り込んだ設計でも、この制約は引き継がれています。

RFC 8446第8章が求めるリプレイ対策3方式と運用コストの差

RFC 8446は第8章で、0-RTTを提供するサーバに次のいずれかを求めています。

• 単一利用チケット：一度使ったチケットを無効化する。確実だが使用状態を全ノードで共有する必要がある。
• ClientHelloの記録：一定の時間窓で受け取ったClientHelloを記録し重複を弾く。記録の保持先が要る。
• 鮮度検査：ticket_ageと実際の経過時間を突き合わせ時間窓を狭める。単独では窓の内側の再送を防げない。

単独サーバなら実装は容易です。難所は複数ノードへ分散した構成で、チケットの状態や受信履歴を共有しない限り、別ノードへ投げ直された再送は素通りする。CDNやロードバランサーの0-RTT設定を有効にする前に、その製品がどの方式を採るかを確認してください。

0-RTTに載せてよい要求の条件と非べき等処理を通した失敗例

載せてよいのは、再実行されても結果が変わらない要求だけです。静的アセットのGET、キャッシュ可能な参照系API。ここに限れば副作用がありません。

問題は、そこを制御せずに有効化した場合です。決済確定や在庫引き当てのPOSTが早期データに乗ると、再送で二重実行が起きる。HTTPでの取り扱いはRFC 8470（2018年9月）が定めており、サーバは早期データでの処理を拒む場合に425 Too Earlyを返します。nginxでは ssl_early_data on に加えて $ssl_early_data 変数を見て425を返す実装が要り、この受け口を書かないまま有効化した構成が最も危険です。

TLS 1.3の有効化と疎通確認｜OpenSSL・nginx・マネージドLBの設定点

ここからは実際に1.3で確立させ、それを確かめる手順です。

OpenSSLとnginxでTLS 1.3を有効にする最小設定と確認コマンド

前提はライブラリの版です。OpenSSLはTLS 1.3を1.1.1（2018年9月）で実装し、nginxは1.13.0以降がOpenSSL 1.1.1と組み合わせて対応します。設定は ssl_protocols TLSv1.2 TLSv1.3; と書くだけで、1.3側のスイート選択は既定に任せて構いません。サポート状況はOpenSSLのバージョン系統と3系からの転換点で確認できます。

openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'
curl -sv --tlsv1.3 --tls-max 1.3 https://example.com/ 2>&1 | grep 'SSL connection'

1行目が Protocol : TLSv1.3 を返せば確立できています。握れない場合はサーバ設定かライブラリの版で止まっているため、まず openssl version を見てください。

マネージドLBでTLS 1.3を選ぶセキュリティポリシーの指定方法

クラウドのロードバランサーでは、TLSの版はセキュリティポリシーの選択で決まります。AWSのALBなら ELBSecurityPolicy-TLS13-1-2-2021-06 のように1.3を含むポリシー名を選び、CloudFrontではTLSv1.2_2021以降を指定する形です。古いポリシーが残った環境では、バックエンドで何を設定しても1.3では確立しません。

この構成ではTLSの終端がロードバランサー側になり、版の管理も証明書の更新もそこへ集約されます。証明書の側はAWS Certificate Managerの有効期間短縮と自動更新の条件も合わせて確認してください。

ミドルボックス互換モードとダウングレード検知での不具合切り分け

「特定の拠点からだけTLSで接続できない」。1.3導入後に出る典型的な症状です。原因の多くは経路上のTLS検査装置やプロキシにあり、RFC 8446はこれを見越してミドルボックス互換モードを定め、不要なChangeCipherSpecをダミーで送りsession_idをエコーして1.2に見せかける動作を入れました。

版を落とさせる攻撃への備えも仕様に入っています。1.3対応サーバが1.2以下で応答する場合、ServerRandomの末尾8バイトへ決められた番兵値を入れる決まりで、1.3を話せるクライアントはこれを見て接続を中断する。切り分けは、まず別回線から openssl s_client -tls1_3 を試すこと。成功するなら原因は経路上の装置です。

ポスト量子ハイブリッド鍵交換｜X25519MLKEM768が既定になった時点と影響

2024年以降、TLS 1.3の鍵交換には量子計算機を見据えた選択肢が加わりました。プロトコルの改訂ではなくグループの追加として入っている点が要点です。

X25519MLKEM768が既定化した時期と主要実装の対応状況

X25519MLKEM768は、従来のX25519とML-KEM-768を組み合わせたハイブリッドの鍵合意グループです（IANA値4588）。ブラウザ側の既定化はChrome 131とFirefox 132（いずれも2024年11月）で、サーバ側ではOpenSSL 3.5（2025年4月）がML-KEMをネイティブに実装しました。

仕様文書のdraft-ietf-tls-ecdhe-mlkemは最新版が05（2026年5月26日）で、2026年8月時点ではIESG承認を経てRFC発行の手続き中という段階です。実装から見た要点は、supported_groupsへグループを1つ足すだけで済み、TLS 1.3のハンドシェイク自体は変わらない点にあります。

ポスト量子鍵交換でのハンドシェイク肥大化と切り戻しの判断基準

副作用はサイズです。ML-KEM-768の公開鍵は1,184バイト、暗号文は1,088バイト。これをkey_shareへ載せるとClientHelloが一般的なMTU（1,500バイト）を超えて複数のTCPセグメントに分かれ、再構成できない中間装置や古い実装が接続を落とします。

切り戻しの判断は明確です。TLSの版を1.2へ下げるのではなく、supported_groupsからハイブリッドのグループだけを外してください。版を下げると1.3で得た他の利点まで失います。既定のまま運用し、不具合が出た経路だけグループ単位で切る。この順序が2026年8月時点での妥当な運用です。

企業システムでのTLS 1.3採用判断｜0-RTT不採用とTLS 1.2併存の線引き

ここからは実際の案件でどこまで倒すかの判断です。条件を付けて言い切ります。

TLS 1.3のみに倒せる条件と1.2を残すべき相手の見分け方

判断軸は1つ、通信相手を列挙できるかどうかです。社内API、自社が配布するモバイルアプリ、接続元が特定できるB2B連携。この3つは1.3のみで構成して構いません。相手側の実装を把握でき、握れない端末が後から現れる余地がないからです。

逆に、TLS 1.2を残すべき相手も明確になります。不特定多数が触る公開Webサイト、更新の止まったPOS機器や複合機、相手先が管理する決済やEDIのゲートウェイ。ここで1.3単独に倒すと、接続不能の問い合わせが確実に発生する。公開Webサイトを1.3単独にする構成は、2026年8月時点では採用しません。

0-RTTを既定で無効にする判断と例外的に有効化してよい条件

0-RTTは既定で無効にします。有効化してよいのは次の3つを同時に満たす場合だけです。第一に、早期データに載る要求が参照系のGETに限定できること。第二に、アプリケーションが425 Too Earlyを返してクライアントに再送させる実装を持つこと。第三に、複数ノード構成ならチケットの単一利用か受信記録の共有が組めていること。

該当するのは、CDN配下の静的配信で初回表示を詰めたい場面くらいでしょう。認証エンドポイントや決済APIでは有効化しません。得られるのはRTT1回ぶん、失うのは二重実行が起きないという保証で、割に合わない交換です。

版を上げても速くならない失敗パターンと先に測るべき2つの指標

「TLS 1.3にしたのに体感が変わらない」。この相談は珍しくありません。1.3が削るのはハンドシェイクの往復1回ぶんだけで、往復遅延が30ミリ秒の経路なら効果も30ミリ秒。画像やJavaScriptの転送量が支配的なページでは、測定誤差に埋もれます。

先に測るべき指標は2つです。1つは新規ハンドシェイクの発生率で、keep-aliveや接続の再利用が効いていれば握り直す回数自体が少ない。もう1つが往復遅延で、これが大きい経路ほど1.3の効果が出ます。外部連携APIの通信設計や既存システムのTLS構成の見直しはAPI開発・システム連携で、接続先ごとの版と鍵交換の要件を整理する段階から対応しています。

よくある質問

TLS 1.3の実装と運用でよく挙がる質問に回答します。

TLS 1.3にすると通信はどれくらい速くなりますか？

短縮できるのはハンドシェイクの往復1回ぶんです。1.2が2-RTTを要したところを1-RTTで済ませるため、往復遅延が50ミリ秒の経路なら約50ミリ秒縮みます。ページ全体で見ると転送量や接続の再利用状況のほうが支配的で、体感差が出ないことも珍しくない。効果が大きいのは遅延の大きいモバイル回線や、新規接続が頻発するAPI呼び出しです。

0-RTTは有効にしても安全ですか？

条件を満たさない限り安全ではありません。早期データには前方秘匿性が無く、記録されたデータを再送信されるリプレイが成立します。RFC 8446第8章は単一利用チケット・ClientHelloの記録・鮮度検査のいずれかを求め、複数ノード構成では状態共有まで必要になる。有効化するなら参照系のGETに限定してください。

TLS 1.3にすると証明書の入れ替えは必要ですか？

既存の証明書をそのまま使えます。1.3が変えたのは鍵交換と署名の扱いで、証明書の形式（X.509）や発行手順は同じです。ただしRSA証明書の鍵は鍵輸送に使われなくなり署名専用の役割になり、署名にはRSASSA-PSSが必須のため、極端に古いライブラリを使う環境では対応を確認してください。

TLS 1.3にしたら一部の端末から接続できなくなりました。原因は何ですか？

疑う順序は3つあります。第一に経路上のTLS検査装置やプロキシで、別回線から openssl s_client -tls1_3 を試して成功するならこれが原因です。第二にクライアント側のライブラリの版で、OpenSSL 1.1.1より前の実装は1.3を話せません。第三がポスト量子ハイブリッド有効時のClientHello肥大化です。

ポスト量子のハイブリッド鍵交換は今すぐ入れるべきですか？

主要ブラウザとサーバ実装では既定で動いているため、判断が要るのは自前でグループを絞っている環境だけです。Chrome 131とFirefox 132（いずれも2024年11月）が既定化し、OpenSSLは3.5（2025年4月）でML-KEMを実装しました。長期間の秘匿性が要る通信ほど先に対応する価値があります。

関連記事

• TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説：証明書と認証局を含む前提
• QUIC（通信プロトコル）とは？HTTP/3を支える仕組みとTCPとの違いを実装視点で解説：0-RTTを内包する設計
• mTLSとは？相互TLS認証の仕組みとクライアント証明書・導入判断を実装目線で解説：クライアント側の認証
• OpenSSL 4.0が2026年4月リリースへ至る背景とバージョン3系からの転換点：実装ライブラリの版管理
• AWS Certificate Managerの有効期間198日化とACME対応：証明書の自動更新