自堕落な技術者の日記

夏休みの宿題みたいな感じで、この2ヶ月くらい、jsrsasignの大改造をし、証明書、CRL、OCSP、CMS SignedData、タイムスタンプの読み取りと生成のコードを大幅に書き直し、後方互換性をバッサリ切ったので、なんだかんだでバージョン10.0.0となりました。これで読み取りも、全部一貫して、生成もJSONでちゃちゃっと簡単にできるようになったかなと思います。

jsrsasignの保守はこれくらいでやめにして、最近は既存の証明書チェーンや、CRL、OCSPレスポンス、タイムスタンプトークンから、検証環境を自動で作るようなツールを作っています。普通だとCAごとに環境作ったり、OCSPレスポンダつくったり、TSA作ったり手間もリソースもかかり面倒くさいですが、一つのVM、一つのIPで、楽ちんポンで、これができちゃうようになるというもので、概ねベータバージョン的なものができ、QCだの、eSeal証明書だの、TSAだのいろんなテスト環境作って遊んでいます。

さて、そんな中、自分のオープンソース活動について、Googleの中の方に推薦頂き、2020年Q3の、Google Open Source Peer Bonus Awardという賞をもらい、賞金ももらってしまいました。(社内表彰みたいなのを除いて)このところ賞をもらうことなんて殆どないのでとても嬉しいです。ありがとうございます。頂いた賞金で、Mac Book Airのバッテリがヘタってきたので交換したり、家族で小さいお祝い会をしたいと思います。

GoogleのOpen Source Peer Bonusは、4半期に一度、Googleの社員の方の推薦でオープンソース活動について表彰いただけるというプログラムなのだそうです。元気のある会社はすごいですねぇ。過去には、2020年1Qの受賞者のアナウンスがこのブログエントリでされていました。今回の表彰もまとめてアナウンスしてもらえるのではないかと思います。 ちなみに、頂いた賞状はこんな感じです。↓↓↓

また、前回あんなエントリを書いたあと、私のオープンソース活動に、いろんな方が気にかけてくれ、お声掛けしてくれたり、寄付してくださったりしました。本当にありがとうございます。これを励みに、のんびり自分のペースで活動を続けていこうと思います。

追記 (2020.10.06)

公式ブログに「Announcing the latest Google Open Source Peer Bonus winners! (Monday, October 5, 2020)」が掲載されました。あざます。あざます。

Certificate Transparency(以下CT)には色々問題があって何だかな〜〜〜と思っているわけですが、山がそこにあったら、登りたくなるのもまた人情（＾＾； CTログサーバーや格納されているデータについて、いろんなツールを作りながら調査をしています。何回かに分けて、CTについてわかったことを書いていこうと思ってます。

プレ証明書について

CTに対応していることを示すために、幾つか方法はあるのですが、実際に有効になっているのは発行する証明書にSigning Time Stamp(SCT)拡張を埋め込むことです。TLSの拡張やOCSPとついでに渡すという方法の実装を見たことがありません。

SCT拡張を含めるためにはプレ証明書なる証明書が必要になるんですが、プレ証明書がどんなものか、どんなフローで発行されるのかはこのスライドで説明しています。DigiCertさんの幾つかのページでもプレ証明書について解説されているのでよかったらご覧ください。 [1] [2] [3]

これまでにCTの仕組みが導入される前の証明書、CTに対応する予定のなかった証明書に関してはCTのログサーバーに普通にX.509証明書のチェーンが格納されるんですが、CTにまともに対応しようとしているベンダーの証明書は、プレ証明書のチェーンが格納されています。Chromeで「公開監査情報があります」と表示されるものについても、プレ証明書ベースのSCT拡張がX.509証明書に含まれているものしか、このように表示されないと思います。

今日の時点で、Google pilotのCTログサーバーには約670万の証明書チェーンが登録されていますが、そのうちプレ証明書として登録されているもの(=Chromeで公開監査ありと表示されるもの)は16万枚分しかありません。

プレ証明書の発行枚数推移

Google pilotログサーバーへのエントリの登録自体は2013年3月26日から、既存の証明書(パス)について登録が開始されていますが、CT導入以降のプレ証明書発行枚数推移をグラフで見てみましょう。

