TLS 1.3とは何ですか？

2018年標準化の最新TLSバージョン。ハンドシェイクを1-RTTに短縮し、Forward Secrecyを必須化しています。

SSL

TLS 1.3

Q: TLS 1.3の概要について教えてください

TLS 1.3 は、インターネット通信を暗号化する TLS プロトコルの最新バージョンです。RFC 8446 として 2018 年 8 月に標準化されました。前バージョンの TLS 1.2（RFC 5246、2008 年）から 10 年ぶりの改定であり、セキュリティと性能の両面で大幅な改善が行われています。

2025年12月16日更新

概要

TLS 1.3 は、インターネット通信を暗号化する TLS プロトコルの最新バージョンです。RFC 8446 として 2018 年 8 月に標準化されました。前バージョンの TLS 1.2（RFC 5246、2008 年）から 10 年ぶりの改定であり、セキュリティと性能の両面で大幅な改善が行われています。

TLS 1.2 からの主要な変更点は 3 つあります。ハンドシェイクのラウンドトリップ数を 2-RTT から 1-RTT に短縮し、接続確立のレイテンシを削減しました。すべての鍵交換でエフェメラル鍵を必須にし、Forward Secrecy を標準仕様として義務化しました。

加えて、RC4、3DES、CBC モード暗号、RSA 鍵交換、静的 Diffie-Hellman など安全性に問題のあるアルゴリズムを仕様レベルで完全に削除しました。

2025 年 6 月時点で、Qualys SSL Pulse の調査対象サイトの 75.3% が TLS 1.3 をサポートしています。Chrome、Firefox、Safari、Edge の現行バージョンはすべて TLS 1.3 に対応しています。

仕組み

TLS 1.3 はハンドシェイクを 1-RTT に短縮し、Forward Secrecy を必須化し、安全性の低いアルゴリズムを仕様レベルで削除しています。

1-RTT ハンドシェイク

TLS 1.2 では、クライアントとサーバーが暗号パラメーターを合意するまでに 2 往復（2-RTT）の通信が必要でした。TLS 1.3 ではこのハンドシェイクを 1 往復（1-RTT）に短縮しています。

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

クライアントが ClientHello を送信する。対応する暗号スイート一覧に加えて、鍵共有パラメーター（key_share 拡張）を同時に含める
サーバーが ServerHello で暗号スイートと鍵共有パラメーターを返す。サーバー証明書と Finished メッセージも同じフライトに含める
クライアントが Finished を返し、ハンドシェイクが完了する

TLS 1.2 ではクライアントがまず暗号パラメーターだけを送信し、サーバーの応答を待ってから鍵交換を行っていました。TLS 1.3 では鍵交換のパラメーターを ClientHello に先行して含めることで、1 往復分の通信を削減しています。100ms のネットワークレイテンシがある環境では、この変更により接続確立が 100〜200ms 短縮されます。

0-RTT 再接続（Early Data）

TLS 1.3 では、過去に接続したサーバーへの再接続時に 0-RTT（Zero Round Trip Time）モードを使用できます。前回のセッションで取得した PSK（Pre-Shared Key）を使い、ClientHello と同時に暗号化されたアプリケーションデータを送信します。

0-RTT は性能上の利点がありますが、セキュリティ上の制約があります。

リプレイ攻撃への脆弱性があります。攻撃者が 0-RTT データを記録して再送すると、サーバーが同じリクエストを複数回処理する可能性があります。決済処理や状態変更を伴う操作には適しません
Forward Secrecy が制限されます。0-RTT データの暗号鍵は PSK のみから導出され、新しい ECDHE 共有鍵は含まれません。PSK が漏洩した場合、0-RTT データは復号されます

このため、0-RTT は GET リクエストなど冪等な操作に限定して使用します。RFC 8446 もサーバー実装者に対してリプレイ対策の実装を求めています。

Forward Secrecy の必須化

TLS 1.2 では RSA 鍵交換が選択肢に含まれていました。RSA 鍵交換はサーバーの長期秘密鍵でセッション鍵を暗号化する方式であり、秘密鍵が漏洩すると過去のすべての通信が復号されます。

TLS 1.3 では RSA 鍵交換と静的 Diffie-Hellman が仕様から削除されました。鍵交換は ECDHE（楕円曲線 Diffie-Hellman Ephemeral）または DHE（Diffie-Hellman Ephemeral）に限定されています。エフェメラル鍵はセッションごとに生成・破棄されるため、サーバーの長期秘密鍵が漏洩しても過去の通信は保護されます。

この変更により、TLS 1.3 では Forward Secrecy が設定ミスで無効になることがありません。TLS 1.2 では管理者が意図せず RSA 鍵交換のスイートを有効にしてしまうリスクがありましたが、TLS 1.3 ではそのリスクが仕様レベルで排除されています。

暗号スイートの簡素化

TLS 1.2 では暗号スイートに鍵交換・認証・暗号化・ハッシュの 4 要素を含めていました。TLS 1.3 では鍵交換と認証をハンドシェイクの別パラメーター（supported_groups 拡張、signature_algorithms 拡張）に分離し、暗号スイートには AEAD 暗号とハッシュ関数だけを含める設計に変更されています。

RFC 8446 で定義された暗号スイートは 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）であり、暗号化と改ざん検知を同時に実行します。TLS 1.2 で問題となった CBC モードや RC4 は選択肢に含まれません。

削除されたアルゴリズムと機能

TLS 1.3 では以下のアルゴリズムと機能が仕様から完全に削除されました。

