TLSとは：TLS1.3の特徴・脆弱性対策から実務向け設定と運用ベストプラクティス

2025年11月18日 最終更新日時 : 2025年11月18日 エバープレイ編集部

TLSとは — ネットワーク通信の「鍵」としての役割

TLS（Transport Layer Security）は、インターネット上でやり取りされるデータの機密性、完全性、認証を提供するためのプロトコルです。元々はSSL（Secure Sockets Layer）として登場し、その後IETFによって標準化・進化してTLSになりました。現在の主流はTLS 1.2とTLS 1.3で、特にTLS 1.3は設計の簡素化とセキュリティ向上を目的に2018年にRFC 8446として標準化されました。

TLSが提供するセキュリティ要素

  • 機密性（Confidentiality）：通信内容を暗号化し第三者の盗聴を防ぐ。
  • 完全性（Integrity）：メッセージが改ざんされていないことを保証する（MACやAEADを利用）。
  • 認証（Authentication）：通常はサーバー証明書を通じてサーバーの正当性を確認する。必要に応じてクライアント証明書（相互TLS）で相互認証も可能。

TLSの基礎要素（暗号方式と鍵管理）

TLSは複数の暗号プリミティブを組み合わせて動作します。大きく分けると次の要素があります。

  • 公開鍵暗号（非対称）：サーバー認証や鍵交換（例：RSA、ECDHEで用いる楕円曲線）に使われます。
  • 共通鍵暗号（対称）：実際の通信データの暗号化に使われます（例：AES-GCM、ChaCha20-Poly1305）。
  • ハッシュ／メッセージ認証：メッセージ改ざん検出に用いる（AEADアルゴリズムは暗号化と認証を同時に行う）。
  • 鍵導出：鍵交換で得た材料から通信で使う複数の鍵を導出する（TLS1.2はPRF、TLS1.3はHKDFを使用）。

ハンドシェイクの流れ（TLS1.2 と TLS1.3 の違い）

TLSの要となるのがハンドシェイクです。ここで暗号アルゴリズムや鍵の生成、サーバー認証が行われます。

  • TLS1.2の典型的な流れ
    • ClientHello（クライアントが対応するバージョン、サポートする暗号スイート、乱数等を送る）
    • ServerHello（サーバーが選択した暗号スイート、乱数等を返す）
    • サーバー証明書の送付（X.509チェーン）
    • （場合によって）サーバー鍵交換メッセージ、CertificateRequest
    • クライアントがプリマスターシークレットを送る（RSAの場合）またはECDHEで鍵共有
    • ChangeCipherSpec と Finished メッセージで暗号化通信へ移行
  • TLS1.3の特徴的流れ
    • ハンドシェイクが大幅に簡素化され、往復回数（RTT）が削減された（0-RTTオプションも存在）
    • 多くの古い暗号・機能（可逆なRSA鍵交換、静的DH、非AEADベースのMACなど）が廃止
    • 鍵導出にHKDFを利用し、前方秘匿性（PFS）を前提とした設計

よく使われる暗号スイートと推奨設定

近年のベストプラクティスは以下のとおりです：

  • TLSバージョンは可能な限りTLS 1.3を優先し、TLS 1.2までを残す場合はTLS 1.0/1.1を無効化する。
  • 鍵交換はECDHE（楕円曲線ディフィー・ヘルマン）を使い、一時鍵で前方秘匿性を確保する。推奨曲線はX25519やsecp256r1（P-256）。
  • 暗号アルゴリズムはAEAD（Authenticated Encryption with Associated Data）を使用：AES-GCM、AES-CCM、ChaCha20-Poly1305など。モバイル環境ではChaCha20-Poly1305が有利なケースがある。
  • サーバー証明書はRSA 2048ビット以上か、ECDSA（P-256など）を利用する。
  • サーバー側でHTTPヘッダーのHSTSを有効化し、OCSPステープリングを実装することで証明書確認のパフォーマンス/信頼性を向上させる。

証明書とPKI（公開鍵基盤）の実務的な注意点

