SSL/TLS完全ガイド：暗号化・認証・証明書からTLS 1.3の最新動向まで

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

セキュアソケットレイヤー（SSL）とは — 概要

セキュアソケットレイヤー（SSL: Secure Sockets Layer）は、インターネット上でデータを安全にやり取りするために設計された暗号化プロトコルの総称です。現在ではSSLの後継であるTLS（Transport Layer Security）が標準として使われており、一般には「SSL/TLS」または単に「TLS」と呼ばれます。SSLは主にウェブのHTTPS、電子メール（IMAPS/POP3S/SMTPS）やその他のアプリケーションで、通信の暗号化・認証・完全性保護を提供します。

歴史的背景

SSLはNetscape社が開発し、初期のバージョン（1.0は公開されず）は内部的な実験的実装でした。SSL 2.0（1995年）や SSL 3.0（1996年）が登場しましたが、多くの脆弱性と設計上の問題が判明しました。これを受けてIETFで標準化が進められ、TLS 1.0（RFC 2246, 1999）はSSL 3.0を基に作られました。その後、TLS 1.1 / 1.2 と進化し、2018年にTLS 1.3（RFC 8446）が公開され、プロトコルは大幅に簡素化・安全化されました。

SSL/TLS が提供する主な機能

  • 機密性（暗号化）: 通信内容を第三者に読まれないようにする。
  • 認証: サーバ（および必要に応じてクライアント）が本物であることを証明する（X.509証明書と公開鍵基盤）。
  • 完全性（メッセージ整合性）: データが途中で改ざんされていないことを検出する。

技術的な仕組み（ハンドシェイクの流れ）

代表的なTLS 1.2のハンドシェイクは概略で次の流れになります（省略形）：

  • ClientHello: クライアントが対応可能なプロトコルバージョン、暗号スイート、ランダム値などを送信。
  • ServerHello: サーバがプロトコルバージョン、選択した暗号スイート、ランダム値を返す。
  • Server Certificate: サーバはX.509証明書を提示し、公開鍵を提供。
  • （必要に応じて）ServerKeyExchange: 鍵交換情報を送る（例: DHE/ECDHE のパラメータ）。
  • ServerHelloDone: サーバがハンドシェイクのサーバ側メッセージを終了。
  • ClientKeyExchange: クライアントはプリマスターシークレットや鍵共有データを送る。
  • ChangeCipherSpec / Finished: 双方で暗号化通信へ切り替え、Finishedメッセージでハンドシェイク整合性を確認。

TLS 1.3では設計が大きく変わり、ハンドシェイクが短縮され、初期から鍵共有（ECDHEなど）を行い、RSA鍵交換や非PFS方式が削除されました。さらに0-RTT（再接続時に早期データ送信）などの仕組みが導入されています。

暗号アルゴリズムと鍵交換方式

SSL/TLSは複数の暗号技術を組み合わせて使います。

  • 公開鍵暗号（認証・鍵交換）: RSA、DSA、ECDSA、Diffie-Hellman（DHE）、楕円曲線DHE（ECDHE）。
  • 共通鍵暗号（通信の機密化）: AES（CBC / GCM）、3DES（旧式）、ChaCha20-Poly1305（モバイル向けに有効）。
  • メッセージ認証: HMAC-SHA256 など。TLS 1.3ではAEAD（Authenticated Encryption with Associated Data）アルゴリズム（例: AES-GCM, ChaCha20-Poly1305）が必須的に使われます。

実運用では「楕円曲線ベースの一時鍵交換（ECDHE）」を用いることで、パーフェクトフォワードシークレシー（PFS）を実現し、将来秘密鍵が漏洩しても過去の通信は解読されにくくなります。

証明書と認証局（CA）体系

サーバ認証はX.509証明書を使用し、証明書は認証局（CA）が発行します。証明書には公開鍵、所有者情報、発行者情報、有効期間、拡張（キー用途、サブジェクト代替名など）が含まれます。ブラウザやOSは信頼できるルートCAを内蔵し、証明書チェーン（サーバ証明書 → 中間CA → ルートCA）を検証します。

