自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

サーバー証明書

SSL Pulseの統計情報でみるSSL/TLSの引越しについて

2014年11月頃から、SSLに関する統計情報を公開しているサイトSSL Pulseのデータから推移情報をブログで公開してきました。隔月で更新するようなことを言ってて、2015年12月から更新が無い状態になっており、「コラ〜〜!サボってんじゃね〜〜」的なことを思われたかたもいらっしゃるかもしれません。すみません。すみません。すみません。

新しいサイト

SSL Pulse Trends(SSL Pulseデータの推移) https://kjur.github.io/www/sslpulsetrend/index_j.htmlというサイトを作りました。今後の毎月の更新はこちらでやっていきます。

サイトを移行した経緯など、、、

前は、エクセルなど駆使してグラフ描いてたんですが、そりゃもう、結構手間がかってたんですよ。自分も興味があって毎月すぐ知りたいんだけど、とても、毎月はできないなと、、、ざっくりとした流れはこんな感じ:

  • 今月のデータファイル(JSON)をwgetでダウンロードする
  • データの推移をTSV形式になるように変換するツールを実行する。グラフに必要なデータ列もこの時作る。
  • TSVファイルをUTF-16にする(Mac Excel対策)
  • Excelで読み込み
  • データを細かい整形(日付フォーマットや表ヘッダなど)
  • 必要なグラフを作る
  • グラフをEMF(拡張メタファイル)でエクスポートする
  • PowerPointに吹き出し等を貼り付け(位置調整)
  • PowerPointの画面を画像キャプチャし、ブログへ
まず、第一の鬼門なんですが、自分は自宅ではMac Book Airを使ってまして、Mac用のExcel(前の2011も今のやつも)は、文字化けしないようにCSVやTSVファイルを読み込むのが骨が折れるんですよ。一応ファイルの入力候補としては普通のUTF-8でも大丈夫そうに見えるんだけど、うまくいかず。結局うまくいったのはメモ帳アプリでUTF-16に変換してから読み込ませるという方法です。Googleとかで"Mac Excel TSV 文字化け"みたいなキーワードで検索すれば、方法が出てくるでしょう。
07

そして、一つ一つグラフを作っていくわけです。
01
で、Excelのグラフの凡例ではちょっと見づらいのでパワポで吹き出しをつけます。
39
どうです?結構面倒くさそうでしょう?

で、新しいサイトでは

とにかくExcelでグラフをつくるのはやめにしたく、JavaScriptベースでグラフを描けないもんかと、調べてみました。最初は、ccchartなんかがデザインも良いかなぁと考えていたんですが、思っていたデザインにするのは、至難の技であると知り、D3.jsという有名なライブラリも見たんですが、一つのフツーのグラフ書くのに多くのコードを書かねばならず断念。D3.jsを簡単に使うためのラッパーがあるそうで、それを幾つか見て、rickshawで何とか許せるグラフが描けたのでそれを使うことにしました。

本当は、SSL Pulseに置いてあるJSON形式のデータファイルをそのまま、表示の度に取り込んで加工してからグラフ表示しようとしたんですが、諸々CORSの壁に阻まれ断念。動的にダウンロードする必要もなくなり、スタティックな解析データをNodeで作って、SOURCEタグで普通にデータ取り込むことになりました。

ブログでたまたまSSL Pulseについて書くだけなら、特別な断りをいれなくてもいいかと思ったんですが、定常的に今後は英語でもページを公開するとなると、SSL Pulseの作者のIvan Ristićさんに仁義というか確認取っといたほうがいいかなと思いました。IvanさんはSSL/TLSの技術解説書の中では最高に良いと思うBulletproof SSL and TLSの著者であり、SSLの設定評価サイトであるssllabsの開発などもしています。

Bulletproof SSL and TLS
Ivan Ristic
Lightning Source Inc
2014-08

最初は、TwitterのDMで連絡取ろうとしたんですが、当然ながら私のフォローして頂いてるわけではないのでDMが送れず、メールアドレスもどこにも記載されていなので、連絡がつきませんでした。そこで、いつもJavaScriptの暗号/PKIライブラリでは情報交換などさせて頂き大変お世話になっているRyan Hurstさんに頼み込み、連絡とってくれないかと伝えました。Ryanさんは「Kenjiを紹介するよ。彼は、すげーJavaScriptの暗号/JWT/X.509ライブラリの作者だ。」と私からのお願い事項のメールを転送してくれました。2日ぐらい待ってて、「う〜〜ん」こりゃレス無しかなぁとも思ってたんですが、返事が来まして「SSL Labsは自由なコンテンツライセンスになってて、君の場合でも全く問題ないとわかると思うよ。同じようなこと(=データ推移情報)をやりたいと思ってたんだけど、時間がなくてね〜〜。」との事でした。よかった、よかった。これで安心して定常的に公開できそうです。

