自堕落な技術者の日記

先日のブログ「Windowsルート証明書の更新プログラム(2014.09)と戯言など」で、

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。

実際に試してみたので、ちょっと書いてみたいと思います。

ルート証明書アップデーターからSSTの取り出し

Windows 7以降のオフライン環境で、信頼するルート認証機関のリストをアップデートするのにアップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exeがあるというので、早速ダウンロードしてみます。wgetでヘッダ見てみると最終更新は"Wed, 12 Nov 2014 17:33:07 GMT"になっているので、最新のアップデートには対応してそうかな？とも思ったんですが、後に最新のルート更新には対応してなかったことがわかりますorz

これはCAB形式自己解凍アーカイブみたいになっているので、exe2cab(Vectorのは64bitでは動作せず)を使って中身のcabファイルを取り出します。

cabファイルの中はこんな感じ。

ADVPACK.DLL
authroots.sst - ルートのスモールセット？
delroots.sst - 削除するルート
roots.sst - 最小限の2つのルート
rootsupd.inf -
updroots.exe - ルートを更新するプログラム
updroots.sst - 追加される多くのルート

cabファイルのタイムスタンプ見てみたら、2013年4月になっているので、どうも直近の2014年9月の更新に対応したアップデートファイルでは無さそうな雰囲気です。

SSTファイルからのルート証明書の取り出し

*.sstファイルはMicrosoft Serialized Certificate Filesというフォーマットらしく、前にも力技で証明書取り出すスクリプトを書いた記憶があるんですがorz、ちょっと調べてみたらPowerShellのExport-CertificateやImport-Certificateで操作できそうな雰囲気。サンプルにはSSTに証明書を追加する例なんかも紹介されていました。ところが、どうもSSTから証明書を取り出す方法がよくわからずに結局断念。

もうちょっと調べてみるとSSTの中の個々の証明書エントリはSerializedCertificateEntryという構造になっているらしく、SSTのヘッダ情報のあとはこの並びになっているので、Perlでちゃちゃっと抜き出すスクリプトを書きました。

id - 4byte 0x00000020
encodingType - 4byte 0x00000001 (= ASN.1 encoding)
length - 4byte 続く証明書データの長さ
certificate - 可変長 証明書生データ

取り出せた証明書の数はこんな感じ、2014年9月のルートの更新では411だそうですから、かなり少なめ。古い情報っぽくてちょっと萎え気味。

SSTファイル	ルート証明書数
authroots.sst	77
roots.sst	6
updroots.sst	275
計	358

で、ぽちぽちルート証明書を開いてみる

とまぁ、ルート証明書の取り出しはできたので、これをそれぞれ開いてみると 「インターネットオプション＞コンテンツ＞証明書＞信頼されたルート認証機関」に 未表示のものだったら、表示されるようになります。

Windows 8.1 Proの最新パッチ済の環境で、358のうち、有効期限切れになっているものや、すでにMicrosoftが登録削除しているものもあるようで、最終的には271個のルート認証機関がちゃんと表示されるようになりました。これの作業前は確か27だったので、大躍進という感じではあります。

