「Transport Layer Security」の版間の差分

削除された内容追加された内容

インライン

2010年1月2日 (土) 18:50時点における版

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との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかしこの細工が無効にされているサーバ環境も存在し、クライアントから見るとSSL 2.0を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない^[1]。SSL 3.0以降に対応した実装が十分に普及したものとして、Internet Explorer 7やMozilla Firefox 2、Opera 9などは、初期状態でSSL 2.0を無効にしている^[2]^[3]^[4]。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている^[5]。

SSL2.0にはチェーン証明書がない。したがって、ルート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からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。特にCBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。また、予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAES暗号が選択肢に加わった。

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

TLS 1.2

2008年8月にRFC 5246としてTLS 1.2が制定された。ハッシュのアルゴリズムにSHA256が追加された。

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

提供する機能

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

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

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

暗号化

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

SSLの各バージョンで使用できる暗号化アルゴリズム
（× = 未対応/廃止、○ = 選択可能、◎ = 実装必須）
アルゴリズム	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2
暗号化なし	×	○	○	○	○
RC2	○	○	○	○	×
RC4	○	○	○	○	○
IDEA	○	○	○	○	×
DES	○	○	○	○	×
トリプルDES	○	○	◎	◎	○
AES	×	×	×	○	◎

共通鍵は、クライアントとサーバの双方から提供される乱数に基づいて決定される。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできない。共通鍵は4つセットで生成し、クライアントから送信するデータの暗号化用とサーバから送信するデータの暗号化用にひとつずつ割り当てる（残り2つは後述するハッシュ値の生成に使われる）。

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

認証

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

SSLの各バージョンで使用できる署名アルゴリズム
（× = 未対応、○ = 選択可能、◎ = 実装必須）
アルゴリズム	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2
RSA	○	○	○	◎	◎
DSA	×	○	◎	○	○

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

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

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

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

改竄検出

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

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

SSLの各バージョンで使用できるハッシュ関数
（× = 未対応、○ = 選択可能、◎ = 実装必須）
アルゴリズム	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2
MD5	○	○	○	○	○
SHA-1	×	○	◎	◎	◎
SHA-256	×	×	×	×	○

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

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

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

前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、既存のポート番号とは別にSSL対応用のポート番号が必要となる。実態としては、SSLの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。ただし、この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。

課題

バーチャルホスト

SSLは、TCP/IPネットワークでホスト名ベースのバーチャルホストを構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を解決し、実際にはIPアドレスとポート番号で接続先を識別している。このためSSLのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。

TLS（SSL）の拡張機能を定義するRFC 4366では、ネゴシエーション時にホスト名を伝える手段を提供している。TLS 1.2を定義するRFC 5246では、サーバ証明書を選択する際にこの情報を使うよう言及している。

逆に、証明書を使い分けず、1種類の証明書を使い回す方法も考えられる。X.509証明書のフォーマットについて記述したRFC 5280によれば、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できる。しかし認証局が実際にそのような証明書を発行するかどうかは、別の問題である。認証局はすべてのホスト名に対して証明書の申請者が正当な管理者であることを確認しなければならないため、証明書発行の負荷は大きくなる。

また、発行先ホスト名にワイルドカードを使う方法も考えられる。HTTP over TLS（HTTPS）を定義するRFC 2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。

どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。

セキュリティー上の考察

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

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

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

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

証明書の正当性

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

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

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

現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。ある著名なセキュリティ研究者はこのような証明書を、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している^[6]。

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

例として、利用者が意図する接続先であるサーバ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）が公開している「安全なウェブサイトの作り方」^[7]という文書の「フィッシング詐欺を助長しないための対策」に対応する。

乱数の品質

他の多くの近代暗号と同様に、SSLもまた、暗号としての強度は乱数の品質に依存している。桁数の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。

古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった^[8]。

2008年 5月15日にはDebianが脆弱性に関する報告^[9]を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536(=2¹⁶)通りの予測可能な物が生成されてしまった事を明らかにした^[10]（なお、この問題は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を含むの全てのオペレーティングスシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている。生成された鍵に問題があるため、Debian GNU/Linuxで生成した鍵をMicrosoft Windowsのような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、JPCERT/CCの勧告^[11]等に従うべきである。

