自堕落な技術者の日記

前回はDigiNotar Cyber CAの証明書の不可解な点について 紹介しましたが、今回は「わけのわからないシリーズ第2段」として DigiNotar OCSPレスポンダ証明書の不可解な点について 紹介していこうと思います。 OCSPやOCSPレスポンダとは何かについては @ITの記事で詳しく紹介されているのでご覧ください。

ocsp-nocheck拡張とOCSPレスポンダ証明書の有効期間のミスマッチ

まず最初に、 validation.diginotar.nlのOCSPレスポンダ証明書には ocsp-nocheck拡張が設定されています。 これは、「(OCSPレスポンダ証明書の有効期間が非常に短く設定されており、OCSPレスポンダの 鍵は頻繁に更新するので鍵危殆化リスクが少なくOCSPレスポンダ証明書を 失効させることもないので)OCSPレスポンダ証明書を失効検証する必要はありませんよ」 という意味を持つフラグです。 ところが、validation.diginotar.nlのOCSPレスポンダ証明書の有効期間は

notBefore: 2007.11.21
notAfter: 2017.11.21

と10年の長きに渡るOCSPレスポンダ証明書なので、失効検証しないというのは難しいかなと思います。 このような状況では、OCSPレスポンダ証明書の廃棄は、上位のCAである DigiNotar Services CAごと廃棄するしか方法がありません。

オレオレOCSP???

なんと驚いた事にvalidation.diginotar.nlのOCSPレスポンダ証明書には 機関情報アクセス(authorityInfoAccess)のOCSPのフィールドがあり、 他のSSLサーバー証明書などと全く同じ http://validation.diginotar.nl という URIを持っています。つまり、OCSPレスポンダ証明書自体がOCSPで検証してよいことを言っています。

これはおかしな話で「OCSPレスポンダ証明書が有効かどうかOCSPレスポンダに聞きに行く」って ことで、こりゃオレオレですよね？

最悪の場合、実装によってはOCSPを使ったパス検証がループしてしまう可能性だってあります。

- www.diginotar.nl が正しいか聞く
　- 失効検証のため www.diginotar.nl が有効かOCSPに聞く
　　- OCSPレスポンダ証明書が有効かOCSPに聞く
　　　- OCSPレスポンダ証明書が有効かOCSPに聞く
　　　　- OCSPレスポンダ証明書が有効かOCSPに聞く
　　　　　•••永遠に続く

おわりに

前回紹介したDigiNotar Cyber CAの証明書も怪しかったですが、 DigiNotarのOCSPレスポンダ証明書も相当怪しいです。 DigiNotarは全体的に凝ったPKI設計になっていますが、いろんなところで間違えています。 (できないなら)シンプルに行った方がいいんじゃないかと思うんですけどねぇ。

今日はこんなところで

関連記事

• 2011.09.11 わけのわからない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について追記

JavaでSSL/TLS通信をしたい時に通常はJSSE(Java Secure Socket Extension)という仕組み使うんですが、これ使えば、実装色々切り替えたり、追加したりなんてことができます。Apache Tomcat(+Sun Java JSSE)だとCamellia系のCipherSuitesに対応してないそうで、何か対応してるもの、追加で対応できそうなものを調べてみました。

Sun Javaで使えるJSSEってあんまり選択肢がないのね

下の例のようにJSSEプロバイダ名を指定することによりJSSEを切り替えればいろんなSSLエンジンを試せるわけですが、

SSLContext ctx = SSLContext.getInstance(アルゴリズム名, プロバイダ名);
SSLContext ctx = SSLContext.getInstance("SSL", "SunJSSE");
SSLContext ctx = SSLContext.getInstance("TLS", "HarmonyJSSE");

Sun Javaで使えそうなJSSEの選択肢って少ないんだなぁってことが調査してみるとわかりました。Sun Javaで使えそうなのは標準品を含めて以下の3つぐらいしかなさそう。

• Sun(Oracle) - SunJSSE
• RSA - RSA BSAFE SSL-J Toolkit
• IAIK - IAIK iSaSiLk Toolkit

暗号アルゴリズム系のためのJCE対応のライブラリは潤沢にある中、JSSEの方は選択肢がすくないですね。

なんか調べてみるとJSSEはJava VMに依存している方が多いんじゃないかって 感じがします。

• IBM Java - IBM JSSE
• GNU classpath - JESSIE (オープンソース)
• Apache Harmony - HarmonyJSSE (BouncyCastle JCEベース)

