SSL/TLSに男らしい脆弱性が発覚

security

next : http://d.hatena.ne.jp/mjt/20091110/p1
追記 : 問題は対策されつつあり、近い将来には重要な問題で無くなる可能性が高い。

サマリ : クライアント証明書を持って無い人は関係ない。Web上で本人証明を伴うサービスを使ってる人は関係有る。
TLSとSSLは同じものと考えて良い。どちらにもこの問題は有る。以下TLSに統一。

前提

ここでのTLS+HTTPでは、２種類のセキュアなコミュニケーションが存在すると仮定する。

  • (A) 匿名でおこなわれる通信
  • (B) 身分証明(クライアント証明)を伴う通信

Bは、例えば電子申請とかに使われる。税金の申告とかをICカードとPCの組み合わせで行うようなアレ。
今回の問題は、このBが危なくなったという話。

問題

TLSは、上位のプロトコル、つまり典型的にはHTTPと分離されて動作する。これが重要な問題。TLSは、いつクライアントの身分証明が必要になるかを事前に把握することが出来ない。

の最後の図を参照。cがクライアント(あなた)、mが中間者(悪い人)、sがサーバとする。
この状況において、mはcの意図しない悪いリクエストをcのふりをして送信することが出来る。つまり、

  • c は、sと間違えてmにリクエストを送る
  • m は、sのふりをして接続が正常に行われたようにみせかける
    • m は、本人確認の必要な悪いリクエスト(POST /secure/evil...)をsに送ってみる
    • s は、そのリクエストが上記Bに相当することを認識するので、mに対してTLS的な身分証明を求める
    • m は、身分証明のリクエストをcに素通しして、代わりにcに身分証明させる
  • s は、cの身分証明が完了したことを認識して、悪いリクエストを実行してしまう
  • cは身分証明をさせられた後、最初のリクエストを送ることになるが、それは何らかの方法でサーバに無視させる

これは成功することが示されている。

対処

多くのケースでは、身分証明を行う際にPIN番号とかなんらかのパスワードの入力を要求する。だから、意図しないタイミングで身分証明を求められた場合は疑いの心を持つしかない。
ただ、一度入力されたパスワードはキャッシュされてしまうこともあるので安心は出来ない。たとえば、MacOSや(7以降の)Windowsは、いわゆるkeyringの仕組みを持っており、一度正常にログインすれば身分証明は自動的に行うようになる。
今の所本質的な解決策は無い。文書に示されている"直ぐに出来る対応"は、身分証明を必要とするようなコンテンツを含んでいるサーバと、そうでないサーバのIPアドレスを分けること。そうすれば、身分証明の際には異なる接続が必要になり、このような問題も避けることが出来る(上のフローで最初に行われるcのリクエストは身分証明が不要であるという前提)。サイトの再構築が必要だが、いわゆるreverse proxyのような機器による自動化も可能だろう。ブラウザも、何らかのリクエストを送った後で身分証明を行うときは警告するべきかもしれない。