最初のプレ証明書がGoogle pilotのCTログサーバーに登録されたのが、2013年11月で、プレ証明書というかSCT対応の証明書発行をサービスとして正式にサポートし始めたのは2014年12月頃であることがわかります。

CTの対応が早かったのはどこの認証局(ブランド)か

2015年9月時点で、96の中間認証局(サブCA)、30のブランドがプレ証明書を発行しています。 プレ証明書の発行が早かった30のブランドの順序、発行日は以下のようになっていました。

認証局ブランド	初プレ証明書発行日
DigiCert	2013年11月01日
COMODO	2014年01月23日
TAIWAN-CA	2014年05月09日
Entrust	2014年07月21日
AffirmTrust	2014年10月27日
Symantec	2014年11月11日
GlobalSign	2014年11月28日
GeoTrust	2014年12月08日
Thawte	2014年12月08日
Buypass	2014年12月10日
Network Solutions	2014年12月15日
USERTRUST	2014年12月16日
Trend Micro	2014年12月22日
Starfield	2014年12月23日
Go Daddy	2014年12月23日
TERENA	2014年12月29日
Trustwave	2015年01月05日
Cybertrust	2015年01月07日
VeriSign	2015年01月12日
QuoVadis	2015年01月14日
HydrantID	2015年01月22日
Google UK	2015年01月27日
Aetna	2015年01月29日
IZENPE	2015年02月04日
Certum	2015年02月05日
Camerfirma	2015年02月20日
NCC	2015年03月30日
SECOM Trust	2015年04月30日
Actalis	2015年05月18日
WoSign	2015年08月20日

CTの仕様策定や実装などでGoogleと協力関係にあったDigiCertが対応が早いのはいいとして、台湾のTAIWAN-CA(TWCA)が対応早かったんですねぇ。日本のベンダーさんも頑張っています。

プレ証明書の発行枚数順位

次にプレ証明書の発行枚数で見てみましょう。大手が多いのは当たり前として、 Cybertrustさん頑張っている感がありますね。 そういえば、StartSSLはどうなってるんでしょうか。 10枚程度以下のところは、まだテスト中って感じですかね。

認証局ブランド	プレ証明書発行枚数
Symantec	50760
DigiCert	20856
GeoTrust	17447
COMODO	14573
Cybertrust	13020
Go Daddy	12635
Thawte	9891
Entrust	6616
GlobalSign	6063
TERENA	2363
QuoVadis	1873
Google UK	1861
Starfield	1262
Network Solutions	939
Trend Micro	615
Certum	367
VeriSign	196
WoSign	187
Trustwave	177
SECOM Trust	161
Buypass	154
IZENPE	116
TAIWAN-CA	76
HydrantID	37
Aetna	34
NCC	25
AffirmTrust	10
Actalis	7
USERTRUST	7
Camerfirma	4

どんなツールをつくったか

調べるにあたっては、PerlやNode(+jsrsasign)などで幾つかツールを作ったりぼちぼち環境を整備しています。公開してもいいんですけど、ドキュメント整備したり、コマンドラインオプションなどちゃんと作り込まないと、「ドキュメントがないから使いもんになんね〜〜！！」とか怒られて非常にヘコむんすよね。オープンソースなんだから、ちょっとコードみてくれりゃいいし、テストコード見りゃそのまま使い方ズバリなので、、、と思うんすけどね〜〜〜。(jsrsasignの愚痴っぽくてすみません。)

ざっくりこんなツールを作ってみています。(他にもいろいろありますが、今回に関係する分だけ。)

• プレ証明書とその解析情報だけを集めたSQLiteデータベース
• ログエントリのleaf_input保存ツール
• ログエントリのextra_data保存ツール
• ログエントリからプレ証明書のチェーンを取り出して証明書として保管するツール
• leaf_inputのデータファイルの解析ツール
• プレ証明書のTBSCertificateからニセ署名をつけて適当な証明書に仕立てるツール (TBSCertificateビューアーって一般的に無いのでこれができると 普通の証明書ビューアー(openssl x509コマンドなど)が使えるのでとても便利。)
• ログエントリの登録日を表示するツール

おわりに

