TLS 1.2 と TLS 1.3 の比較｜変更点と設定すべき項目

TLS 1.2 と TLS 1.3 は、もはや対等な 2 つの選択肢ではありません。TLS 1.2（RFC 5246、2008年）は、ECDHE による鍵交換と AEAD の暗号スイートに限定すれば安全です。TLS 1.3（2018年の RFC 8446、2026年7月に RFC 9846 として改訂）はそれを唯一の選択肢とし、ハンドシェイクのより多くの部分を暗号化します。さらに、ポスト量子ハイブリッド鍵交換と Encrypted Client Hello を提供する唯一のバージョンでもあります。

比較表

	TLS 1.2	TLS 1.3
仕様	RFC 5246（2008年）、現在は RFC 9846 により廃止	RFC 8446（2018年）、RFC 9846（2026年）として改訂
フルハンドシェイク	ラウンドトリップ 2 回	ラウンドトリップ 1 回（HelloRetryRequest 時は 2 回）
セッション再開	セッション ID またはチケット、ラウンドトリップ 1 回	PSK、ラウンドトリップ 1 回、任意で 0-RTT データ
鍵交換	RSA による鍵輸送、DHE、ECDHE	ECDHE、DHE、ハイブリッド KEM、DHE を併用する PSK と併用しない PSK
前方秘匿性	(EC)DHE のスイートでのみ	常にあり（PSK のみによるセッション再開を除く）
暗号スイート	鍵交換、認証、暗号、MAC を指定。CBC、RC4、3DES も使用可能	暗号とハッシュを指定する、AEAD のみの 5 つのスイート
ハンドシェイクの暗号化	証明書は平文	ServerHello 以降はすべて暗号化
署名	PKCS#1 v1.5 または PSS、ECDSA。SHA-1 も使用可能	RSA によるハンドシェイク署名には PSS が必須。SHA-1 は廃止
再ネゴシエーション、圧縮	あり（制限しなければ危険）	廃止
ダウングレード保護	Finished のハッシュのみ。FALLBACK_SCSV	ServerHello.random 内のセンチネル値とトランスクリプト
ポスト量子鍵交換	利用不可	`X25519MLKEM768` と NIST 曲線のハイブリッド
Encrypted Client Hello	利用不可	RFC 9849

ハンドシェイク

TLS 1.2 は、先にネゴシエーションを行い、そのあとで鍵を交換します。クライアントが暗号スイートを列挙し、サーバーがその中から 1 つを選んで証明書と鍵交換パラメーターを送り、クライアントがキーシェア（key share）を送って、双方がハンドシェイクを完了します。アプリケーションデータが流れ始めるまでにラウンドトリップが 2 回かかり、証明書は平文のまま送られます。静的 RSA のスイートでは、クライアントがプレマスターシークレットをサーバー証明書の鍵で暗号化するため、後からその鍵を入手した者は、記録されたすべてのセッションを復号できます。

TLS 1.3 は推測から始めます。クライアントは最初のメッセージで、優先するグループのキーシェアを送ります。サーバーは自身のキーシェアで応答し、続けてすぐに、暗号化された拡張、証明書、CertificateVerify、Finished を送ります。クライアントはラウンドトリップ 1 回でデータを送信できます。再開したセッションでは 0-RTT のアーリーデータまで送れますが、そのデータについてはリプレイ保護が失われます。

次のスクリプトは、2026年10月20日に OpenSSL 3.6.5 で公開サーバーに対して実行したもので、同じクライアントが各バージョンを強制した場合の実際の結果を示しています。

1 台のサーバー、2 つのプロトコルバージョン

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

出力

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

このサーバーは AEAD を伴う ECDHE しか許可しないため、ここでは TLS 1.2 の接続も安全ですが、使えるのは古典的な X25519 に限られます。TLS 1.3 の接続では、ポスト量子ハイブリッドがネゴシエートされます。

TLS 1.3 で廃止されたものとその理由

2010年代の有名な TLS 攻撃のほぼすべてが、TLS 1.3 で削除された TLS 1.2 時代の機能を突いたものでした。

MAC-then-encrypt の CBC モード（BEAST、Lucky Thirteen、POODLE）：残っているのは AEAD 暗号だけです。
RC4（統計的な偏り）と 3DES（SWEET32）：廃止されました。
RSA による鍵輸送（Bleichenbacher のパディングオラクル、ROBOT。前方秘匿性なし）：廃止されました。
エクスポートグレードおよび任意の有限体の群（FREAK、Logjam）：残っているのは名前付きグループだけです。
再ネゴシエーションと圧縮（トリプルハンドシェイク、CRIME）：廃止されました。
トランスクリプトの一部だけに対する署名（TLS 1.2 の ServerKeyExchange はパラメーターにしか署名しません）：CertificateVerify がトランスクリプト全体に署名します。
署名での SHA-1 と MD5：廃止されました。

