調査と解説

SSL / TLS の機能

SSL は暗号化，認証，改竄検出の機能を提供している． 具体的なアルゴリズムはそれぞれ複数の選択肢が定義されていて，SSL 通信の開始時に行われるネゴシエーション時に，双方が許容するアルゴリズムの中からそれぞれ 1 つが選択される．

選択肢によっては攻撃への耐性の強度が大きく変化する場合もある． たとえば，双方が同意すれば 「暗号化なし」 を選択することもできる． 許容できない選択肢はあらかじめ交渉の候補からはずしておくこともできるが，望ましくないアルゴリズムが選択された場合はユーザに警告するという対策も考えられる． 一般に公開されている製品は，実際にこれらの対策をとっている．

なお，選択できるアルゴリズムは SSL のバージョンによって異なる． また，暗号化，認証，改竄検出の 3 つをひとまとめにして選択肢が定義されており，しかも全ての組み合わせが網羅されているわけではないので，同時に利用できない組み合わせも存在する．

暗号化

共通鍵暗号に基づく暗号化を提供する． SSL の各バージョンで使用できる暗号化アルゴリズムは下表のとおりである．

共通鍵はクライアントとサーバの双方から提供される乱数にもとづいて決定される． 双方で生成した乱数を使用するため，リプレイ攻撃では同一の共通鍵を得ることはできない．

鍵の盗聴を防ぐ仕組みとして，サーバ証明書が RSA 暗号を用いて署名されている場合は，クライアントから送る鍵情報の一部をサーバの公開鍵で暗号化することができる． サーバの秘密鍵を知らない部外者は，この情報を復号できない． あるいは (RSA 暗号を使っていない場合などは) Diffie-Hellman 鍵共有アルゴリズムを使うこともできる．

認証

SSL は公開鍵証明書に基づく認証を提供する． SSL の各バージョンで認証に使用できる署名アルゴリズムは下表のとおりである．

SSL においては，通常，サーバだけが証明書を提示し，クライアントがその正当性を確認する． クライアント認証はオプションとなっており，必要な場合にはサーバがクライアントに対して証明書の提示を求める．

なりすましを防ぐために，証明書には認証局 (CA, Certification Authority) による電子署名が必要となる． またサーバ証明書には発行先サーバのホスト名が書き込まれており，クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる． この確認を行わない場合，攻撃者はサーバ A の管理者でなくても，自分が管理するサーバ B の正当な証明書を取得して，その証明書を使ってサーバ A を名乗ることができてしまう．

なお証明書には有効期限が設定されている． 暗号理論およびコンピュータの計算能力は日々進歩しており，現在は安全とみなされる技術であっても長年にわたって安全性を保てる保証はない． また暗号技術の制約上，莫大な計算能力をつぎ込んで解読を続ければ，いつか暗号は解読されると考えるべきである． このため，一定期間ごとに証明書を再発行し，鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している．

改竄検出

SSL の各レコードにはハッシュ値が付加されている． 各レコードにはシーケンス番号が振られており，このシーケンス番号も含めてハッシュ値が算出されているため，一部のレコードを重複して送りつける形のリプレイ攻撃も検出できる． また，(アプリケーション層プロトコルによる代替手段がない限り) 通信の終了を知らせるレコードを送り合うことになっている． このレコードが送られないうちに接続が切断された場合は，強制切断攻撃による介入を受けたと判断することができる．

SSL の各バージョンにおいて使用できるハッシュ関数は下表のとおりである．

アプリケーション層プロトコルへの適用

SSL は特定のアプリケーション層プロトコルに依存しないため，HTTP 以外にも多くのプロトコルにおいて採用され，クレジットカード情報や個人情報，その他の機密情報を通信する際の手段として活用されている．

既存のアプリケーション層プロトコルで SSL を利用する場合，大きく 2 つの適用方式が考えられる．

1. 下位層 (通常は TCP) の接続を確立したらすぐに SSL の交渉を開始し，SSL 接続が確立してからアプリケーション層プロトコルの通信を開始する方式．
2. まず既存のアプリケーション層プロトコルで通信を開始し，その中で SSL への切り替えを指示する方式．

前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である． その反面，既存のポート番号とは別に SSL 対応用のポート番号が必要となる． 実態としては，SSL の最初の適用例である HTTPS をはじめとして，前者の方式を使うことが多い．

セキュリティ上の考察

SSL 適用の有無と使用アルゴリズムの強度

SSL を導入さえすればセキュリティが確保できるわけではない． SSL 通信は，平文での通信に比べて余分な計算機能力を使用するため，本当に必要なとき以外は使用しないことが多い． システムはデータの重要性を判断することができないので，SSL が必要なときに正しく使われているかどうかは，利用者自身が判断しなければならない．

とくに WWW においては SSL を使用した通信と使用しない通信とが交錯しているため，どの通信で SSL が使用されているか把握することが重要になる． 多くの Web ブラウザは，画面のどこかに南京錠の絵を表示したり，アドレスバーの色を変化させたりして，利用者に情報を提供している．

また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため，SSL を使用していても，システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある． このような場合もダイアログ・メッセージなどを使って利用者に警告すべきである．

証明書の正当性

SSL は公開鍵証明書を用いて認証を行い，なりすましを極力排除しようとする． しかしシステムの自動的な対応には限界があり，すべてのなりすましを検出できるわけではない．

電子証明書には認証局による電子署名が与えられる． その署名の正当性を評価するためには認証局の証明書が必要であり，最終的にはルート証明書と呼ばれる一群の証明書に行きつく． 各システムは，認証局の証明書として信用できるルート証明書を，あらかじめ保持している． 認証局は自身の秘密鍵を厳重に秘匿し，また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる． これらが保証されない認証局のルート証明書を組み込むことは，SSL における認証機能を破綻させることになる． 仮に認証局自体は安全でも，入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである．

SSL で認証を行うためには，認証局の署名に加えて，証明書の発行先を確認する必要がある． 確認しない場合，サーバ A の管理権限を持たない者がサーバ B として正当な証明書を取得し，その証明書を使ってサーバ A を名乗ることができてしまう． SSL 用のサーバ証明書には発行先サーバのホスト名が書き込まれており，クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる．

現実には，正当とされるサーバであっても，これらの検証において問題があると判断される証明書を使って運用されているサーバが少なからず存在する．

この検証は，システムが意図する接続先のホスト名と一致することを検証しているのであり，利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある． 利用者が意図している接続先かどうかを判断するためには，さらに以下の情報が必要である．

1. 利用者は意図する接続先の正しいホスト名を知っている
2. 利用者は現在の接続先が，正しいホスト名と一致していることを確認できる

参考文献

• Wikipedia の Secure Socket Layer (この項目の記述にあたっては この項目を参照した)．
• [Fre 96] Alan O. Freier, Philip Karlton, and Paul C. Kocher, "The SSL Protocol Version 3.0", Netscape Communications Corp., March 1996, http://wp.netscape.com/eng/ssl3/ssl-toc.html.
• [RFC 4346] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, IETF, April 2006.