今回は、ログデータベースを調べてわかった、統計的な話を中心にレポートしました。次回はデータ構造、プレ証明書の内容なんかを中心に書けるといいなと思ってます。ではでは。

2015年9月19日(土)に「Symantec caught issuing rogue Google.com certificates」 という記事が飛び込んできて、認証局、証明書、SSL関係のインシデントだと わくわくして飛びつくわけですが、ざっと読んでみると

大手セキュリティベンダーのSymantecの子会社で低価な証明書の発行サービスをやっている Thawteが、2015年9月14日にgoogle.com、www.google.com用のEV SSL証明書を、Googleに了解なく 不正に発行していたことが、証明書の公開監査記録(Certificate Transparency)によりわかった。

という事のようです。厳格な審査で発行されるEV証明書でこのような問題が起きちゃうのは マズイですね〜。Twitterではこのように言っている人もいて、

Alex Stamos@alexstamos

Big win for certificate transparency, which Symantec ironically resisted. Bravo @agl__ @BenLaurie and crew https://t.co/S0ytRkGxLe

2015/09/20 07:29:41

「Certificate Transparencyがあったおかげだね。よかったね。」みたいな雰囲気になっており、最悪だなぁと思っているわけです。 今日はシルバーウィークで暇ですし、そのあたりの事を書いてみようと思います。

Certificate Transparencyとは

Certificate Transparency(以下 CT)とは、Googleの中の人が考えた仕組みで、 全ての認証局から発行された過去から現在のSSLサーバー証明書(と証明書チェーン)を全て、 ログサーバーと言われるサーバーに記録して公開し、 不正な証明書の発行を世界中のみんなで早く見つけてましょうという仕組みです。 一部の証明書発行サービスではもう対応が始まっており、 「透かし入り証明書」などと言っている会社さんもありますが、 「証明書発行の透明性」と言った方が意味を正しく伝えられると思います。

登録のためのプロトコル、保管されるデータフォーマット、仕組みは実験RFCにもなっており、ログサーバーやウェブブラウザや認証局の実装の実績が十分できたからという理由でスタンダードトラックに移す計画もされています。

CTに関しては、この1年ほど詳しく見ていて、様々な問題がある事からCTの利用について否定的な意見を持っていて、勉強会などでも数回お話させていただいています。

関係者からのコメントを見てみる

今回の事件について、Googleのセキュリティ＆プライバシーとCT担当するプロジェクトマネージャーがブログで「Improved Digital Certificate Security」という記事を9月18日に発表しており、

• 9月14日19:20 GMT頃、Symantecの子会社ThawteのCAが google.comとwww.google.com用のプレ証明書(pre-certificate)を発行した。
• このプレ証明書の発行は、Googleが要求したものではなく、Thawteが勝手に発行したもの。
• Googleは、CTログからこの不正発行を発見した。
• GoogleとThawte(Symantec)の情報交換により、Thawteの内部テスト目的の発行だとわかった。
• GoogleはChromeに掲載される失効情報に使用された公開鍵を登録し無効化した。
• 現時点ではリスクは無い。

としています。これに対し、Thawte(Symantec)の関係者は同9月18日に 「A Tough Day as Leaders」というブログを公開しており、

• 3つのドメインに対して数枚のテスト証明書を、内部で不適切に発行してしまった。
• これらの鍵はThawteの管理下にあり、問題が発見されてからすぐに証明書を失効させた。
• 現時点ではインターネット上でいかなる危険もない。
• 当該のドメインのオーナーには報告した。
• 運用上のミス(human error)であったが再発防止に努める。

としています。この記事では「(我々は)セキュリティ業界のリーダーだから(云々)」という 表現が何度もあって、コメント欄に「ちっともリーダーとしての対応じゃないじゃん」みたいな 事が書かれていますが、その通りで、かなり無責任な報告だし、 これで終わりにしてはならないと思います。報告は以下の点で不満が残ります。

• いつ、不正証明書が発行され、問題が発覚し、Google等と協議し、 証明書を失効させ、ブラウザの証明書ブラックリストに記載したか、時系列が明らかでない。
• 発行対象のドメインが明らかでない。google.com、www.google.comと一つは何か。
• 何のテストであったのか、テスト目的も明らかでない。
• なぜ、テスト環境でやらなかったのか明らかでない。本来、本番環境でテストすべきでないのに。
• なぜ、example.com等テスト用のドメインでやらなかったのか。 特に、google.comは国家レベルでの盗聴に使われ問題になっているのに。
• Thawte EV用認証局の運用規程違反である可能性が高いが、言及がない。
• EV証明書を発行する認証局の監査基準である、 WebTrust for CA - EV監査基準と照らしてどうだったのか。