RFC 9846 は TLS 1.2 の実装に対する要件も厳しくしており、RFC 9325 は TLS 1.2 の安全なサブセットとして、AEAD を伴う ECDHE または DHE、拡張マスターシークレット（RFC 7627）、安全な再ネゴシエーションを挙げています。

TLS 1.3 だけが提供する機能

ポスト量子ハイブリッド鍵交換（X25519MLKEM768、RFC 10024）：主要ブラウザーでは 2024年後半から、OpenSSL では 3.5 から、デフォルトでネゴシエートされています。
Encrypted Client Hello（RFC 9849）：DNS の HTTPS レコードと組み合わせて使うと、サーバー名をネットワークから隠せます。
証明書の圧縮（RFC 8879）と委任クレデンシャル（RFC 9345）。
QUIC：TLS 1.3 のハンドシェイクを内部に組み込んでおり、HTTP/3 のトランスポートとして使われます。

コンプライアンスとポリシー

米国連邦政府のシステム：NIST SP 800-52 Rev. 2 は、政府の TLS サーバーに 2024年1月1日までに TLS 1.3 をサポートすることを求めており、承認済みのスイートを使う TLS 1.2 も認めています。
ペイメントカード環境：PCI DSS は 2018年6月30日以降、SSL と初期の TLS（1.0）を禁止しています。TLS 1.2 と 1.3 はどちらも許容されます。
IETF：RFC 8996 は 2021年に TLS 1.0 と 1.1 を非推奨にしました。ブラウザーは 2020年にこれらを削除しています。
ポスト量子への移行計画：NIST IR 8547（ドラフト）と CNSA 2.0 はハイブリッドまたはポスト量子の鍵確立を前提としており、これは TLS 1.3 でしか利用できません。

どちらを選ぶべきか

公開 Web サイトと API：TLS 1.3 を優先し、フォールバックとして安全なサブセットに絞った TLS 1.2 を使います。
内部サービス、サービスメッシュ、mTLS：TLS 1.3 のみを使います。
レガシーなクライアント（古い Android、組み込みデバイス、古いバージョンの Java と Windows）：ECDHE と AEAD に限定した TLS 1.2 を使い、これらのクライアントの廃止を計画します。
トラフィックを検査するミドルボックス：TLS 1.3、ECH、ポスト量子による大きな ClientHello に対応するにはアップデートが必要になると見込んでください。ミドルボックスのためにサーバー側の対応を遅らせるべきではありません。
ポスト量子の機密性が必要なすべての通信：ハイブリッドグループを使う TLS 1.3 を使います。

移行時の注意点

TLS ライブラリをアップグレードする：TLS 1.3 には OpenSSL 1.1.1 以降、デフォルトのポスト量子グループには 3.5 以降が必要です。最新の BoringSSL、Go、Java 11 以降、Windows Server 2022 以降も対応しています。
TLS 1.2 と並行して TLS 1.3 を有効にする：そのうえで、TLS 1.2 を ECDHE と AEAD のスイートに絞り込みます。nginx では ssl_protocols TLSv1.2 TLSv1.3; とし、ssl_ciphers のリストは短くします。TLS 1.3 のスイートは別に設定されるためです。
証明書と鍵を確認する：ハンドシェイクの署名には同じ鍵で PSS を使うため、RSA 証明書は TLS 1.3 でもそのまま使えます。ECDSA 証明書も変更なしで使えます。
0-RTT の扱いを決める：アーリーデータとして送られるリクエストのリプレイをアプリケーションが安全に処理できない限り、無効のままにします。
残っている TLS 1.2 のトラフィックを計測する：トラフィックがゼロになったところでは、無効にする日付を決めます。TLS 設定生成ツールは一般的なサーバー向けの設定を生成し、ドメイン一括チェッカーはホストがどのバージョンを受け付けるかを報告します。

参考資料

RFC 9846：TLS 1.3（§1.3 TLS 1.2 との相違点、§1.4 TLS 1.2 に影響する更新）
RFC 5246：TLS 1.2
RFC 9325：TLS と DTLS を安全に使うための推奨事項
RFC 8996：TLS 1.0 と TLS 1.1 の非推奨化
RFC 10024：TLS 1.3 向けのハイブリッド ML-KEM 鍵共有
RFC 9849：TLS Encrypted Client Hello
NIST SP 800-52 Rev. 2
PCI SSC：SSL と初期の TLS からの移行

比較表