2246としてTLS1.0を公表した。1.0の標準化作業は1996年に開始され、年内に完了する予定だったが、いくつかの問題に阻まれ、公表は1999年まで遅延した。3.0とあまり変わらないが、アルゴリズムやルートCAの自己署名証明書の取扱いなどの仕様の詳細が変更されたことに加え、これまであまり実装されていなかった選択肢のいくつかが必須と定められた。1.0を実装した製品が普及するまでには、さらに数年を要した。3.0より新しい規格であることを示すため、ネゴシエーションにおけるバージョン番号は3.1となっている。1.0からの変更点は、新しく発見された攻撃手法に対する耐性の強化が中心である。CBC攻撃に対する耐性を上げるため、初期化ベクトルを明示的に指定することにし、さらにパディングの処理も改善された。予期せぬ回線クローズ後に、セッションを再開できるようになった。共通鍵暗号アルゴリズムとしてAES暗号が選択肢に加わった。ネゴシエーションにおけるバージョン番号は3.2となっている。ハッシュのアルゴリズムにSHA256が追加された。ネゴシエーションにおけるバージョン番号は3.3となっている。具体的なアルゴリズムはそれぞれ複数の選択肢が定義されており、SSL通信の開始時に行われるネゴシエーション時に、双方が許容するアルゴリズムの中から選択される。選択肢によっては、攻撃への耐性の強度が大きく変化する場合もある(極端な例だが、双方が同意すれば「暗号化なし」を選択することもできる)。許容できない選択肢はあらかじめネゴシエーションの候補から外しておいたり、また望ましくないアルゴリズムが選択された場合はユーザーに警告したりといった対策が考えられる。一般に公開されている製品は、実際にこれらの対策が取られている。選択できるアルゴリズムはSSLのバージョンによって異なる。基づく暗号化を提供する。以下のアルゴリズムが選択肢として定義されている。3268で追加された。5469に解説がある。共通鍵は、クライアントとサーバの双方から提供される乱数に基づいて決定される。双方で生成した乱数を組み合わせて使用するため、リプレイ攻撃では同一の共通鍵を得ることはできない。共通鍵は4つセットで生成し、クライアントから送信するデータの暗号化用とサーバから送信するデータの暗号化用にひとつずつ割り当てる(残り2つは後述するハッシュ値の生成に使われる)。鍵の盗聴を防ぐ仕組みとして、サーバ証明書がRSA暗号を用いて署名されている場合は、クライアントから送る鍵情報の一部をサーバの公開鍵で暗号化することができる。サーバの秘密鍵を知らない部外者は、この情報を復号できない。(RSA暗号を使っていない場合などは)Diffie-Hellman鍵共有アルゴリズムを使うこともできる。認証SSLは公開鍵証明書に基づく認証を提供する。認証に使用する署名アルゴリズムの選択肢は以下のとおりである。○SSLでは通常、サーバだけが証明書を提示し、クライアントがその正当性を確認する。クライアント認証はオプションとなっており、必要な場合にはサーバがクライアントに対して証明書の提示を求める。よる電子署名が必要となる。サーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。この確認を行わない場合、攻撃者はサーバAの管理者でなくても、自分が管理するサーバBの正当な証明書を取得して、その証明書を使ってサーバAを名乗ることができてしまう。証明書に関する問題については「#証明書の正当性」の節を参照。証明書には有効期限が設定されている。暗号理論およびコンピュータの計算能力は日々進歩しており、現在安全とみなされる技術であっても長年にわたって安全性を保てる保証はない。暗号技術の制約上、莫大な計算能力をつぎ込んで解読を続ければ、いつか暗号は解読されると考えるべきである。このため、一定期間ごとに証明書を再発行し、鍵を変更するとともに必要に応じて使用するアルゴリズムも更新している。改竄検出SSLでデータレコードを送信する際には、レコードのシーケンス番号、ハッシュ用共通鍵、データからハッシュ値を算出し、レコードに付加する。ハッシュ用共通鍵を知らない攻撃者は、データを改竄しても対応するハッシュ値を生成できない。一部のレコードを重複して送りつけるリプレイ攻撃は、シーケンス番号が異なるため、やはりハッシュ値で検出できる。(アプリケーション層プロトコルによる代替手段がない限り)通信の終了を知らせるレコードを送り合うことになっており、これが送られないうちに接続が切断された場合は、強制切断攻撃による介入を受けたと判断することができる。ハッシュ関数の選択肢は以下のとおりである。○アプリケーション層プロトコルへの適用SSLは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。既存のアプリケーション層プロトコルでSSLを利用する場合、大きく2つの適用方式が考えられる。ひとつは、下位層(通常はTCP)の接続を確立したらすぐにSSLのネゴシエーションを開始し、SSL接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。ひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でSSLへの切り替えを指示する方式である。前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、既存のポート番号とは別にSSL対応用のポート番号が必要となる。実態としては、SSLの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。課題バーチャルホストSSLは、TCP/IPネットワークでホスト名ベースのバーチャルホストを構成する際に問題となる。TCP/IPでは通信を開始する前にホスト名を解決し、実際にはIPアドレスとポート番号で接続先を識別している。このためSSLのネゴシエーションの時点では、バーチャルホストのうちどのホスト名を期待しているのか判断できず、ホスト名ごとに異なるサーバー証明書を使い分けることができない。4366では、ネゴシエーション時にホスト名を伝える手段を提供している。5246では、サーバ証明書を選択する際にこの情報を使うよう言及している。逆に、証明書を使い分けず、1種類の証明書を使い回す方法も考えられる。5280によれば、発行先ホスト名を保持するsubjectAltNameはひとつの証明書に複数のエントリを作成できる。認証局が実際にそのような証明書を発行するかどうかは、別の問題である。認証局はすべてのホスト名に対して証明書の申請者が正当な管理者であることを確認しなければならないため、証明書発行の負荷は大きくなる。発行先ホスト名にワイルドカードを使う方法も考えられる。2818は、ワイルドカードの適用について記述している。バーチャルホストの対象が、ひとつのドメイン名の中のホストであれば、この方法で対応できる場合もある。どの方法も実装によって対応状況にバラつきがあり、環境によっては使えない可能性がある。IPアドレスベースのバーチャルホストであれば、ネゴシエーションの時点で確実にどのバーチャルホストを期待しているか判断できるので、問題なく証明書を使い分けることができる。セキュリティー上の考察SSL適用の有無と使用アルゴリズムの強度SSLを導入さえすればセキュリティーが確保できるという認識は誤っている。SSL通信は、平文での通信に比べて(主に暗号化・復号時)余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、SSLが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。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つの条件を満たす必要がある。利用者は意図する接続先の正しいホスト名を知っている。利用者は、現在システムに指示されている接続先が、自分の知っている正しいホスト名と一致していることを確認できる。(IPA)が公開している「安全なウェブサイトの作り方」[7]という文書の「フィッシング詐欺を助長しないための対策」に対応する。他の多くの近代暗号と同様に、SSLもまた、暗号としての強度は乱数の品質に依存している。桁数(bit長)の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。(これは,公開鍵暗号システムにも言える)もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった[8]。2008年5月15日にはDebianが脆弱性に関する報告[9]を発表した。OpenSSLライブラリのパッケージメンテナンスの際に誤ったパッチを導入した結果、鍵生成に適切な乱数が使われず僅か65536(=216)通りの予測可能な物が生成されてしまった事を明らかにした[10](なお、この問題はOpenSSLそのものの脆弱性ではない)。Xandrosである。脆弱性のあるバージョンのOpenSSLは2006年9月17日に公開された。安定バージョンがリリースされた2007年4月8日以降は確実に影響を受ける。コネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを総当たり攻撃で試すだけでいずれの鍵が使われているか解読可能であり(SSHでは20分間で解読できたと報告されている)、また脆弱な鍵がインストールされたDebianを含むの全てのオペレーティングスシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている。Windowsのような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、JPCERT/CCの勧告[11]等に従うべきである。3.0以降の再ネゴシエーション機能を利用して、クライアントからのリクエストの先頭に中間者が任意のデータを挿入できるという脆弱性が報告された[12][13]。プロトコル自体の脆弱性であり、すべての実装が影響を受ける。この脆弱性への簡単な対策は、サーバにおいて再ネゴシエーションを禁止することである。5746として提案されている。5746に対応しない限りクライアントは再ネゴシエーションが発生したことを検出できないので、クライアント単体で対応することは不可能である。オーム社、2003年11月28日、第1版第1刷。4-274-06542-1。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年1月3日閲覧。2010年2月13日閲覧。(1960年)スコーバレーオリンピック開幕(1960年)ガンビアがイギリスから独立(1965年)ハワイで世界初のトライアスロン大会開催(1978年)アルジェリア南部のサハラ砂漠で降雪。