自堕落な技術者の日記 : SHA256 - livedoor Blog（ブログ）

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日までとアナウンスをしています。

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日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。

本ブログの関連記事

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

タグ：: #Windows; #SHA256; #SHA2; #Microsoft; #Google; #Chrome; #SHA1; #SSL; #サーバー証明書; #証明書

どこかのブログか記事でWindows Server 2003はSHA256withRSA等、SHA2シリーズの証明書に対応しているという記事を見て、Windows Server 2003は対応済であると勘違いしていたんですが、昨日、ちょっと試してみてWindows Server 2003 SP1 Standard Editionでは、どうやら対応していないっぽいんです。

SHA256withRSA 2048bitのルート証明書をインポートしようとして表示させてみたんですが、ここで説明したような、Windows XP SP2のときと同じ「証明書は壊れているか、変更されている可能性があります。」というメッセージが表示されます。

また、Windows Server 2003でSP2とかR2とかで対応するようになったという記事も探してみたんですが、見つけることができませんでした。結局Windows Server 2003ではどのような方法を使ってもSHA256withRSA証明書には対応させることはできず、SPなども出ておらず、Windows Server 2008を使いなさいということのようです、、、、残念、

今回の調査にあたって、証明書関連のツールを少し整備しました。Challenge PKI Test Suite(CPKITS)やOpenSSL、AiCrypto、IAIK、BouncyCastle、Entrust Toolkit、または完全自前、等様々なツールで証明書データを作り出すツールを場合によって使い分けていたんですが、現状どれも一長一短というところで、使いやすさでは、CPKITSがとても心地よいのですが、基本はAiCryptoを使っているためにSHA2には対応していません。

そこで、今回用意したツールはSHA1withRSAの証明書やCRLと署名用の鍵を利用して、元の証明書やCRLの構造をそのままに、単にAlgorithmIdentifierをSHA256 or SHA512withRSA等に置き換え、署名値を置き換えるJythonのスクリプトです。

CPKITSがDNや拡張などかなり柔軟な証明書生成に対応しており、これをアルゴリズムと署名値だけ置き換えて、SHA256withRSA、SHA512withRSAの証明書のテストができるようにするためのツールです。

タグ：: #windows; #Server; #2003; #SHA256; #SHA256withRSA

自堕落な技術者の日記

SHA256

(小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件

関連記事

ChromeのSHA1証明書のアラート表示ポリシの問題点