自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

Xperia

JPCERTのEV証明書とAndroidのウェブブラウザについて(解決済)

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

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

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

まず、IPAはこんな感じ。セコムトラストさんのEVです。
ev-ipa
次にJPCERTコーディネーションセンターのサイトはこんな感じ。ベリサインさんのものです。
ev-jpcert
そしてJPCERTとIPAで運営しているJVN(Japan Vulnerability Notes)のサイトはJPCERTが取得したベリサインのEV証明書を使っています。
ev-jvn
ちなみにwww.jpcert.or.jpの証明書チェーンをFireFoxの証明書ビューアでみるとこんな感じ。
ev-jpcert-ffcertview
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が無いためにパス構築に失敗している可能性もある。

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

初代Xperia(Android 1.6)に搭載されたルート認証局証明書

前回からの続きで、docomoのスマートフォンXperiaについて調べています。今回はXperiaに搭載されている信頼するルート証明書について書こうと思います。

XperiaのOSは2009年9月15日にリリースされたちょっと古めのAndroid 1.6なんだそうです。ルート証明書の一覧は "/system/etc/security/cacerts.bks" にあり、ファイルを取り出すにはAndroid SDKのツールを使って母艦にコピーします。

% adb pull /system/etc/security/cacerts.bks cacerts.bks

"cacerts.bks"はJavaのkeytoolで扱える証明書ストアになっているんですが、BouncyCastle JCEライブラリ専用の証明書ストアになっているので、これを指定して取り出します。

で、ルート証明書の一覧を見てみたところ、こんな感じでした。
Xperia Root Certificates
全部で52のルート証明書が登録されており、Windowsの297に比べてかなり少なめ、下のリストのSun Javaと見比べるとやや古いSun Java J2SE 6.0 Update 5ぐらいの時期のルートをもとにしているのかもしれません。

  • Sun JDK 6.0 update 19 - 75
  • Sun JDK 6.0 update 18 - 72
  • Sun JDK 6.0 update 7 - 55
  • Sun JDK 6.0 - 43
登録されているルート証明書をみてみると、ほとんどが2009年11月のMicrosoftのWindows Root Certificate Programに含まれている証明書なんですが、3つだけ
  • Global Sign Root CA (C=BEのもの)
  • StartCom Free SSL CA
  • Sony Ericsson Secure E2E CA
だけがプログラムに含まれないAndroid独自の証明書のようです。(ソニエリ以外はSun Javaには入ってたのかな?)。Global Sign Root CAのkeyUsageのエンコーディングで警告がでますね。時間があるとき、見てみます。

ソニエリが入っているってことは、cacerts.bksは、Android OSに共通なものではなくて、機種毎に違うものなのかもしれませんね。

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

追記:GlobalSignのkeyUsageの警告

古いGlobalSignのルート証明書でkeyUsage拡張のエンコーディングで警告がでるので見てみました。ASN.1 BIT STRING型の値としてはkeyCertSign(5)とCRLSign(6)のビットが立っていて最上位が一つビットが立たないのでunused bitsが1になり、正しくは

03:02:01:06(BIT STRING 1 unused bits '1100000'B)
となるところが間違えて
03:02:00:06
となっちゃっているのでエンコーディングの警告が出ていたのでした。古い証明書ではたまにこんな間違いがありますよね。

Xperia上のブラウザがサポートするSSL/TLS CipherSuites

少し時間があったので会社から貸与されたdocomoの新型スマートフォンXperiaをいろいろいじってみました。今回は、手始めにXperiaで使われそうなウェブブラウザのSSL/TLSのCipherSuiteについて調べてみました。

  • Xperia (Android 1.6)の標準ブラウザ
  • Xperia上のOpera mini beta5 (5.0.18302)


SSL-TLS Supported CipherSuites

HTMLの表の方もあるのでこちらもどうぞ。

で、表を見てみると特徴はこんなところでしょうか。

  • Xperia標準ブラウザのSSL/TLS
    • SSLv3, TLSv1.0をサポートし、SSLv2をサポートしない。切り替え設定はできない。
    • サポートするCipherSuitesは19で標準的なPCブラウザの70%くらい
    • 最近のブラウザはサポートしなくなりつつある強度弱めなMD5,DES,3DESをサポート
  • Xperia上のOpera mini beta5のSSL/TLS
    • SSLv3, TLSv1.0をサポートし、SSLv2をサポートしない。切り替え設定はできない。
    • サポートするCipherSuitesは18で標準的なPCブラウザの70%くらい
    • PC版OperaからはDH_RSA, DH_DSSなどを削除している
    • TLS_EMPTY_RENEGOTIATION_INFO_SCSV(x00ff)をサポートしている
2009年3月に発表されたSSL rebindingやSSL renegotiationといわれるSSL/TLSの仕様の欠陥をついた攻撃方法に対応するために新たに追加された拡張をOpera miniではサポートしているらしい。 Opera miniにRFC 5746 Transport Layer Security (TLS) Renegotiation Indication Extension 3.3. Renegotiation Protection Request Signaling Cipher Suite Value で規定されている安全な再ネゴシエーションのための拡張を表すCipherSuite(もどき)が入っているのには、ちょっとびっくりした。多分iPhoneのOpera miniや、最新のPC版Operaでもこれをサポートしているのかな? ClientHelloにTLS_EMPTY_RENEGOTIATION_INFO_SCSVというCipherSuiteがある場合、これはアルゴリズムでも何でもなくて、セキュアな再ネゴシエーションを行いますよというフラグになっています。

う〜ん、Operaはやる事早いな。サーバー側は、まだ全然ついてきてないんですよねぇ、、、確か、、、

今日は、こんなところで

関連記事

最新記事
Categories
Archives
記事Google検索

本ブログ内をGoogle検索
Twitter
Yahoo!アクセス解析
Travel Advisor
QRコード
QRコード
  • ライブドアブログ