WEBブラウザのSSL実装におけるワイルドカードの問題
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にする必要はありません。いじょ。
|
|
|