TLS(トランスポート層セキュリティ).

TLS はアプリケーションプロトコル(HTTP・SMTP・IMAP・gRPC など)とトランスポート層(通常 TCP、QUIC では UDP)の間に位置し、平文の双方向ストリームを認証された暗号化チャネルへ変換します。ハンドシェイクでは X.509 証明書によりサーバー(必要に応じてクライアント)を認証し、暗号スイートを交渉してセッション鍵を導出します。前方秘匿性のため楕円曲線 Diffie–Hellman(ECDHE)を用いるのが一般的で、将来鍵が漏えいしても過去に記録された通信は復号できません。

バージョン。 現役は TLS 1.2(RFC 5246、2008)と TLS 1.3(RFC 8446、2018)です。TLS 1.3 は RC4・CBC モード・静的 RSA 鍵交換などの旧方式を廃し、ハンドシェイクを 1 往復に短縮、任意の 0-RTT 再開を追加しました。SSL 2.0/3.0 と TLS 1.0/1.1 は RFC 8996(2021)で正式に非推奨化されています。

現実の弱点。 TLS の破綻は設計ではなく実装で起きがちです。Heartbleed(CVE-2014-0160)は不正な heartbeat で OpenSSL サーバーのメモリ(秘密鍵を含む)を読み出しました。POODLE(CVE-2014-3566)は SSL 3.0 の CBC パディングを、BEAST(CVE-2011-3389)と Lucky Thirteen(CVE-2013-0169)は TLS 1.0 の CBC を突きました。これらが AES-GCM や ChaCha20-Poly1305 といった AEAD を用いる TLS 1.2+ への移行を後押ししました。

防御。 旧バージョンと脆弱なスイートを無効化し、OCSP ステープリングと Certificate Transparency を導入、HSTS を強制、鍵をローテーションし、サービス間通信やゼロトラスト設計では mTLS を採用します。

flowchart TD
  A[Client Hello:バージョン + 暗号スイート一覧 + key share] --> B[サーバー]
  B --> C[Server Hello:選択スイート + key share]
  C --> D[サーバーが X.509 証明書チェーンを送信]
  D --> E[クライアントが信頼された CA に対しチェーンを検証]
  E --> F[ECDHE 交換で共有秘密を導出]
  F --> G[双方がセッション鍵を導出]
  G --> H[暗号化されたアプリデータ:AES-GCM / ChaCha20-Poly1305]