Security(トランスポート・レイヤー・セキュリティ、TLS)は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する。TLSはIETFによって策定された。これは、TLSの元になったプロトコルがSSLであり[1]、そのSSLという名称が広く普及していることによる[2]。概要[編集]TLSは多くの場合、コネクション型のトランスポート層プロトコル(通常はTCP)とアプリケーション層のあいだにおいて使われる。HTTPでの利用を意識して設計されているが、アプリケーション層の特定のプロトコルには依存せず、様々なアプリケーションにおいて使われている。して独立して標準化されている。TLSはHTTPなどのアプリケーション層のプロトコルと組み合わせることで、HTTPSなどセキュアな通信プロトコルを実現している。110アプリケーション層プロトコルへの適用[編集]TLSは特定のアプリケーション層プロトコルに依存しないため、HTTP以外にも多くのプロトコルにおいて採用され、クレジットカード情報や個人情報、その他の機密情報を通信する際の手段として活用されている。既存のアプリケーション層プロトコルでTLSを利用する場合、大きく2つの適用方式が考えられる。ひとつは、下位層(通常はTCP)の接続を確立したらすぐにTLSのネゴシエーションを開始し、TLS接続が確立してからアプリケーション層プロトコルの通信を開始する方式である。ひとつは、まず既存のアプリケーション層プロトコルで通信を開始し、その中でTLSへの切り替えを指示する方式である。切り替えコマンドとしてSTARTTLSが広まっているため、この方式自体をSTARTTLSと呼ぶこともある。前者はアプリケーション層のプロトコルをまったく変更しなくてすむことが利点である。その反面、平文で接続を開始する実装と共存できなくなるため、既存のポート番号とは別にTLS対応用のポート番号が必要となる。実態としては、SSL/TLSの最初の適用例であるHTTPSをはじめとして、前者の方式を使うことが多い。この方式はバーチャルホストを構成する際に問題となる可能性がある。詳細は#バーチャルホストの節を参照。ポート番号を分ける方式をSSL、同一ポート番号で切替える方式(STARTTLS方式)をTLSと呼んでいる実装もある[3]。TLS/SSLという用語の区別がプロトコルのバージョンを指しているか、アプリケーション層プロトコルへの適用方式を指しているかは、文脈で判断する必要がある。セキュリティ上の考察[編集]TLS適用の有無と使用アルゴリズムの強度[編集]TLSを導入さえすればセキュリティが確保できるという認識は誤っている。TLS通信は、平文での通信に比べて(主に暗号化・復号時)余分な計算機能力を使用するため、本当に必要なとき以外は使用しないことが多い。システムはデータの重要性を判断することができないので、TLSが必要なときに正しく使われているかどうかは、利用者自身が判断しなければならない。Webでは、ハイパーリンクによるページ遷移を繰り返して処理を行うため、どの通信でSSL/TLSが使用されているか把握することが重要になる。多くのウェブブラウザは、画面のどこかに南京錠のアイコンを表示したり、アドレスバーの色を変化させたりして、利用者に情報を提供している。実際に使用するアルゴリズムは双方のネゴシエーションによって決まるため、TLSを使用していても、システムとして許容はするが推奨できないアルゴリズムが採用される可能性がある。このような場合もダイアログメッセージなどを使って利用者に警告すべきである。証明書の正当性[編集]TLSは公開鍵証明書を用いて認証を行い、なりすましを極力排除しようとする。システムの自動的な対応には限界があり、すべてのなりすましを検出できるわけではない。公開鍵証明書には認証局による電子署名が与えられる。その署名の正当性を評価するためには認証局の証明書が必要であり、最終的にはルート証明書と呼ばれる一群の証明書に行きつく。各システムは、認証局の証明書として信用できるルート証明書を、あらかじめ保持している。認証局は自身の秘密鍵を厳重に秘匿し、また証明書の発行にあたっては正当なサーバ管理者かどうか確認することが求められる。これらが保証されない認証局のルート証明書を組み込むことは、TLSにおける認証機能を破綻させることになる。仮に認証局自体は安全でも、入手したルート証明書が本当に意図する認証局のものかどうか判断することは難しいという点も注意すべきである。TLSで認証を行うためには、認証局の署名に加えて、証明書の発行先を確認する必要がある。確認しない場合、サーバAの管理権限を持たない者がサーバBとして正当な証明書を取得し、その証明書を使ってサーバAを名乗ることができてしまう。TLS用のサーバ証明書には発行先サーバのホスト名が書き込まれており、クライアントは自分が接続しようとしているサーバのホスト名と一致するかどうか確認することができる。現実には「正当な」サーバであっても、これらの検証において「問題がある」と判断される証明書を使って運用されているサーバが少なからず存在する。セキュリティ研究者の高木浩光は、このような証明書のことを、オレオレ詐欺をもじって「オレオレ証明書」と呼んで批判している[4]。この検証は、システムに指示された接続先のホスト名と実際に接続した先のホスト名が一致することを検証しているのであり、利用者が意図する接続先とは必ずしも一致しないことに注意する必要がある。例として、利用者が意図する接続先であるサーバAがホスト名www.example.comでサービスを提供しており、攻撃者はサーバBおよびホスト名www.example.orgを取得している場合を考える。仮に攻撃者がDNS偽装に成功して、www.example.comへの接続をサーバBに導くことができたとしても、www.example.comのサーバ証明書を入手できないので、TLS接続を提供することはできない。攻撃者も、www.example.orgのサーバ証明書を入手することはできる。したがって、サーバAに接続しようとしている利用者を、www.example.comではなくwww.example.orgへ接続させることができれば、クライアントからは正当な証明書を持ったサーバとしか見えない。上記のような例も考慮した上で、利用者が意図している接続先かどうかを判断するためには、以下の2つの条件を満たす必要がある。利用者は意図する接続先の正しいホスト名を知っている。利用者は、現在システムに指示されている接続先が、自分の知っている正しいホスト名と一致していることを確認できる。公開している「安全なウェブサイトの作り方」[5]という文書の「フィッシング詐欺を助長しないための対策」に対応する。乱数の品質[編集]他の多くの近代暗号と同様に、TLSもまた、暗号としての強度は乱数の品質に依存している。桁数(ビット長)の大きな暗号は推測が難しいという前提が暗号強度の根拠となっている。(これは、公開鍵暗号システムにも言える)もし何らかの理由で乱数の出現確率が大きく偏るようなことがあれば、総当たり攻撃で解読される可能性が上昇する。通常は、これは実装の問題に起因している。古い例では、Netscapeの初期の実装における乱数生成の脆弱性がある。プロセスIDや時刻から乱数を生成していることが判明し、これらの情報を取得できる場合には総当たり攻撃の所要時間が大幅に短くなるという問題があった[6]。2008年5月15日にはDebianが脆弱性に関する報告[7]を発表した。通りの予測可能な物が生成されてしまった事を明らかにした[8](なお、この問題はOpenSSLそのものの脆弱性ではない)。Debian、sidux、Ubuntu、UserLinux、Xandrosである。脆弱性のあるバージョンのOpenSSLは2006年9月17日に公開された。安定バージョンがリリースされた2007年4月8日以降は確実に影響を受ける。脆弱性のあるバージョンのOpenSSLで作られた鍵全て、SSH鍵、OpenVPN鍵、DNSSEC鍵、X.509証明書を生成するのに使われる鍵データ、およびSSL/TLSコネクションに使うセッション鍵等が影響を受ける。これらの鍵は65536通り全てを総当たり攻撃で試すだけでいずれの鍵が使われているか解読可能であり(SSHでは20分間で解読できたと報告されている)、また脆弱な鍵がインストールされたDebianを含む全てのオペレーティングシステムにおいて緊急の対応が必要であると専門家が注意を呼びかけている。Windowsのような非UNIXシステムに導入しているような場合も、この脆弱性の影響を受ける。具体的対応については、Debianの報告の他、JPCERT/CCの勧告[9]等に従うべきである。1.2の概要を説明する。secretを用いて暗号通信することで確立されたセッションにおけるコネクションをセキュアにするTLSレコードプロトコルがある。アラートプロトコルがある。TLSハンドシェイクプロトコル[編集]TLSハンドシェイクプロトコルは4つのフェーズに大別できる。第一フェーズ[編集]第一のフェーズではサーバ・クライアント間で通信に必要情報の合意を図る。このフェーズでは、まずクライアントからサーバにClientHelloが送信され、次にサーバからクライアントにServerHelloが送信される[10]。(cipher_suites)、通信内容の圧縮方法、および拡張領域の6つからなる[10]。乱数は鍵共有におけるリプレイ攻撃を防ぐためのものである。ServerHelloもClientHelloと同様の6つからなっている(名称は一部異なる)[10]。ServerHelloの主な目的は、ClientHelloで提示された選択肢の中でサーバにとって好ましいものを選択する事で、例えばClientHelloで提示されたcipher_suitesの中から、サーバが通信に使いたいcipher_suiteを一組選ぶ[10]。乱数はClientHelloとは独立して選ぶ[10]。これもリプレイ攻撃を回避するためである。セッションIDは特に問題がなければClientHelloと同一のものを返す。第二フェーズ[編集]第二フェーズではサーバからクライアントに対して鍵共有に必要な情報を送る。具体的にはサーバはCertificate、ServerKeyExchange、CertificateRequest、ServerHelloDoneを(第一フェーズServerHelloに引き続き)クライアントに送信する[10]。Certificateは鍵共有で用いる公開鍵とその証明書で別途取り決めがない限りX.509v3のフォーマットに従う[10]。鍵共有方式としてDH_anonを用いている場合にはcertificateは必要ない[10]。pという形のデータを送る。ここでxはサーバの秘密の乱数である。鍵共有プロトコルがDHE_DSS、DHE_RSA、DH_anonでは何らかのserver_key_exchangeを送るが、RSA、DH_DSS、DH_RSAでは何も送らない[10]。CertificateRequestはクライアントの公開鍵とその証明書を送ることを要求するためのもので、サーバが許容できる証明書の種別、ハッシュと署名方式、および認証局のリストからなっている[10]。最後にサーバ側からのメッセージ送信が終わった事を示すServerHelloDoneをクライアントに送る。第三フェーズ[編集]第三フェーズではクライアントからサーバに対して鍵共有に必要な情報を送る。具体的にはクライアントはCertificate、ClientKeyExchange、CertificateVerifyをサーバに送る[11]。Certificateは鍵共有で用いるクライアントの公開鍵とその証明書である。証明書はサーバから送られてきたCertificateRequestの条件を満たさねばならない。pという形のデータを送る。ここでyはクライアントの秘密の乱数である。secretが共有された事になる。secretである[11]。プロトコルのメッセージをサーバに送り、終了を意味するFinishedをサーバに送る。プロトコルのメッセージをクライアントに送り、終了を意味するFinishedをクライアントに送る[10]。防護を施した上で、通信内容を通信相手に送信する[12]。1.3ではAEADのみが利用可能となっている。1.1以降においてIVはTLSレコードプロトコルの送信者がランダムに選ぶ[12]。ランダムなIVは、BEAST攻撃への対策として有効である。secretを用いる。バージョン[編集]コンピュータの計算能力の向上とともに、認証の突破、暗号の解読、改竄も以前よりは容易に行えるようになり、セキュリティ確保のための技術も厳しさを増している。以下のサポートを停止するサイトも出てきている。1.0[編集]ネットスケープコミュニケーションズ社がSSLの最初のバージョンとして設計していたが、設計レビューの段階でプロトコル自体に大きな脆弱性が発見され、破棄された。1.0を実装した製品はない。2.0として発表した。3.0において修正された。2.0の脆弱性のひとつは、ネゴシエーションの情報を改竄すると、提示する選択肢のうち最弱のアルゴリズムを使わせることができ(ダウングレード攻撃)、改竄を受けたことを検出できないというものである。2.0で接続させることさえ可能になる。2.0との互換性を提供するにあたり、乱数領域を使った細工を加えることで、このような攻撃を検出する仕組みを組み込んだ。2.0を無効にしない限りこの脆弱性の影響を受ける可能性を否定できない[16]。2.0を無効にしている[17][18][19]。3.0以降へ対応する動きが広まっている[20]。2.0にはチェーン証明書がなく、ルートCAから発行したSSLサーバ証明書しか使うことができない。2.0の使用は禁止された。