WEBブラウザのSSL実装におけるワイルドカードの問題
1 ：1：
SSL は基本的に end-to-end な暗号プロトコルです。SSLでは
ブラウザがアクセスしたＷＥＢサーバの正当性を判断する手段として
基本的に
（１） サーバ証明書のデジタル署名（ＣＲＬの検証を含む）
（２） 署名認証局の正当性
（３） サーバ証明書の subject.cn に書かれたサーバのＤＮＳ名
この３つを持っています。
（１）（２）を偽造することは困難ですので、たとえば、攻撃者は
（３）を攻略するためにＤＮＳデータベースへの攻撃を行って
なりすましによりＷＥＢサーバを偽装したとします。
この場合、（２）の検査によりブラウザが警告を発します。
また、ＤＮＳデータベースへの攻撃では数件のＷＥＢサーバの
改ざんになり、攻撃対象がおのずと限られることもポイントです。
ところで、（３）のＤＮＳ名の検査で、「*」がワイルドカードとして
解釈されるようにブラウザのSSLが実装されています。
これは、たとえば、クラスタ構成の場合において使用されます。
しかし、このワイルドカード機能は、TLDに対しても適用されます。
つまり、subject.cn=* なサーバ証明書は全てのＤＮＳ名とマッチし、
その場合（３）の検査ではブラウザは警告を発しません。
ここで、エシュロンが出てきます。認証機関が秘密裏に
subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
さらに、そのサーバ証明書を大きなＩＸのルーターにインストールし、
すべての 443/tcp のパケットを横取りして、man-in-the-middleの攻撃を
するプログラムをインストールしたと「仮に」したら、どうでしょうか。
この場合、ブラウザは警告を発しませんので、利用者は
わざわざサーバ証明書の内容を検査しないでしょう。
利用者は man-in-the-middle攻撃がなされたことに気が付きません。
また、この攻撃は、ＩＸを通るすべての HTTPS 接続を対象とすることが
できます。そして、セッションＩＤを利用することで、「すべての 443/tcp」
でなく「指定された時間帯や確率で SSL ハンドシェイク」を横取りして再現性を低くし、
クライアント側からの疑惑を回避させることも可能です。
ここまでお読みになられた方なら、あなたがするべきことが何か
もうわかっていますよね。
さあ、あなたの接続先のサーバ証明書が subject.cn=* でないことを確認しましょう。
ブラウザがアクセスしたＷＥＢサーバの正当性を判断する手段として
基本的に
（１） サーバ証明書のデジタル署名（ＣＲＬの検証を含む）
（２） 署名認証局の正当性
（３） サーバ証明書の subject.cn に書かれたサーバのＤＮＳ名
この３つを持っています。
（１）（２）を偽造することは困難ですので、たとえば、攻撃者は
（３）を攻略するためにＤＮＳデータベースへの攻撃を行って
なりすましによりＷＥＢサーバを偽装したとします。
この場合、（２）の検査によりブラウザが警告を発します。
また、ＤＮＳデータベースへの攻撃では数件のＷＥＢサーバの
改ざんになり、攻撃対象がおのずと限られることもポイントです。
ところで、（３）のＤＮＳ名の検査で、「*」がワイルドカードとして
解釈されるようにブラウザのSSLが実装されています。
これは、たとえば、クラスタ構成の場合において使用されます。
しかし、このワイルドカード機能は、TLDに対しても適用されます。
つまり、subject.cn=* なサーバ証明書は全てのＤＮＳ名とマッチし、
その場合（３）の検査ではブラウザは警告を発しません。
ここで、エシュロンが出てきます。認証機関が秘密裏に
subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
さらに、そのサーバ証明書を大きなＩＸのルーターにインストールし、
すべての 443/tcp のパケットを横取りして、man-in-the-middleの攻撃を
するプログラムをインストールしたと「仮に」したら、どうでしょうか。
この場合、ブラウザは警告を発しませんので、利用者は
わざわざサーバ証明書の内容を検査しないでしょう。
利用者は man-in-the-middle攻撃がなされたことに気が付きません。
また、この攻撃は、ＩＸを通るすべての HTTPS 接続を対象とすることが
できます。そして、セッションＩＤを利用することで、「すべての 443/tcp」
でなく「指定された時間帯や確率で SSL ハンドシェイク」を横取りして再現性を低くし、
クライアント側からの疑惑を回避させることも可能です。
ここまでお読みになられた方なら、あなたがするべきことが何か
もうわかっていますよね。
さあ、あなたの接続先のサーバ証明書が subject.cn=* でないことを確認しましょう。
|
|
|
2 ：名無しさん＠お腹いっぱい。：02/03/16 14:31
わけもわからず、とりあえず
ｽﾞｻﾞｰっと。
ｽﾞｻﾞｰっと。
3 ：名無しさん＠お腹いっぱい。：02/03/16 15:26
どういうマッチのさせ方ならいいのでしょうか？
4 ：名無しさん＠お腹いっぱい。：02/03/16 15:52
どこからのコピペか知らんが
> ここで、エシュロンが出てきます。認証機関が秘密裏に
> subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
誰か1人でもcn=*な証明書を保存出来たならば、その認証局が発行した動かぬ証拠になる。
そういう認証局は速攻でルートサーバからはずせばいいだけ。
> ここで、エシュロンが出てきます。認証機関が秘密裏に
> subject.cn=* なサーバ証明書を米政府に対して発行したと「仮に」したら、
誰か1人でもcn=*な証明書を保存出来たならば、その認証局が発行した動かぬ証拠になる。
そういう認証局は速攻でルートサーバからはずせばいいだけ。
6 ：1：02/03/17 00:57
>>4
>誰か1人でもcn=*な証明書を保存出来たならば、その認証局が発行した動かぬ証拠になる。
>そういう認証局は速攻でルートサーバからはずせばいいだけ。
え〜と、誰かが気が付いてくれるまで待っていればいいのですか？
あなたの重要な個人情報が盗聴されてからでは遅いのではないのですか？
例えば、証券会社へのＳＳＬ接続で、パスワードが盗まれて、
あなたが気がつく前に保有する株を売られてしまったり、
登録されている個人情報が書き換えられてしまったら、どうでしょうか。
そのときに、あなたが失った資産を守ってくれるもの（法律）はありますか？
>誰からも信頼されなくなった認証局はつぶれるだけ。
>つまり、このリスクは>>1かこの文書を書いたﾔｼの脳内妄想って事だ。
私が書いたことは、サーバ証明書の subject.cn はワイルドカードが適用
されるので、自分の目でちゃんと確かめないといけないよ
ということですが、それが脳内妄想なのでしょうか？
>>4 は >>1 の内容を後１０００回くらい読み直してみてください。
そうすれば、理解していただけると思いますよ。
>誰か1人でもcn=*な証明書を保存出来たならば、その認証局が発行した動かぬ証拠になる。
>そういう認証局は速攻でルートサーバからはずせばいいだけ。
え〜と、誰かが気が付いてくれるまで待っていればいいのですか？
あなたの重要な個人情報が盗聴されてからでは遅いのではないのですか？
例えば、証券会社へのＳＳＬ接続で、パスワードが盗まれて、
あなたが気がつく前に保有する株を売られてしまったり、
登録されている個人情報が書き換えられてしまったら、どうでしょうか。
そのときに、あなたが失った資産を守ってくれるもの（法律）はありますか？
>誰からも信頼されなくなった認証局はつぶれるだけ。
>つまり、このリスクは>>1かこの文書を書いたﾔｼの脳内妄想って事だ。
私が書いたことは、サーバ証明書の subject.cn はワイルドカードが適用
されるので、自分の目でちゃんと確かめないといけないよ
ということですが、それが脳内妄想なのでしょうか？
>>4 は >>1 の内容を後１０００回くらい読み直してみてください。
そうすれば、理解していただけると思いますよ。
7 ：1：02/03/17 01:00
8 ：1：02/03/17 01:03
>>4
>>6 の内容をもうすこしわかりやすくしますね。
たとえば、ウィルスですが「ワクチンソフトがあれば万全」ではないですよね。
ワクチンをインストールしていてもメールの添付ファイルの実行は不用意には
するべきではありませんよね？
それと同じで、SSL の接続においては、注意するべき事項があるということです。
>>6 の内容をもうすこしわかりやすくしますね。
たとえば、ウィルスですが「ワクチンソフトがあれば万全」ではないですよね。
ワクチンをインストールしていてもメールの添付ファイルの実行は不用意には
するべきではありませんよね？
それと同じで、SSL の接続においては、注意するべき事項があるということです。
9 ：名無しさん＠お腹いっぱい。：02/03/17 01:19
>>6
おぃおぃ、話すりかえちゃいかんよ。
米政府が個人の財産狙うという妄想かい?
認証局が(米)政府と通じてワイルドカードな証明書を発行することは、
その認証局が自分の首を自分ででしめるという事だ。
>>1は>>3を10万回くらい読み返すことだな。認証局が(盗聴の為に)そういう事を
しないという事がわかるかもしれない。
頭悪そうだからわからないかもしれないけどな。
おぃおぃ、話すりかえちゃいかんよ。
米政府が個人の財産狙うという妄想かい?
認証局が(米)政府と通じてワイルドカードな証明書を発行することは、
その認証局が自分の首を自分ででしめるという事だ。
>>1は>>3を10万回くらい読み返すことだな。認証局が(盗聴の為に)そういう事を
しないという事がわかるかもしれない。
頭悪そうだからわからないかもしれないけどな。
10 ：1：02/03/17 01:25
>>9
世の中はお金で動いています。
米政府の高官が犯罪犯して
トンズラするかもしれませんよね。
そのときに、認証局のえらい人を金で
抱き込めばよいでしょう。
認証局なんて赤字なところばっかりですから、
潰れそうなところを使えばよいでしょ。
ムネオみたいな人が、不況で苦しんでいる人に
愛の手を差し出すって筋書きですね。
世の中はお金で動いています。
米政府の高官が犯罪犯して
トンズラするかもしれませんよね。
そのときに、認証局のえらい人を金で
抱き込めばよいでしょう。
認証局なんて赤字なところばっかりですから、
潰れそうなところを使えばよいでしょ。
ムネオみたいな人が、不況で苦しんでいる人に
愛の手を差し出すって筋書きですね。
11 ：1：02/03/17 01:27
12 ：名無しさん＠お腹いっぱい。：02/03/17 02:38
>>10
電子署名の持つ意味を考えて見ることだ。
身分証明書晒しながら犯罪犯した奴がかつて存在したならそれを示して見れ。
>>11
エシュロンはその存在が実証されていないから生き残っている。
一般人にその存在を知らせるような運用システムであるはずがない。
詐欺に引っかかったとしてもエシュロンの存在を確認できた英雄になれるな。(プ
電子署名の持つ意味を考えて見ることだ。
身分証明書晒しながら犯罪犯した奴がかつて存在したならそれを示して見れ。
>>11
エシュロンはその存在が実証されていないから生き残っている。
一般人にその存在を知らせるような運用システムであるはずがない。
詐欺に引っかかったとしてもエシュロンの存在を確認できた英雄になれるな。(プ
13 ：名無しさん＠お腹いっぱい。：02/03/19 13:20
で、>>3には見事にシカトこいてるわけね。
まあ返事できるわけないけどね。ただのデンパだから。
まあ返事できるわけないけどね。ただのデンパだから。
なんか、宇宙人が攻撃してくるぞ〜ってな
内容に偏ってきたので、別の話題にしますです。
内容に偏ってきたので、別の話題にしますです。
SSLではX.509証明書を使いますが、これにはバージョンがあって
v1からv3まであります。で、v1は使用しないのがよいのですが、
ルート認証機関の証明書とかサーバ証明書とかにはまだ使われています。
v1の証明書にはイロイロ問題があるのでv3ができたのですが、
その問題のうち、わかりやすいのを解説します。有名な話です。
でも、やっぱりSSLのman-in-the-middle attackの話ですが ＾＾）
有名な認証機関Ａがあって、Ａのルート証明書がＩＥとかＮＳに入っているとします。
Ａのルート証明書は v1 で、このルート証明書から直接v1のサーバ証明書を
発行しています（よくある形態です）。Ｂ社のサーバ証明書を発行したとします。
A-CA(X.509 v1)
↓発行
B's Server cert(X.509 v1)
しかし、発行したサーバ証明書をB社がＣＡ証明書として使用してしまうのです。
そして、あろうことか、Ａ社の名前を騙って、Ａ社の偽ルート証明書を発行してしまうのです！！
（もちろん、公開鍵は違いますよ）
B's Server cert(X.509 v1)
↓発行
偽A社ルートＣＡ(公開鍵は本物と違う)
↓発行
偽C bank サーバ証明書（こいつを使う）
で、さらに、この偽ルートから、どっかの会社の偽サーバ証明書を発行します。
たとえば、有名な金融機関のオンラインなんちゃらのサーバ証明書とかです。
とりあえず、C bank とします。
で、ルーターに仕掛けます。やりかたは>>1 です。
あ、それとSSLハンドシェイクのときに、中間CAはすべてごっそりとクライアントに渡すようにします。
すると、ユーザーには、警告はでません。（本物のA-CAが階層の最上位のルート証明書だからね）
また、C bank の本当のサーバ証明書も有名なA社のサーバ証明書だったり
するので、サーバ証明書の issuer を見てもＡ社の名前になってて、
偽Ａ社ルートＣＡであることに気づきづらいわけですね。
この攻撃を見抜くためには、証明書の階層を確認しないとダメです。めんどくさいね！！
NSの場合は、階層がグラフィカルに表示されないので、fingerprint をチェック
しないとわかりません。さらにめんどくさいね！！
これに対処するには、B社のサーバ証明書をv3証明書にして、basicConstraints フィールドを導入
すればよいです。これは、証明書がＣＡ証明書であるかないかのフラグを持ちます。
だから、これを見れば、B社サーバ証明書でCAやっているのを拒否できます。
とりあえず、この問題ではA-CA証明書をv3にする必要はありません。いじょ。
v1からv3まであります。で、v1は使用しないのがよいのですが、
ルート認証機関の証明書とかサーバ証明書とかにはまだ使われています。
v1の証明書にはイロイロ問題があるのでv3ができたのですが、
その問題のうち、わかりやすいのを解説します。有名な話です。
でも、やっぱりSSLのman-in-the-middle attackの話ですが ＾＾）
有名な認証機関Ａがあって、Ａのルート証明書がＩＥとかＮＳに入っているとします。
Ａのルート証明書は v1 で、このルート証明書から直接v1のサーバ証明書を
発行しています（よくある形態です）。Ｂ社のサーバ証明書を発行したとします。
A-CA(X.509 v1)
↓発行
B's Server cert(X.509 v1)
しかし、発行したサーバ証明書をB社がＣＡ証明書として使用してしまうのです。
そして、あろうことか、Ａ社の名前を騙って、Ａ社の偽ルート証明書を発行してしまうのです！！
（もちろん、公開鍵は違いますよ）
B's Server cert(X.509 v1)
↓発行
偽A社ルートＣＡ(公開鍵は本物と違う)
↓発行
偽C bank サーバ証明書（こいつを使う）
で、さらに、この偽ルートから、どっかの会社の偽サーバ証明書を発行します。
たとえば、有名な金融機関のオンラインなんちゃらのサーバ証明書とかです。
とりあえず、C bank とします。
で、ルーターに仕掛けます。やりかたは>>1 です。
あ、それとSSLハンドシェイクのときに、中間CAはすべてごっそりとクライアントに渡すようにします。
すると、ユーザーには、警告はでません。（本物のA-CAが階層の最上位のルート証明書だからね）
また、C bank の本当のサーバ証明書も有名なA社のサーバ証明書だったり
するので、サーバ証明書の issuer を見てもＡ社の名前になってて、
偽Ａ社ルートＣＡであることに気づきづらいわけですね。
この攻撃を見抜くためには、証明書の階層を確認しないとダメです。めんどくさいね！！
NSの場合は、階層がグラフィカルに表示されないので、fingerprint をチェック
しないとわかりません。さらにめんどくさいね！！
これに対処するには、B社のサーバ証明書をv3証明書にして、basicConstraints フィールドを導入
すればよいです。これは、証明書がＣＡ証明書であるかないかのフラグを持ちます。
だから、これを見れば、B社サーバ証明書でCAやっているのを拒否できます。
とりあえず、この問題ではA-CA証明書をv3にする必要はありません。いじょ。
過去の記憶
http://www.watch.impress.co.jp/internet/www/article/980629/pkcs1bug.htm
RSAのSSL実装方式にセキュリティバグ
サーバー各社がパッチを配布
■URL
http://www.rsa.com/pressbox/html/980626.html
http://www.bell-labs.com./news/1998/june/26/1.html
http://www.watch.impress.co.jp/internet/www/article/980629/pkcs1bug.htm
RSAのSSL実装方式にセキュリティバグ
サーバー各社がパッチを配布
■URL
http://www.rsa.com/pressbox/html/980626.html
http://www.bell-labs.com./news/1998/june/26/1.html
過去の記憶
http://www.meer.net/~ericm/papers/ssl_servers.html
SSLv2 Protocol Weaknesses
ＳＳＬハンドシェイクのときにciphersuiteをダウングレードさせる攻撃。
電文を切り捨てる攻撃
http://www.meer.net/~ericm/papers/ssl_servers.html
SSLv2 Protocol Weaknesses
ＳＳＬハンドシェイクのときにciphersuiteをダウングレードさせる攻撃。
電文を切り捨てる攻撃
ひさしぶりに書いてみる。
IISのクライアント認証で、CRLをhttpで読み取る場合、
WEBサーバが 500 エラーを返した場合と、404 エラーを返した場合で、
クライアント認証の挙動が変わるね。
IISのクライアント認証で、CRLをhttpで読み取る場合、
WEBサーバが 500 エラーを返した場合と、404 エラーを返した場合で、
クライアント認証の挙動が変わるね。
政府認証基盤の統合リポジトリの
アドレスは www.gpki.go.jp で公開してないね。
ここに書いてしまおうかと。知りたい人はITEM2000をＤＬしる。
アドレスは www.gpki.go.jp で公開してないね。
ここに書いてしまおうかと。知りたい人はITEM2000をＤＬしる。
Ministry of Justice ってのは毎年ＣＡ証明書を更新するんだとさ。
だから、毎年リンク証明書を発行するんだけどね。
この間発行したリンク証明書(NewWithOld)の notAfter 間違っていましたよ。ええ。
2004年までが正しいのに、2005年までになっていました。まあ、難しいけどねぇ。
だから、毎年リンク証明書を発行するんだけどね。
この間発行したリンク証明書(NewWithOld)の notAfter 間違っていましたよ。ええ。
2004年までが正しいのに、2005年までになっていました。まあ、難しいけどねぇ。