Rickshawの使い方は概ねこんな感じです。

<div id="chart_container"><div id="grade_chart"></div></div> <script> var graph = new Rickshaw.Graph({ element: グラフを描くキャンバスが挿入されるDIVのDOM, width: グラフ幅, height: グラフ高, renderer: グラフ形式(棒グラフとか折れ線グラフとか), series: [{"color": グラフデータ色, "name": データ名(TLS1.2とかSHA256withRSAとかデータ名), "data": [{x: 値, y: 値}, {x: 値, y: 値} ...]}, : (複数のデータがあれば続く) ] }); graph.render(); </script>
同じ形式のグラフ描くのに、同じようなコード書くのも面倒なので、さらにラッパーを作りました。
RickshawUtilGraph(グラフ描くDOM IDの共通ヘッド(グラフや凡例、XY軸など), グラフの共通テンプレート, データ(グラフデータ、データ名) [,オプションでグラフ形式を変えたい場合のパラメータ] [,オプションでグラフ色変えたい場合のパラメータ]);
これでようやく、SSL Pulseの更新があっても、make 一発でグラフデータを作れるので、毎月の更新も負担にならなくなりました。

というわけで、まだ素っ気ないページですが日本語ページ公開にこぎつけました。今までなかった評価グレード(A-F)の分布推移のグラフはNPNのHTTP/2サポートプロトコルの推移のグラフも付け加わっています。
42
しばらくしたら英語ページの作成にとりかかりたいと思います。

今後とも、よろしくお願いします。

関連記事

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

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

関連記事

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

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のステータス表示は以下のようになっているようです。

表示内容
chrome_stat_1ok EV証明書でない正常なHTTPS接続の場合
chrome_stat_2yellow secure, but with minor errors
例えばHTTPSとHTTPのコンテンツの混在の場合などに出る。
chrome_stat_3white neutral, lacking security
平文のHTTPなど、セキュリティが無い中立の状態。
chrome_stat_4red affirmatively insecure
危険だと断言できる場合。
(参考) EV SSLサーバー証明書で正常にHTTPS接続できている場合
chrome_stat_5ev

Google Chromeは証明書チェーンがSHA1かどうかチェック

WindowsのSHA1移行ポリシーはエンドエンティ証明書、すなわちSSLサーバー証明書がSHA1かどうかだけをチェックしており、中間CA証明書がSHA1かどうかは関係無かったのですが、Google Chromeの移行ポリシーは、全ての中間CA証明書もチェックするので注意しなければなりません。
path1

で、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証明書 chrome_stat_1ok chrome_stat_1ok chrome_stat_1ok chrome_stat_1ok chrome_stat_4red
有効期限が2016年6月1日から12月31日までのSHA1証明書 chrome_stat_1ok chrome_stat_1ok chrome_stat_2yellow chrome_stat_2yellow chrome_stat_4red
有効期限が2017年1月1日以降のSHA1証明書 chrome_stat_1ok chrome_stat_2yellow chrome_stat_3white chrome_stat_4red chrome_stat_4red
Windowsの場合(Chrome同等の表示として) chrome_stat_1ok chrome_stat_1ok chrome_stat_1ok chrome_stat_1ok chrome_stat_4red
表を見ていただければわかる通り、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ステータス表示にすべきではないでしょうか。
    notafterdiff
  • 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には、問題があるかのような黄色表示 chrome_stat_2yellow になります。事前に知らされていれば、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日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。

本ブログの関連記事

関連リンク

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

GlobalSignのEV SSL証明書が2048bitに

米国機関が要請:グローバルサイン、EV SSL証明書を2048ビットに対応 - ITmedia エンタープライズ
GMOグローバルサインは12月26日、同社のEV SSL証明書が米政府機関「NIST」の定める暗号鍵長の2048ビットへの移行に対応したと発表した。

 NISTは、政府調達に関する共通鍵暗号や公開鍵暗号、ハッシュ関数の運用を見直し、コンピュータによる解読技術の進化などを考慮して2010年末までに2048ビットの暗号鍵長へ移行するよう求めている。日本では移行期間の期限を2013年としている。

 同社では、ルート証明書や中間証明書、加入者証明書の発行システムを2048ビットの暗号鍵長に対応させ、2010年12月31日以降も有効なEV SSL証明書は2048ビット対応で発行するという。


だそうです、、、、メモメモ、、、、

米国国立標準技術研究所(NIST)が要請したから「やりました」、、、っていうのがスゴイ話ですね。

ルートのMD5からの移行が先決なのではとも思いますが、どうなんでしょうか、、、、(^^;
最新記事
Categories
Archives
Twitter
記事Google検索

本ブログ内をGoogle検索
Yahoo!アクセス解析
Travel Advisor
記事検索
QRコード
QRコード
  • ライブドアブログ