自堕落な技術者の日記 : SSL - livedoor Blog（ブログ）

SSL

2011年09月11日00:04

カテゴリ: PKI; SSL証明書

わけのわからないDigiNotar Cyber CAの証明書

オランダの認証局DigiNotarが攻撃を受け、今わかっているだけで不正なSSLサーバー証明書を531枚発行してしまった件を、気になってずっとウォッチしています。

いろいろ疑問に思っていることがあり時間があるとき、ここでも紹介していきたいと思っているんですが、その気になるところの一つにDigiNotar Cyber CAというのがあります。 Torプロジェクトのページで不正に発行された証明書の一覧(531枚)がCSVやExcel形式でダウンロードできるようになっており、不正な証明書を発行してしまったDigiNotar管理下の認証局の一覧は

DigiNotar Cyber CA
DigiNotar Extended Validation CA★
DigiNotar Public CA - G2
DigiNotar Public CA 2025★
Koninklijke Notariele Beroepsorganisatie CA
Stichting TTP Infos CA

となっています。「★」印をつけたものは DigiNotarのページからダウンロードできる中間CA証明書になんですが、他のものはGoogle等で探してみてもダウンロードすることができませんでした。被害があった認証局の証明書がDigiNotarのサイトで公開されていないのは非常に問題だと思っていて、特に DigiNotar Cyber CAは "*.google.com"、"*.skype.com" などの想定被害の大きいSSLサーバー証明書を発行しているCAなので、CA証明書が無いと対策の打ちようがないと思っていました。不正に発行された証明書についてOCSPオンライン証明書検証の結果がほとんど有効のままになっているのでは?と報告している人もいて(OCSPレスポンダ証明書が無効であれば問題ないわけですが)それを調査するためにもCA証明書が必要になるわけです。

やっとみつけた

DigiNotarのサイトに無いのでちょっとあきらめ気味だったんですが、 FireFox 3.6.22 の証明書ストアを見てみたら以下の信頼するCA証明書がありました。

DigiNotar Root CA
DigiNotar Services 1024 CA
DigiNotar Cyber CA (2枚)
DigiNotar PKIoverheid CA Orgaisatie - G2
DigiNotar PKIoverheid CA Overheiden Berdrijven

なんだ、DigiNotar Cyber CAあるじゃないですか、、、それも2枚も。ぱっと見、ふんふん、名前がちょっと違うルート証明書で有効期間もちょっとだけ違うんだなと納得しそうになったんです。まぁ、特別な事情があって同じようなルート作ったんだろうなぁ、、、と。

DigiNotar Cyber CA (1枚目)
　発行者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA,Email=info@diginotar.nl
　主体者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA,Email=info@diginotar.nl
　有効期間：2006.10.04-2011.10.04
DigiNotar Cyber CA (2枚目)
　発行者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA
　主体者：C=NL,O=DigiNotar,CN=DigiNotar Cyber CA
　有効期間：2006.09.27-2013.09.20

そしたら、あれれ？？？拡張領域あるじゃないですか？？？それも全く同じ値、、、、

発行者鍵識別子：
　A6:0C:1D:9F:61:FF:07:17:B5:BF:38:46:DB:43:30:D5:8E:B0:52:06
　C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions, Inc.,CN=GTE CyberTrust Global Root
　serial:01:A5
主体者鍵識別子：
　AB:F9:68:DF:CF:4A:37:D7:7B:45:8C:5F:72:DE:40:44:C3:65:BB:C2
証明書ポリシ：
　CPS: http://www.public-trust.com/CPS/OmniRoot.html
CRL配布点
　URI:http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl

ってことは、DigiNotar Cyber CAの証明書は2枚とも自己署名ルート証明書ではなくて主体者名、発行者名が同じなのにGTE CyberTrust Global Rootから発行された中間CA証明書ってことなんですよね。 CPSやCRLDPの場所もGTEを管理している所のものになっているみたいですしね。

この2枚の証明書がさらに不可解なのはシリアル番号で両方とも(0x0fffffff)で同じ値になっているってことです。CA鍵が同じっていうのもアレですが、同じシリアル番号の異なる証明書をGTE CyberTrustは発行したって事になるわけですよね。普通の認証局なら考えられない話ですし、シリアル番号をあえて同じにする意図もよくわかりません。

さらには、DigiNotar Cyber CA証明書の発行者は同じFireFoxに入っているGTE CyberTrust Global Rootではなくて、Mac OSXには入っていたシリアル番号(0x01A5)の方のGTE CyberTrust Global Root になっているわけです。どのようなケースでDigiNotar Cyber CAのような移行策が必要だったのか、そもそもメリットがわからないのよくわかりません。さぞかし大人の事情があったのでしょう。