Thawteはこれまでにも幾つかの問題を起こしており、 業界から「退場」頂いたほうがいいんじゃないかな、とも思ってしまいます。

さてさて、じゃぁCT覗いてみますか

先に、「プレ証明書」について簡単に説明しておきましょう。 勉強会スライドのこのページをみるといいんですが、CTに証明書の発行ログが記録された証明書を発行するために以下の手順で発行されます。

1. 認証局は発行予定の証明書のデータ(TBSCertificate)からプレ証明書を作ってログサーバーに送る。
2. ログサーバーでプレ証明書をログ登録し、登録の証拠としてSigned Certificate Timestamp(SCT)という署名データを認証局に送り返す。
3. 認証局は、ログサーバーに登録された証拠であるSCTを証明書拡張領域に含め、証明書を発行する。

プレ証明書は、ログサーバーに登録される情報で、「認証局が証明書を発行しようとした証拠」としてログサーバーから公開されるものです。

Googleからの発表によると、プレ証明書が発行されたのは9月14日19:20 GMT頃だそうなので、 CTログサーバーにアクセスしてその時間あたりのログエントリをかき集めます。 CTのデータ構造やらアクセスAPIが全くイケてなくて、SSLサーバー証明書の発行対象 ドメイン名や認証局から検索することは全くできず、とりあえず取り出してから調べてみないと いけないんですよ。全く、検索させる気あるんですかねぇ？誰がこんな酷いAPI作ったんですかねぇ？

最悪なことには、ログサーバーのデータのミラーを会社に置いてきてしまい、 家のMacでは、なぜか自作のPerlのツール群も動かないし(CPANモジュールが入らない)、 Rubyのツールもなぜか動かず(新しいバージョンだと動かない)、 仕方ないのでNodeでちゃちゃっとツール作り直す始末、、、orz

とりあえず、Googleのpilotログサーバーに対して、9月14日の19:10〜19:30頃の間の ログエントリを取り出そうかとするわけですが、時間指定でエントリを取り出すことも できないので、まず、適当なインデックスのエントリを取り出して、時間のあたりをつけ 登録時刻のタイムスタンプを調べ19:10のおおよそのインデックスの値を調べます。 Nodeで指定インデックスの時刻を調べるツールを作り、 9213980が19:09:03、9214310が19:31:22だとわかりました。その間のエントリ数は、 330個なんで、かなり絞れました。

その330個のログエントリを取り出して、X.509のちゃんとした証明書は除いて、 プレ証明書だけをファイルに落とすツールを作り、19個のファイルを見ていくと、 19:20:01に発行されたインデックス9214148のものがgoogle.com用の プレ証明書そうだとわかりました。

なんでこんなに手間かっていうと、なんか、これらのプレ証明書用のログエントリが、 RFCで規定されているデータ構造と違うっぽくって、昔自分で作ったツールではパーズできない データ構造になっちゃってるんですよね〜〜〜〜。多分、登録側がRFC違反しているのでは と思うんですが、、、

次にプレ証明書を見てみます

目的のログエントリが見つかったので、プレ証明書を取り出して中身を見てみましょう。 でも、データ見たらプレ証明書のASN.1構造じゃなくて、単に発行予定のTBSCertificateなんですよね。 プレ証明書用の拡張も無いし、、、なんでだろ。RFC違反じゃないのかなぁ。 TBSCertificateの中身はこんな感じ。

