TLS 1.3はTransport Layer Securityプロトコルの現在のバージョンで、2018年8月にRFC 8446として公開されました。漸進的な更新ではなく根本的な再設計であり、HTTPSを以前のどのバージョンよりも高速、シンプル、安全にします。
2026年時点で、Webサイトの62%がTLS 1.3をサポートしており、すべての主要ブラウザが2018年からサポートしています。
TLS 1.2からの変更点
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| ハンドシェイク | 2ラウンドトリップ | 1ラウンドトリップ（1-RTT） |
| 再開接続 | 1ラウンドトリップ | 0-RTT（最初のメッセージでデータ） |
| 暗号スイート | 37（多くが弱い） | 5（すべて安全） |
| 前方秘匿性 | オプション | 必須 |
| RSA鍵交換 | サポート | 削除 |
| 静的DH | サポート | 削除 |
| CBC暗号 | サポート | 削除 |
| RC4, DES, 3DES | 一部の設定 | 削除 |
| ハンドシェイク内のMD5, SHA-1 | 許可 | 削除 |
| ハンドシェイク内の証明書 | 平文（可視） | 暗号化 |
| 圧縮 | オプション | 削除（CRIME防止） |
| 再ネゴシエーション | サポート | 削除 |
設計哲学：設定ミスの可能性があるものをすべて削除。TLS 1.2は37の暗号スイートがあります — 安全なものも壊れたものもあります。TLS 1.3は5つ、すべて安全です。
TLS 1.3の5つの暗号スイート
TLS_AES_256_GCM_SHA384 ← 最強、最も一般的
TLS_AES_128_GCM_SHA256 ← 広く使用、わずかに高速
TLS_CHACHA20_POLY1305_SHA256 ← ARM/モバイルに最適（AES-NIなし）
TLS_AES_128_CCM_SHA256 ← IoT/組み込み
TLS_AES_128_CCM_8_SHA256 ← IoT/組み込み（短いタグ）これらを誤設定することはできません — すべてが強い鍵を持つAEAD暗号です。TLS 1.2のような「うっかり弱い暗号を有効にする」リスクはありません。
1-RTTハンドシェイク：なぜ高速か
TLS 1.2ハンドシェイク（2ラウンドトリップ）：
Client → Server: ClientHello (supported ciphers)
Server → Client: ServerHello, Certificate, KeyExchange
Client → Server: KeyExchange, ChangeCipherSpec, Finished
Server → Client: ChangeCipherSpec, Finished
[暗号化データが流れる前に4メッセージ]TLS 1.3ハンドシェイク（1ラウンドトリップ）：
Client → Server: ClientHello + KeyShare
Server → Client: ServerHello + KeyShare + Certificate + Finished
Client → Server: Finished
[1ラウンドトリップ後に暗号化データが流れる]クライアントが最初のメッセージで鍵共有パラメータを送信するため、サーバーがアルゴリズムを指定するのを待つ必要がありません。これによりハンドシェイクが2ラウンドトリップから1に短縮されます。
0-RTT再開
再訪問者（以前接続したことがある）の場合、TLS 1.3は0-RTTをサポートします — 最初のメッセージで暗号化されたアプリケーションデータを送信：
Client → Server: ClientHello + KeyShare + EarlyData (encrypted request)
Server → Client: ServerHello + responseハンドシェイク完了前にリクエストが送信されます。トレードオフ：0-RTTデータはリプレイ攻撃に脆弱なため、べき等なリクエスト（GETのみ、POSTではない）にのみ使用すべきです。
必須の前方秘匿性
TLS 1.2ではRSA鍵交換を使用できました — サーバーの長期RSA鍵がプリマスターシークレットを直接復号します。誰かがトラフィックを記録し、後でサーバーの秘密鍵を盗めば、過去のすべての通信を復号できます。
TLS 1.3はRSA鍵交換を完全に削除しました。すべての鍵交換は一時的なDiffie-Hellman（ECDHE）を使用します — 接続ごとに固有の鍵ペアが生成されます。サーバーの秘密鍵を盗んでも過去のセッションの復号には役立ちません。前方秘匿性の詳細 →
暗号化された証明書
TLS 1.2では、サーバーの証明書（ドメイン名を含む）はハンドシェイク中に平文で送信されます。受動的な観察者はどのサイトに接続しているか見ることができます。
TLS 1.3では、証明書はハンドシェイク鍵が導出された後に送信されます — 暗号化されています。SNI（Server Name Indication）はTLS 1.3ではまだ可視ですが、**Encrypted Client Hello（ECH）**が将来それも暗号化します。
TLS 1.3を有効にする方法
既に有効か確認
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# 期待値: TLSv1.3Nginx（1.13以上 + OpenSSL 1.1.1以上）
ssl_protocols TLSv1.2 TLSv1.3;TLS 1.3は最新のNginxではデフォルトで有効です — 無効にしなければ動作します。
Apache（2.4.37以上 + OpenSSL 1.1.1以上）
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1これでTLS 1.2と1.3が有効になります。
OpenSSLバージョンを確認
openssl version
# 必要: OpenSSL 1.1.1+ for TLS 1.3 supportOpenSSLが古い場合は、アップグレードするかOSをアップグレードしてください。
TLS 1.3のみを強制すべきですか？
まだです。 約38%のサイトがTLS 1.3をサポートしておらず、一部のクライアント（企業プロキシ、Java 8、古い組み込みシステム）はTLS 1.2のみをサポートしています。今日TLS 1.2を廃止すると一部のユーザーをロックアウトします。
推奨設定： TLS 1.2と1.3の両方をサポート。最新クライアントにはTLS 1.3の速度を提供しつつ互換性を維持します。これはGoogle、Cloudflare、ほとんどの主要サイトが行っていることです。
よくある質問
TLS 1.3に新しい証明書が必要ですか？
いいえ。同じ証明書がTLS 1.2と1.3で動作します。証明書はプロトコルに依存しません — どのTLSバージョンが使用するかに関係なく、公開鍵とCA署名を含んでいます。
TLS 1.3はパフォーマンスに影響しますか？
はい、プラスの方向に。1-RTTハンドシェイクは初回接続で50〜100ms節約します。0-RTT再開は再訪問者のハンドシェイク遅延を完全に排除します。HTTP/2（HTTPSが必要）と組み合わせると、TLS 1.3サイトは測定可能なほど高速です。
TLS 1.2はまだ安全ですか？
はい、AEAD暗号スイート（AES-GCM、ChaCha20-Poly1305）とECDHE鍵交換を使用すれば。TLS 1.2のCBC暗号は避けてください — 攻撃（BEAST、Lucky13）に脆弱です。TLS 1.3の方が優れていますが、最新暗号を使用したTLS 1.2は安全なままです。
TLS 1.4はありますか？
TLS 1.4の計画はありません。IETFは予見可能な将来にわたってTLS 1.3をターゲットと考えています。次の大きな変更は、既存のECDHEとのハイブリッドとしてポスト量子鍵交換（ML-KEM）を組み込むことです — これはTLS 1.3内で行われ、新しいバージョンとしてではありません。