OCSPの検証結果もまたわからない

2枚のうちどちらが使われているかわからないながらもDigiNotar Cyber CAの証明書はとりあえず入手できたわけです。 DigiNotar Cyber CAから発行されたSSLサーバー証明書が一枚も入手できていないのでこれがDigiNotarの共通のOCSPレスポンダで検証できるのかはわからないのですが、ある一つの不正な証明書のシリアルとCyber CAの証明書により検証してみます。すると2つのCAで別の結果が返ってきて

DigiNotar Cyber CA (1枚目)が発行者だったとした時のOCSP応答：
　malformed-request(1)
DigiNotar Cyber CA (2枚目)が発行者だったとした時のOCSP応答：
　Cert Status: unknown
　This Update: GeneralizedTime "00010101000000Z"
　Next Update: GeneralizedTime "00010101000000Z"

GeneralizedTimeとしてものすごい値が返ってきました。他にもこのOCSPレスポンダは疑問に思うところが多々あって、 DigiNotar用にカスタムで実装したもののような気がしています。

返ってきた２つの値から、 DigiNotar Cyber CAから発行されたSSLサーバー証明書は OCSP失効検証をサポートしないと考えるのが自然でしょうか。

ちなみにDigiNotar Cyber CAの発行するCRLは？

ちなみにDigiNotar Cyber CAが発行するCRLのURLは1枚目が発行したものは見つかったものの2枚目が発行した方は見つかっていない。CRLの検証では鍵よりもむしろ発行者識別名の方が必要なので、1枚目と2枚目と同じCA鍵であったとしても、そのCRLは1枚目の方にしか使えないですよね。

今日はこんなところで

GTE CyberTrust Global Rootの発行するCRL(追記)

DigiNotar Cyber CA 中間CA証明書はFireFox 3.6.22の信頼する CA証明書リストに入っているのでGTE CyberTrust Global Rootからの証明書検証をする必要もないですが、DigiNotar Cyber CA証明書には CRL配布点も書いてありますし、 GTE CyberTrust Global Rootは今でもCRLを発行しているので失効検証はできます。そのCRLをちょっとみてみると、大体3ヶ月おきに発行されているようで

thisUpdate: 2011.08.31
nextUpdate: 2011.12.03

となっており当然DigiNotar Cyber CAの2枚の証明書のシリアル 0x0fffffffは記載されておらず、DigiNotar Cyber CA証明書が GTE CyberTrustから失効されているということはありませんでした。

GTE CyberTrust Global Rootを信頼点として検証した場合、結局、識別名のチェーンがつながらないのでパス検証失敗になりますけどね。

更新履歴

2011.09.11 - GTE CyberTrustのCRLについて追記

タグ：: #脆弱性; #証明書; #認証局; #CA; #SSL

2009年09月01日19:35

カテゴリ: SSL証明書; 脆弱性

Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(続き1)

前回は、BlackHatで紹介されたSSLサーバー証明書の対象ホスト名を格納するCN(common name)属性の処理の不具合を突いた脆弱性について紹介しました。

今日は、実際にテストサーバーを立ち上げてブラウザで接続するとどうなるのか試してみます。

Challenge PKI Test Suite(改)の機能追加

手持ちの状態のTest Suiteでは、証明書識別名のオブジェクト識別子について
(1) オブジェクト識別子のサブ識別子で大きな整数を指定すると桁が溢れる(機知のバグ)
(2) X.690に違反して0x80でパディングしてエンコードすることができない。
といった状態でした。
RDNの属性タイプを表す方法として以下のサポートを追加して、テストコードを追加しました。
(1) CN, OU, O, C, serialNumberなど属性タイプを名前で指定できる。(現行)
(2) 1.2.3.4 のように十進カンマ区切りでOIDを指定できる。(現行、桁溢れのバグ)
(3) #550403 のように16進数で属性タイプを指定できる。(機能追加)

証明書の生成

SSLサーバーのホスト名に以下の2つを仮定して発行します。

CN=www.evil3.jp: 悪意のある攻撃者が本当に所持しているドメインのホスト
CN'=www.good-bank.com: 詐欺対象のホスト

