HOME情報セキュリティ資料・報告書・出版物調査・研究報告書情報セキュリティ技術動向調査(2009 年下期)

本文を印刷する

情報セキュリティ

情報セキュリティ技術動向調査(2009 年下期)

2 SSL/TLSのrenegotiation(再ネゴシエーション)における脆弱性

木村 泰司

1. 概要

  2009年11月、SSL(Secure Sockets Layer)およびTLS(Transport Layer Security)の脆弱性[1][2][3]がPhoneFactor社のMarsh Ray氏によって公表された[4]。脆弱性のあるTLSv1.2とSSLv3.0は、Webページのセキュアな閲覧の為に使われている最新のプロトコルで影響範囲が広い。
  発見された脆弱性は、SSL/TLSのサーバとクライアントの間で、暗号アルゴリズムや暗号鍵の変更等のために使われるrenegotiation(以下、再ネゴシエーションと呼ぶ)の手順(以下、ハンドシェイクと呼ぶ)にある。攻撃が成功すると、クライアント側から送信する通信データの中に任意の文字列を挿入することができ、Man-in-the-middle attack(以下、中間者攻撃)が可能になるというものである。
  この脆弱性の発見を受けて、IETFのTLS WGでは、対策を提案したRFC 5746[5] をわずか3ヵ月程でまとめ、2010年2月に公表した。またSSL/TLSのライブラリで知られるOpenSSLは、脆弱性が発見されたのちに、急遽、再ネゴシエーション機能を無効化したバージョンがリリースされ[6]、その後RFC 5746で提案された対策を実装した0.9.8m-beta1がリリースされた。
  本稿では、インターネットにおける通信の安全性に大きく影響することを踏まえて、2009年度後半の動向として、SSL/TLSの再ネゴシエーションにおける脆弱性について述べる。

2. 再ネゴシエーション・ハンドシェイクとその脆弱性

  SSLとTLSはTCPの上位に位置するプロトコルである。TLSのセッション(以下、セッションと呼ぶ)は、TCPのコネクションが確立したのち、その通信路を利用して鍵確立などが行われる。TLSのネゴシエーション・ハンドシェイク(以下、ネゴシエーション)には、クライアントとサーバがセッションを新規に確立するための初期ネゴシエーションと、一度確立したセッションのパラメーターを変更するための再ネゴシエーションの2種類がある。
  初期ネゴシエーションでは、クライアントとサーバが、使用できる暗号アルゴリズムの情報やそのパラメーターを伝達したり、通信データの暗号化に使われる共有鍵のためのランダム値を伝達したりする。このハンドシェイクが成功するとセッションが確立し、以降のクライアント・サーバ間の通信はネゴシエーションされた内容に基づいて暗号化される。

  TLSの再ネゴシエーションは、TLSv1.0およびSSLv3.0で新たに提案されたハンドシェイクである。一度確立したセッションに置き換わる新たなセッションを確立するために、クライアントとサーバの間で行われる。再ネゴシエーションは、既に確立しているセッションを使って、サーバからクライアントへのHelloRequestと呼ばれる要請のメッセージか、クライアントからの初期ネゴシエーションと同様のClientHelloのメッセージが送られることによって開始する。
  再ネゴシエーションは、暗号化されているセッションを使って行われるため、盗聴してもその内容を知ることは基本的に難しい。また実際のハンドシェイクを偽造することも難しい。しかしMarsh Ray氏によると、再ネゴシエーションの前後のセッションは、暗号化の状態が連続していても、認証の状態は不連続であり、後のセッションのトラフィックが予測可能である場合、攻撃者が予め用意しておいたセッションと入れ替えられると指摘されている[7]。2009年11月、IETF TLS WGで同じ脆弱性を発見したMartin Rex氏のInternet-Draft[8] では、この脆弱性を利用した攻撃パターンとして、以下の3つが挙げられている。


 

○再ネゴシエーションの脆弱性を利用した攻撃パターン

  • クライアントの初期ネゴシエーションの入れ替え
    • クライアントの初期ネゴシエーションが終わった後のセッションを、サーバの別の再ネゴシエーション後のセッションに入れ替える。
  • サーバの初期ネゴシエーションの入れ替え
    • クライアントの別の再ネゴシエーション後のセッションを、サーバの初期ネゴシエーションが終わった後のセッションに入れ替える。
  • 別個のセッションから単一セッションの作成
    • クライアントと攻撃者、攻撃者とサーバの間のセッションを、クライアントとサーバの間の単一のセッションにつなげる。攻撃者はクライアントとサーバの間の通信を完全に中継できる。

  いずれのパターンでも、クライアントとサーバはネゴシエーションが成功しているように見えるため、基本的に攻撃されていることを検知することは難しい。

