ソースを表示
出典: Wikipedio
SSL
のソース
移動:
ナビゲーション
,
検索
以下に示された理由によりページの編集を行うことができません:
この処理は
登録利用者
の権限を持った利用者のみが実行できます。
以下にソースを表示しています:
'''Transport Layer Security'''(トランスポート・レイヤー・セキュリティー、'''TLS''')は、[[セキュア通信|セキュリティーを要求される通信]]のための[[通信プロトコル|プロトコル]]である。また、当プロトコルを発表した[[IETF]]の作業部会の名前でもある。歴史的な理由により、当プロトコルは、しばしば(特に区別する場合を除いて)'''Secure Sockets Layer''' ('''SSL''') とも呼ばれている。これは、TLSの元になったプロトコルがSSLだったこと<ref>プロトコル名を含めた歴史については、Eric Rescorla著,「マスタリングTCP/IP SSL/TLS編」,オーム社開発局(2003年) ISBN 4-274-06542-1 の2章6節が詳しい。</ref>と、SSLという名称が広く普及していることによる。以下においては、特にことわりのないかぎり、作業部会ではなく、プロトコルのほうを指す。本項でも、バージョンを特定せずに単にSSLと記述する場合はTLSを含む。 TLSは、コネクション型の[[OSI参照モデル#トランスポート層|トランスポート層]]プロトコルの上位に位置し、通常は[[Transmission Control Protocol|TCP]]をラッピングする形で利用される。特に[[Hypertext Transfer Protocol|HTTP]]での利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存しない。 == バージョン == === SSL 1.0 === [[ネットスケープコミュニケーションズ]]社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな[[セキュリティホール#脆弱性|脆弱性]]が発見され、破棄された。このため、SSL 1.0を実装した製品はない。 === SSL 2.0 === ネットスケープコミュニケーションズ社はSSL 1.0の問題を修正して再設計し、[[1994年]]にSSL 2.0として発表した。また、同社の[[ウェブブラウザ]]である[[Netscape Navigator (ネットスケープコミュニケーションズ)|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を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない<ref>{{Cite web |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にはチェーン証明書がない。 したがって、[[ルート証明書|ルートCA]]から発行したSSLサーバ証明書しか使うことができない。 === SSL 3.0 === ネットスケープコミュニケーションズ社はSSL 2.0の問題を修正するとともに機能追加を行い、[[1995年]]にSSL 3.0を発表した。また、Netscape Navigator 2.0においてSSL 3.0を実装した。 === TLS 1.0 === [[Internet Engineering Task Force|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が制定された。ハッシュのアルゴリズムに[[SHA]]256が追加された。 ネゴシエーションにおけるバージョン番号は3.3となっている。 == 提供する機能 == [[ファイル:SSLによるセキュアな通信.jpg|250px|thumb|SSLによるセキュアな通信]] SSLは[[暗号|暗号化]]、[[認証]]、[[改竄]]検出の機能を提供する。具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、SSL通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択される。 選択肢によっては、攻撃への耐性の強度が大きく変化する場合もある(極端な例だが、双方が同意すれば「暗号化なし」を選択することもできる)。許容できない選択肢はあらかじめネゴシエーションの候補から外しておいたり、また望ましくないアルゴリズムが選択された場合はユーザーに警告したりといった対策が考えられる。一般に公開されている製品は、実際にこれらの対策が取られている。 なお、選択できるアルゴリズムはSSLのバージョンによって異なる。また、暗号化、認証、改竄検出の3つをひとまとめにして選択肢が定義されており、しかも全ての組み合わせが網羅されているわけではないので、同時に利用できない組み合わせも存在する。 === 暗号化 === [[共通鍵暗号]]に基づく暗号化を提供する。以下のアルゴリズムが選択肢として定義されている。 {| class="wikitable" style="text-align:center" |+ SSLの各バージョンで使用できる暗号化アルゴリズム <br /> (× = 未対応/廃止、○ = 選択可能、◎ = 実装必須) ! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2 |- ! 暗号化なし | × || ○ || ○ || ○ || ○ |- ! [[RC2]] | ○ || ○ || ○ || ○ || × |- ! [[RC4]] | ○ || ○ || ○ || ○ || ○ |- ! [[International Data Encryption Algorithm|IDEA]] | ○ || ○ || ○ || ○ || × |- ! [[DES (暗号)|DES]] | ○ || ○ || ○ || ○ || × |- ! [[トリプルDES]] | ○ || ○ || ◎ || ◎ || ○ |- ! [[AES暗号|AES]] | × || × || △ || ○ || ◎ |} AESはTLS 1.0を定義するRFC 2246には含まれていないが、RFC 3268で追加された。IDEAとDESがTLS1.2で廃止された件はRFC 5469に解説がある。また上記以外に、個別の[[Request for Comments|RFC]]で導入された暗号化アルゴリズムとして、[[Camellia]](RFC 4132)、[[SEED (暗号)|SEED]](RFC 4162)がある。 共通鍵は、クライアントとサーバの双方から提供される[[乱数列|乱数]]に基づいて決定される。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできない。共通鍵は4つセットで生成し、クライアントから送信するデータの暗号化用とサーバから送信するデータの暗号化用にひとつずつ割り当てる(残り2つは後述するハッシュ値の生成に使われる)。 鍵の盗聴を防ぐ仕組みとして、サーバ証明書がRSA暗号を用いて署名されている場合は、クライアントから送る鍵情報の一部をサーバの公開鍵で暗号化することができる。サーバの秘密鍵を知らない部外者は、この情報を復号できない。あるいは(RSA暗号を使っていない場合などは)[[Diffie-Hellman鍵共有]]アルゴリズムを使うこともできる。 === 認証 === SSLは[[公開鍵証明書]]に基づく認証を提供する。認証に使用する署名アルゴリズムの選択肢は以下のとおりである。 {| class="wikitable" style="text-align:center" |+ SSLの各バージョンで使用できる署名アルゴリズム <br /> (× = 未対応、○ = 選択可能、◎ = 実装必須) ! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2 |- ! [[RSA暗号|RSA]] | ○ || ○ || ○ || ◎ || ◎ |- ! [[Digital Signature Algorithm|DSA]] | × || ○ || ◎ || ○ || ○ |} SSLでは通常、サーバだけが証明書を提示し、クライアントがその正当性を確認する。クライアント認証はオプションとなっており、必要な場合にはサーバがクライアントに対して証明書の提示を求める。 なりすましを防ぐために、証明書には[[認証局]] (CA; Certification Authority) による[[電子署名]]が必要となる。またサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。この確認を行わない場合、攻撃者はサーバAの管理者でなくても、自分が管理するサーバBの正当な証明書を取得して、その証明書を使ってサーバAを名乗ることができてしまう。 証明書に関する問題については「[[#証明書の正当性]]」の節を参照。 なお証明書には有効期限が設定されている。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はない。また暗号技術の制約上、莫大な計算能力をつぎ込んで解読を続ければ、いつか暗号は解読されると考えるべきである。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している。 === 改竄検出 === SSLでデータレコードを送信する際には、レコードのシーケンス番号、ハッシュ用共通鍵、データから[[ハッシュ関数|ハッシュ値]]を算出し、レコードに付加する。ハッシュ用共通鍵を知らない攻撃者は、データを改竄しても対応するハッシュ値を生成できない。一部のレコードを重複して送りつける[[反射攻撃|リプレイ攻撃]]は、シーケンス番号が異なるため、やはりハッシュ値で検出できる。また、(アプリケーション層プロトコルによる代替手段がない限り)通信の終了を知らせるレコードを送り合うことになっており、これが送られないうちに接続が切断された場合は、強制切断攻撃による介入を受けたと判断することができる。 ハッシュ関数の選択肢は以下のとおりである。 {| class="wikitable" style="text-align:center" |+ SSLの各バージョンで使用できるハッシュ関数 <br /> (× = 未対応、○ = 選択可能、◎ = 実装必須) ! アルゴリズム !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2 |- ! [[MD5]] | ○ || ○ || ○ || ○ || ○ |- ! [[SHA|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では、ネゴシエーション時にホスト名を伝える手段として[[:en:Server Name Indication|Server Name Indication]](SNI)を提供している。TLS 1.2を定義するRFC 5246では、サーバ証明書を選択する際にこの情報を使うよう言及している。 逆に、証明書を使い分けず、1種類の証明書を使い回す方法も考えられる。[[X.509]]証明書のフォーマットについて記述したRFC 5280によれば、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できる。しかし認証局が実際にそのような証明書を発行するかどうかは、別の問題である。認証局はすべてのホスト名に対して証明書の申請者が正当な管理者であることを確認しなければならないため、証明書発行の負荷は大きくなる。 また、発行先ホスト名に[[ワイルドカード (情報処理)|ワイルドカード]]を使う方法も考えられる。HTTP over TLS(HTTPS)を定義するRFC 2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。 どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。なおIPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。 == セキュリティー上の考察 == === SSL適用の有無と使用アルゴリズムの強度 === SSLを導入さえすればセキュリティーが確保できるという認識は誤っている。SSL通信は、[[平文]]での通信に比べて(主に[[暗号化]]・[[復号]]時)余分な[[計算時間|計算機能力]]を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、SSLが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。 [[ファイル:Firefox-SSL-padlock.png|frame|right|Mozilla Firefoxにおける南京錠アイコンの例]] 特に[[World Wide Web]]では、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSLが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに[[南京錠]]の[[アイコン]]を表示したり、[[アドレスバー]]の色を変化させたりして、利用者に情報を提供している。 また実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、SSLを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。 === 証明書の正当性 === SSLは公開鍵証明書を用いて認証を行い、[[なりすまし]]を極力排除しようとする。しかしシステムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。 [[公開鍵証明書]]には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的には[[ルート証明書]]と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、SSLにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。 SSLで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。SSL用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。 現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。ある著名なセキュリティ研究者はこのような証明書を、[[振り込め詐欺|オレオレ詐欺]]をもじって「[[オレオレ証明書]]」と呼んで批判している<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>。 この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。 例として、利用者が意図する接続先であるサーバ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)が公開している「安全なウェブサイトの作り方」<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もまた、暗号としての強度は乱数の品質に依存している。桁数([[bit]]長)の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。(これは,[[公開鍵暗号]]システムにも言える)もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、[[総当たり攻撃]]で解読される可能性が上昇する。通常は、これは実装の問題に起因している。 古い例では、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>等に従うべきである。 === 再ネゴシエーション脆弱性 === 2009年11月4日、SSL 3.0以降の再ネゴシエーション機能を利用して、クライアントからのリクエストの先頭に[[中間者攻撃|中間者]]が任意のデータを挿入できるという脆弱性が報告された<ref>{{Cite web |last=Ray |first=Marsh |coauthors=Steve Dispensa |date=2009-11-04 |url=http://extendedsubset.com/Renegotiating_TLS.pdf |title=Renegotiating TLS |format=PDF |language=英語 |accessdate=2010-02-13 }}</ref><ref>{{Cite web |date=2009-11-13 |url=https://jvn.jp/cert/JVNVU120541/index.html |title=JVNVU#120541 SSL および TLS プロトコルに脆弱性 |work=Japan Vulnerability Notes |publisher=JPCERT/CC and IPA |accessdate=2010-02-13 }}</ref>。プロトコル自体の脆弱性であり、すべての実装が影響を受ける。 この脆弱性への簡単な対策は、サーバにおいて再ネゴシエーションを禁止することである。根本対応としては、TLS Extensionを使った安全な再ネゴシエーション手順がRFC 5746として提案されている。この脆弱性を利用した中間者攻撃では、サーバがRFC 5746に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント単体で対応することは不可能である。 == 参考文献 == * {{Cite book|和書 |author=Eric Rescorla |others=齊藤孝道・鬼頭利之・古森貞監訳 |title=マスタリングTCP/IP SSL/TLS編 |edition=第1版第1刷 |date=2003-11-28 |publisher=オーム社 |isbn=4-274-06542-1 }} == 脚注 == {{reflist}} == 関連項目 == * [[HTTPS]] * [[Datagram Transport Layer Security]] * [[FTPS]] * [[OpenSSL]] * [[GnuTLS]] * [[Secure Shell|SSH]] * [[フィッシング (詐欺)|フィッシング]] * [[Extended Validation 証明書]] (EV SSL) * [[共通鍵暗号]] * [[共用SSL]] * [[認証局]] * [[SSLオフロード]] * [[ヌルターミネーション攻撃]] == 外部リンク == * [http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html SSL 2.0 PROTOCOL SPECIFICATION(英語、1994年)] * [http://www.freesoft.org/CIE/Topics/ssl-draft/3-SPEC.HTM SSL 3.0 Specification (英語、1996年)] * [http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt Netscape's final SSL 3.0 draft (英語、1996年)] * 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 * RFC 5746 - Transport Layer Security (TLS) Renegotiation Indication Extension === 日本の認証局ベンダー(50音順) === <!-- シェア順だと時間経過とともに変わるが、50音順なら時間経過にともなう維持管理は不要。 --> * [http://crosstrust.co.jp/ クロストラスト] * [http://jp.comodo.com/ コモドジャパン] * [http://www.cybertrust.ne.jp/ サイバートラストジャパン] * [http://jp.globalsign.com/ GMOグローバルサイン] * [http://www.secomtrust.net/ セコムトラストシステムズ] * [http://www.verisign.co.jp/ 日本ベリサイン] {{DEFAULTSORT:とらんすほおと れいや せきゆりてい}} [[Category:アプリケーション層プロトコル]] [[Category:コンピュータ・ネットワーク・セキュリティ]] [[Category:セキュア通信]] [[Category:電子商取引]] [[bg:TLS]] [[cs:Transport Layer Security]] [[da:Transport Layer Security]] [[de:Transport Layer Security]] [[el:TLS]] [[en:Transport Layer Security]] [[es:Transport Layer Security]] [[et:Transpordikihi turbeprotokoll]] [[eu:Transport Layer Security]] [[fa:امنیت لایه انتقال]] [[fi:TLS]] [[fr:Transport Layer Security]] [[hr:TLS]] [[id:Transport Layer Security]] [[it:Transport Layer Security]] [[ko:트랜스포트 레이어 보안]] [[lt:Transport Layer Security]] [[lv:Transport Layer Security]] [[nl:Secure Sockets Layer]] [[nn:Transport Layer Security]] [[no:Transport Layer Security]] [[pl:Transport Layer Security]] [[pt:Transport Layer Security]] [[ro:Securitatea nivelului de transport]] [[ru:TLS]] [[simple:Transport Layer Security]] [[sk:Transport Layer Security]] [[sv:Transport Layer Security]] [[th:Transport Layer Security]] [[uk:Transport Layer Security]] [[yo:Transport Layer Security]] [[zh:传输层安全]]
このページで使われているテンプレート:
Template:Cite book
Template:Cite web
Template:Reflist
SSL
に戻る。
表示
本文
ノート
ソースを表示
履歴
個人用ツール
ログイン
ナビゲーション
メインページ
コミュニティ・ポータル
最近の出来事
最近更新したページ
おまかせ表示
ヘルプ
検索
ツールボックス
リンク元
リンク先の更新状況
特別ページ