自堕落な技術者の日記

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についてはいろいろ深く突っ込んで調査しており、どこかで吐き出したいんですが、雑務に追われなかなかチャンスが無いなぁ。