WEBブラウザのSSL実装におけるワイルドカードの問題
SSL は基本的に end-to-end な暗号プロトコルです。SSLでは
ブラウザがアクセスしたWEBサーバの正当性を判断する手段として
基本的に
(1) サーバ証明書のデジタル署名(CRLの検証を含む)
(2) 署名認証局の正当性
(3) サーバ証明書の subject.cn に書かれたサーバのDNS名
この3つを持っています。
(1)(2)を偽造することは困難ですので、たとえば、攻撃者は
(3)を攻略するためにDNSデータベースへの攻撃を行って
なりすましによりWEBサーバを偽装したとします。
この場合、(2)の検査によりブラウザが警告を発します。
また、DNSデータベースへの攻撃では数件のWEBサーバの
改ざんになり、攻撃対象がおのずと限られることもポイントです。
ところで、(3)のDNS名の検査で、「*」がワイルドカードとして
解釈されるようにブラウザのSSLが実装されています。
これは、たとえば、クラスタ構成の場合において使用されます。
しかし、このワイルドカード機能は、TLDに対しても適用されます。
つまり、subject.cn=* なサーバ証明書は全てのDNS名とマッチし、
その場合(3)の検査ではブラウザは警告を発しません。
ここで、エシュロンが出てきます。認証機関が秘密裏に
subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
さらに、そのサーバ証明書を大きなIXのルーターにインストールし、
すべての 443/tcp のパケットを横取りして、man-in-the-middleの攻撃を
するプログラムをインストールしたと「仮に」したら、どうでしょうか。
この場合、ブラウザは警告を発しませんので、利用者は
わざわざサーバ証明書の内容を検査しないでしょう。
利用者は man-in-the-middle攻撃がなされたことに気が付きません。
また、この攻撃は、IXを通るすべての HTTPS 接続を対象とすることが
できます。そして、セッションIDを利用することで、「すべての 443/tcp」
でなく「指定された時間帯や確率で SSL ハンドシェイク」を横取りして再現性を低くし、
クライアント側からの疑惑を回避させることも可能です。
ここまでお読みになられた方なら、あなたがするべきことが何か
もうわかっていますよね。
さあ、あなたの接続先のサーバ証明書が subject.cn=* でないことを確認しましょう。
わけもわからず、とりあえず
ズザーっと。
3 :
名無しさん@お腹いっぱい。:02/03/16 15:26
どういうマッチのさせ方ならいいのでしょうか?
どこからのコピペか知らんが
> ここで、エシュロンが出てきます。認証機関が秘密裏に
> subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
誰か1人でもcn=*な証明書を保存出来たならば、その認証局が発行した動かぬ証拠になる。
そういう認証局は速攻でルートサーバからはずせばいいだけ。
誰からも信頼されなくなった認証局はつぶれるだけ。
つまり、このリスクは
>>1かこの文書を書いたヤシの脳内妄想って事だ。
>>4 >誰か1人でもcn=*な証明書を保存出来たならば、その認証局が発行した動かぬ証拠になる。
>そういう認証局は速攻でルートサーバからはずせばいいだけ。
え〜と、誰かが気が付いてくれるまで待っていればいいのですか?
あなたの重要な個人情報が盗聴されてからでは遅いのではないのですか?
例えば、証券会社へのSSL接続で、パスワードが盗まれて、
あなたが気がつく前に保有する株を売られてしまったり、
登録されている個人情報が書き換えられてしまったら、どうでしょうか。
そのときに、あなたが失った資産を守ってくれるもの(法律)はありますか?
>誰からも信頼されなくなった認証局はつぶれるだけ。
>つまり、このリスクは
>>1かこの文書を書いたヤシの脳内妄想って事だ。
私が書いたことは、サーバ証明書の subject.cn はワイルドカードが適用
されるので、自分の目でちゃんと確かめないといけないよ
ということですが、それが脳内妄想なのでしょうか?
>>4 は
>>1 の内容を後1000回くらい読み直してみてください。
そうすれば、理解していただけると思いますよ。
>>3 country TLDの場合は、第4レベルからワイルドカードを許し、
そうでないときには、第3レベルから許せばよいと思います。
>>4 >>6 の内容をもうすこしわかりやすくしますね。
たとえば、ウィルスですが「ワクチンソフトがあれば万全」ではないですよね。
ワクチンをインストールしていてもメールの添付ファイルの実行は不用意には
するべきではありませんよね?
それと同じで、SSL の接続においては、注意するべき事項があるということです。
>>6 おぃおぃ、話すりかえちゃいかんよ。
米政府が個人の財産狙うという妄想かい?
認証局が(米)政府と通じてワイルドカードな証明書を発行することは、
その認証局が自分の首を自分ででしめるという事だ。
>>1は
>>3を10万回くらい読み返すことだな。認証局が(盗聴の為に)そういう事を
しないという事がわかるかもしれない。
頭悪そうだからわからないかもしれないけどな。
>>9 世の中はお金で動いています。
米政府の高官が犯罪犯して
トンズラするかもしれませんよね。
そのときに、認証局のえらい人を金で
抱き込めばよいでしょう。
認証局なんて赤字なところばっかりですから、
潰れそうなところを使えばよいでしょ。
ムネオみたいな人が、不況で苦しんでいる人に
愛の手を差し出すって筋書きですね。
>>10 に補足
あ、エシュロンの真の目的は別ですが、
悪巧みを持ったバカなヤツが、それを手段として
行使する可能性はあるでしょ。
>>10 電子署名の持つ意味を考えて見ることだ。
身分証明書晒しながら犯罪犯した奴がかつて存在したならそれを示して見れ。
>>11 エシュロンはその存在が実証されていないから生き残っている。
一般人にその存在を知らせるような運用システムであるはずがない。
詐欺に引っかかったとしてもエシュロンの存在を確認できた英雄になれるな。(プ
で、
>>3には見事にシカトこいてるわけね。
まあ返事できるわけないけどね。ただのデンパだから。
>>13 >>7 ここにかいてあります。
神経内科っていうのがありますので、
そちらにご相談なさるのがよいと思いますよ。
なんか、宇宙人が攻撃してくるぞ〜ってな
内容に偏ってきたので、別の話題にしますです。
SSLではX.509証明書を使いますが、これにはバージョンがあって
v1からv3まであります。で、v1は使用しないのがよいのですが、
ルート認証機関の証明書とかサーバ証明書とかにはまだ使われています。
v1の証明書にはイロイロ問題があるのでv3ができたのですが、
その問題のうち、わかりやすいのを解説します。有名な話です。
でも、やっぱりSSLのman-in-the-middle attackの話ですが ^^)
有名な認証機関Aがあって、Aのルート証明書がIEとかNSに入っているとします。
Aのルート証明書は v1 で、このルート証明書から直接v1のサーバ証明書を
発行しています(よくある形態です)。B社のサーバ証明書を発行したとします。
A-CA(X.509 v1)
↓発行
B's Server cert(X.509 v1)
しかし、発行したサーバ証明書をB社がCA証明書として使用してしまうのです。
そして、あろうことか、A社の名前を騙って、A社の偽ルート証明書を発行してしまうのです!!
(もちろん、公開鍵は違いますよ)
B's Server cert(X.509 v1)
↓発行
偽A社ルートCA(公開鍵は本物と違う)
↓発行
偽C bank サーバ証明書(こいつを使う)
で、さらに、この偽ルートから、どっかの会社の偽サーバ証明書を発行します。
たとえば、有名な金融機関のオンラインなんちゃらのサーバ証明書とかです。
とりあえず、C bank とします。
で、ルーターに仕掛けます。やりかたは
>>1 です。
あ、それとSSLハンドシェイクのときに、中間CAはすべてごっそりとクライアントに渡すようにします。
すると、ユーザーには、警告はでません。(本物のA-CAが階層の最上位のルート証明書だからね)
また、C bank の本当のサーバ証明書も有名なA社のサーバ証明書だったり
するので、サーバ証明書の issuer を見てもA社の名前になってて、
偽A社ルートCAであることに気づきづらいわけですね。
この攻撃を見抜くためには、証明書の階層を確認しないとダメです。めんどくさいね!!
NSの場合は、階層がグラフィカルに表示されないので、fingerprint をチェック
しないとわかりません。さらにめんどくさいね!!
これに対処するには、B社のサーバ証明書をv3証明書にして、basicConstraints フィールドを導入
すればよいです。これは、証明書がCA証明書であるかないかのフラグを持ちます。
だから、これを見れば、B社サーバ証明書でCAやっているのを拒否できます。
とりあえず、この問題ではA-CA証明書をv3にする必要はありません。いじょ。
ひさしぶりに書いてみる。
IISのクライアント認証で、CRLをhttpで読み取る場合、
WEBサーバが 500 エラーを返した場合と、404 エラーを返した場合で、
クライアント認証の挙動が変わるね。
政府認証基盤の統合リポジトリの
アドレスは www.gpki.go.jp で公開してないね。
ここに書いてしまおうかと。知りたい人はITEM2000をDLしる。
Ministry of Justice ってのは毎年CA証明書を更新するんだとさ。
だから、毎年リンク証明書を発行するんだけどね。
この間発行したリンク証明書(NewWithOld)の notAfter 間違っていましたよ。ええ。
2004年までが正しいのに、2005年までになっていました。まあ、難しいけどねぇ。