シリアル番号：0A B4 C7 3C 41 3A 01 94 9F 23 78 F2 B2 29 F6 6C
署名アルゴリズム：SHA256withRSA
発行者名：CN=thawte EV SSL CA - G3, O=thawte, Inc., CN=US
有効期間：2015年9月14日 00:00:00 UTC〜2015年9月15日23:59:59 UTC
主体者名：CN=google.com, L=Mountain view, ST=California, CN=US, SN=2158113, 
　　　　　businessCategory=Private Organization,
　　　　　organizationName=Symantec Corp, 
　　　　　jurisdictionOfIncorporationSP=Delaware, 
　　　　　jurisdictionOfIncorporationC=US
拡張領域：
　主体者別名：www.google.com, google.com
　基本制約：空
　鍵使用目的：digitalSignature, keyEncipherment
　CRLDP：http://ti.symcb.com/ti.crl
　証明書ポリシ：
　　OID：Thawte EV policy (2 16 840 1 113733 1 7 48 1)
　　CPS：https://www.thawte.com/cps
　　UNotice：https://www.thawte.com/repository
　拡張鍵使用目的：serverAuth, clientAuth
　発行者鍵識別子：F07051DAD32A914F5277D78677740FCE711A6C22
　AIA：
　　OCSP：http://ti.symcd.com
　　caIssuers：http://ti.symcb.com/ti.crt

いや〜〜、もろシマンテックが主体者になってるgoogle.comのEVSSL証明書になっちゃってますね〜〜。そりゃマズイですよね〜〜〜。Thawteが勝手にSymantec主体者の証明書を発行しちゃっているのもマズイですよね。有効期間は1日とか言ってたけど、丸二日ですよね〜〜。

おわりに

結局は、Thawteのオペミスというか大失態で、本番環境で「神経がピリピリしてる最もマズイドメイン」の証明書を発行しちゃったってことなんですが、まともな認証局ソフトウェアを使っていれば内部の監査ログにも残るし、外に漏れなきゃ内部テストで済んでるんですが、認証局がしっかりしていれば、こんなことはあり得ないはずなんですよね〜〜〜〜。CTの運用だっていい加減だし、技術的にも完全性を持たない仕組みだし、プライバシーの問題もあるし、CT自体にもいろいろ問題があるのに、そんなことは全く注目されずに、「CTあってよかった。」みたいな論調になってて、つけいるスキを与えてしまいホント残念だな、と。他の証明書発行サービスというか認証ベンダーはThawteに対して怒っていいし、CA Browser Forumも、SSL Browser Forumみたいな実態になってるので全く当てにならないし、CA Security Councilあたりが厳しく問題にあたらないとマズイと思うんですけど、証明書発行サービスの及び腰には、ガッカリしてます。

追記1 (2015.09.21 20:05)

発行されているCRLを確認したところ、前述の google.com 不正証明書は、2015年9月16日 17:53:55 UTCに失効されていることがわかりました。どうせ有効期限切れなので失効させることもないと思いますけどね。

追記 (2015.10.01 20:00)

ログサーバーのプレ証明書の全ログエントリの解析用システムを作っていたので、報告遅くなりました。 Symantecの報告には

We learned on Wednesday that a small number of test certificates were inappropriately issued internally this week for three domains during product testing.

「3つのドメイン」とあったので、当該の証明書 www.google.comとgoogle.com以外にどこかもう一つあるのでは？と思い、プレ証明書のログエントリを全件調査し、また、当該の証明書が発行された時期を注意深く確認したところ、thawteから発行されたプレ証明書で、他に怪しいものはありませんでした。考えられる事として、

• 主体者識別名(DN)のCNのwww.google.com
• 主体者別名(subjectAltName)拡張のwww.google.com
• 主体者別名(subjectAltName)拡張のgoogle.com

を3つとして数えていて、結局は www.google.com、google.comの2つだけだったという事なんですかね。まぁ、良かったのかもしれません。

追記 (2015.11.01 23:59)

10月2日(or 10月13日)、Symantecが今回のインシデントに関して最終報告書を公開しました。
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3b.pdf
レポートには大したことは書かれていないように見えます。

これに対してGoogleがブログに投稿しています。
Sustaining Digital Certificate Security (2015/10/28)
https://googleonlinesecurity.blogspot.jp/2015/10/sustaining-digital-certificate-security.html

GoogleのCertificate Transparency (解説 [1] [2] [3]) のログデータベースはパブリックなHTTPSサイトに関する証明書のログデータベースなので、いろんな情報が取得できます。2015年3月27日時点で、6,949,166枚のSSLサーバー証明書に関する情報が格納されており、毎日1万枚以上増え続けています。これだけの枚数ですから、ここ数年有効な全世界のSSLサーバー証明書は網羅されているとして良いのかなと思います。以前紹介したgo.jpドメインのHTTPSサイトの調査もこの公開データをもとに調査しました。