参考文献

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

脚注

^ 大岩寛 (2005年10月13日). “[Security] SSL 2.0 version rollback の件のFAQ”. おおいわのこめんと. 2010年1月3日閲覧。
^ Eric Lawrence (2006年1月31日). “Internet Explorer 7 における HTTPS セキュリティーの強化点”. Microsoft Corporation. 2010年1月3日閲覧。
^ “サイトが古くて安全でないバージョンの SSL プロトコルを使用しているため、安全な接続ができませんでした”. Firefox サポート (2009年7月6日). 2010年1月3日閲覧。
^ “Opera 9 のサポートするウェブ標準ならびに仕様”. Opera Software ASA.. 2010年1月3日閲覧。
^ 勝村幸博 (2006年6月2日). “「SSL 2.0だけに対応したWebサイトはわずか0.1％」---ネットクラフト”. 日経BP IT pro. 2010年1月3日閲覧。
^ 高木浩光 (2007年11月17日). “オレオレ証明書の区分第三版”. 高木浩光＠自宅の日記. 2010年1月3日閲覧。
^ “「安全なウェブサイトの作り方　改訂第3版」を公開”. 独立行政法人情報処理推進機構 (2008年6月11日). 2010年1月3日閲覧。
^ Ian Goldberg; David Wagner (1996年1月1日). “Randomness and the Netscape Browser” (英語). Dr. Dobb's. 2010年1月3日閲覧。
^ “OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等）”. Debian JP Project (2008年5月15日). 2010年1月3日閲覧。
^ “Debian generated SSH-Keys working exploit”. SecurityFocus (2008年5月15日). 2010年1月3日閲覧。
^ “Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起”. JPCERT/CC (2008年5月19日). 2010年1月3日閲覧。

外部リンク

SSL 2.0 PROTOCOL SPECIFICATION（英語）
SSL 3.0 SPECIFICATION(英語)
RFC 2246 - The TLS Protocol Version 1.0
RFC 3749 - Transport Layer Security Protocol Compression Methods
RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1
RFC 4347 - Datagram Transport Layer Security
RFC 4366 - Transport Layer Security (TLS) Extensions
RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2

日本の認証局ベンダー(50音順)

[1] 大岩寛 (2005年10月13日). “[Security] SSL 2.0 version rollback の件のFAQ”. おおいわのこめんと. 2010年1月3日閲覧。

[2] Eric Lawrence (2006年1月31日). “Internet Explorer 7 における HTTPS セキュリティーの強化点”. Microsoft Corporation. 2010年1月3日閲覧。

[3] “サイトが古くて安全でないバージョンの SSL プロトコルを使用しているため、安全な接続ができませんでした”. Firefox サポート (2009年7月6日). 2010年1月3日閲覧。

[4] “Opera 9 のサポートするウェブ標準ならびに仕様”. Opera Software ASA.. 2010年1月3日閲覧。

[5] 勝村幸博 (2006年6月2日). “「SSL 2.0だけに対応したWebサイトはわずか0.1％」---ネットクラフト”. 日経BP IT pro. 2010年1月3日閲覧。

[6] 高木浩光 (2007年11月17日). “オレオレ証明書の区分第三版”. 高木浩光＠自宅の日記. 2010年1月3日閲覧。

[7] “「安全なウェブサイトの作り方　改訂第3版」を公開”. 独立行政法人情報処理推進機構 (2008年6月11日). 2010年1月3日閲覧。

[8] Ian Goldberg; David Wagner (1996年1月1日). “Randomness and the Netscape Browser” (英語). Dr. Dobb's. 2010年1月3日閲覧。

[9] “OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等）”. Debian JP Project (2008年5月15日). 2010年1月3日閲覧。

[10] “Debian generated SSH-Keys working exploit”. SecurityFocus (2008年5月15日). 2010年1月3日閲覧。

[11] “Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起”. JPCERT/CC (2008年5月19日). 2010年1月3日閲覧。

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