新しいCipher Suitesを追加したいと思ったら、Sun Java用にJSSEを書き起こすっていう 手もありですが、コード署名しないと何かと面倒なのでおススメではありません。 JESSIEでやろうとするとGNU classpathなんでちょっとなぁ、、、と。JESSIE自体、 あんまりメンテナンスしてないみたいだし。 で、最終的にApache Harmonyを調べてみるのがいいのかな、、と思ったわけです。 Apache HarmonyはオープンソースでフリーなJavaの実装だそうです。

Apache HarmonyとTomcatを試してみる

Apahce HarmonyのSSL/TLSの機能というか、JSSEの機能は暗号ライブラリとしてBouncyCastle JCE Libraryを使用しており、SunJCEは使えません。 従ってHTTPSのためのSSLサーバー証明書と鍵はJKS形式はSun独自の形式なので使えなくてBouncyCastle JCEがサポートしている PKCS#12かBKS(BouncyCastle Key Store)形式を使う必要があります。 ただ、OpenSSLで生成したPKCS#12でやってみたところMacエラーだったりで読み込めず BKSを使うのがよいのかもしれません。 JKSからBKSへの変換ツールは「ここ」に置いてみたので使ってみてください。

conf/server.xmlファイルにはこんな感じでkeystoreFile、keystorePass 、keystoreTypeを設定します。

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
 maxThreads="150" scheme="https" secure="true"
 clientAuth="false" sslProtocol="TLS"
 keystoreFile="conf/zzz.bks"
 keystorePass="changeit"
 keystoreType="BKS" />

あとはbin/catalina.batに以下のようなパス設定をしとけばApache Tomcat + Apache Harmonyは動くと思います。

set CATALINA_HOME=C:\Java\apache-tomcat-6.0.30-wharmony
set JAVA_HOME=C:\harmony-6.0-jdk-991881
set JRE_HOME=C:\harmony-6.0-jdk-991881\jre

ウェブブラウザ等でHTTPSでつなぐことはできたでしょうか？

で、OpenSSLで繋いでみる

openssl s_client機能を使ってApache Tomcat + Harmonyのサーバーに接続してみましょう。

% openssl s_client -host zzz.com -port 8443
CONNECTED(00000003)
depth=1 /C=JP/O=HOGE
verify error:num=19:self signed certificate in certificate chain
verify return:0
14052:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:209:
14052:error:1408D07B:SSL routines:SSL3_GET_KEY_EXCHANGE:bad signature:s3_clnt.c:1447:

とJava実装やブラウザだと出てこないエラーが出てきてしまいました。ググってみるに-cipherを設定しないことが 原因のようで-cipher 'ALL:!kEDH'を指定してちょっと絞り込みをしないといけないそうです。

% openssl s_client -host zzz.com -port 8443 -cipher 'ALL:!kEDH'
CONNECTED(00000003)
中略
depth=1 /C=JP/O=HOGE
verify error:num=19:self signed certificate in certificate chain
verify return:0
read R BLOCK
DONE

これでApache Tomcat + HarmonyにOpenSSL s_clientで繋ぐことができるようになりました。

Apache HarmonyのJSSEのコード

Apache HarmonyのJSSEはjre/lib/boot/x-net{.jar,-src.jar}にある org.apache.harmony.xnet.provider.jsse パッケージがそれに当たります。 x-net.jar自体はコード署名されてないようなので、 CipherSuiteを追加し放題で x-net.jarに入れ替えても動きそうな雰囲気です。

JSSEプロバイダの定義はJSSEProvider.javaにあります。 コメントのところに割と詳しい説明があって以下のようなものが書かれています。

• サポートしているCipherSuites：別表
• 使用する共通鍵暗号アルゴリズム：IDEA,RC2,RC4,DES,3DES
• 使用するMacアルゴリズム:MD5, SHA-1
• 使用する鍵交換アルゴリズム: RSA, DH, DHE

Apache Harmony 6.0 build 991881のHarmonyJSSEプロバイダーで提供されているアルゴリズムとその値の一覧は以下の通りのようです。

SSLContext = TLS(=TLSv1)
KeyManagementFactory = X509
TrustManagementFactory = X509

HarmonyJSSEがサポートしているCipherSuiteの一覧は以下の通りです。

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

そして、そのうちデフォルトの設定で提供するCipherSuiteは以下の通りです。

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