3. 脆弱性の影響

  前回の第76回IETFにおけるTLS WGでの発表資料[9] によると、この脆弱性を利用すると、以下のようなことが可能になると指摘されている。SSL/TLS自体の脆弱性であるため、この他にもSSL/TLSを使ったIMAPやLDAP等の様々なプロトコルに影響する。

 
  • クライアントに成りすましたデータ挿入
    • クライアント認証が行われたTLSの通信において、認証手続きが行われていないセッションでのデータ挿入が可能である。
  • クライアントの送信データの取得
    • クライアント証明書なしに、TLSを通じてクライアントがサーバに向けて送信したデータを取得できる。
  • 意図しない認証状態への変更
    • 本来はクライアント認証を必要としないにも関わらず、クライアント認証をサーバが要求するように、再ネゴシエーションを通じて本来と異なる認証状態にさせられてしまう可能性がある。

  中間者攻撃の実現には、クライアントやサーバとSSL/TLSのセッションを確立できるような通信環境が必要であるが、本来SSL/TLSはそのような攻撃が行われる環境においてもセキュアな通信を実現する目的で設計されたプロトコルである。インターネットを含む様々なネットワークでは、その想定の下でSSL/TLSが使われているという意味で、重大な脆弱性が発見されたといえる。

4. 対策

  SSL/TLSの再ネゴシエーションの脆弱性に対して、IETF TLS WGでは再ネゴシエーションの手続きを修正する根本的な対策が提案された。この脆弱性の対策は、RFC 57461を反映した実装を利用することである。再ネゴシエーションが必要ない場合には、これを無効にすることも考えられる。なお、SSL/TLSのライブラリであるOpenSSLでは、RFC 5746を反映したバージョンがリリースされている。
  この修正では、再ネゴシエーションに新たに二つの変更が加えられた。ひとつはコネクション状態を示すフラグ等の追加である。TLSv1.2[10]の6.1節で定義されているコネクション状態において、セキュアにセッションを引き継ぐことを示すsecure_renegotiationと呼ばれるフラグと、client_verify_data、server_verify_dataと呼ばれる、直前のセッションで交換されたメッセージを含める値である。もうひとつは、renegotiation_infoと呼ばれるTLS拡張である。TLS拡張は、ネゴシエーションの際のClientHelloとServerHelloの末尾に付けられる値である。renegotiation_infoには前述のコネクション状態を示すclient_verify_dataおよびserver_verify_dataが含まれており、再ネゴシエーションが行われる前後のセッションの連続性が確認できるようになっている。


1 このドキュメントは、広島で開催された第76回IETF期間中のTLS WGで発表されたが、同時に異例の速さでRFCにするためのスケジュールも発表された11月30日にWG Last Callを終え、12月22日にIETF Last Call完了、2月14日にRFC Editorの作業を終えてRFCとして公開するというものである。

5. まとめ

  SSL/TLSはhttpsをはじめ、SSL-VPNなど、インターネットにおけるセキュアな通信を実現する方式として、最も広く使われているプロトコルのひとつであるといえる。その脆弱性の影響は大きいが、IETFのTLS WGではいち早く根本的な解決方法を提案し、それはSSL/TLSのライブラリであるOpenSSLにも反映された。
  現代の、数多くのプログラムの脆弱性が発見される中で、特にプロトコルの脆弱性に対して必ずしも十分な速さで対策がとれるとは限らない。今後も、善意の技術者が迅速に解決に向けた活動を実施できることが重要であると考えられる。

以上

参考文献

[1] CVE-2009-3555,
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
[2] “Vulnerability Note VU#120541 SSL and TLS protocols renegotiation vulnerability”,
http://www.kb.cert.org/vuls/id/120541
[3] “JVNVU#120541:SSLおよびTLSプロトコルに脆弱性”,
http://jvn.jp/cert/JVNVU120541/
[4] “Authentication Gap in TLS Renegotiation” (Marsh Ray氏のブログ),
http://extendedsubset.com/?p=8
[5] “Transport Layer Security (TLS) Renegotiation Indication Extension”,
http://tools.ietf.org/html/rfc5746日本語訳
[6] “OpenSSL version 0.9.8l released” (0.9.8lのannouce.txt),
http://cvs.openssl.org/fileview?f=openssl-web/news/announce.txt&v=1.52
[7] “Renegotiating TLS”,
http://extendedsubset.com/Renegotiating_TLS.pdf
[8] “Transport Layer Security (TLS) Secure Renegotiation”
http://tools.ietf.org/id/draft-mrex-tls-secure-renegotiation-04.txt
[9] “TLS Renegotiation Vulnerability”
http://tools.ietf.org/agenda/76/slides/tls-7.pdf
[10] RFC 5246, “The Transport Layer Security (TLS) Protocol Version 1.2”,
http://tools.ietf.org/html/rfc5246日本語訳

 

目次へ 次へ