本来ならばCN(2.5.4.3=0x550403)であるようなOIDを、騙すためのニセのCN(CN')の作り方としては以下の2つで行います。

(1) 末尾"3"をX.690に違反して0x80(複数可)でパディングする(0x05048003)
(2) 末尾"3"を64bit整数で桁あふれした後"3"となる値とする。

方法(2)については、桁溢れする数を"0x010000000000000003"(9バイト)として、これをビット表現にし末尾より7ビットで分割してこれをバイトとし、末尾を除き8ビット目を1とし、"2.5.4."の部分を連結すると、0x82808080808080808003となります。

OpenSSL 0.9.8kではどう見える？

OpenSSLのコマンドではどのように証明書の識別名が表示されるのか確認してみたいと思います。

■コマンド
% openssl x509 -in 証明書 -noout -text
■OID末尾"3"が0x8003の場合(X.690違反のゼロパディング)
Subject: C=JP, O=Evil-CN-OID, CN=www.evil3.jp/2.5.4.3=www.good-bank.com
■OID末尾"3"が0x82808080808080808003(64bit整数桁溢れ)
Subject: C=JP, O=Evil-CN-OID, CN=www.evil3.jp/2.5.4.18446744073709551619=www.good-bank.com

CNモドキはちゃんと区別して表示されているようです。CNは2.5.4.3なんですが、0x80パディングされたものとはきちんと区別しています。(18446744073709551619は0x010000000000000003の10進数表現です。)

dumpasn1での表示

■本物のCN(common name)の表示

SEQUENCE {

  #06 03 55 04 03

  OBJECT IDENTIFIER commonName (2 5 4 3)

  #13 0C 77 77 77 2E 65 76 69 6C 33 2E 6A 70

  PrintableString 'www.evil3.jp'

  }



■ニセのCN①(X.690違反の0x80パディング)

SEQUENCE {

  #06 04 55 04 80 03

  OBJECT IDENTIFIER '2 5 4 3'

  #13 11 77 77 77 2E 67 6F 6F 64 2D 62 61 6E 6B 2E 63 6F 6D

  PrintableString 'www.good-bank.com'

  }



■ニセのCN②(64ビット整数桁溢れ)

SEQUENCE {

  #06 0C 55 04 82 80 80 80 80 80 80 80 80 03

  OBJECT IDENTIFIER '2 5 4 3'

  #13 11 77 77 77 2E 67 6F 6F 64 2D 62 61 6E 6B 2E 63 6F 6D

  PrintableString 'www.good-bank.com'

  }

①も②も表示上は本当のCNと区別できています。しかしながら②では、OBJECT IDENTIFIER '2 5 4 3'となってしまっており、整数の桁溢れが起きていることがわかります。

まずは正式な(悪い人の)URLに接続

ちゃんと正しくSSL接続できてますんで、これは問題無し。

FireFox 3.5.2でニセCNのホストに接続

それでは、次にX.690に違反して0x80でパディングしてあるニセCNのURL "https://www.good-bank.com/" に接続してみます。

おお、ちゃんと警告出ますね。エライ。
cnoid02-ff35-dlg

おお、ちゃんとダイアログまで、、、メッセージにも嘘が無くて好感が持てます。ちなみに証明書はこんな感じで表示されます。
cnoid03-ff35-crtdlg

ニセCNについて、文字化けのように表示されているので、まぁ、怪しいとわかります。

64bit整数桁あふれする場合でも、表示は同じだったので、キャプチャは割愛します。

Internet Explorer 8でニセCNのホストに接続

先週あたりにWindows Updateした、ほぼ最新だと思うIE8でニセCNのURLに接続してみました。
cnoid06-ie8-goodbank

一切警告なくニセCNのサイトに接続できてしまいますね。
cnoid07

証明書ダイアログで観てみるとX.690違反の0x80パディングでも整数桁溢れでも表示上はCN(common name)であるとして表示されてしまいます。

Google Chrome 2でニセCNサイトに接続

今日の時点で最新だと思うGoogle Chrome 2.0.172.43で同様に接続してみました。
cnoid09

こちらも警告なく接続できてしまいます。
cnoid10

証明書もwww.good-bank.com用で問題ないことになっちゃってますね。

Opera 9.5で接続

この他にOpera for Windows 9.50 build10063でも試してみたんですが、Opera自体がDNSで引けないホストは表示ができないような気がするんです(ローカルPCのhttp://192.168.1.133/等でも接続不能)。そのためテストできませんでした。

と、、、思ったら単に余計なプロキシが設定されていただけでした。すみません。疑ってゴメンヨ。気を取り直して接続してみます。まずは、(怪しいけど)正しいHTTPS接続。
cnoid-opera-02

まぁ、安全です(笑)。
cnoid-opera-03

次にニセCNのサイトに接続してみます。
cnoid-opera-04

ちゃんと親切な警告がでます。もうちょっと色が変わったりインパクトがある警告だといいんですけどね。

これも、どっちのニセCNでも結果は同じでした。

Operaの最新版は現時点で9.64だそうで、ちょっと古いやつですが、ニセCN OID問題についてはちゃんと対応されているってことで、、、

ruby + httpclient2

rubyとhttpclient2のモジュールでも試してみました。OpenSSLベースですが、ニセCNサイトに接続するとちゃんとエラーになってくれます。

/usr/lib/ruby/1.8/openssl/ssl.rb:123:in `post_connection_check': hostname was not match with the server certificate (OpenSSL::SSL::SSLError)

以上、こんな感じで実験報告でした。

ではでは

※注意：この記事のウィンドウキャプチャ画像は、余計な部分、空白などを除くためにトリミングしたり、空白の削除等の加工をしています。

Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(2009.08.29)

Black Hat:SSLサーバー証明書中のCNのOID処理不具合を突いた攻撃(続き1)(2009.09.01)>

タグ：: #BlackHat; #SSL; #証明書; #脆弱性; #識別名; #Nullターミネーション; #X.509

2008年12月30日12:01

カテゴリ: PKI

GlobalSignのEV SSL証明書が2048bitに

米国機関が要請：グローバルサイン、EV SSL証明書を2048ビットに対応 - ITmedia エンタープライズ

GMOグローバルサインは12月26日、同社のEV SSL証明書が米政府機関「NIST」の定める暗号鍵長の2048ビットへの移行に対応したと発表した。

　NISTは、政府調達に関する共通鍵暗号や公開鍵暗号、ハッシュ関数の運用を見直し、コンピュータによる解読技術の進化などを考慮して2010年末までに2048ビットの暗号鍵長へ移行するよう求めている。日本では移行期間の期限を2013年としている。

　同社では、ルート証明書や中間証明書、加入者証明書の発行システムを2048ビットの暗号鍵長に対応させ、2010年12月31日以降も有効なEV SSL証明書は2048ビット対応で発行するという。

だそうです、、、、メモメモ、、、、

米国国立標準技術研究所(NIST)が要請したから「やりました」、、、っていうのがスゴイ話ですね。

ルートのMD5からの移行が先決なのではとも思いますが、どうなんでしょうか、、、、（＾＾；

タグ：: #EV; #SSL; #サーバー証明書

2008年09月30日22:37

カテゴリ: セキュリティ; OpenSSL

Apache2.2.9+OpenSSL0.9.8h Win32

Index of /dist/httpd/binaries/win32

手元にSSLクライアント認証が試せる適当なサーバーがほしかったので
apache_2.2.9-win32-x86-openssl-0.9.8h-r2.msi
を入れてみました。

前はWindows上でApache+mod_sslをビルドするのがとても面倒だった気がしたんですが、なんだ、、、、インストーラーがちゃんとあるじゃないですか～～～～。ちょっとhttpd.conf、httpd-ssl.confを設定するだけでSSLクライアント認証が試せてしまいます。(有難い有難い、、、、)

NumericStringやGraphicStringをSubject DNに含む証明書でクライアント認証してみようとしたんだけど、単にエラーになるだけだった、、、つまんないの（′∀｀）

ちなみにサポートしてないDirectoryString Typeのクライアント証明書を使った際に出るエラーはこれ、LogLevelはinfo以下でないとだめ、、、、

asn1 encoding routines:ASN1_ITEM_EX_D2I:mstring wrong tag

タグ：: #apache; #OpenSSL; #SSL

2008年09月18日07:52

カテゴリ: セキュリティ; OpenSSL

OpenSSL 0.9.8iリリース

9月15日敬老の日にOpenSSL 0.9.8iがリリースされたというのでCHANGESを覗いてみました。

他はどうでもよいんですが、↓

Add CryptoAPI ENGINE to support use of RSA and DSA keys held in Windows
keystores. Support for SSL/TLS client authentication too.
Not compiled unless enable-capieng specified to Configure.

これ「チ、チょっと、おと～～～さぁ～～ん！！！」って感じでよね（＾＾ｖ

enable-capieng オプション付きでビルドしてやればWindows CryptoAPIの証明書・鍵ストアが使えると、、、、、SSLクライアント認証もいけるそうです。いろいろ制約事項の多かったWindows証明書ストアでの鍵生成・証明書発行要求にも使えるかも～～～～～

0.9.8i 以降の話もCHANGESに書いてしまっているという情報もあるので確認して本当ならこれはビルドしてみない手はありません、、、、

engines/e_capi.c があるので大丈夫そうかな、、、

＜追記＞
ちょっとココで配布されるのを待ってみよう、、、
http://www.slproweb.com/products/Win32OpenSSL.html