今晩はこんなところで、、、
ではでは

本ブログで述べられている問題はJPCERT様に迅速に対応頂き、既に2011年1月7日お昼頃には解決し、Androidでも問題なくhttps://www.jpcert.or.jp/のサイトが閲覧できるようになっております。関係者の皆様、ご対応誠にありがとうございました。

ちょっと前の話ですがTLを見てたら、JPCERTやIPAなど、日本の情報セキュリティを牽引する組織がEV SSLサーバ証明書を使ってると知り、さすがだなぁ、、、と思ったわけですが、さらにTLを追ってみると「Xperiaではルートが搭載されてないため警告が出る」というのを見つけたんです。ほんまかいな？と思ってちょっと調べてみました。

JPCERT、JVN、IPAをFireFoxで見てみると

まず、IPAはこんな感じ。セコムトラストさんのEVです。

次にJPCERTコーディネーションセンターのサイトはこんな感じ。ベリサインさんのものです。

そしてJPCERTとIPAで運営しているJVN(Japan Vulnerability Notes)のサイトはJPCERTが取得したベリサインのEV証明書を使っています。

ちなみにwww.jpcert.or.jpの証明書チェーンをFireFoxの証明書ビューアでみるとこんな感じ。

VeriSign Class 3 Public Primary Certification Authority - G5は最近のFirefoxやWindowsのアップデートなどで搭載されているルート証明書です。これがAndroidでは搭載されていないんだろうっていうのは、まぁ、ある話で私んとこのブログの「Xperiaに搭載されたルート認証局証明書」にもある通りG5などというものは搭載されていません。

で、Xperiaで見てみると

自分のXperia(ビルド2.0.B.0.138)の標準ウェブブラウザでhttps://www.jpcert.or.jp/を開いて見るに

セキュリティ警告
このサイトのセキュリティ証明書には問題があります。
この証明書は信頼できる認証機関のものではありません。

と出てきました。まぁ、TLにあった通りルート証明書が搭載されてないせいなんだろうと、「その時」は思いました。 で、試しに https://jvn.jp/ を開いてみるとする～～っと警告も無しに問題なく表示されるじゃないですか。www.jpcert.or.jpもjvn.jpも同じVeriSign Class 3 Extended Validation SSL CAから発行されている証明書なのでルート証明書が搭載されていないというのが問題でないことがわかります。

じゃぁ、JPCERTだけ何故うまくいかないの？

まず、https://www.jpcert.or.jp/ につないでパケットキャプチャしてみるとTLSのCertificatesは以下の順序のものが送られています。

(1) SN:5e 5d 84 ba bc 68 a6 92 2b ce 4d b5 38 25 30 6a
主体者：www.jpcert.or.jp
発行者：VeriSign Class 3 Extended Validation SSL CA
(2) SN:35 97 31 87 f3 87 3a 07 32 7e ce 58 0c 9b 7e da
主体者：VeriSign Class 3 Public Primary CA - G5
発行者：VeriSign Class 3 Public Primary CA
(3) SN:5b 77 59 c6 17 84 e1 5e c7 27 c0 32 95 29 28 6b
主体者：VeriSign Class 3 Extended Validation SSL CA
発行者：VeriSign Class 3 Public Primary CA - G5

一方、https://jvn.jp/ につないだ場合は、こんな感じで含まれている2枚の中間CA証明書(2)(3)の順序が違うだけのようです。

(1) SN:12 84 db b5 0a 38 d0 ef 5d c2 ae 7e d2 ba 37 2b
主体者：jvn.jp
発行者：VeriSign Class 3 Extended Validation SSL CA
(2) SN:5b 77 59 c6 17 84 e1 5e c7 27 c0 32 95 29 28 6b
主体者：VeriSign Class 3 Extended Validation SSL CA
発行者：VeriSign Class 3 Public Primary CA - G5
(3) SN:35 97 31 87 f3 87 3a 07 32 7e ce 58 0c 9b 7e da
主体者：VeriSign Class 3 Public Primary CA - G5
発行者：VeriSign Class 3 Public Primary CA

そして、Androidに搭載されているルート証明書のうちルートとなるのは以下の証明書です。

V1 md2RSA SN:70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf
主体者：VeriSign Class 3 Public Primary CA
発行者：VeriSign Class 3 Public Primary CA