@@ 14行目: / 14行目: @@
 その後、SSL 2.0にもいくつかの脆弱性が発見され、SSL 3.0において修正された。SSL 2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ（ダウングレード攻撃）、改竄を受けたことを検出できないというものである。さらに悪いことに、この脆弱性を利用すると、双方がSSL 3.0をサポートしていてもSSL 2.0で接続させることさえ可能になる。
+SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかしこの細工が無効にされているサーバ環境も存在し、クライアントから見るとSSL 2.0を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない<ref>{{Cite web
-SSL 3.0ではSSL 2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。しかし一部の製品においてこの細工の実装に問題があったため、結局のところ無視されていることが多い<ref>[http://www.oiwa.jp/~yutaka/tdiary/20051013.html#p01 <nowiki>[Security]</nowiki> SSL 2.0 version rollback の件のFAQ]（おおいわのこめんと (2005-10-13)）</ref>。SSL 3.0以降に対応した実装が十分に普及したものとして、[[Internet Explorer|Internet Explorer 7]]や[[Mozilla Firefox|Mozilla Firefox 2]]、[[Opera|Opera 9]]などは、初期状態でSSL 2.0を無効にしている<ref>[http://www.microsoft.com/japan/msdn/ie/expie/ie7_https_imps.aspx Internet Explorer 7 における HTTPS セキュリティーの強化点 (Windows IETechCol)]</ref><ref>[http://www.mozilla-japan.org/kb/solution/2094 Mozilla Japan ナレッジベース - 安全な接続 (SSL) を使用したサイトへアクセスできない]</ref><ref>[http://jp.opera.com/docs/specs/#network Opera 9 でサポートされるウェブ仕様 - CSS : ネットワークプロトコルサポート]</ref>。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている<ref>[http://itpro.nikkeibp.co.jp/article/NEWS/20060602/239846/ 「SSL 2.0だけに対応したWebサイトはわずか0.1％」---ネットクラフト]（[[日経BP社]] IT pro）</ref>。
+|author=大岩 寛
+|date=2005-10-13
+|url=http://www.oiwa.jp/~yutaka/tdiary/20051013.html#p01
+|title=<nowiki>[Security]</nowiki> SSL 2.0 version rollback の件のFAQ
+|work=おおいわのこめんと
+|accessdate=2010-01-03
+}}</ref>。SSL 3.0以降に対応した実装が十分に普及したものとして、[[Internet Explorer|Internet Explorer 7]]や[[Mozilla Firefox|Mozilla Firefox 2]]、[[Opera|Opera 9]]などは、初期状態でSSL 2.0を無効にしている<ref>{{Cite web
+|author=Eric Lawrence
+|date=2006-01-31
+|url=http://www.microsoft.com/japan/msdn/ie/expie/ie7_https_imps.aspx
+|title=Internet Explorer 7 における HTTPS セキュリティーの強化点
+|publisher=Microsoft Corporation
+|accessdate=2010-01-03
+}}</ref><ref>{{Cite web
+|date=2009-07-06
+|url=http://support.mozilla.com/ja/kb/%E3%82%B5%E3%82%A4%E3%83%88%E3%81%8C%E5%8F%A4%E3%81%8F%E3%81%A6%E5%AE%89%E5%85%A8%E3%81%A7%E3%81%AA%E3%81%84%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%81%AE+SSL+%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%9F%E3%82%81%E3%80%81%E5%AE%89%E5%85%A8%E3%81%AA%E6%8E%A5%E7%B6%9A%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93%E3%81%A7%E3%81%97%E3%81%9F
+|title=サイトが古くて安全でないバージョンの SSL プロトコルを使用しているため、安全な接続ができませんでした
+|work=Firefox サポート
+|accessdate=2010-01-03
+}}</ref><ref>{{Cite web
+|url=http://jp.opera.com/docs/specs/opera9/#network
+|title=Opera 9 のサポートするウェブ標準ならびに仕様
+|publisher=Opera Software ASA.
+|accessdate=2010-01-03
+}}</ref>。この決定を受け、SSL 2.0しか対応していなかったサーバでも、SSL 3.0以降へ対応する動きが広まっている<ref>{{Cite web
+|author=勝村 幸博
+|date=2006-06-02
+|url=http://itpro.nikkeibp.co.jp/article/NEWS/20060602/239846/
+|title=「SSL 2.0だけに対応したWebサイトはわずか0.1％」---ネットクラフト
+|publisher=[[日経BP]] IT pro
+|accessdate=2010-01-03
+}}</ref>。
 SSL2.0にはチェーン証明書がない。
@@ 156行目: / 188行目: @@
 SSLで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。SSL用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。
-現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。ある著名なセキュリティ研究者はこのような証明書を、[[振り込め詐欺|オレオレ詐欺]]をもじって「[[オレオレ証明書]]」と呼んで批判している<ref>[http://takagi-hiromitsu.jp/diary/20071117.html#p02 オレオレ証明書の区分 第三版]（[[高木浩光]]＠自宅の日記 [[2007年]]11月17日）</ref>。
+現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。ある著名なセキュリティ研究者はこのような証明書を、[[振り込め詐欺|オレオレ詐欺]]をもじって「[[オレオレ証明書]]」と呼んで批判している<ref>{{Cite web
+|author=高木 浩光
+|authorlink=高木浩光
+|date=2007-11-17
+|url=http://takagi-hiromitsu.jp/diary/20071117.html#p02
+|title=オレオレ証明書の区分 第三版
+|work=高木浩光＠自宅の日記
+|accessdate=2010-01-03
+}}</ref>。
 この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。
@@ 167行目: / 207行目: @@
 # 利用者は、現在システムに指示されている接続先が、自分の知っている正しいホスト名と一致していることを確認できる。
-は、[[情報処理推進機構]]（IPA）が公開している「安全なウェブサイトの作り方」<ref>[http://www.ipa.go.jp/security/vuln/websecurity.html 「安全なウェブサイトの作り方　改訂第2版」の発行について]</ref>という文書の「[[フィッシング (詐欺)|フィッシング]]詐欺を助長しないための対策」に対応する。
+は、[[情報処理推進機構]]（IPA）が公開している「安全なウェブサイトの作り方」<ref>{{Cite web
+|date=2008-06-11
+|url=http://www.ipa.go.jp/security/vuln/websecurity.html
+|title=「安全なウェブサイトの作り方　改訂第3版」を公開
+|publisher=独立行政法人 [[情報処理推進機構]]
+|accessdate=2010-01-03
+}}</ref>という文書の「[[フィッシング (詐欺)|フィッシング]]詐欺を助長しないための対策」に対応する。
+=== 乱数の品質 ===
-=== 危険性について関連情報 ===
+他の多くの近代暗号と同様に、SSLもまた、暗号としての強度は乱数の品質に依存している。桁数の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、[[総当たり攻撃]]で解読される可能性が上昇する。通常は、これは実装の問題に起因している。
-[[Debian]]は[[2008年]][[5月15日]]脆弱性に関する報告<ref>[http://www.debian.or.jp/blog/openssl_package_and_its_vulnerability.html OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等）]</ref>を発表した。[[OpenSSL]]ライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536(=2<sup>16</sup>)通りの予測可能な物が生成されてしまった事を明らかにした<ref>[http://www.securityfocus.com/archive/1/492112/30/0/threaded Debian generated SSH-Keys working exploit May 15 2008 05:54AM]</ref>（なお、この問題はOpenSSLそのものの脆弱性ではない）。この影響を受けるのはDebian sargeより後のバージョンのDebianと、それから派生した[[Damn Small Linux]], [[KNOPPIX]], [[Linspire]], [[Progeny Debian]], [[sidux]], [[Ubuntu]], [[UserLinux]], [[Xandros]]である。脆弱性のあるバージョンのOpenSSLは[[2006年]][[9月17日]]に公開された。安定バージョンがリリースされた[[2007年]][[4月8日]]以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、[[Secure Shell|SSH]] 鍵、[[OpenVPN]] 鍵、[[DNS Security Extensions|DNSSEC]] 鍵、[[X.509]] 証明書を生成するのに使われる鍵データ、および SSL/TLS コネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを[[ブルートフォースアタック]]で試すだけでいずれの鍵が使われているか解読可能であり(SSHでは20分間で解読できたと報告されている)、また脆弱な鍵がインストールされたDebianを含むの全てのオペレーティングスシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている(その対象には[[Microsoft Windows]]など非UNIX系OSも含む)。具体的対応については、Debianの報告の他、[[JPCERT/CC]]の勧告<ref>[http://www.jpcert.or.jp/at/2008/at080008.txt Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起]</ref>等に従うべきである。
+古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。[[プロセス識別子|プロセスID]]や時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった<ref>{{Cite web
+|author=Ian Goldberg
+|coauthors=David Wagner
+|date=1996-01-01
+|url=http://www.ddj.com/windows/184409807
+|title=Randomness and the Netscape Browser
+|publisher=Dr. Dobb's
+|language=英語
+|accessdate=2010-01-03
+}}</ref>。
+[[2008年]][[5月15日]]には[[Debian]]が脆弱性に関する報告<ref>{{Cite web
+|date=2008-05-15
+|url=http://www.debian.or.jp/blog/openssl_package_and_its_vulnerability.html
+|title=OpenSSL パッケージの脆弱性とその影響について (SSH鍵、SSL証明書等）
+|publisher=[[Debian]] JP Project
+|accessdate=2010-01-03
+}}</ref>を発表した。[[OpenSSL]]ライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536(=2<sup>16</sup>)通りの予測可能な物が生成されてしまった事を明らかにした<ref>{{Cite web
+|date=2008-05-15
+|url=http://www.securityfocus.com/archive/1/492112/30/0/threaded
+|title=Debian generated SSH-Keys working exploit
+|publisher=SecurityFocus
+|accessdate=2010-01-03
+}}</ref>（なお、この問題はOpenSSLそのものの脆弱性ではない）。この影響を受けるのはDebian sargeより後のバージョンのDebianと、それから派生した[[Damn Small Linux]], [[KNOPPIX]], [[Linspire]], [[Progeny Debian]], [[sidux]], [[Ubuntu]], [[UserLinux]], [[Xandros]]である。脆弱性のあるバージョンのOpenSSLは[[2006年]][[9月17日]]に公開された。安定バージョンがリリースされた[[2007年]][[4月8日]]以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、[[Secure Shell|SSH]] 鍵、[[OpenVPN]] 鍵、[[DNS Security Extensions|DNSSEC]] 鍵、[[X.509]] 証明書を生成するのに使われる鍵データ、および SSL/TLS コネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを総当たり攻撃で試すだけでいずれの鍵が使われているか解読可能であり(SSHでは20分間で解読できたと報告されている)、また脆弱な鍵がインストールされたDebianを含むの全てのオペレーティングスシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている。生成された鍵に問題があるため、Debian GNU/Linuxで生成した鍵を[[Microsoft Windows]]のような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、[[JPCERT/CC]]の勧告<ref>{{Cite web
+|date=2008-05-19
+|url=http://www.jpcert.or.jp/at/2008/at080008.txt
+|title=Debian GNU/Linux に含まれる OpenSSL/OpenSSH の脆弱性に関する注意喚起
+|publisher=[[JPCERT/CC]]
+|accessdate=2010-01-03
+}}</ref>等に従うべきである。
 == 参考文献 ==
+* {{Cite book|和書
-* Eric Rescorla 『マスタリングTCP/IP SSL/TLS編』 齊藤孝道・鬼頭利之・古森貞監訳、オーム社、平成15年（[[2003年]]）、ISBN 4-274-06542-1。
+|author=Eric Rescorla
+|others=齊藤孝道・鬼頭利之・古森貞監訳
+|title=マスタリングTCP/IP SSL/TLS編
+|edition=第1版第1刷
+|date=2003-11-28
+|publisher=オーム社
+|isbn=4-274-06542-1
+}}
 == 脚注 ==