自堕落な技術者の日記

SSL Pulse の 2015年4月版が公開されましたね。いつもは2ヶ月に1回状況報告しようとしていたんですが、SHA1証明書からSHA2証明書への移行が気になってたので、証明書の鍵や署名アルゴリズムの移行状況だけグラフにしてみました。SHA1証明書が51%、SHA2証明書が48%とかなり近づいています。

同じように推移したとすると、2015年5月にはSHA1証明書の数がSHA256証明書の数を追い越しそうですね。

関連記事

• SSL Pulseの統計情報で見るSSL/TLS (2015年5月版) (2015.05.11)
• (小ネタ)来月にはSHA2証明書の枚数がSHA1を追い越しそうな件 (2015.04.11)
• SSL Pulseの統計情報で見るSSL/TLS (2015年3月版) (2015.03.17)
• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

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

証明書ハンターであり、CipherSuiteウォッチャーの@kjurです。

ChromeのWindows、Macの新しい安定版版 31 が昨日、11月13日にリリースされたので 早速CipherSuiteを見てみました。

これがアップデート前のChrome 30

Chrome 30.0.1599.101 on Windows 7 SP1
Client Hello Version: TLS 1.0
TLS Version: TLS 1.2
Num Cipher Suites: 20
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

これがアップデート後のChrome 31

Chrome 31.0.1650.48 on Windows 7 SP1
Client Hello Version: TLS 1.0
TLS Version: TLS 1.2
Num Cipher Suites: 18
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

CipherSuiteの数が20から18に減っています。

特徴的なところは

• 30から31になってGCMでないSHA2は全て削除された
• 30までGCMには対応していなかった
31になったAES GCM SHA2が新たに追加された
• ちょっと順序も入れ替わっていてAES GCM SHA2が優先になっている

といったとこでしょうか。

これからOWASP Nightです。今日はこの辺で

NISTのSHA-3 HASHコンペのメーリングリストでJeff JohnsonさんがSHA-3候補のハッシュアルゴリズムとRSA署名アルゴリズムのオブジェクト識別子(OID)をテンポラリでもいいから割り当ててという発言がありました。

同じような事を考えてくれる人がいてよかったですが、テンポラリはいただけない。混乱するだけだから、、、、、候補になった奴は正式にNISTでOID振っちゃっていいんじゃないですかね？

大御所Paul Hoffmanさんは、「評価も終わってないのに使うつもり？」みたいな話をしていますが、コンペで一等賞になろうがなるまいが一部のアルゴリズムは使う人（国）が出てくるでしょうから、多分お金のかからないNIST内の決め事だけの話だと思うので先に割り当てといていいのではと思います。

例えばRound1候補に "1.3.14.3.2.777.1" から "1.3.14.3.2.777.51" 割り当てて
その中の一つ "1.3.14.3.2.777.7" が優勝して他を殆ど捨てることになっても大した問題じゃない気がするんですが、どうですかね、、、、、「13」は嫌だ、とか、後になってこのOIDにしたせいで不具合が多いんじゃないかという都市伝説が生まれるとかそういうのはあるのかな？

実際に署名やMACなどハッシュアプリケーションとして使ってみないとわからない問題も出てくるんじゃないかと、、、、、

kurushima @ 自堕落な技術者のヰキ(公開版) - Hash/次世代SHA3ハッシュアルゴリズム

Engineering comparison of SHA-3 candidates / SHA3参加アルゴリズムの比較調査
http://www.skein-hash.info/sha3-engineering
Classification of the SHA-3 Candidates / SHA3参加アルゴリズム比較の論文
http://www.uni-weimar.de/cms/fileadmin/medien/medsicherheit/Research/SHA3/Classification_of_the_SHA-3_Candidates.pdf

SHA-3コンペまとめサイトでETSI ESI副議長のErnstさんに教わったリンクを追加しときました、、、、

クロックサイクルで少ない時間で速い方が良いみたいな話になっているようですが、、、少ない時間で処理できるほど、その分衝突が見つけやすくなったってことにならないんですかね？？？（素人ですみません、、、）

PDFとかも最新版ではパスワードによる暗号化機能でAESを使うようになって、前よりも解くスピードが速くなっちゃったからPDF password reminderみたいなブルートフォースによるパスワード解析ソフトでも（何も手を加えていないのに）従来手法のままで解析スピードが格段にアップしちゃったらしいですよね、、、、、

NIST.gov - Computer Security Division - Computer Security Resource Center

The new hash algorithm will be called “SHA-3” and will augment the hash algorithms currently specified in FIPS 180-2, Secure Hash Standard. Entries for the competition must be received by October 31, 2008.

NISTではSHA2の次のハッシュアルゴリズム SHA3の公募とコンペティションを行い、2010年Q2には最良のアルゴリズムを選定します。

まとめは別館のほうで行っていこうと思います。IAIKのまとめページSHA3 Zooによると34のアルゴリズムが参加し、セキュリティでは有名なBruce SchneierやRon Rivestなどのチームも参加するようです。

ハッシュ関数の一番重要なアプリケーションは署名だと思うんですが、これらのハッシュ関数を署名で使う場合にはハッシュアルゴリズムのオブジェクト識別子(OID)およびこれらを用いた署名アルゴリズムのOIDを規定しないと利用することができません。

コンペの開催と同時にとりあえずOIDの割り当てをしてしまい、すぐに署名に使えるようにして欲しいなぁ、、、と思っています。最優秀が決まってから１〜２年かけてOID決めましょうなんていうんじゃ話にならないと思いません？ただの決め事なので、、、、

間近に迫る「暗号の2010年問題」、企業が取るべき対応は？−RSAセキュリティ

現在主流のいくつかの暗号も、近い将来、安全性を担保するだけの強度が足りなくなってしまうといわれている。そうした状況を受け、2010年に米国連邦政府が次世代暗号方式への移行を決定。その波紋が各業界へ伝わったことで生じた問題が、暗号の2010年問題である。

さすが、RSAさんは頑張っています。エライ！セキュリティの専門家なんだからこうした活動をもっとベンダーが積極的にやらないといけないと思います。本当はもっと早く大々的にやってもらえたらな、、、とも思います。

出回っている根幹となる暗号ライブラリは基本的に既に対応できていると思うのですが、ミドルウェアだったり、証明書だったり、一部のOS、ブラウザやオフィススイートなどよく使われるアプリケーション(この前のマクロのコード署名もそうですね、、、)が進まないと利用者としてはどうしようも無いし、選べないという感はあります、、、、

古いOSなんかもありますし、SHA2への移行が叫ばれている現在MD2とか使われていたり、仕様上RSA512しか使えないようになっていたりね、、、、なかなか難しい、、、、（　´∀｀）つ

IETF S/MIME WGで、CMS署名にSHA2アルゴリズムを使うInternet DraftのWG Last Callがかかっています。2008年10月20日までです。

当たり前のように既に使われているOIDを使えるようにしただけのなので、特にコメントは無いと思いますが、一応、、、、

＃DSA, ECDSAのテストをしてみたい、、、