本当は講演資料つくらないとマジでヤバイ感じなんですが、現実逃避して、ちょっと訳あってDSAやECDSA公開鍵のSSLサーバー証明書の利用、発行状況について調べてみたのでご報告を。そもそもはDSA公開鍵のSSLサーバー証明書を使っているDSSの暗号スイートなんて本当に使える公開サイトなんかあんのかって話を知りたかったわけです。

ほとんどの証明書はRSA公開鍵のSSLサーバー証明書であり、SSL Pulseの調査結果を見てもECDSAの証明書など割合からしてちょびっとな状況なわけですが、ログデータベースで見てみるとこんな感じです。(以下、2015年3月27日時点)

証明書	枚数	比率(%)
登録サーバー証明書(ログエントリ)の枚数	6,949,166枚	100%
うちECDSA公開鍵のSSLサーバー証明書の枚数	398,841枚	5.3%
うちDSA公開鍵のSSLサーバー証明書の枚数	100枚	0.0014%

念のため補足しとくと、DSA公開鍵のSSLサーバー証明書とはSubjectPublicKeyInfoフィールドにDSA公開鍵が格納された証明書の事を意味し、これを発行する認証局の鍵のアルゴリズムはRSAでもDSAでもECC(ECDSA)でも何でも構いません。SSLサーバー証明書のSubjectPublicKeyInfoのアルゴリズムにより、SSL/TLSで通信した場合の暗号スイートの認証や鍵交換が決まり、DSA公開鍵の場合にはDSSの暗号スイートが使用されます。ECC(ECDSA)証明書についても同じような感じです。

DSA公開鍵のSSLサーバー証明書

100枚の証明書のうち、さらに実際に接続してみて現在も利用可能なサイトを調べてみました。

証明書	枚数	比率(%)
登録サーバー証明書(ログエントリ)の枚数	6,949,166枚	100%
うちDSA公開鍵のSSLサーバー証明書の枚数	100枚	0.0014%
うち接続可能なDSA公開鍵のSSLサーバー証明書のサイト	11	0.00016%
うちシマンテック以外のDSA公開鍵のSSLサーバー証明書のサイト	3	0.00004%

いや〜、たった11サイトでしたよ。そのうち8サイトはドメイン名から シマンテックさんのテストサイトであることは明らかなので、一般のサイトは たった3つでした。DSA証明書を発行しているブランドは、 シマンテックさん以外は、Thawte、cacert.org、ips CAだけでした。 クライアントもサーバーもDSA公開鍵SSLサーバー証明書を使った DSS暗号スイートを使う可能性は殆ど無いと考えてよいんじゃないですかね。

ちなみに、Firefox 36、Chrome 41 でこのDSA証明書のサイトへアクセスしてみると、以下のように表示され、暗号スイートとしてそもそもサポートしていなかったり、信頼するルートに入っていなかったりで接続できません。OpenSSLのs_clientコマンドで接続するしかないわけです。

ECDSA公開鍵のSSLサーバー証明書

ECDSA証明書については5%とそれなりに数はあるわけですが、 ちょっとドメインのリスト見てみると殆どcloudflaressl.comドメインばっかりなんですよ。

証明書	枚数	比率(%)
ECDSA公開鍵のSSLサーバー証明書の枚数	398,841枚	100%
うちcloudflaressl.comのECDSA公開鍵のSSLサーバー証明書の枚数	398,262枚	99.85%
うちcloudflaressl.com以外のECDSA公開鍵のSSLサーバー証明書の枚数	569枚	0.15%

誰かが、「全世界で数パーセントもECDSA証明書が使われてて純増していて、ECDSA証明書は段々流行りつつあるんですよ」なんて教えてくれた人がいたような気もするんですが、cloudflare以外では全世界でたった569枚しか売れてないんじゃないですか！！！ECDSA証明書はcloudflareさんが支えてたんですねぇ。しみじみ。

