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に掲載される失効情報に使用された公開鍵を登録し無効化した。
- 現時点ではリスクは無い。
- 3つのドメインに対して数枚のテスト証明書を、内部で不適切に発行してしまった。
- これらの鍵はThawteの管理下にあり、問題が発見されてからすぐに証明書を失効させた。
- 現時点ではインターネット上でいかなる危険もない。
- 当該のドメインのオーナーには報告した。
- 運用上のミス(human error)であったが再発防止に努める。
- いつ、不正証明書が発行され、問題が発覚し、Google等と協議し、 証明書を失効させ、ブラウザの証明書ブラックリストに記載したか、時系列が明らかでない。
- 発行対象のドメインが明らかでない。google.com、www.google.comと一つは何か。
- 何のテストであったのか、テスト目的も明らかでない。
- なぜ、テスト環境でやらなかったのか明らかでない。本来、本番環境でテストすべきでないのに。
- なぜ、example.com等テスト用のドメインでやらなかったのか。 特に、google.comは国家レベルでの盗聴に使われ問題になっているのに。
- Thawte EV用認証局の運用規程違反である可能性が高いが、言及がない。
- EV証明書を発行する認証局の監査基準である、 WebTrust for CA - EV監査基準と照らしてどうだったのか。
さてさて、じゃぁCT覗いてみますか
先に、「プレ証明書」について簡単に説明しておきましょう。 勉強会スライドのこのページをみるといいんですが、CTに証明書の発行ログが記録された証明書を発行するために以下の手順で発行されます。
- 認証局は発行予定の証明書のデータ(TBSCertificate)からプレ証明書を作ってログサーバーに送る。
- ログサーバーでプレ証明書をログ登録し、登録の証拠としてSigned Certificate Timestamp(SCT)という署名データを認証局に送り返す。
- 認証局は、ログサーバーに登録された証拠である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の中身はこんな感じ。
いや〜〜、もろシマンテックが主体者になってるgoogle.comのEVSSL証明書になっちゃってますね〜〜。そりゃマズイですよね〜〜〜。Thawteが勝手にSymantec主体者の証明書を発行しちゃっているのもマズイですよね。有効期間は1日とか言ってたけど、丸二日ですよね〜〜。シリアル番号：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
おわりに
結局は、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
追記 (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