サービスパックを当てていなかったり、Windows UpdateをしていないWindows XPやそれ以前のOSならばG5ではなく、上記のルート証明書が使われます。例えば、Windows UpdateをしていないWindows XP SP3 English 上のIE 6.0.2900.5512.xpsp.080413-2111ブラウザの場合以下のようになります。

(1) ルート証明書
SN:70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf
発行者：VeriSign Class 3 Public Primary CA
主体者：VeriSign Class 3 Public Primary CA
(2) 中間CA証明書1
SN:35 97 31 87 f3 87 3a 07 32 7e ce 58 0c 9b 7e da
発行者：VeriSign Class 3 Public Primary CA
主体者：VeriSign Class 3 Public Primary CA - G5
(3) 中間CA証明書2
SN:5b 77 59 c6 17 84 e1 5e c7 27 c0 32 95 29 28 6b
発行者：VeriSign Class 3 Public Primary CA - G5
主体者：VeriSign Class 3 Extended Validation SSL CA
(4) EV SSL証明書
SN:5e 5d 84 ba bc 68 a6 92 2b ce 4d b5 38 25 30 6a
発行者：VeriSign Class 3 Extended Validation SSL CA
主体者：www.jpcert.or.jp

で、Xperiaでhttps://www.jpcert.or.jp/がうまくいかない原因は、最近のブラウザではありえない話ですが、SSLのハンドシェイクの際にCertificatesで送られている証明書の順番がエンドエンティティから最上位の中間CAの順に並んでいないことが原因っぽいのです。

ちなみにAndroidで動作するFireFoxやOpera Miniでは問題なくパス検証できるようです。

Androidの標準ブラウザでSSLのCertificatesで送られる証明書の順序のよりパス構築ができなくなっている原因として、もう少し証明書チェーンを見てみると

中間CA証明書1
SN:35 97 31 87 f3 87 3a 07 32 7e ce 58 0c 9b 7e da
発行者：VeriSign Class 3 Public Primary CA
主体者：VeriSign Class 3 Public Primary CA - G5

にも問題があるんじゃないかという気もします。この中間CA証明書にはSubjectKeyIdentifierはあるんですが、AuthorityKeyIdentifierが無いのです。そのせいでパス構築に失敗してる可能性はあるかと、、、そんなもん無くてもフツーはパス構築してほしいところですけどね、、、。JPCERTさんには証明書の順序直して頂けるとうれしい気もしますが、めったにXperiaから見ることもないので、まぁ、いっかという気もしちゃいます。

ちなみに規定 RFC 2246では

ちなみにSSL/TLSを定めた規定RFC 2246 The TLS Protocol Version 1.0 - Section 7.4.2 Server certificateでは、

This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
(RFC 2246 7.4.2 Server certificateのcertificate_listの定義より)

と書かれており、

SSLサーバ証明書, 中間CAn, ..., 中間CA1, [ルート証明書]

一応はこの順序で送られるようにサーバのSSL設定をしないといけないんだけども、順序が正しく設定されてないなんてことはしょっちゅうあるので多くのブラウザは頑張ってくれるんですけどね、、、

まとめ