あ、そうそうGoogleでは*.google.comとかECCの公開鍵のSSLサーバー証明書を使っていてSSL/TLSで接続するとECDHE_ECDSAの暗号スイートになるんですが、その証明書の発行する認証局の鍵はRSAでSHA1withRSAで署名してるんですよね。「ChromeでSHA2移行をせかせる割には、お前はSHA1なんかいっっつ！！」みたいな。

おわりに

というわけで、全世界でどれくらいDSA証明書、ECDSA証明書が使われているのかを見てみました。結構興味深い事実もわかって個人的にはよかったかなと思います。オレはまだ本気出してないだけ。明日から講演資料作成頑張りまっすorz Certificate Transparencyについてはいろいろ深く突っ込んで調査しており、どこかで吐き出したいんですが、雑務に追われなかなかチャンスが無いなぁ。

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安定版についてはクリスマスシーズンを挟むので 時期が未定なのだと思います。

a2c - Google Code

a2c is an ASN.1 compiler. It reads one or more ASN.1 syntax files (often called ASN.1 modules) and emits a C program that embodies that syntax. a2c is useful to programmers who are writing C programs that will read and/or write data that is expressed in an ASN.1 format, such as PKIX certificates and CMS (S/MIME) messages.

署名ポリシ等を読み込ませようとASN.1モジュールを食わせてみるも、見事に失敗、、、、どもうシンタックスが比較的新しいものにしか対応していないようだ、、、、

特に

ANY DEFINED BY

が新しいASN.1モジュールでどう表現されているのか、ちゃんと理解していないために躓いている。早速挫折モード、、、、、、、

そもそも、多くで参照されているrfc3280.asnがダウンロードできないし、、、、、

a2c - Google Code

a2c is an ASN.1 compiler. It reads one or more ASN.1 syntax files (often called ASN.1 modules) and emits a C program that embodies that syntax. a2c is useful to programmers who are writing C programs that will read and/or write data that is expressed in an ASN.1 format, such as PKIX certificates and CMS (S/MIME) messages.

IETFのS/MIMEとPKIXのWGのMLに大御所Paul Hoffmanさんがポストしていたんですが、GoogleにASN.1シンタックスからCのコードを生成するコンパイラがあるそうです。まともなASN.1コンパイラが欲しいと思っていたんですが、これはかなり期待できそう、、、、BSDライセンスというのも有り難い、、、、

X.509証明書とかはまぁ、問題ないんですがRFC 3125ASN.1署名ポリシやCAdES長期署名フォーマットの属性なんか、あやしい実装により生成されたファイルで問題究明したいときにシンタックスチェッカがあると、原因特定できるので非常にありがたいです。

時間があるとき、ちょっと遊んでみよう。

昨晩は飲みに行ったのにブログ用の写真を撮るのを忘れてしまった、、、、、博多とり鍋結構おいしかったのに、、、、、さらには、ぐるなびクーポン使うの忘れてるし、、、、orz

グーグル版セカンドライフ「Lively」、開始わずか4ヶ月で閉鎖が決定 - Technobahn

【Technobahn 2008/11/20 18:14】グーグルは19日、3次元仮想世界「Lively（ライブリー）」のサービスを年内で終了することを発表した。ライブリーは今年の7月にサービスが開始されたものとなるため、サービス開始からわずか4ヶ月で閉鎖が決定したこととなる。

トホホ、、、はやすぎ、、、、、アンインストールしちゃっていいってことですよね、、、、

My love letters (livedoor Blog life) : Google 検索を、サイドバーに付ける方法（ブログパーツのように） - livedoor Blog（ブログ）


livedoor Blogの標準の検索機能があまりにもショッパイようで、あまり古い記事だと全くヒットしなくなっちゃうってことに気づきました。ネットで調べてみるとMy love lettersさんのところのブログで記事のGoogle検索のプラグインの作り方が書いてあったので早速入れてみました、、、、、

はひ〜〜〜、ちゃんと検索できている。すばらしい、、、、ありがとうございます。

そのままだとGoogleのロゴが煩わしいのと文字化けしてしまうのでちょっと変更しています。(oe="utf-8"にしないといけないみたい、、、、)

US-CERT Vulnerability Note VU#612636

US-CERTからGoogle Apps用のSAMLシングルサインオンの脆弱性に関するレポートが出ています。