TLSでサーバーの正当性を示すX.509証明書は、信頼された認証局（CA）によって発行されます。運用上の注意点は以下の通りです。

  • 有効期限管理：短い有効期間（例：90日間の自動更新）を採用することでキー漏洩時のリスクを低減する。Let's Encryptは自動化の代表例。
  • 鍵管理：プライベートキーは厳重に管理し、可能ならHSMに格納する。
  • 失効確認：CRLやOCSP、OCSPステープリングで失効確認をサポートする。ただしクライアント側のチェックが必ず行われるとは限らない点に注意。
  • チェーンの正しさ：中間証明書の提供、チェーン構築の確認を忘れない。
  • CAの信頼性リスク：過去にCAの誤発行や侵害が起きており、運用者は信頼するCAを厳選する必要がある。

セキュリティ上の歴史的脆弱性と教訓

TLS/SSLは長年にわたって多くの脆弱性や設計上の問題に直面してきました。代表的なものと対応は次の通りです。

  • BEAST（TLS1.0のCBCに関する攻撃）— ブラウザやサーバーのパッチ、TLS1.1/1.2への移行で緩和。
  • POODLE（SSLv3の脆弱性）— SSLv3を廃止するきっかけに。
  • Heartbleed（OpenSSLの実装バグ）— ライブラリのバグが重大な情報漏洩につながる事例。ライブラリの更新と秘密鍵の再発行が必要。
  • FREAK、Logjam、ROBOT 等— 古い暗号のサポートや不十分なパラメータに起因する攻撃。輸出版弱い暗号（export-grade）や小さなDHパラメータは無効化。
  • Lucky13（TLSのMAC実装に関するタイミング攻撃）— 実装面での難しさもあり、安全なライブラリを使用し続けることが重要。

これらの教訓から、プロトコルや実装の古い機能は速やかに廃止し、信頼できるライブラリ（OpenSSL、BoringSSL、LibreSSL、Mozilla NSS、LibreSSL等の最新版）を利用することが求められます。

実運用での具体的ベストプラクティス

  • サーバー側：TLS 1.3を有効化、TLS 1.0/1.1は無効化。TLS 1.2を残す場合は強力なスイートのみ許可。
  • Cipher優先順：ECDHE + AES-GCM/ChaCha20-Poly1305 を上位に置く。
  • 前方秘匿性（PFS）を必須化する。静的RSA鍵交換を避ける。
  • OCSPステープリング、HSTS、HPKP（現在は注意が必要）の理解と適切な運用。
  • 証明書の自動更新（ACMEプロトコル/Let's Encrypt等）と監視（証明書期限切れアラート）。
  • セキュリティヘッダー：HSTSやContent Security Policy等を併用してWebの安全性を高める。
  • ログと監視：TLSハンドシェイク失敗や証明書チェーンエラーを監視する。

特殊用途：相互TLS、0-RTT、SNIなど

  • 相互TLS（mTLS）：クライアント証明書を用いて双方向認証を行う。APIや内部システムの認証で利用される。
  • 0-RTT（TLS1.3）：セッション情報がある場合に一部データを0往復で送れるが、再生攻撃（リプレイ）に対する注意が必要。
  • SNI（Server Name Indication）：1つのIPで複数ドメインを扱う際に、クライアントが接続時にホスト名を送る拡張。ただし初期のSNI情報は平文で送られる（接続前のメタデータ）。

まとめ：TLSは常に進化する「運用と設計のセット」

TLSは単なる暗号化の仕組みではなく、プロトコル設計、暗号選択、証明書や鍵の運用、実装の安全性が総合的に絡み合うシステムです。最新のバージョン（TLS1.3）や推奨設定を採用すること、ライブラリと証明書の管理を怠らないこと、脆弱性情報に敏感であることが安全なサービス提供の鍵となります。

参考文献

カテゴリー
IT
前の記事
ジョン・ハイアット入門：名盤・代表曲と聴きどころを徹底ガイドNew!!
2025年11月18日
次の記事
John Hiatt入門：レコードで聴きたいおすすめアルバム6選と聴きどころNew!!
2025年11月18日