TLS/SSL史 SSL 2.0→TLS 1.3 1995-2026（ティーエルエス史）
TLS Transport Layer Security 30年史 1995-2026。SSL 1.0 (1994 Netscape Taher Elgamal Father of SSL・公開せず)・SSL 2.0 (1995年2月 Netscape・初公開)・SSL 3.0 (1996年11月 RFC 6101・POODLE Attack 2014年破られる)→IETF統合・TLS 1.0 (1999年1月 RFC 2246 SSL 3.1相当)→TLS 1.1 (2006 RFC 4346)→TLS 1.2 (2008年8月 RFC 5246・GCM AEAD・10年Stand)→TLS 1.3 (2018年8月 RFC 8446 New Era・1-RTT Handshake+0-RTT Resume・PFS Perfect Forward Secrecy必須・ChaCha20+AES-GCM Suite限定・Removed: SHA-1+RSA Key Exchange+CBC+RC4 全廃)・QUIC (2012 Google Jim Roskind→2021 IETF RFC 9001・UDP+TLS 1.3 0-RTT組込・HTTP/3基盤)・OpenSSL (1998 Eric Young SSLeay→OpenSSL Project FOSS・現3.4 2024)→Heartbleed Bug (2014年4月 Neel Mehta Google→Codenomicon・$10B+被害推定)→OpenSSL 1.0.1g Patch・LibreSSL (2014 OpenBSD Theo de Raadt OpenSSL Fork)・BoringSSL (Google 2014 OpenSSL Fork内部利用)・mbed TLS (旧 PolarSSL ARM Embedded)・wolfSSL (旧CyaSSL)・rustls (2016 Joseph Birr-Pixton Rust Memory Safe・現rustls 0.23 2024)・Mutual TLS mTLS (Client+Server Cert)・Certificate Transparency (2013 Google Ben Laurie・Public Log)・Let's Encrypt (2014年11月 EFF+Mozilla+Cisco・Free DV Cert・5億+ Cert発行 2024・ACME RFC 8555)・cert-manager Kubernetes・Cloudflare Universal SSL (2014 Free)・AWS Certificate Manager (2016 Free DV)・SNI Server Name Indication (RFC 6066)+ESNI Encrypted SNI→ECH Encrypted Client Hello (2024 RFC 9000 Cloudflare先行)・Post-Quantum TLS: Kyber+Dilithium (2024 Cloudflare+Google統合)・¥0 OSS Free 2026 LE+Cloudflare→Universal HTTPS時代。
概要
TLS（Transport Layer Security）は、インターネット上で機密性・完全性・認証を保証するためのプロトコルである。1995 年に Netscape が SSL 2.0 を公開して以来、IETF によって標準化が進められ、現在は TLS 1.3（2018）をベースに QUIC（UDP 上で TLS 1.3 を実装したプロトコル）やポストクォンタム鍵交換が検討されている。1994 年に公開されなかった SSL 1.0 から始まり、2026 年には「Universal HTTPS」時代へと移行する見込みである。
主な特徴・仕組み
| 版 | 公開年 | 主要変更点 | 代表的な数値 |
|---|---|---|---|
| SSL 2.0 | 1995 | 初公開、CBC モードのみ | 512‑bit RSA |
| SSL 3.0 | 1996 | 1 つのハンドシェイク、MAC 追加 | 256‑bit MD5 |
| TLS 1.0 | 1999 | RSA‑PKCS1 v1.5 で鍵交換 | 1024‑bit RSA |
| TLS 1.1 | 2006 | CBC 攻撃対策 | 128‑bit AES |
| TLS 1.2 | 2008 | GCM AEAD、SHA‑256 | 256‑bit AES‑GCM |
| TLS 1.3 | 2018 | 1‑RTT ハンドシェイク、0‑RTT | 128‑bit ChaCha20-Poly1305 |
| QUIC | 2012 | UDP + TLS 1.3 | 0‑RTT で 1 ms 以内 |
| Post‑Quantum TLS | 2024 | Kyber‑512 + Dilithium‑2 | 256‑bit PQC |
ハンドシェイク
TLS 1.3 では「ClientHello → ServerHello → EncryptedExtensions → Certificate → CertificateVerify → Finished」の 1‑RTT で完結し、0‑RTT で再接続時の遅延を 0 ms 近くに抑える。QUIC ではさらに UDP の再送制御とマルチプレクシングを組み合わせ、平均 1 ms 以内のレイテンシを実現している。
鍵交換
TLS 1.3 では Diffie–Hellman で PFS（Perfect Forward Secrecy）を必須化。ECDHE‑P‑256 がデフォルトで、AES‑GCM か ChaCha20‑Poly1305 のいずれかが選択される。SHA‑1 と RSA‑PKCS1 v1.5 は完全に除外され、RC4 と CBC モードは廃止。
証明書
証明書は X.509v3 で、拡張キー使用（ServerAuth, ClientAuth）をサポート。Let’s Encrypt が 2014 年に導入した ACME（RFC 8555）により、DV 証明書を 5 億件以上発行。2025 年には「Certificate Transparency Log」を自動検証する機能が標準化され、証明書の不正発行をリアルタイムで検知できるようになった。
具体例・対応製品（テーブル必須）
| 製品名 | 型番/バージョン | 対応 TLS バージョン | QUIC/HTTP 3 | 主要機能 | 参考数値 |
|---|---|---|---|---|---|
| OpenSSL | 3.0.8 | TLS 1.3 | なし | FIPS 140‑2 互換 | 256‑bit AES‑GCM |
| BoringSSL | 2025‑04 | TLS 1.3 | あり（QUIC 1.0） | 内部使用、Google Cloud | 0‑RTT 0.8 ms |
| LibreSSL | 3.8 | TLS 1.3 | なし | OpenSSL からのフォーク | 128‑bit ChaCha20 |
| mbed TLS | 2.28 | TLS 1.3 | なし | ARM Cortex‑M 用 | 32‑bit ARMv7 |
| wolfSSL | 5.0 | TLS 1.3 | あり（HTTP 3） | IoT 専用 | 128‑bit AES‑GCM |
| rustls | 0.23 | TLS 1.3 | なし | Rust で安全設計 | 0‑RTT 1 ms |
| Cloudflare Universal SSL | 2026 | TLS 1.3 | あり（HTTP 3） | CDN + DDoS 防御 | 0‑RTT 0.5 ms |
| AWS Certificate Manager | 2025 | TLS 1.3 | あり（HTTP 3） | 無料 DV 証明書 | 1 ms 以内 |
| cert‑manager (Kubernetes) | 2026 | TLS 1.3 | なし | 自動証明書更新 | 10 s 以内 |
| Google QUIC (QUIC 1.0) | 2024 | TLS 1.3 | あり（HTTP 3） | 0‑RTT 0.6 ms |
選び方・注意点
- TLS 1.3 の採用
- 既存システムが TLS 1.2 しかサポートしない場合、レガシーサーバーを更新するか、プロキシで TLS 1.3 を終端する。
- QUIC の利用
- 高速化が必要なリアルタイムアプリ（VoIP、ゲーム）では QUIC を採用。UDP のファイアウォール設定を確認。
- 証明書の自動更新
- Let’s Encrypt の ACME を利用する場合、サーバー側に ACME クライアント（cert‑manager 等）が必要。
- Post‑Quantum への準備
- 2025 年以降は PQC キー交換（Kyber‑512）を検討。現在は実験的であり、ハードウェアアクセラレーションが必要。
- パフォーマンス監視
- 0‑RTT の再利用は再送時に失敗するとロールバックが発生。監視ツールで失敗率を 1 % 未満に抑える。
関連用語との違い
| 用語 | 定義 | 主な違い |
|---|---|---|
| SSL | 1990 年代に Netscape が開発したプロトコル。 | TLS の前身で、現在は非推奨。 |
| TLS | 1999 年に IETF が標準化したプロトコル。 | SSL 3.0 の拡張版。 |
| TLS 1.3 | 2018 年に RFC 8446 で定義。 | 1‑RTT ハンドシェイク、0‑RTT、PFS 必須。 |
| QUIC | Google が開発し、IETF が RFC 9001 で標準化。 | UDP 上で TLS 1.3 を実装し、HTTP 3 をベース。 |
| mTLS | Mutual TLS の略。 | クライアントも証明書を提示。 |
よくある質問 (FAQ)
-
TLS 1.3 で 0‑RTT を使うとセキュリティリスクは？
0‑RTT は再送時に鍵が再生成されるため、鍵漏洩のリスクは低いが、再送失敗時にロールバックが必要。実装側でロールバックを許容できるか確認すること。 -
Let’s Encrypt の無料証明書は有効期限が 90 日と短いのに、どのように運用するの？
ACME クライアントを自動化し、証明書更新を 60 日前に実行。多くの CDN（Cloudflare、AWS ACM）では自動更新が組み込まれている。 -
Post‑Quantum TLS を導入する際に注意すべき点は？
PQC 鍵交換は現在実験的で、鍵長が長くなるため CPU 負荷が増大。ハードウェアアクセラレーション（AES‑NI、SHA‑NI）がある環境でのテストが必須。
まとめ
1995 年の SSL 2.0 から 2026 年の「Universal HTTPS」へ至るまで、TLS はプロトコル設計と実装の両面で大きく進化してきた。TLS 1.3 での 1‑RTT ハンドシェイクと PFS の必須化、QUIC による UDP 上での高速化、そして Let’s Encrypt と ACME による証明書自動化は、インターネット全体のセキュリティとパフォーマンスを向上させた。2025‑2026 年の動向としては、Encrypted Client Hello（ECH）での SNI 隠蔽、ポストクォンタム鍵交換の実装、そしてクラウドベースの自動証明書管理が主流となる見込みである。今後は、これらの技術を組み合わせて、ほぼ全ての通信が TLS 1.3 以上で保護される時代が到来する。