SSL/TLS完全ガイド：TLS 1.3・証明書運用と安全な設定ベストプラクティス
エバープレイ編集部SSL/TLSとは — 概要
SSL（Secure Sockets Layer）およびTLS（Transport Layer Security）は、ネットワーク上でデータを安全に送受信するためのプロトコル群です。主にウェブブラウザとサーバ間の通信（HTTPS）で使われますが、SMTP、IMAP、FTP、VPNなど多くのアプリケーションプロトコルの下位で利用されます。TLSは技術的にSSLの後継であり、現在は「TLS」が標準用語です。
歴史とバージョン
- SSL 2.0 / 3.0：古いバージョンで多数の脆弱性が発見され、現在は廃止されています（特にSSLv3はPOODLE攻撃で危険）。
- TLS 1.0 / 1.1：TLSの初期版。近年では脆弱性や設計上の問題により非推奨化され、主要ブラウザや標準でサポートが終了しています。
- TLS 1.2（RFC 5246）：広く使われる安定版。AEAD暗号や柔軟なハンドシェイクをサポート。
- TLS 1.3（RFC 8446, 2018）：ハンドシェイクの簡素化、不要な機能の削除（静的RSA鍵交換など）、0-RTTの導入による高速化とセキュリティ改善。
TLSの基本的な役割
- 機密性（Confidentiality）：通信内容を暗号化して第三者に読まれないようにする。
- 認証（Authentication）：サーバ（および必要ならクライアント）の正当性を証明する。通常は公開鍵証明書（X.509）と信頼された認証局（CA）による。
- 完全性（Integrity）：通信内容が改ざんされていないことを保証する（MACまたはAEADで実現）。
仕組みの深掘り：レコード層とハンドシェイク
TLSは大きく「レコード層」と「ハンドシェイク層」に分かれます。ハンドシェイクで暗号アルゴリズムや鍵交換方式を合意し、セッション鍵を確立します。レコード層は実際のアプリケーションデータを暗号化・認証して送受信します。
ハンドシェイクの流れ（TLS 1.2の代表的なパターン）は概ね次の通りです：
- ClientHello：クライアントが対応可能なプロトコルバージョン、暗号スイート、乱数を送信。
- ServerHello：サーバが選択したパラメータを返す。サーバ証明書も送られる。
- 証明書検証：クライアントは証明書チェーンを検証し、CAの信頼ルートを確認する。
- 鍵交換：キー導出のための秘密情報を交換（RSA、DHE、ECDHE など）。ここで生成される共有鍵からセッション鍵を導出。
- Finishedメッセージ：双方が鍵で保護されたFinishedメッセージを交換し、ハンドシェイクの整合性を確認。
TLS 1.3ではハンドシェイクがさらに短縮され、初回接続でも1往復（1-RTT）、再接続時には0-RTTでデータ送信が可能です（ただし0-RTTには再生攻撃リスクがある）。またTLS 1.3では静的RSA鍵交換、古い暗号が廃止されています。
鍵交換と完全前方秘匿性（PFS）
鍵交換方式はセキュリティ性に直結します。過去の「RSA鍵交換」は、サーバの秘密鍵が漏えいすると過去の通信も復号できる問題がありました。これに対し、DHE（Diffie-Hellman）やECDHE（楕円曲線Diffie-Hellman）を用いるとセッションごとに一時的な鍵が生成され、サーバ秘密鍵が漏れても過去のセッションは守られる（Perfect Forward Secrecy）ため推奨されます。実運用ではECDHEが効率と安全性から一般的です。
暗号アルゴリズムとモード（推奨）
- AEAD方式（Authenticated Encryption with Associated Data）：AES-GCM、ChaCha20-Poly1305などが推奨。暗号化と認証を同時に行い安全性が高い。
- 鍵長・曲線選択：AESは128/256ビット、楕円曲線ではsecp256r1（P-256）やX25519が広く使われる。
- 古い暗号（RC4、MD5、SHA-1ベースのMAC、NULL暗号など）は脆弱で無効化すべき。
証明書と認証局（CA）、証明書の運用
サーバ認証はX.509証明書によって行われ、信頼できるCAが発行します。証明書には公開鍵、所有者情報、有効期限、SAN（Subject Alternative Name）などが含まれます。近年はCN（Common Name）ではなくSANでの名前照合が実務上の標準です。
証明書発行の自動化にはACMEプロトコル（例：Let's Encrypt）が広く使われ、短期間の自動更新で運用負荷とリスクを低減します。証明書の失効確認にはCRL（証明書失効リスト）やOCSP、OCSP stapling（サーバ側でOCSP応答を添付）があります。証明書透明性（Certificate Transparency, CT）ログにより不正発行の検出も行われます。
よくある攻撃と対策
- 中間者攻撃（MitM）：有効な証明書と鍵の不正使用を許すと成立。対策は信頼できるCA管理、証明書透明性、HSTSなど。
- ダウングレード攻撃：クライアント／サーバを古い脆弱なバージョンに落とす。TLS 1.3やTLS_FALLBACK_SCSVなどで防止。
- プロトコル固有の脆弱性：POODLE（SSLv3）、BEAST、CRIME、BREACH、Lucky13など。最新のプロトコル・安全な暗号で対策。
- 実装バグ：Heartbleed（OpenSSLのCVE-2014-0160）のようなライブラリの脆弱性は迅速なアップデートが必須。
実運用上のベストプラクティス
- プロトコル：TLS 1.2以上をサポートし、可能であればTLS 1.3を有効化する。
- 暗号スイート：AEAD（AES-GCM、ChaCha20-Poly1305）、ECDHE を優先。古い暗号は無効化。
- 証明書：短寿命の証明書を自動更新（例：Let's Encrypt）し、SANを正しく設定する。ルート/中間証明書チェーンを正しく配置。
- OCSP stapling、HSTS（Preload登録を含む）を導入して中間者やDowngradeリスクを低減。
- Perfect Forward Secrecy（PFS）を有効化。
- 定期的なスキャン：SSL/TLS設定スキャナー（例：Qualys SSL Labs）で評価し、脆弱点を修正。
- ライブラリの更新：OpenSSL/LibreSSL/BoringSSLなどTLS実装は定期的に更新し、既知の脆弱性を即時対応。
TLSの運用で注意すべき点
証明書のチェーンエラー、サーバ名（SNI）未対応、古いクライアントとの互換性など運用上の問題が発生します。特にレガシークライアント対応のために古い暗号やプロトコルを残すと全体の安全性を損なうため、ビジネス要件とリスクを天秤にかけて段階的に切り捨てる計画が必要です。
TLSの将来
TLSは性能改善（TLS 1.3の0-RTTなど）とセキュリティ強化の両面で進化しています。量子コンピュータ耐性の必要性が高まる中、ポスト量子暗号（PQC）との共存やハイブリッド方式が研究・標準化の対象となっています。将来的には既存のTLSスタックにポスト量子アルゴリズムを組み込む移行が進む見込みです。
まとめ
TLSはインターネット上の機密性・認証・整合性を実現する基盤技術であり、その正しい設定と運用は現代のWebセキュリティに不可欠です。最新バージョン（TLS 1.3）の採用、PFSの導入、AEAD暗号の使用、証明書の自動化と失効確認機構の整備、ライブラリの迅速なアップデートが現場での重要ポイントです。定期的な評価と継続的な改善を行うことで、安全な通信基盤を維持できます。
参考文献
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2
- Let's Encrypt（ACMEによる証明書自動発行）
- OpenSSL プロジェクト
- OWASP — Transport Layer Protection Cheat Sheet
- Qualys SSL Labs — SSL/TLS Server Test
- CA/Browser Forum（証明書運用ルールの策定）
- Heartbleed（OpenSSL脆弱性の解説）
投稿者プロフィール
