TLS 1.2 と 1.3 の違い：1-RTT ハンドシェイク、暗号スイートの簡素化、0-RTT のリスク

約9分
TLSHTTPSセキュリティ

TLS 1.3 は RFC 8446（2018 年 8 月）で正式化され、すでに HTTPS 接続の 9 割以上で使われている状況です。1.2 からの変更は単なる暗号アルゴリズムの追加ではなく、ハンドシェイク手順そのものの再設計で、性能・セキュリティの両面で大きな改善があります。本記事では仕組みと運用上の影響を整理します。

ハンドシェイクの RTT 数

TLS 1.2 と 1.3 で最も明確に違うのは、初回接続時のラウンドトリップ数です。

TLS 1.2：2-RTT

Client                                  Server
  |                                       |
  |---- ClientHello -------------------->|
  |<--- ServerHello, Certificate,         |
  |     ServerKeyExchange, ServerHelloDone|
  |---- ClientKeyExchange,                |
  |     ChangeCipherSpec, Finished ------>|
  |<--- ChangeCipherSpec, Finished --------|
  |---- Application Data ---------------->|

クライアントがアプリケーションデータを送れるまで 2 RTT かかる。地球の反対側のサーバなら 200ms × 2 = 400ms 待つ。

TLS 1.3：1-RTT

Client                                  Server
  |                                       |
  |---- ClientHello (with key share) --->|
  |<--- ServerHello, EncryptedExtensions, |
  |     Certificate, CertificateVerify,   |
  |     Finished --------------------------|
  |---- Finished, Application Data ------>|

クライアントが ClientHello で鍵交換情報を一緒に送るため、1 RTT で済む。アプリケーションデータも Finished と一緒に送れる。

地球の反対側で 200ms 改善。クライアントから見た「最初の HTTP レスポンスまでの時間」が短くなり、特にモバイル・低速回線でユーザー体感が向上します。

暗号スイートの簡素化

TLS 1.2 の暗号スイート命名

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

複数の要素が連結されている：

要素例意味
鍵交換ECDHE楕円曲線 Diffie-Hellman
認証RSARSA 証明書
暗号AES_128_GCMAES-128 GCM モード
MACSHA256SHA-256

組み合わせは 100 種類以上あり、ほとんど使われない・脆弱なもの（RC4、3DES、MD5、SHA1、EXPORT 系）も含まれていました。これが下位互換性のための弱点を残し、設定ミスで脆弱な暗号が選ばれることがありました。

TLS 1.3 の暗号スイート命名

TLS_AES_128_GCM_SHA256

短くなり、暗号と MAC の組み合わせだけを指定。鍵交換と認証は別途交渉。

定義されている cipher suite は 5 種類のみ：

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

すべて AEAD（Authenticated Encryption with Associated Data）暗号で、設定ミスの余地がない。古い RC4 / 3DES / CBC モードはすべて削除。

削除された機能

TLS 1.3 で廃止された主な機能：

  • 静的 RSA 鍵交換（forward secrecy がない）→ ECDHE 必須
  • DSA 認証（実用上ほぼ使われない）
  • MD5 / SHA-1 ハッシュ（衝突攻撃あり）
  • CBC モード（Lucky 13 攻撃の母体）
  • RC4（複数の脆弱性）
  • EXPORT 暗号（FREAK 攻撃の原因）
  • 圧縮（CRIME 攻撃の母体）
  • 非 AEAD 暗号スイート

これらは過去のすべての TLS 攻撃（POODLE、BEAST、Lucky 13、FREAK、Logjam など）の母体で、根本から取り除かれた形です。

0-RTT モード（オプション）

TLS 1.3 は再接続時に 0-RTT でアプリケーションデータを送れる機能を持ちます：

Client                                  Server
  |                                       |
  |---- ClientHello (PSK) +               |
  |     0-RTT Application Data ---------->|
  |<--- ServerHello, ... Finished, ------|
  |     Server Application Data           |

過去のセッションから派生した Pre-Shared Key (PSK) を使い、初回パケットでアプリデータを送れる。RTT が完全に消えます。

0-RTT のリスク：リプレイ攻撃