(TURKTRUSTが表示されていることに他意はありません（＾＾；

おわりに

いや〜〜、隠し球っぽくて気持ち悪かったのが、表示されて随分すっきりしますね〜〜。ただ、

やっと271は表示されたが411まではまだ遠い

私はビックリマンチョコ世代ではないですが、仮面ライダースナックとか集めましたね〜〜。ソシャゲーのコンプガチャみたいんなもんなんですかね〜〜。最後までちゃんと表示させたくなりますよね〜〜〜。 411まではまだ道のりは遠い感じですねぇ。やっぱり、Certificate Transparencyのデータに手をつけないといかんかなぁ、、、と思っているところです。

今日は、この辺で、、、

関連記事

• Windows信頼するルート認証機関コンプへの道(第一回) (2015.05.10)
• Windowsルート証明書の更新プログラム(2014.09)と戯言など (2015.05.03)
• Windowsルート証明書の更新プログラム(2010.08)
• Windowsルート証明書の更新プログラム(2010.05)
• Windowsルート証明書の更新プログラム(2009.11)
• Windowsルート証明書の更新プログラム(2009.09)の続き
• Windowsルート証明書の更新プログラム(2009.09)
• Windowsルート証明書の更新プログラム(2009.02)
• Windows95の信頼するルート認証機関(2008.11.28)

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15〜25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

• ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
• 初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
• 例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
• Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
• つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。

もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。

RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね〜〜。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。

iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね？ 本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

1. 公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
2. Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
3. Macのテキストエディタで開きUTF-16で保存する。
4. MacのExcelでインポートする。
5. インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
6. ルート証明書リストのExcelが完成！！！ (泣)
7. ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計 したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな！」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。

なんかこう、 あれです、411もあるわけですから、フルコンプしたいですよねぇ？ 先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ？！！！

これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。 例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと！！！(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや〜、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ〜か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが 、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな？？？

関連記事

• Windows信頼するルート認証機関コンプへの道(第一回) (2015.05.10)
• Windowsルート証明書の更新プログラム(2014.09)と戯言など (2015.05.03)
• Windowsルート証明書の更新プログラム(2010.08)
• Windowsルート証明書の更新プログラム(2010.05)
• Windowsルート証明書の更新プログラム(2009.11)
• Windowsルート証明書の更新プログラム(2009.09)の続き
• Windowsルート証明書の更新プログラム(2009.09)
• Windowsルート証明書の更新プログラム(2009.02)
• Windows95の信頼するルート認証機関(2008.11.28)

ちょっと遠い関連記事

• Android 4.3.1 と 4.4 KitKatのルート証明書リストの違いを見てみたぞ(2013年11月10日)
• Android 4.0.4 と 4.3.1 のルート証明書リストの違いを見てみたぞ(2013年11月6日)
• Xperiaに搭載されたルート認証局証明書 (2010年4月26日)
• Android 4.0 以降のルート証明書ストアを調べるツールを作ってみたいぞ (2012年09月30日)
• (小ネタ)Android 4.0 ICSのルート証明書ストア (2012年09月04日)
• (小ネタ)Root CA Viewer Lite for Android(Free)の公開 (2014年10月24日)

SSL Pulse の 2015年4月版が公開されましたね。いつもは2ヶ月に1回状況報告しようとしていたんですが、SHA1証明書からSHA2証明書への移行が気になってたので、証明書の鍵や署名アルゴリズムの移行状況だけグラフにしてみました。SHA1証明書が51%、SHA2証明書が48%とかなり近づいています。

同じように推移したとすると、2015年5月にはSHA1証明書の数がSHA256証明書の数を追い越しそうですね。

関連記事

• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

先週のInternet Week 2014でHTTPSサーバー設定のセッションのパネルパネルで言えなかった事の第二弾です。

自分のサイトが公開サイトである場合にはQualys SSLLabsのサイトを使って外部からSSLの暗号スイートの設定を確認すればよいんですが、イントラ内の場合には厄介ですよね。パケットキャプチャで調べるわけにもいかないし、OpenSSLのs_clientで暗号スイート一つ一つチクチク調べるのは面倒だし。

そんな時、クライアント側にWindowsが使えればwww.g-sec.luで公開しているsslauditというツールが便利です。

検査対象のサーバー(IPアドレスでも可)とポート(デフォルトでは443)を指定して、「Start」ボタンを押すだけです。利用可能なものだけを表示する場合には「Display supported ciphers」をチェックしてからスタートするとよいでしょう。

• SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2全てのプロトコルに対しプロトコル毎に サポートしている暗号スイートを調査
• 暗号スイートはGCM,ECDHE,SHA2など最新を含めかなり広範囲でサポートされており実用上問題にはならない。 (GOSTとかよっぽどマイナーなのは無かったと思う。)

よかったら使ってみてください。

関連リンク

• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS
• Internet Week 2014パネルで話しそびれたネタ2: イントラ内でSSLサーバー設定を確認するツールsslaudit
• Internet Week 2014 S14 講演2「サーバの正しいSSL/TLS設定のツボ」補足情報ページ

SHA1withなんとかで署名されたSSLサーバー証明書に対するGoogle Chromeの 将来の取扱いポリシについて、Googleのブログで9月5日に情報公開され、ちょっとビックリした人も多いんじゃないでしょうか。私は、「こりゃちょっと問題だなぁ。」と思ったので今日はブログで書いてみようと思います。

SHA1が充分な暗号強度がなくなりつつある話

暗号の専門家ではないので、よくわからないのですが、 例えばコレなんかをみてみるとSHA1ハッシュアルゴリズムの暗号強度が充分でなくなってきていると言われており、暗号に関する日本で主要なガイドラインであるCRYPTREC暗号リストではSHA1は「運用監視暗号リスト」、危殆化リスクが高まっているが互換性維持のため仕方なく使って良いリストに入っています。

このような状況を受けて、製品ベンダー、証明書発行サービスなどのサービサーなどはSHA1からSHA2への移行をようやく始めたところなのかなと思います。

米国の標準化機関であるNISTは2011年1月に「NIST SP 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lenghs(暗号アルゴリズムと鍵長の使用に関する勧告)」を発行しており、その中で「SHA1を使った署名の生成と検証は2013年12月31日以降、認められない。」としていますが、NIST内でもSHA1証明書を使ったサイトがまだ残っているそうで、「自分も守れてないじゃ〜〜ん」みたいな状態になっているそうです。

2013年11発表のMicrosoft製品のSHA1移行ポリシー

幾つかの業界や製品では先行してSHA1からの移行ポリシーを策定、公表しているものもありますが、SSLサーバー証明書に関しては幅広い製品やサービスで使われ、SHA1を使っている比率も高く移行は難しいのだろうと思います。本来ならCA Browser ForumのBaseline Profileで規定されてもよかったのだろうと思いますが、SHA1からの移行については言及されていません。 そんな中、2013年11月12日に発表されたMicrosoft製品に関して公開された2つのSHA1移行ポリシーはちょっと衝撃的でした。

Windows Root Certificate Program - Technical Requirements version 2.0

このプログラムはWindows製品の「ルート証明書プログラム」という、Windowsの信頼するルート証明書に加えてもらうためには、どのような基準を満たさなければならないかを定めたものですが、「対象の認証局は2016年1月1日以降、SHA1証明書を発行をしてはならない。」としています。

Windows PKI Blog: SHA1 Deprecation Policy

「Windows製品では2017年1月1日以降、SHA1のSSLサーバー証明書を受理しないためエラーとなる。」としています。すなわち、Windows製品でSSLを使えるようにするには、SHA1 SSLサーバー証明書を2016年12月31日までにSHA2にリプレースしなければならないという事だそうです。

SHA1 証明書がそろそろ偽造の危険性があるという認識も高まっており、充分な猶予期間もありますし、その頃には、SSLサーバー証明書を扱う全ての製品のSHA2対応もかなり進んでいるでしょうから、よく考えられた妥当なスケジュールなのかなと思います。

これに関して注目すべきポイントは以下の2つかと思います。

• 中間CA証明書やルート証明書のSHA1については言及していない。
• 2016年1月1日と、2017年1月1日という2つのマイルストーンを守りさえすればよい。

このMicrosoftのSHA1移行ポリシーのアナウンスを受けて、主要なSSL証明書発行サービスは、SHA1証明書の発行は2015年12月31日までとアナウンスをしています。

• シマンテック社： ハッシュアルゴリズムのSHA-1からSHA-2への移行に関して
• グローバルサイン社：SHA-2電子証明書への移行について

2014年9月5日に公開されたGoogle ChromeのSHA1 証明書対応ポリシー

2014年9月5日に「Google Online Security Blog: Gradually sunsetting SHA-1」 にて、Google ChromeのSHA-1証明書にするポリシーの変更が発表され、一部の人は驚きを持って読んだのではないかと思います。 ITmediaエンタープライズでも 「Google、「SHA-1」サポート中止のスケジュールを発表(2014.09.08)」 として紹介されました。(何点か間違いがあるので、原文を参照するのがいいでしょう。)

これは簡単に言ってしまうと、「SHA-1のSSLサーバー証明書によってHTTPSの接続表示を近々(大きく)変えますよ」というアナウンスです。

Google ChromeのHTTPSステータス表示

Google ChromeのアドレスバーにおけるHTTPSのステータス表示は以下のようになっているようです。

表示	内容
	EV証明書でない正常なHTTPS接続の場合
	secure, but with minor errors 例えばHTTPSとHTTPのコンテンツの混在の場合などに出る。
	neutral, lacking security 平文のHTTPなど、セキュリティが無い中立の状態。
	affirmatively insecure 危険だと断言できる場合。
(参考) EV SSLサーバー証明書で正常にHTTPS接続できている場合

Google Chromeは証明書チェーンがSHA1かどうかチェック

WindowsのSHA1移行ポリシーはエンドエンティ証明書、すなわちSSLサーバー証明書がSHA1かどうかだけをチェックしており、中間CA証明書がSHA1かどうかは関係無かったのですが、Google Chromeの移行ポリシーは、全ての中間CA証明書もチェックするので注意しなければなりません。

で、ChromeでSHA1証明書でHTTPS接続した場合どうなるのか？

9月5日に発表された、ChromeでSHA1証明書にHTTPS接続した場合のURLアドレスバーのHTTPSステータス表示が、この半年で3回出てくるChromeのバージョンによって、どう変わっていくのかを整理したのが下の表です。

	Chrome 39 開発版の途中まで 〜2014.09.26 38安定版まで (〜2014.11上旬)	Chrome 39 開発版の途中から (2014.09.26〜 2014.11.09) 39安定版 リリースから (2014.11上旬〜	Chrome 40 開発版の途中から (2014.11.09〜 2015.Q1) 40安定版 リリースから (2015.01?〜	Chrome 41 開発版の途中から (2015.Q1〜 2016.12.31) 41安定版 リリースから (2015.03?〜	2017.01.01〜
有効期限が2016年5月31日までのSHA1証明書
有効期限が2016年6月1日から12月31日までのSHA1証明書
有効期限が2017年1月1日以降のSHA1証明書
Windowsの場合(Chrome同等の表示として)

表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。

今回のChromeのSHA1対応ポリシの問題点

今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。

• 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思統一されたSHA1証明書の移行計画を示し、EV証明書のように準拠するブラウザは同じようなステータス表示にするべきだったと思います。
• 2つの有効期限の異なる証明書があって、その有効期限により表示状態が異なるということは問題です。 今回はSHA1署名アルゴリズムの暗号危殆化を問題に取り上げているのですから、有効期限の長短にかかわらず、ある時点での暗号危殆化の程度は全く同じであり、同じものに対しては同一のHTTPSステータス表示にすべきではないでしょうか。
  
  
• 2017年1月1日からを、SHA1証明書を使ってはならない日と定めたとして、2年3ヶ月以上も前にユーザに表示を変えて伝える必要があるのでしょうか。2017年1月1日まではSHA1証明書を使って良いとするなら、いかなる警告もそのことで出す必要がなく、これはユーザも、ウェブサイト運営者も混乱させるだけです。2年以上も前に表示が異なってしまうことで、ユーザはサイトへクレームや問い合わせを入れるようになり、ウェブサイト管理者は仕方なく2年前倒しでSHA2証明書への移行を迫られることになります。
• 最近のモダンなブラウザではSHA2証明書に対応していますが、古いJavaや、組込み機器、ICカード、ガラケー(フィーチャーフォン)などSHA2証明書に対応できない環境は、未だに多数あります。これらの環境と歩調をあわせながらSSLサーバー証明書のSHA2移行を進める必要があったのではないでしょうか。
• 前述のOSなどのレベルでアルゴリズムとしてSHA2署名をサポートしていたとしても、検証などで使おうとするSHA2証明書のトラストアンカとなるルート証明書が「信頼するルート証明書」ストアに入っているかどうかは別の問題。例えば全てのお客様や、全社員のWindows XP SP3に対してルート証明書を追加させるという事はかなり困難。
• Netcraftの2014年5月の調査によれば、 インターネット上のウェブサイトのうち92%がSHA1証明書のままであり、SHA2証明書へ移行済なのはわずか7%にすぎません。HeartBleed脆弱性の影響で証明書のリプレースが多くあったため、SHA2への移行は進んだようですが、それでもたった7%です。このような状況で2014年9月にはHTTPSステータス表示を変えるというのは急すぎないでしょうか。(追記 SSLPulseによると2014年9月時点でSHA2は15%だそう)
• SHA1証明書に対する表示変更のポリシーを2014年9月5日にアナウンスしてから、わずか21日後の2014年9月26日の開発版アップデート、安定版では2014年11月頃の39リリースで、影響を受けるサイトが出始めます。充分な猶予期間、準備期間を持てるように例えば半年や1年といったスパンで事前アナウンスをする必要があったのではないでしょうか。
• SSLサーバー証明書は一般に2年や1年といった有効期間のものを購入される組織が多いと思いますが、例えば2014年6月1日から、アナウンスのあった2014年9月5日に2年物のSHA1証明書を購入し設定したウェブサイトは、早速2015年の1Qには、問題があるかのような黄色表示 になります。事前に知らされていれば、1年物を買うとかSHA2証明書を買うとか対策ができたかもしれません。 これは、あまりに不親切でユーザやサイト管理者の事を考えていない行為だと思います。
• 2017年1月1日以降が有効期限であるSHA1証明書が、2017年1月1日以降は使えなくなるという事は理解できるとして、2016年6月1日から2016年12月31日の間に有効期限がある証明書を分けてアラート表示をする必要があるとは思えません。

参考にすべきページ

今回のChromeのSHA1移行について問題提起や対策などを示している良いページがあるので、紹介しておきたいと思います。

CSO Online: Do you agree with Google's tactics to speed adoption of SHA-2 certificates?

CA Security Councilの中の人の問題提起。オンラインショップクリスマス商戦の時にこのような問題を起こすのや良くないとも言っている。Windows Server 2003ではhotfixなしでは非対応だと。他にも参考になるアドバイスがある。意見も募集している。

BLOG: IVAN RISTIC: SHA1 deprecation: what you need to know (2014.09.09)

SSLの状態を調べられるQualysのSSLLabsを作っていたり、SSLの設定ガイドなどを書いているIvanさんのページで、今回のGoogle Chrome SHA1移行について、どのように対処するのが良いか解説しています。いつも冷静な分析をされる人ですが、今回に関し批評が無いのは寂しい。

CA Security Council: List of Operating Systems, Browsers, and Servers Which Support SHA-256 Hashes in SSL Certificates (last update Sep 8, 2014)

最新のSHA-256サポート状況のリストです。参考になります。でも、OSや環境レベルでSHA2をサポートしたと言っても、これから使おうとしているSHA2証明書のトラストアンカとなるルート証明書が信頼するルート証明書ストアに入っているかは別の問題。

おわりに

Google Chromeは良いブラウザだと思うし、便利だし、大好きなんですが、CRLSetの問題と、今回のSHA1対応の件はちょっとヒドイなぁと思います。サイトの運営者の方は、最初のマイルストーンの9月26日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。

本ブログの関連記事

• 将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話(2012.02.13)
• Windows Server 2003とSHA2証明書(2008.08.24) - コメントにhotfix

関連リンク

Mozilla Security Blog: Phasing Out Certificates with SHA-1 based Signature Algorithms (2014.09.23)

Mozilla Firefoxからも同様のSHA1移行ポリシーが公開されました。

(訂正)バージョン番号の修正(2014.09.17)

バージョン38が既にリリースされていると勘違いして、 今回のSHA1アラート表示の修正が、マイナーで入るのかと勘違いしたため表の バージョンの表記がおかしくなっていましたので修正しました。 バージョンの確認はこちらでできるようになっており、直近のメジャーですと以下のようなリリース履歴であるとわかりました。すみませんでした。(影響日やバージョンについて再修正しました9/17 12:50)

• 安定版メジャー 37.0.2062.94 2014.08.26 for Win,Mac,Linux
• 安定版メジャー 36.0.1985.125 2014.07.16 for Win,Mac,Linux
• 安定版メジャー 35.0.1916.114 2014.05.20 for Win,Mac,Linux
• 安定版メジャー 34.0.1847.116 2014.04.08 for Win,Mac,Linux

通常は安定版(Stable Channel)のリリースは6週間おき だそうですが、40安定版についてはクリスマスシーズンを挟むので 時期が未定なのだと思います。

SSL/TLS CipherSuiteウォッチャーの@kjurです。

2013年11月13日にマイクロソフトから度肝が抜かれるほどびっくりした Windows 7 SP1以降の「重要」更新プログラムが出てもうアップデートした人も いるんじゃないかと。既にSurface Pro 2などのWindows 8.1にはこの 更新が適用されているというので二度見しちゃいましたよ。

マイクロソフトセキュリティアドバイザリ(2868725) RC4を無効化する更新プログラム
http://support.microsoft.com/kb/2868725/ja
http://technet.microsoft.com/ja-jp/security/advisory/2868725

BEAST対策でRC4マンセーみたいな感じだったのに、RC4使えなくしちゃうんですよ。いきなりですごくないですか? 証明書とかSHA1を止める準備も着々と進んでいてマジでマイクロソフトやるなぁと度肝を抜かれました。

となりの人がこのパッチを適用されたWindows 8.1のSurface Pro 2を持っているのでちょっとマシンをお借りしてCipherSuite比較してみました。(Special Thanks To 隣の平井堅に似た人)

ちなみにこっちはWindows 7 SP1でRC4無効化パッチ(KB2868725)未適用のIE8.0のCiphrSuite。

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 12
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

そんでこれがWindows 8.1 Pro、IE 11.0.9600.16384のCipherSuite。

Client Hello Version: TLS 1.2
TLS Version: TLS 1.2
Num Cipher Suites: 19
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

特徴的なのはこんなとこ。

• 本当にRC4はなくなってしまった。
• ClientHelloではClientHelloのバージョンもTLSバージョンもTLSv1.2になっており、接続に失敗してもTLSのバージョンをダウングレードしたりはしないんですが、頂いた報告や私も確認してみた所、クライアントがTLSv1.2のみを要求して、サーバーがTLSv1.0と返してきてもハンドシェイクできてしまうみたいです。iOSとか他の実装はClientHelloをダウングレードしてやり直すものが多いですが。本来ならばClientHello TLSv1.0、TLS versionがTLSv1.2とするのが正しいClientHello要求だと思います。
• 対応するCipherSuiteが12から19に増えました。
• SHA2系のCipherSuite、AES GCMのCipherSuiteが追加されました。
• でもRSA GCMは無くてECDSA GCMだけでかなり残念
• CipherSuiteの優先順位が微妙

GCMの対応はAndroid、MacOS X版Chrome、Android版Operaに続いてIE11もとうとう来たかという感じですね。Firefoxの対応が待たれます。過剰なBEAST対策祭りでAES止めちゃってRC4しか残してないとかRC4と3DESしか残してないとかいうサイトはつながらなくなったり、弱い暗号になっちゃったりするかもしれないのでケアしないといけないかもですね。

今日はこの辺で

マイクロソフトのルート証明書の更新プログラムが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)

前回の9月のに引き続き、11月もルート証明書の更新があったのをすっかり忘れていました。

何が追加されたのか(今回も現実逃避モードで)調べてみました。前の9月から2ヶ月しか経っていないので、たった7つしか増えていません。

認証局	発行組織	国
ipsCA Main CA Root	ipsCA	スペイン
ipsCA Global CA Root	ipsCA	スペイン
Autoridad de Certificacion Firmaprofesional		スペイン
CCA India 2007	India PKI	インド
Autoridade Certificadora Raiz Brasileira v1	ICP-Brasil	ブラジル
Security Communication RootCA2	SECOM Trust Systems	日本
Entrust.net Certification Authority (2048)	Entrust	米国

スペイン多いですね。インドっていうのがやる感じです。他はノーコメントで（＾＾；

Windows Updateから情報を辿ると2009年2月のアップデートと同じ情報が表示されるんですよね。ルートが更新される場合には何が追加になったのかきちんと公開して欲しいなぁ、、、と思います。

リンク

・マイクロソフト：ルート証明書の更新プログラム[2009 年11月](KB931125)

随分前のブログにWindowsルート証明書更新プログラムの事を書いたわけですが、iPhoneのルートってどうなんだろうと思って調べているうちに、そもそも、このWindowsのプログラムで登録されているCAの数っていくつなんだろうと思ったわけです。

WindowsのCAのまともな資料はこれになります(PDF)。

一つ一つ数え上げるのも大変なので、一旦PDFをテキストに変換してハッシュアルゴリズムでカウントすることにしました。

署名のハッシュアルゴリズム	数
MD2	11
MD5	41
SHA1	231
SHA2	1
SHA256	15
SHA384	4
総数	303

というわけでWindowsルート認証機関として登録されている認証局の総数は303なようです。

では、iPhone (3.0 or 3.1)はというと328みたいです。30程度増えちゃってますね。どんなとこが増えているのか機会があったら紹介したいと思います。

ではでは

＜追記＞

• ちらっと見たところ公的個人認証のブリッジとか、米国DoDのブリッジとかが入っているようですね。ブリッジを直接信頼するのはちょっと違和感ありますね。
• iPhone OS 3.0のルート認証局数を331→328に訂正