RSA 鍵交換（Forward Secrecy なし）
静的 Diffie-Hellman 鍵交換（Forward Secrecy なし）
CBC モード暗号（BEAST 攻撃、Lucky Thirteen 攻撃の対象）
RC4（RFC 7465 で 2015 年に禁止）
3DES（Sweet32 攻撃で 2016 年に脆弱性が公表）
SHA-1 ハッシュ（衝突攻撃が実証済み）
圧縮（CRIME 攻撃の原因）
再ネゴシエーション（実装の脆弱性が繰り返し発見）

設定例

Nginx で TLS 1.3 を有効化し、TLS 1.2 との併用や TLS 1.3 単独運用を行う構成を示します。

Nginx で TLS 1.3 を有効化

server {
    listen 443 ssl;
    server_name example.com;

    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.2 の暗号スイート（後方互換性のため維持）
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    # TLS 1.3 の暗号スイート（nginx 1.19.4 以降）
    ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # TLS 1.3 ではクライアント優先を推奨
    ssl_prefer_server_ciphers off;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

ssl_protocols に TLSv1.3 を含めることで TLS 1.3 が有効になります。OpenSSL 1.1.1 以降と nginx 1.13.0 以降の組み合わせが必要です。TLS 1.3 の暗号スイートを個別に制御するには nginx 1.19.4 以降の ssl_conf_command ディレクティブを使用します。

TLS 1.3 のみに限定する場合

server {
    listen 443 ssl;
    server_name example.com;

    ssl_protocols TLSv1.3;
    ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
    ssl_prefer_server_ciphers off;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

TLS 1.2 を完全に無効化すると、古いクライアント（Android 4.x、IE 11 など）が接続できなくなります。対象ユーザー層を確認した上で判断します。

確認方法

openssl でサーバーの TLS 1.3 対応を確認するには次のコマンドを使います。

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384

Protocol が TLSv1.3 であれば、サーバーは TLS 1.3 に対応しています。接続に失敗した場合は TLS 1.3 が有効になっていません。

サーバーが対応している TLS バージョンの範囲を確認するには、各バージョンを指定して接続テストを行います。

# TLS 1.2 での接続テスト
echo | openssl s_client -connect example.com:443 -servername example.com -tls1_2 2>/dev/null | grep "Protocol"

# TLS 1.3 での接続テスト
echo | openssl s_client -connect example.com:443 -servername example.com -tls1_3 2>/dev/null | grep "Protocol"

外部の視点からも確認したい場合は、Labee Dev Toolbox の SSL Cert API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ssl-cert?hostname=example.com"

{
  "success": true,
  "data": {
    "hostname": "example.com",
    "port": 443,
    "reachable": true,
    "status": 200
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

data.reachable が true であれば TLS ハンドシェイクが成立しています。false の場合、TLS バージョンの非互換や証明書の問題が原因である可能性があります。

よくある問題

TLS 1.3 の導入では、OpenSSL のバージョン不足や 0-RTT のリプレイリスク、古いクライアントとの互換性が障壁になります。

OpenSSL のバージョンが古く TLS 1.3 が使えない

TLS 1.3 を利用するには OpenSSL 1.1.1 以降が必要です。CentOS 7 の標準パッケージは OpenSSL 1.0.2 であり、TLS 1.3 に対応していません。openssl version で現在のバージョンを確認します。

openssl version

OpenSSL 1.1.1 未満の場合、OS のアップグレードまたは OpenSSL のソースビルドが必要です。nginx や Apache がリンクしている OpenSSL のバージョンも nginx -V や httpd -V で確認します。

TLS 1.3 を有効にしたのに使われない

ssl_protocols に TLSv1.3 を追加しても、nginx が古い OpenSSL にリンクされていると TLS 1.3 は動作しません。nginx が実際に使用している OpenSSL のバージョンは次のコマンドで確認できます。

nginx -V 2>&1 | grep "built with"

出力に OpenSSL 1.1.1 以降が表示されていない場合、nginx の再ビルドまたはパッケージの更新が必要です。

0-RTT を有効にしたままリプレイ攻撃を受ける

0-RTT（Early Data）を有効にすると、攻撃者が記録した 0-RTT データを再送してリクエストを重複実行させるリプレイ攻撃のリスクがあります。nginx では ssl_early_data ディレクティブで 0-RTT を制御します。

# 0-RTT を有効にする場合
ssl_early_data on;

# アプリケーション側でリプレイを検出するためのヘッダー
proxy_set_header Early-Data $ssl_early_data;

バックエンドアプリケーションは Early-Data: 1 ヘッダーを受け取った場合に、冪等でない操作（決済、データ更新など）を拒否する処理を実装する必要があります。リプレイ対策が困難な場合は ssl_early_data off（デフォルト）のままにします。

TLS 1.2 を無効化して古いクライアントが接続不能

TLS 1.3 のみを有効にすると、TLS 1.2 までしか対応していないクライアントが接続できません。Android 4.x、IE 11、Java 8（Update 261 未満）、OpenSSL 1.0.x 系のツールなどが該当します。サーバーのアクセスログで TLSv1.2 の接続割合を確認し、十分に低い水準になってから TLS 1.2 を無効化します。

ミドルボックスによるハンドシェイク妨害

一部の企業ネットワークやファイアウォール（ミドルボックス）が TLS 1.3 のハンドシェイクを正しく処理できず、接続が失敗するケースがあります。TLS 1.3 の策定過程でこの問題が発覚し、ClientHello のバージョンフィールドを 0x0303（TLS 1.2）のまま維持し、実際のバージョンは supported_versions 拡張で交渉する設計が採用されました。それでもミドルボックスが問題を起こす場合、サーバー側で TLS 1.2 を併用可能にしておくことで接続を維持できます。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す