0-RTT データは前向き秘密性の保証が弱く、攻撃者が同じパケットを再送できる（リプレイ攻撃）。サーバはこれを区別できないので、0-RTT は 冪等な操作にだけ使うべき：

  • ✓ GET リクエスト
  • ✗ POST /transfer-money のような副作用のある操作

主要なサーバ実装（nginx、HAProxy、Cloudflare）は 0-RTT を冪等メソッドのみ許可するオプションを提供。

証明書周りの変更

サーバ証明書の暗号化

TLS 1.2 ではサーバ証明書が平文で送信されていました。tcpdump で接続を観測すると、どのドメインに接続しているか丸見え。

TLS 1.3 では証明書は 暗号化された後に送られるので、ネットワーク観測者からは見えません（ただし SNI は別途課題、ECH 参照）。

Encrypted Client Hello (ECH)

ClientHello には SNI（Server Name Indication） という「どのサーバに接続するか」を平文で含むフィールドがあり、これは TLS 1.3 でも露出していました。これを暗号化するのが Encrypted Client Hello (ECH)。

ECH はまだ実験的で、Cloudflare・Firefox で部分実装されています。完全普及にはあと数年。

運用上の影響

サーバ側の TLS 1.3 化

Nginx 1.13.0+、Apache 2.4.37+ で TLS 1.3 サポート。OpenSSL 1.1.1+ が必要。

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;     # TLS 1.2 用
# TLS 1.3 のスイートは別途 ssl_conf_command で

クライアント側

主要ブラウザ（Chrome 70+、Firefox 63+、Safari 12.1+）はすべて TLS 1.3 対応。TLS 1.2 を完全に無効化するのは、IE 11 や古いモバイルへのアクセスを切る判断と同義。

証明書の選択

TLS 1.3 でも RSA 証明書は使えますが、ECDSA 証明書のほうが小さく、ハンドシェイクが速い。Let’s Encrypt は ECDSA 証明書を発行できるので、新規取得時は ECDSA を選ぶのが軽量。

ベンチマーク：実測の改善

主要な接続シナリオで TLS 1.2 → 1.3 移行による短縮：

シナリオTLS 1.2TLS 1.3削減
同一 DC 内（5ms RTT）10ms5ms5ms
国内（30ms RTT）60ms30ms30ms
大陸間（150ms RTT）300ms150ms150ms
0-RTT 再接続60ms（1.2 では資料による）0ms60ms 以上

「初回接続は数 100ms、再接続は 0ms」という極端な改善が、ECサイトの離脱率や検索ランキングにじわじわ効きます。

落とし穴

1. Middlebox との互換性

企業ネットワークの中間機器（社内 Proxy・SSL Inspection）が TLS 1.3 を正しく処理できないことがあります。「自宅では動くが社内からは動かない」というユーザーレポートの典型。

回避策として、TLS 1.3 では ClientHello に `TLS 1.2 のように見せるダミーフィールドを含めて中間機器を欺く設計（compatibility mode）になっています。多くの場合これで動くが、完全な保証はない。

2. SSLv3 / TLS 1.0 / TLS 1.1 の脆弱性

TLS 1.3 を有効にしても、TLS 1.0 / 1.1 / SSLv3 が無効化されていなければ攻撃者が古いバージョンに ダウングレードできます（ただし TLS 1.3 自体はダウングレード対策を強化）。すべての 1.0 / 1.1 を切り、TLS 1.2 と 1.3 のみを許可する。

3. クライアントの選択

TLS 1.3 は両端が対応していて初めて使えます。サーバ側で 1.3 を有効にしても、クライアントが 1.2 までしか喋らなければ 1.2 で接続。利用率を上げるには両側の更新が要る。

まとめ

TLS 1.3 は単なる「アルゴリズムの新しい版」ではなく、ハンドシェイクの再設計・脆弱機能の削除・暗号スイートの整理を含む大規模な変更です。1-RTT で初回接続が 1 RTT 短縮され、0-RTT で再接続が無 RTT 化、暗号スイートは 5 種類だけに整理されて設定ミスの余地がない、というのが主な利点。サーバ側の TLS 1.3 有効化と古いプロトコル無効化が、現代の Web サイトの最低ラインの設定です。