SSL/TLSにおける中間者攻撃（MITM:Man-In-The-Middle）が可能となる脆弱性？

脆弱性

SSL/TLS において、中間者攻撃が可能となる脆弱性が発見されました（CVE-2009-3555*1, BID 36935）。すでに実証コード（PoC: Proof of Concept）も公開されているようです。「HTTPS 通信も盗聴可能になんの！？」と思い、気になったので公開されている情報をざっと読んでみました。が、正直なところ、きちんと理解できず、どれほどの脅威になるのかよく分かりませんでした。関連情報を読んで、僕が考えたこの脆弱性のポイント、理解できなかった点をまとめてみます。

誤解等ありましたら、是非コメント・Twitter・メールで教えてください:D

私見：この脆弱性のポイント

関連情報を読んだ限りでは、僕はこの脆弱性のポイントを以下の 2 つだと考えます。

  1. 前提条件として、中間者攻撃ができる環境を準備しなければいけない
  2. SSL/TLS 通信を改ざんできるのではなく、任意の平文を挿入できるだけである
ポイント 1. について

この脆弱性を悪用するためには、中間者攻撃ができる環境を準備しなければならないと考えます。中間者攻撃を実現するには、a) hosts ファイルの改ざん、b) DNS 情報の改ざん（DNS キャッシュポイズニングやドメインハイジャック）、c) ブラウザのプロキシサーバの設定改ざん、d) ARP ポイズニング*2といった手法があります。この脆弱性によって、中間者攻撃を実現する敷居が低くなったわけではないと思います。

ポイント 2. について

発見者 Marsh Ray氏、Steve Dispensa氏が公開している資料によると、この脆弱性を悪用することで、SSL/TLS 通信において、任意の平文を挿入できるようです（以下に該当部分を引用）。該当資料は一通り読みましたが、SSL/TLS の暗号化・復号については何も触れていないことから、SSL/TLS 通信を改ざんできるわけではないようです。

Summary
Transport Layer Security (TLS, RFC 5246 and previous, including SSL v3 and previous) is subject to a number of serious man-in-the-middle (MITM) attacks related to renegotiation. In general, these problems allow an MITM to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream, leading to a variety of abuse possibilities.

Renegotiating_TLS

この脆弱性を悪用したとして、ウェブアプリケーションに CSRF の脆弱性がある場合、SSL/TLS 通信において CSRF を実現されてしまうといったあたりが脅威となるのでしょうか。この脆弱性の技術的な背景が理解できなかったため、推測の粋を出ません。

理解できなかった点

この脆弱性で僕が理解できなかったのは、この脆弱性の技術的背景です。

発見者 Marsh Ray氏、Steve Dispensa氏が公開している資料では、SSL/TLS*3の 2 つの機能 − a) Renegotiation 機能、b) セッションの再利用（Session resumption） − を脆弱性の技術的背景として説明しています。機能 a) を利用する 3 つのシナリオを提示して、そのシナリオにおいて任意の平文を挿入できるとのことです。3 つのシナリオは以下の通りです。

  1. クライアント認証が必要となり、Renegotiation が生じる（トリガー：Server）
  2. サーバ・クライアントの暗号スイートが異なるため、Renegotiation が生じる（トリガー：Server）
  3. クライアントから Renegotiation 要求により、Renegotiation が生じる（トリガー：Client）

どのシナリオでも、中間者とサーバ間で確立した SSL/TLS セッションを再利用して、クライアントとサーバ間で確立した SSL/TLS セッションに任意の平文を挿入するようですが、この仕組みがよく分かりません。SSL/TLS 機能 b) を説明していることから、既存の SSL/TLS セッションのやり取りを Replay して、ごにょごにょしているんだけど思うんですが・・・

おまけ：SSL/TLS の Renegotiation 機能

RFC 5246では、TLS においてRenegotiation 機能は必須ではなく、あくまでオプショナルなものと定義しています。この脆弱性を対策した OpenSSL では、Renegotiation 機能を無効にしたことから、あまり利用される機会もないものだろうか（SANS Diary の記事）

Do you support renegotiation, both client and server initiated?
While renegotiation is an optional feature, supporting it is
highly recommended.

D.4. Implementation Pitfalls, RFC5246

参考情報

【収集用メールアドレス】：q1w2e3w2@gmail.com

*1:この日記を書いた時点では、RESERVED 状態

*2:SSL MITM では、クライアント・中間者、中間者・サーバ間で 2 つの SSL セッションを確立する必要があると思うので、ARP Spoofing が有効であるか疑問である。

*3:資料では、TLS の仕様を基に解説しているようだ