Let's start Scheme

2012-05-08

セキュリティについての考察

SSL/TLSのおけるセキュリティの考察。

実装がまったく行き詰っていて、息抜きにふと思いついたことをつらつら書いているとも言う。

以下に記載した内容に基づいて盗聴、改竄を行ったとしても当方は一切責任を取らない。また、この記事はそのような犯罪行為を推奨するものでもない。(お約束の免責事項)

ふと、ひょっとしたらハッキング(世間一般的に通じる言い方、本当はクラッキングと言う。一応)できるんじゃね?と思ったのでその手順。もちろん試してないし、僕にそのようなことが出来る技術はない。ただ仕様書を読んでいて出来そうだと思っただけ。

【用意するもの】
  • 偽のサーバー証明書
  • なりすまし用のルータ
  • SSL/TLSのパケットを作れる技術
【手順】
  1. クライアントが送ってきたCLIENT-HELLOのcipher suitesからDHなsuitesを取り除いてサーバーに送る。このときクライアントの乱数を記録しておく。
  2. サーバーが送ってくる情報のうち、決定したcipher suite、サーバーの乱数、サーバー証明書を抜き取る。また、サーバー証明を用意した偽の証明書と置き換えてクライアントに送る。
  3. クライアントがpre master secretを暗号化したものを送ってくるので、偽の証明書の秘密鍵で複合。master secretを作成する。また、送られてきたpre master secretを本物の証明書で暗号化してサーバーに送る。
  4. 以下、暗号化されたメッセージは手元のマスター鍵で複合したり、MACを合成したりしてなりすます。
【簡単な解説】
  1. Deffie-Hellmanを使われると現在のところ現実的な時間で鍵を手に入れることができないので、クライアントがサポートしているcipherから抜き取る必要がある。
  2. この時点でサーバーの証明書を抜き取ってしまえば、クライアントは成りすまし証明書を検出する方法はない。
  3. クライアントに対してはサーバーの振り、クライアントに対してはサーバーの振りをする。しないと不整合が起きるので。
3番が重要で、まともなクライアントなら偽の証明書にはルートCAがないということで警告を出すはず。でもユーザが構わずOKしたら、う~ん怖い。
もちろん、この程度のことはきっと議論され尽くしているはずなので基本的には問題にならないと思う。っが、RFCだけ見た感じだとそんなこと考えられてなかったので、どうなんだろう?

No comments:

Post a Comment