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の再ネゴシエーションにおける脆弱性について述べる。

 　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つが挙げられている。

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

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

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

 　SSL/TLSの再ネゴシエーションの脆弱性に対して、IETF TLS WGでは再ネゴシエーションの手続きを修正する根本的な対策が提案された。この脆弱性の対策は、RFC 5746¹を反映した実装を利用することである。再ネゴシエーションが必要ない場合には、これを無効にすることも考えられる。なお、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が含まれており、再ネゴシエーションが行われる前後のセッションの連続性が確認できるようになっている。

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