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にリプレースしなければならないという事だそうです。
これに関して注目すべきポイントは以下の2つかと思います。
- 中間CA証明書やルート証明書のSHA1については言及していない。
- 2016年1月1日と、2017年1月1日という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年9月26日版まで |
Chrome 40の 2014年11月9日版まで |
Chrome 41の 2015年Q1版まで |
2016年12月31日まで | 2017年1月1日以降 | |
|---|---|---|---|---|---|
| 有効期限が2016年5月31日までのSHA1証明書 | |||||
| 有効期限が2016年6月1日から12月31日までのSHA1証明書 | |||||
| 有効期限が2017年1月1日以降のSHA1証明書 | |||||
| Windowsの場合(Chrome同等の表示として) |
今回の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移行を進める必要があったのではないでしょうか。
- 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日のアップデートでは、影響を受けるサイトが出始めます。充分な猶予期間、準備期間を持てるように例えば半年や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移行について、どのように対処するのが良いか解説しています。いつも冷静な分析をされる人ですが、今回に関し批評が無いのは寂しい。
おわりに
Google Chromeは良いブラウザだと思うし、便利だし、大好きなんですが、CRLSetの問題と、今回のSHA1対応の件はちょっとヒドイなぁと思います。サイトの運営者の方は、最初のマイルストーンの9月26日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。