証明書の種類には、ドメイン検証（DV）、組織検証（OV）、拡張検証（EV）などがあり、Let's Encrypt のような自動発行サービス（ACMEプロトコル）によりDV証明書の取得が普及しました。

証明書失効と確認手段

証明書の失効確認はCRL（Certificate Revocation List）やOCSP（Online Certificate Status Protocol）で行います。運用の観点からはOCSPステープリング（サーバが証明書状態を取得してクライアントに提示する仕組み）が有効で、通信遅延やプライバシー問題の解決に使われます（RFC 6066など）。

代表的な脆弱性とその対策

  • SSL 3.0 の POODLE（2014）: パディングに関する攻撃。SSL 3.0の無効化が推奨。
  • TLS 1.0/1.1 の古い脆弱性（BEAST, CRIME など）: 古いバージョンは廃止を推奨。
  • ハンドシェイクの再ネゴシエーション脆弱性: RFC 5746 による修正が導入。
  • 実装レベルの脆弱性（例: Heartbleed は OpenSSL のバグ）: ライブラリの更新が重要。
  • スイートの設定ミス（弱い暗号やRC4、3DESなどの許容）: モダンな設定（AES-GCM, ChaCha20-Poly1305, ECDHE 優先）を使用。

TLS 1.3 の主な特徴（TLS としての最新基準）

  • ハンドシェイクの簡素化と高速化（接続ラウンドトリップの削減）。
  • 安全性の高い暗号のみを採用、RSA鍵交換や静的RSAが除去。
  • 初期からPFSを前提とする設計。
  • 0-RTT による再接続早期データ送信（リプレイに注意が必要）。
  • 暗号スイートの想定がAEAD中心に統一され、圧縮を廃止してサイドチャネル攻撃を減らす。

実務上の導入・運用ポイント

  • TLSバージョンは可能な限り TLS 1.2 以上、理想は TLS 1.3 を有効化。
  • 暗号スイートは ECDHE を優先し、AEAD（AES-GCM、ChaCha20-Poly1305）を選択。
  • 古いプロトコル（SSL 2.0/3.0、TLS 1.0/1.1）は無効化。
  • 証明書は期限・発行元・CN/SAN を適切に管理し、自動更新（Let’s Encrypt 等）を導入することで人的ミスを減らす。
  • OCSP ステープリングやHSTS（HTTP Strict Transport Security）、SNI（Server Name Indication）、ALPN（HTTP/2のネゴシエーション）といった周辺技術も有効活用する。
  • 定期的な脆弱性スキャンとライブラリアップデート（OpenSSL, LibreSSL, BoringSSL 等）を怠らない。

よくある誤解

  • 「SSL = HTTPS」ではないが、HTTPSは通常SSL/TLSにより実装されるため混同されやすい。
  • 証明書があるだけで安全というわけではなく、プロトコルや暗号スイートの設定、実装の健全性が重要。
  • 古いブラウザやOSの互換性のために弱い設定を残すと攻撃の対象になる。

まとめ

SSLは歴史的な名称ですが、現代の安全な通信はTLSが担っています。設計的には暗号化、認証、完全性保護という三つの柱で成り立ち、証明書とCAのエコシステム、鍵交換方式、使用する暗号スイート、実装の堅牢性が組み合わさって初めて通信の安全が確保されます。実務では最新のTLSバージョン・強力な暗号スイートの採用、自動的な証明書更新、定期的なアップデートと脆弱性対応が不可欠です。

参考文献

カテゴリー
IT
前の記事
ディル・アン・グレイ完全ガイド｜プロフィール・音楽性・代表曲・ライブの魅力を徹底解説New!!
2025年11月20日
次の記事
ハンドシェイクの仕組みと実務ガイド: TCP三者ハンドシェイクからTLS1.3・WebSocket・SSHまで セキュリティと性能を最適化New!!
2025年11月20日