TLS 1.3 てぃーえるえす いちてんさん
簡単に言うとこんな感じ！
インターネットで情報を「鍵のかかった封筒」に入れて安全にやり取りする仕組みの、最新・最強バージョンだよ！古い弱い暗号を全部取り除いて、速くて安全になったのが TLS 1.3 なんだ！
TLS 1.3とは
TLS（Transport Layer Security） は、インターネット上の通信を暗号化して盗聴・改ざんを防ぐプロトコル（通信規約）です。ブラウザで「https://」から始まるURLにアクセスするとき、裏側で動いているのがこの TLS です。TLS 1.3 は 2018年に標準化された現行の最新バージョンで、前バージョン（TLS 1.2）と比べてセキュリティと速度の両面で大きく改善されています。
TLS 1.3 の最大の特徴は「古くて危険な暗号方式を思い切って削除した」点です。TLS 1.2 までは後方互換性のために弱い暗号も残っていましたが、1.3 ではそれらをばっさりカット。また、通信を始める前の「お互いを確認し合う手続き（ハンドシェイク）」を大幅に効率化し、接続にかかる往復回数を減らすことで表示速度も向上しました。
ビジネスの観点では、自社のWebサービスやAPIが TLS 1.3 に対応しているかどうかは、セキュリティ要件の確認や調達仕様書に記載する重要な項目になります。PCI DSS（クレジットカード業界のセキュリティ基準）など各種規格でも TLS 1.2 以上が必須とされており、1.3 対応はその上を行く「現時点でのベストプラクティス」と言えます。
TLS 1.3の主な改善点
TLS 1.2 と TLS 1.3 を並べると、変更の大きさがよくわかります。
| 項目 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| ハンドシェイク往復数 | 2-RTT（2往復） | 1-RTT（1往復）※初回 |
| 再接続時 | 1-RTT | 0-RTT（往復ゼロも可能） |
| 使える鍵交換方式 | RSA など複数（弱いものも残存） | DHE / ECDHE のみ（前方秘匿性を保証） |
| 使える対称暗号 | AES-CBC など古いものも含む | AES-GCM / ChaCha20-Poly1305 のみ |
| ハンドシェイクの暗号化 | 一部平文 | 全体を暗号化 |
| 廃止された機能 | ― | RC4, 3DES, MD5, SHA-1, RSA鍵交換 など |
「前方秘匿性（PFS）」とは
前方秘匿性（Perfect Forward Secrecy） とは、「過去の通信記録が後から解読されない」性質のことです。TLS 1.2 の一部の設定では、サーバーの秘密鍵が漏れると過去の通信も復号されてしまうリスクがありました。TLS 1.3 では ECDHE（楕円曲線ディフィー・ヘルマン鍵交換） を必須にすることで、セッションごとに異なる鍵を生成し、万が一の漏洩時も「そのセッション以外は安全」な状態を保証します。
0-RTT とは（速さの秘密）
一度接続したことのあるサーバーへの再接続では、0-RTT（ゼロ・ラウンドトリップタイム） という仕組みを使い、最初の通信データを「お互いを確認し合う前」に送り始めることができます。これにより体感速度が向上しますが、リプレイ攻撃（同じデータを再送する攻撃）のリスクがあるため、べき等でない操作（購入・送金など）への適用には注意が必要です。
ハンドシェイクの流れ（TLS 1.2 vs 1.3）
TLS 1.2 では接続確立まで 2往復（2-RTT） かかっていたところ、TLS 1.3 では 1往復（1-RTT） で完了します。
歴史と背景
- 1994年 — Netscape が SSL 2.0 を開発。HTTPS の原型が登場
- 1999年 — IETF が SSL を引き継ぎ TLS 1.0（RFC 2246）として標準化
- 2006年 — TLS 1.1（RFC 4346）公開。CBC 攻撃対策を強化
- 2008年 — TLS 1.2（RFC 5246）公開。SHA-256 対応など現代的な暗号を追加
- 2011〜2016年 — BEAST・CRIME・POODLE・DROWN など TLS 1.2 以前の脆弱性が次々と発覚。抜本的な刷新が求められる
- 2018年8月 — TLS 1.3（RFC 8446）正式公開。約4年の議論・28回のドラフト改訂を経て策定
- 2020年 — PCI DSS v3.2 により TLS 1.0 が禁止。TLS 1.2 以上が業界標準に
- 2021年 — IETF が TLS 1.0 / 1.1 を正式に非推奨（RFC 8996）と宣言
- 現在 — 主要ブラウザ・クラウドサービスは TLS 1.3 に対応済み。新規システム構築では 1.3 が事実上のスタンダード
TLS 1.3 が廃止した暗号と、残した暗号
TLS 1.3 の「思い切った削除」が何を意味するか、対比表で確認しましょう。
| 種別 | TLS 1.2 まで使えた（危険なもの） | TLS 1.3 で許可される暗号 |
|---|---|---|
| 鍵交換 | RSA静的鍵交換（前方秘匿なし） | ECDHE / DHE のみ |
| 対称暗号 | RC4, 3DES, AES-CBC | AES-GCM, AES-CCM, ChaCha20-Poly1305 |
| ハッシュ | MD5, SHA-1 | SHA-256 以上 |
| 署名 | RSA-PKCS1v1.5 | RSA-PSS, ECDSA, EdDSA |
| 圧縮 | TLS 圧縮（CRIME攻撃の原因） | 廃止 |
覚え方のポイント：「TLS 1.3 = 古い鍵をぜんぶ捨てた引っ越し」
TLS 1.2 の家には「古くて危ない鍵（弱い暗号）」が残っていた。TLS 1.3 は引っ越しして新居には必要最低限の強い鍵だけ持ち込んだイメージ。選択肢が減ったぶん、設定ミスによる脆弱化も起きにくくなっています。
実務での確認ポイント
システム調達・選定の際に確認すべき TLS 1.3 関連の項目をまとめます。
| 確認項目 | 内容 |
|---|---|
| サーバー対応状況 | Apache 2.4.36+, Nginx 1.13+, IIS (Windows Server 2022+) など |
| クライアント対応 | Chrome 70+, Firefox 63+, Safari 12.1+, Edge 79+ |
| ロードバランサー | AWS ALB・Cloudflare・Azure Front Door は TLS 1.3 対応済み |
| 0-RTT の使用可否 | 冪等でないAPI（決済・送信系）では無効化を推奨 |
| TLS 1.0/1.1 の無効化 | PCI DSS 準拠・セキュリティ要件として確認 |
| 証明書の種類 | TLS 1.3 は RSA 2048bit 以上 / ECDSA P-256 以上を推奨 |
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| RFC 8446 | TLS 1.3 の本体仕様 |
| RFC 5246 | TLS 1.2 の仕様（旧バージョン・比較参照用） |
| RFC 8996 | TLS 1.0 / 1.1 の非推奨化宣言 |
| RFC 8998 | TLS 1.3 における SM4 暗号スイートの追加 |
| RFC 9001 | QUIC における TLS 1.3 の使用方法 |
| RFC 7301 | ALPN（Application-Layer Protocol Negotiation）。TLS 上でのプロトコル交渉に使用 |
関連用語
- TLS（Transport Layer Security） — インターネット通信を暗号化する標準プロトコルの総称
- SSL（Secure Sockets Layer） — TLS の前身。現在は非推奨だが名称として残ることが多い
- PKI（公開鍵基盤） — TLS の証明書を発行・管理する仕組み全体
- 電子証明書（サーバー証明書） — TLS ハンドシェイクでサーバーの正当性を証明するデジタル証明書
- HTTPS — HTTP に TLS を組み合わせた暗号化通信プロトコル
- ECDHE（楕円曲線ディフィー・ヘルマン鍵交換） — TLS 1.3 で必須となった前方秘匿性を実現する鍵交換方式
- QUIC — TLS 1.3 を内包した次世代トランスポートプロトコル。HTTP/3 の基盤
- PCI DSS — クレジットカード業界のセキュリティ基準。TLS バージョン要件を規定