Secure_Socket_Layer

Secure Sockets Layer（セキュアソケットレイヤー、SSL）は、セキュリティーを要求される通信のためのプロトコルである。コネクション型のトランスポート層プロトコルの上位に位置し、通常はTCPをラッピングする形で利用される。特にHTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存しない。

後継バージョンをRFCとして発表する際にTransport Layer Security（TLS）という名称に変更されたが、SSLという名称が広く普及していることもあり、（特に区別する場合を除いて）TLSも含めてSSLと呼ばれることがある。本項でも、バージョンを特定せずに単にSSLと記述する場合はTLSを含む。

バージョン

SSL 1.0

ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。このため、SSL 1.0を実装した製品はない。

SSL 2.0

ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、1994年にSSL 2.0として発表した。また、同社のウェブブラウザであるNetscape Navigator 1.1においてSSL 2.0を実装した。

その後、SSL 2.0にもいくつかの脆弱性が発見され、SSL 3.0において修正された。SSL 2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ（ダウングレード攻撃）、改竄を受けたことを検出できないというものである。さらに悪いことに、この脆弱性を利用すると、双方がSSL 3.0をサポートしていてもSSL 2.0で接続させることさえ可能になる。

SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかし一部の製品においてこの細工の実装に問題があったため、結局のところ無視されていることが多い[Security SSL 2.0 version rollback の件のFAQ]（おおいわのこめんと (2005-10-13)）。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしているInternetMozillaOpera。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている「SSL（日経BP社 IT pro）。

したがって、ルートCAから発行したSSLサーバ証明書しか使うことができない。

SSL 3.0

ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、1995年にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。

TLS 1.0

IETFのTLSワーキンググループはRFC 2246としてTLS1.0を公表した。TLS 1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。

TLS 1.0が提供する機能はSSL 3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。このため、TLS 1.0を実装した製品が普及するまでには、さらに数年を要した。

なおTLS 1.0はSSL 3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。

TLS 1.1

2006年にRFC 4346としてTLS 1.1が制定された。TLS 1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。また、AES暗号が選択肢に加わった。

ネゴシエーションにおけるバージョン番号は3.2となっている。

TLS 1.2

2008年8月にRFC 5246としてTLS 1.2が制定された。CBC攻撃の耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理が改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。ハッシュのアルゴリズムにSHA256が追加された。ネゴシエーションにおけるバージョン番号は3.3となっている。

提供する機能

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

選択肢によっては、攻撃への耐性の強度が大きく変化する場合もある（極端な例だが、双方が同意すれば「暗号化なし」を選択することもできる）。許容できない選択肢はあらかじめネゴシエーションの候補から外しておいたり、また望ましくないアルゴリズムが選択された場合はユーザーに警告したりといった対策が考えられる。一般に公開されている製品は、実際にこれらの対策が取られている。

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

暗号化

共通鍵暗号に基づく暗号化を提供する。以下のアルゴリズムが選択肢として定義されている。

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

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

認証

SSLは公開鍵証明書に基づく認証を提供する。認証に使用する署名アルゴリズムの選択肢は以下のとおりである。

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

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

証明書に関する問題は、#証明書の正当性の節を参照せよ。

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

改竄検出

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

ハッシュ関数の選択肢は以下のとおりである。

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

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

既存のアプリケーション層プロトコルでSSLを利用する場合、大きく2つの適用方式が考えられる。まずひとつは、下位層（通常はTCP）の接続を確立したらすぐにSSLのネゴシエーションを開始し、SSL接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。もうひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でSSLへの切り替えを指示する方式である。

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

前者の方式のもうひとつの問題点として、名前ベースのバーチャルホストを提供できないという点がある。なぜなら、証明書の検証はSSLネゴシエーションの一部として実施されるが、この時点ではアプリケーション層の通信が開始されていないためサーバはホスト名を知らず、証明書を使い分けることができないためである。

例外として、発行先ホスト名にワイルドカードを含めた1種類の証明書で対応できる場合は、証明書を使い分ける必要がないので、名前ベースのバーチャルホストを提供できる。またIPアドレスベースのバーチャルホストであれば、SSLネゴシエーションの時点でIPアドレスは既知なので、問題はない。

セキュリティー上の考察

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

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

特にWorld Wide Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSLが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠の絵を表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供している。

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

証明書の正当性

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

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

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

現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。ある著名なセキュリティ研究者はこのような証明書を、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判しているオレオレ証明書の区分（高木浩光＠自宅の日記 2007年11月17日）。

この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。

例として、利用者が意図する接続先であるサーバAがホスト名www.example.comでサービスを提供しており、攻撃者はサーバBおよびホスト名www.example.orgを取得している場合を考える。仮に攻撃者がDNS偽装に成功して、www.example.comへの接続をサーバBに導くことができたとしても、www.example.comのサーバ証明書を入手できないので、SSL接続を提供することはできない。しかし攻撃者も、www.example.orgのサーバ証明書を入手することはできる。したがって、サーバAに接続しようとしている利用者を、www.example.comではなくwww.example.orgへ接続させることができれば、クライアントからは正当な証明書を持ったサーバとしか見えない。

上記のような例も考慮した上で、利用者が意図している接続先かどうかを判断するためには、以下の2つの条件を満たす必要がある。

# 利用者は、現在システムに指示されている接続先が、自分の知っている正しいホスト名と一致していることを確認できる。

2は、情報処理推進機構（IPA）が公開している「安全なウェブサイトの作り方」「安全なウェブサイトの作り方　改訂第2版」の発行についてという文書の「フィッシング詐欺を助長しないための対策」に対応する。

鍵の強度

Debianは2008年5月15日脆弱性に関する報告OpenSSLを発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536通りの予測可能な物が生成されてしまった事を明らかにしたDebian（なお、この問題はOpenSSLそのものの脆弱性ではない）。この影響を受けるのはDebian sargeより後のバージョンのDebianと、それから派生したDamn Small Linux, KNOPPIX, Linspire, Progeny Debian, sidux, Ubuntu, UserLinux, Xandrosである。脆弱性のあるバージョンのOpenSSLは2006年9月17日に公開された。安定バージョンがリリースされた2007年4月8日以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、SSH 鍵、OpenVPN 鍵、DNSSEC 鍵、X.509 証明書を生成するのに使われる鍵データ、および SSL/TLS コネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てをブルートフォースアタックで試すだけでいずれの鍵が使われているか解読可能であり(SSHでは20分間で解読できたと報告されている)、また脆弱な鍵がインストールされたDebianを含むの全てのオペレーティングスシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている(その対象にはMicrosoft Windowsなど非UNIX系OSも含む)。具体的対応については、Debianの報告の他、JPCERT/CCの勧告Debian等に従うべきである。

日本の認証局ベンダー(シェア順)

• 日本ベリサイン
• グローバルサイン
• セコムトラストシステムズ
• サイバートラストジャパン
• 日本クロストラスト

参考文献

• Eric Rescorla 『マスタリングTCP/IP SSL/TLS編』 齊藤孝道・鬼頭利之・古森貞監訳、オーム社、平成15年（2003年）、ISBN 4-274-06542-1。

脚注