コンテンツにスキップ

Transport Layer Security

出典: フリー百科事典『ウィキペディア（Wikipedia）』

これはこのページの過去の版です。Nagae (会話 | 投稿記録) による 2010年2月13日 (土) 10:52 （個人設定で未設定ならUTC）時点の版 (再ネゴシエーション脆弱性)であり、現在の版とは大きく異なる場合があります。

TCP/IP群
アプリケーション層
カテゴリ
トランスポート層
カテゴリ
インターネット層
カテゴリ
リンク層
カテゴリ

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通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択される。

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

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

暗号化

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

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

AESはTLS 1.0を定義するRFC 2246には含まれていないが、RFC 3268で追加された。IDEAとDESがTLS1.2で廃止された件はRFC 5469に解説がある。また上記以外に、個別のRFCで導入された暗号化アルゴリズムとして、Camellia︵RFC 4132︶、SEED︵RFC 4162︶がある。

共通鍵は、クライアントとサーバの双方から提供される乱数に基づいて決定される。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできない。共通鍵は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が必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。
Mozilla Firefoxにおける南京錠アイコンの例
特に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もまた、暗号としての強度は乱数の品質に依存している。桁数(bit長)の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。︵これは，公開鍵暗号システムにも言える︶もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。

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

2008年5月15日にはDebianが脆弱性に関する報告[9]を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536(=216)通りの予測可能な物が生成されてしまった事を明らかにした[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]等に従うべきである。

再ネゴシエーション脆弱性


2009年11月4日、SSL 3.0以降の再ネゴシエーション機能を利用して、クライアントからのリクエストの先頭に中間者が任意のデータを挿入できるという脆弱性が報告された[12][13]。プロトコル自体の脆弱性であり、すべての実装が影響を受ける。

この脆弱性への簡単な対策は、サーバにおいて再ネゴシエーションを禁止することである。根本対応としては、TLS Extensionを使った安全な再ネゴシエーション手順がRFC 5746として提案されている。この脆弱性を利用した中間者攻撃では、サーバがRFC 5746に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント単体で対応することは不可能である。

参考文献

  • 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日閲覧。

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

(12)^ Ray, Marsh; Steve Dispensa (2009年11月4日). “Renegotiating TLS” (PDF) (英語). 2010年2月13日閲覧。

(13)^ “JVNVU#120541 SSL および TLS プロトコルに脆弱性”. Japan Vulnerability Notes.  JPCERT/CC and IPA (2009年11月13日). 2010年2月13日閲覧。

関連項目

外部リンク

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

「https://ja.wikipedia.org/w/index.php?title=Transport_Layer_Security&oldid=30513461」から取得