• JPCERTのサイト(https://www.jpcert.or.jp/)をAndroidの標準ブラウザで開くと信頼できない証明書のエラーが出る。これはこのブラウザに特定の問題のようだ。
• ルート証明書が搭載されていない事が原因ではない。
• SSLのハンドシェイクで送られてくる証明書の順序が原因のようだ。
• 問題を解決するには
  • https://www.jpcert.or.jp/のサーバーのSSLの証明書の順序をjvn.jpと同じになるようにする。もしくは
  • Androidのウェブブラウザのパス構築をSSLハンドシェイクのCertificateの順序について、他のブラウザのように順序に依存しないような実装にする。
• 中間CA証明書にAuthorityKeyIdentifierが無いためにパス構築に失敗している可能性もある。

やべやべ、お風呂はいんないと、、、ではでは、

自分はWindows XPが大好きなのでWindow VistaやWindows 7はほとんど使ってなかったんですが、最近になって仕方なく使っています。これを書いているThinkPad X201sもWindows 7ですし、、、、

証明書ビューアーで証明書見ててちょっと疑問に思ったんです。

有効期間　1999/ 07/ 10 から 2019/ 07/ 10

なんで「有効」と開始日の日にちだけが太字になるんだろう？？？と、、、、「有効」にだけ特別な意味があるのか？？とか、、、、

で、ちょっと探して英語版の出力を見てみました。英語版では

Valid from 10. 3. 2009 to 10. 3. 2010

となっています。すると、単純にUnicodeでのバイト数で太字の位置を決めてるんじゃないかと、、、正しくは

有効期間　1999/ 07/ 10 から 2019/ 07/ 10 じゃなくて
有効期間　1999/ 07/ 10 から 2019/ 07/ 10

なんじゃないかと、、、 結構実装が適当ですねぇｗ。日付に余計な空白があるのも非常に違和感があります。

今日は小ネタで、、、、
おやすみなさい。

ご無沙汰しております。なかなか時間が取れないのと、おもしろそうなブログネタが見つからないので、なかなかブログを書けずにいました。お世話になっているK先生のつぶやきを見ていてニンテンドーWiiがSSLクライアント認証をしているらしいと書いてあったので、ちょっと興味があって見てみました。

クライアント認証を使ってそうな所

クライアント認証使っているということですが、Wiiではアカウント使って証明書を発行していうなんてこともなさそうなので、多分出荷時に機器に埋め込まれている機器認証なんだと思います。おそらくWiiショッピングでWiiアプリを買う時に使ってるんじゃなかろうかとキャプチャしてみることにします。

クライアント認証証明書の取得

いろいろ試してみたんですけど、なかなかこれという方法が無くて楽して証明書を取り出そうとして、何度も失敗し、結局面倒な方法で地道に行くしかなかったです。

1. プロキシを立ててWiresharkでパケットキャプチャする。この方法だとHTTPでラップされている分取り出しが面倒なので、キャプチャだけして後回し。
2. Fiddler2を使おうとするも、これも目的には合わない。
3. WiiをWifiクライアントとして、ThinkPad X201s Windows7をアクセスポイント化してキャプチャしようかと思いましたが、これを行うためにはAdhocモードが必要ですが、ThinkPadの不具合でこれができないようです。
4. 続いてWiiをWifiクライアントとして、DellのXPのノートをアクセスポイント化してみたんですが、他のWifiクライアントは繋がるんですがWiiは繋がりませんでした。ニンテンドーDSでも同様の問題が報告されているようで、ニンテンドー製品に共通の問題のような気がしてきました。
5. 押し入れに眠っていたリピータハブにアクセスポイントつけてキャプチャするかとも思ったんですが、アクセスポイントを設定する手順やらマニュアルやらが見当たらないので、面倒になりこれは最後の手段とすることにしました。
6. で、結局プロキシサーバのキャプチャから抜くという方法にしたわけです。

WiiのCipherSuite

まずは、お約束でWiiのサポートするCipher Suitesをみてみました。
0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0037 TLS_DH_RSA_WITH_AES_256_CBC_SHA
0036 TLS_DH_DSS_WITH_AES_256_CBC_SHA
0035 TLS_RSA_WITH_AES_256_CBC_SHA
0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0031 TLS_DH_RSA_WITH_AES_128_CBC_SHA
0030 TLS_DH_DSS_WITH_AES_128_CBC_SHA
002f TLS_RSA_WITH_AES_128_CBC_SHA
0005 TLS_RSA_WITH_RC4_128_SHA
0004 TLS_RSA_WITH_RC4_128_MD5
0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
000d TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0010 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
000a TLS_RSA_WITH_3DES_EDE_CBC_SHA
で、使われたのはこれです。
0035 TLS_RSA_WITH_AES_256_CBC_SHA

クライアント証明書は機器認証用なのか？

キャプチャ結果を見てみると確かにクライアント認証はされています。証明書チェーンはこんな感じです。

■SSLクライアント証明書
主体者名：/C=US/S=Washington/L=Redmond/O=Nintendo of America Inc./OU=Wii/CN=Wii Shop Prod 1/E=ca@noa.nintendo.com
有効期限：2006.10.25-2036.10.17
主体者鍵：RSA 1024bit
署名：SHA1withRSA
Netscapeコメント：OpenSSL Generated Certificate
■ルート証明書
主体者名：/C=US/S=Washington/O=Nintendo of America Inc/OU=NOA/CN=Nintendo CA/E=ca@noa.nintendo.com
有効期限：2005.08.10-2049.12.28
主体者鍵：RSA 1024bit
署名：SHA1withRSA

どうです？な〜〜んだ、って感じでしょ？機器に個別に発行されているような機器証明書が発行されてるんじゃなくて、Wiiで共通のクライアント証明書が発行されているだけで、それもOpenSSLで発行されているようなものでした。ちなみに公開指数はちゃんと65537でした。どうせ大した結果得られないなら面倒臭がらずに最初からプロキシのキャプチャを読んだ方がよかったです。トホホ。証明書コレクションがちょっと増えただけでも良しとしますか、、、

ではでは

マイクロソフトのルート証明書の更新プログラムが2010年8月23日にリリースされていました。最近、全く気にしてなかったんですが nahi さんのつぶやきを見ていたら更新されていたことを知りました。

前回から3ヶ月しか経っていないので、大した更新も無いんじゃないかと思っているんですが、今更ながら調べてみました。自分の持っているルートが338→341に増えたので、たった3つだけ増えたってことらしいです。 で、増えたのは以下の3つ。

国	認証局名
US	Microsoft Root Certificate Authority 2010
US	AffirmTrust Premium ECC
LT	Registru Centro Sertifikavimo Centras, VI Registru Centras RCSC (RootCA)

Microsoft Root Certificate Authority 2010

MSのルートもSHA256withRSA 4096bitのルート証明書を出してきたみたいです。

AffirmTrust Premium ECC

米国 AffirmTrust の楕円のルート証明書です。曲線はOIDが1.3.132.0.34で 鍵長 384bit の曲線名がSEC 2ではsecp384r1、NISTではP-384と呼ばれているものです。 SEC 2は楕円暗号業界団体 Standards for Efficient Cryptography Group (SECG) が定めた楕円暗号に 関する規格です。署名アルゴリズムは SHA384withECDSA でした。

Registru Centro Sertifikavimo Centras

リトアニア(LT)のルート証明書は適格証明書(QC)のルート証明書になっていて SHA1withRSA 4096bit 鍵の証明書でした。QCステートメントを見てみると以下の値が設定されていました。

0.4.0.1862.1.1 QcCompliance

ETSI TS 101 862で規定されたQC準拠であることを示す。

0.4.0.1862.1.3 QcEuRetentPeriod: 値=10

この証明書は10年間CAで保存される。

0.4.0.1862.1.4 QcEuSSCD

証明書の公開鍵に対応した秘密鍵がセキュアな署名生成デバイス (SSCD:Secure Signature Creation Devidce)上にあることを示す。

OIDが 1.3.6.1.4.1.311.21.1のMicrosoft CertSrv CA Version (cAKeyCertIndexPair?)拡張 が入っているのでWindows Server 2003以降のCAから発行されたもののようです。

これからRSA鍵のルートCAは鍵長4096bitっていうのが多くなってくるんでしょうね。

関連記事

• Windowsルート証明書の更新プログラム (2010.05)
• Windows ルート証明書の更新プログラム(2009.11)
• Windows ルート証明書の更新プログラム(2009.09)の続き
• Windows ルート証明書の更新プログラム(2009.09)
• Windows ルート認証機関の更新(2009.02)

マイクロソフトのルート証明書の更新プログラムが2010年5月24日にリリースされていました。最近、注目してなかたので全然気づかなかった。早速、どのようなルートが追加されたのか調査してみました。更新後、登録されているルートCAは337ぐらいになったんだと思います。更新の前後で追加になった26のCAは以下の通りです。

国	認証局名
US	AffirmTrust Commercial CA
US	AffirmTrust Premium CA
US	AffirmTrust Networking CA
BE	Belgacom E-Trust Root CA
BE	Belgacom E-Trust QC Root CA
US	GlobalSign Root CA R3
CZ	I.CA Qualified CA
CZ	I.CA Standard CA
US	VeriSign Class1 Public Primary CA
US	VeriSign Class3 Public Primary CA
DK	KMD Qualifed Person CA
DK	KMD Root CA
DK	KMD CA-Server
US	Starfield Root CA G2
US	Starfield Services Root CA G2
ZA	Thawte Premium Server CA
CZ	PostSignum Root QCA
ZA	Thawte Server CA
FR	KEYNECTIS ROOT CA
DE	TC TrustCenter Universal CA III
PL	CC Signet RootCA
GB	Comodo Secure CA
US	Go Daddy Root CA G2
FI	TeliaSonera Root CA v1
JP	Japanese Government MPHPT CA
ES	Spain Registrars Root CA

う〜む、今回の更新はまともな国のまともな認証サービスのものばかりで、あまり面白みにかけますね。欧州各国では適格証明書(QC)用のルートが随分増えたなぁというのも特徴的かもしれません。

関連記事

• Windows ルート証明書の更新プログラム(2009.11)
• Windows ルート証明書の更新プログラム(2009.09)の続き
• Windows ルート証明書の更新プログラム(2009.09)
• Windows ルート認証機関の更新(2009.02)

MD5偽サブCA問題などで有名なAlex Sotirovさんのつぶやきでおっかないのを見つけた。

This is beyond awesome: Mozilla is shipping a trusted root certificate and they have no idea where it came from: http://bit.ly/cMz4Ue

何やら、最新のFirefoxにも入っている以下のルート証明書

OU = RSA Security 1024 V3
O = RSA Security Inc
Valid From: 2/22/01
Valid To: 2/22/26
SHA1 Fingerprint:
3C:BB:5D:E0:FC:D6:39:7C:05:88:E5:66:97:BD:46:2A:BD:F9:5C:76

は、今やRSAでもVeriSignでも管理も所有もされておらず、監査も受けていないというのだ。そんなルート認証局は早く削除すべきだとニュースに投稿があったらしい。

これが本当なら怖い話だなぁ、、、と思う。RSAやVeriSignは、今は管理していなくてもかつて管理していた認証局なんだから責任もって「信頼されるルート認証機関」から削除を働きかける必要があったんじゃないかなぁ、、、と思う。

今後の動きはウォッチしたいと思います。

証明書の発行サービスや、セキュリティソフトウェアなどを販売しているComodo社からGoogle Chromeベースの新しいウェブブラウザComodo Dragonが無償提供されるようになりました。この名前、世界最大のトカゲであるコモドオオトカゲ(Komodo Dragon)にひっかけてるんですねぇ。 このブラウザの特徴の中に「簡単なSSL証明書の特定」と「Chrome上でのプライバシー機能の向上」というのがあるらしいので、その辺りを中心に見てみたいと思います。

まずはEV証明書だとどうか

まずは、EV SSLサーバー証明書を使っているサイトを閲覧し違いをみてみます。そのためには、Google Chromeと同じく(設定していなければ)「サーバー証明書の取り消しを確認する」を「オン」にしておかなければなりません。証明書発行サービスがあえて出してきたウェブブラウザなので、これは「強制オン」にしても良かったのかなとも思います。

まずは、Comodo DragonでEVサイトを表示するとこんな感じ。

これがGoogle Chromeだとこうなります。単にアイコンが違うだけみたいですね。

Microsoft Internet Explorer 8だとこんな感じ。EVサイトの表示に関して個人的に一番好感を持っています。

Firefox 3.6ではこうです。これも悪くない。

設定オプションに違いはあるか？

次に、Comodo DragonとGoogle Chromeで設定オプションに違いはあるのかをみてみました。どうやら大きな違いはなさそう。
「ナビゲーションエラーがあれば解決のヒントを表示する」はDragonではオンにすることができません。あと、クッキーの管理についてDragonは古いChromeをベースにしているのか

のような感じで、Chromeだとサイト毎に管理されており改良されています。
シークレットウィンドウの機能に関してもChromeとDragonで何ら違いは見受けられませんでした。

あれれ？

幾つかの証明書サービスの発行する証明書で発行したSSL証明書を使ったサイトで証明書関連の警告が出ることがありました。
同じサイトでGoogle Chromeではこのようになり警告は出ません。
おおっ、やはり何か特別な証明書検証をしているんでしょうか。期待度大です、、、証明書チェーンやパケットキャプチャしたり、うまくいく組織認証サイト(OV)とドメイン認証サイト(DV)でいろいろ違いを調べてみましたが割と参入の新しい(言葉選んでるなぁ、、、)特定の証明書サービスだとエラーが出ているような気がします。エラーメッセージを元に調べてみると、ただのバグだったみたいです。他にもスキンを切り替えられないなど幾つかのバグも報告されているようです。

おわりに

機能概要に踊らされて期待をこめつつ新しいブラウザComodo Dragonをみてみましたが、Google Chromeとのセキュリティに関する違いは無いようで、単にスキンが変更されただけのもののようです。公開されている情報やレビュー記事なども少ないので現時点見落としている点もあるかもしれませんが、今後に期待ということで、、、

関連リンク

• Comodo Dragon Internet Browser (公式サイト)
• ２ちゃんねる 「Comodo Dragon」Chromium派生ブラウザ スレッド