自堕落な技術者の日記

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

RC4

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
しばらくしたら英語ページの作成にとりかかりたいと思います。

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

関連記事

SSL Pulseの統計情報で見るSSL/TLS (2015年12月版)

いやぁ、年の瀬ですねぇ。最近、SSL/TLS関連の調査に全く時間が取れてないっす。 SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 10月に引き続き2015年12月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。 今月は、なかなかデータ公開が早かったっぽいですが、気づくのに遅れました。

脆弱性対応の推移


201512-a1vuln

SSL/TLSプロトコルの推移


201512-a2proto

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


201512-a3crt

新しい技術のサポートの推移


201512-a4adv
SPDYが下がっています。HTTP/2への移行が始まっています。実はSSL PulseでHTTP/2の対応状況も4ヶ月前あたりから取れるようになっているので、そろそろ可視化したいと思っています。

鍵交換の最低鍵長


201512-a5kx

DH(E)鍵交換の最低鍵長


201512-a6dh
DH鍵交換のサポート率は、ほぼ横ばいであるのに対して、

ECDH鍵交換の最低鍵長


201512-a7ecdh
ECDH(E)への対応は進んでいることがわかります。

おわりに

年末進行で、そんなに呑みに行っている気もしませんが、なんか仕事が山積みですorz コメント少なめですみません。今月はこの辺で。

関連記事

SSL Pulseの統計情報で見るSSL/TLS (2015年10月版)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 8月に引き続き2015年10月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。 今月は、なかなかデータ公開してくれなくて、確か10月19日頃ようやくアップデートされたようです。新しい項目増えているわけでもないのに、なんででしょうね。

脆弱性対応の推移


201510vuln
RC4の利用可能率が順調に継続して下がっており、今月では53%のサイトしか使えなくなりました。 また、ECDHEやDHEの鍵交換をサポートするPFSに対応したサイトは71.5%にまで上がっており、かなりのサーバーで使えるようになってきました。

SSL/TLSプロトコルの推移


201510proto
POODLEの影響でSSLv3が使えるサイトが32.5%にまで下がっています。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


201510crt
Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、今月も順調にSHA2移行が進んでおりSHA1withRSAが24.1%、SHA256withRSAが74.9%まで進んでいます。あと残り1/4になりましたね〜〜〜。

新しい技術のサポートの推移


201510adv
HSTSも、OCSP Staplingも、EVも徐々に上がっていますが、全く大したことない。

鍵交換の最低鍵長


201510kx
鍵交換の鍵長は順調に、512bit、1024bitの利用をやめ、2048bit相当に移行が進んでいるようですが、、、

DH(E)鍵交換の最低鍵長


201510dh
DH鍵交換をサポートしないサイトが48.2%もあり、暗号強度が十分でないDH1024bitも減ってはいるものの、28.9%もあり、いろんな意見はあるでしょうが、DH(E)は使わずにECDH(E)を使うのが良いのではと思います。

ECDH鍵交換の最低鍵長


201510ecdh
ECDH/ECDHEが使えていないサイトが34.2%にまで減り、ECC 256bitを使えるサイトが61.9%にまで増えています。かなり普及してきたという感があり、「何も考えずにとりあえずECDHE使えるようにしとけ!」と思います。

おわりに

講演資料2本作らないとマジでやばす。今日はこの辺で。

関連記事

SSL Pulseの統計情報で見るSSL/TLS (2015年8月版)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 6月に引き続き今月も8月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。

脆弱性対応の推移


201508-vuln
RC4の利用可能率が順調に下がっているなど、おおむね順調な感じがしますね。つまらん。

SSL/TLSプロトコルの推移


201508-ssl
POODLEの影響でSSLv3の無効化が35.0%まで順調に下がっています。これもつまらん。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


201508-crt
Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、今月も順調にSHA2移行が進んでおりSHA1withRSAが31.9%、SHA256withRSAが67.2%まで進んでいます。

新しい技術のサポートの推移


201508-new
う〜む、これもつまらん。

鍵交換の最低鍵長


201508-kx
鍵交換の鍵長は順調に、512bit、1024bitの利用をやめ、2048bit相当に移行が進んでいます。

DH鍵交換の最低鍵長


201508-dh
暗号強度の十分でないDH1024bit、512bitの利用は順調に減り、2048bitは増えていますが、そうはいっても大した率でなく、やはりDH/DHEは使わないのが良いと思います。

ECDH鍵交換の最低鍵長


201508-ecdh
ECDH/ECDHEが使えていないサイトが順調に減り、使えるサイトが増えており、ECC 256bitのECDH/ECDHEが使えるサイトが58.5%まで増えています。

おわりに

今週は、セキュリティ・キャンプ全国大会に来ているので、あっさり風味で。

関連記事

SSL Pulseの統計情報で見るSSL/TLS (2015年6月版)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 5月に引き続き6月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。 本当は隔月にしようと思ってたんですが、Logjamの影響が見たかったので今月はやってしまいました。 (ウソ、今月はやらなくて良い月だったのに忘れててグラフを作ってしまっただけですorz )

脆弱性対応の推移


201506vuln

SSL/TLSプロトコルの推移


201506proto
POODLEの影響でSSLv3の無効化が順調に下がっており、サポートするサイトは37.6%までに減りました。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


201506crt
Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、SHA1とSHA2証明書の比率が5月に逆転しましたが、順調にSHA2移行が進み、SHA2が60%、SHA1が40%まできていることがわかります。

新しい技術のサポートの推移


201506adv
OCSP stapling対応率は伸びかかったのにまた戻ってしまいました。

鍵交換の最低鍵長


201506kx
鍵交換の情報が3月から取れるようになり、ようやく傾向がつかめるようになってきています。

DH鍵交換の最低鍵長


201506dh
弱い輸出グレードのDH(E)鍵のダウングレードによるLogjam脆弱性が5月に公表されたことで、全体的にDH鍵交換の鍵長が増えていますが、とは言っても2、3%の変化しかなく、 やはりDH鍵交換の鍵長を増やすよう設定するよりも、DH鍵交換は使わず、ECDH系の鍵交換を使うのが良いように思います。

Logjam脆弱性の発見者の一人であるMatthew Green先生のブログによると、この攻撃を成功させるには中間者がハンドシェイク中の十分短い時間でDH鍵の解読をしなければならないそうですが、ある鍵パラメーターについて事前計算をしておけばこれは可能であり、512bitなら一般的な環境でも数十秒で解くことは可能であり、1024bitの場合、一般的な環境では無理かもしれないがNSAのような諜報機関であれば、その予算と比較して全く不可能という値でもないということです。怖いですね〜〜〜。

ECDH鍵交換の最低鍵長


201506ecdh
ECDH系の鍵交換を使えるサイトと、使えないサイトの比率が5月に逆転しましたが、ECC 256bitの利用が順調に進んでいていることがわかります。

おわりに

来週月曜はJNSAの勉強会なので、早く資料作らんといかんなぁ。しかし、おぎゃ〜さんは、ものすごい集客力だなぁ。

関連記事

SSL Pulseの統計情報で見るSSL/TLS (2015年5月版)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 3月に引き続き5月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。 隔月で見ていけたらと思っています(^^;

脆弱性対応の推移


201505vuln

SSL/TLSプロトコルの推移


201505proto
POODLEの影響でSSLv3の無効化が順調に下がっており、サポートするサイトは40%までに減りました。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


201505cert
Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、SHA1とSHA2証明書の比率が逆転しました。今月のグラフで最も特徴的な事かと思います。

新しい技術のサポートの推移


201505adv
OCSP stapling対応率は順調に伸びていますが。大したことはありません。

鍵交換の最低鍵長


201505kx
鍵交換の情報が3月から取れるようになり、ようやく傾向がつかめるようになってきています。

DH鍵交換の最低鍵長


201505dh
DH鍵交換に対応するサイトはわずかながら増えていますが、2048bitだけでなく、安全でないとされる1024bitも増えていること、またそれ以上に安全でない512bitが使われていることは非常に問題です。このような傾向からも、DH鍵交換の鍵長を増やすよう設定するよりも、DH鍵交換は使わず、ECDH系の鍵交換を使うのが良いように思います。

先日ブログに書いたTLSの実装と導入上の推奨をまとめたRFC 7525の4.4節にもDH鍵交換の課題が整理されており、RFC 7525では「使うな」とは言っていませんが、これを読むとDH系の鍵交換は使うべきではないように思います。

ECDH鍵交換の最低鍵長


201505ecdh
ECDH系の鍵交換を使えるサイトと、使えないサイトの比率が逆転し、ECDH系の鍵交換への対応が半数を超えてきました。ECDH系鍵交換を使えない比率の減り方がDHに比べて顕著です。

おわりに

なんか今週末はブログラッシュっすね。メッセージ入りSSLサーバー証明書の件が書けなかったなぁ。今日はこの辺で。

関連記事

「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項」の公開

2015年5月7日に「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項(Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS))」が公開されました。

昨年あたり、SSL/TLSで使われる暗号アルゴリズム、プロトコルや実装にいろいろな問題が見つかり、製品をそのままデフォルトで使っているとロクなことが無いわけですが、どんなことに注意しながら実装や設定をしなければならないかをベストカレントプラクティス(現時点での最良の慣行)としてまとめたRFCだそうです。

最近、SSL/TLSの設定ネタでお話しする機会を頂いたりしておりますが [1] [2] 、RFC 7525をざっと見たところ、概ね違ったことは言ってないようにおもいます。今日は、RFC 7525について、ちょっと見てみたところを書いていきたいと思います。

RFC 7525の目的

RFC 7525の目的は、仕様から以下の2つなのかなと思います。

  • 最低限満たすべき推奨事項を示す。
  • TLS 1.3が普及するまでのつなぎで対応しておくべき事を示す。

RFC 7525のポイント

各節から拾ってきたRFC 7525のポイントをまとめると以下のようになります。

  • 3.1.1節 TLSプロトコル
    • POODLE等の対策として、SSLv2、SSLv3の利用禁止(MUST NOT)
    • CBCモード対策としてTLS 1.0の利用抑制(SHOULD NOT)
    • TLS 1.2の実装必須(MUST)
    • TLS 1.2、TLS 1.1、TLS 1.0の順で優先(MUST)
  • 3.1.2節 DTLSプロトコル
    • DTLS 1.0の利用抑制(SHOULD NOT)
    • DTLS 1.2の実装必須(MUST)
    • DTLS 1.2、DTLS 1.0の順で優先(MUST)
  • プロトコルその他
    • 3.1.3節 TLS 1.x からSSLv2、SSLv3のフォールバック禁止(MUST NOT)
    • 3.2節 HSTS(HTTP Strict Transport Security)ヘッダのサポート必須(MUST)
    • 3.3節 CRIME攻撃等の回避のためTLS圧縮を利用抑止(SHOULD)
    • 3.4節 セッション再開でセッションチケットの通信における認証と暗号化は必須(MUST)
    • 3.5節 TLS再ネゴシエーションが必要な場合、renegotiation_info拡張のサポート必須(MUST)
    • 3.6節 Server Name Indication(SNI)のサポート必須(MUST)
    • 4.5節 Truncated HMAC TLS拡張の利用禁止(MUST NOT)
    • 6.5節 証明書失効検証では、OCSP、status_request・status_request_v2 TLS拡張、OCSP stapling拡張を利用すべき(SHOULD)
  • 4節 暗号スイートの推奨
    • NULL暗号スイートでの接続禁止(MUST NOT)
    • RC4暗号スイートでの接続禁止(MUST NOT)
    • EXPORT等、112ビット未満の暗号スイートでの接続禁止(MUST NOT)
    • 128ビット未満の暗号スイートでの接続抑止(SHOULD NOT)
    • TLS_RSA_WITH_*の接続抑制(SHOULD NOT)
    • DHE、ECDHEなどPFSをサポートする暗号スイートの優先接続のサポート(MUST)
    • TLS_{DHE,ECDHE}_RSA_WITH_AES_{128,256}_GCM_SHA{256,384}を推奨(RECOMMENDED)
  • 4.3節 公開鍵長
    • DHE鍵交換の場合、DH鍵長は2048bit以上を推奨(RECOMMENDED)
    • ECDH鍵の場合、192bit未満の曲線は利用抑止(SHOULD NOT)
  • 4.3節 証明書
    • RSA場合、鍵長2048bit以上の証明書を推奨(RECOMMENDED)
    • 証明書の署名はSHA-256の利用を推奨(RECOMMENDED)

RFC 7525を見て気になった点

気になった点や感想的なものをまとめてみます。

  • 最小限の推奨事項といいながら、MUST、SHOULDに従ったとするとかなり厳格な要件で、これに対応できるのは最新のウェブブラウザ、ウェブサーバーのみであり、ちょっと前の組み込み機器、SSLアクセラレーターなどは、これらの要件を満たすことは不可能かなと思います。
  • やはり、最新のソフトウェアのみで対応すればよい環境と、後方互換性を必要とする環境とで区別して推奨事項を述べるのがよいのではと思います。
  • RSA鍵交換を抑制(SHOULD)する一方で、SEED、IDEA、Camelliaなど言及されないアルゴリズムも多く、これらの扱う際に混乱します。
  • PFSやRC4を強調しすぎで、CBCモードは軽視されている。
  • 鍵長の話はもう少しシンプルに纏められたのではと思う。文章が整理されておらずわかりにい。
  • アプリケーションプロトコル(HTTP, SMTP, IMAP, IRC, XMPP等)の言及はあまり役立たない。
  • 証明書要件はRECOMMENDEDと、かなり緩め。

RFC 7525の良かった点

一方、このRFC 7525の良かった点はこんなとこかなと、、、

  • 何を根拠(Rationale)としてそのような設定を要求するのかが明らかになっており良い。
  • 実装(implementation)と展開(deployment)を分けて書いてあるのはよい。
  • Opportunistic Securityについて、単なるフォールバックよりも危険が懸念されることを明確にし、RFC 7525の対象外としたのは良い。
  • 証明書失効の課題が整理されたのは良い。
  • 特に、プロプライエタリな失効検証がスケールしない点を指摘したのは良い。

おわりに

RFC 7525はベストカレントプラクティスと言いながら、少しトガった要求事項になっていて、最新の環境だけでしか動かない感じです。InternetWeekでお話をした時から、状況もいろいろ変わっていて、現時点での暗号スイート設定のおすすめは、近々書きたいと思っています。あと、メジャーなサーバーでの設定ファイルを作るウェブツールなども作ってしまいたいと思ってるんですが、なかなか先に進まない。

来週の情報セキュリティExpoでは、IPAさんのブースで私も委員として作成に携わらせて頂いた「SSL/TLS暗号設定ガイドライン」の説明もあったりするそうです。このガイドは主にサーバー管理者向けに幾つかのケースに分けてセキュリティ要件を定めて設定例を示したもので、RFC 7525 よりは、より具体的にどうすればよいかがわかるようになっています。最後の委員会が終わったあとも、リクエストがあったので追加原稿はいろいろ出させて頂いたんですが、どうも最終的に、特に暗号スイートの設定について、思った通りのものにはならなかったですね。いろんな意味で後悔しています。

今日はこの辺で

SSL Pulseの統計情報で見るSSL/TLS (2015年3月版)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 1月に引き続き3月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。

SSL Pulseのデータの追加

2015年3月より、以下のデータを追加で観測するようになりました。

  • POODLE攻撃の緩和策としてGoogleからインターネットドラフトが出され、 Google Chrome、OpenSSLの最新版などでは対応している TLS_FALLBACK_SCSVのサポート状況
  • 通信障害等によるOCSPレスポンダへのアクセス不能により、失効した証明書のサイトにつながってしまったり、認証局が利用者のサイト訪問記録を取得しないように導入されたOCSP staplingのサポート状況
  • 鍵交換の際の最低鍵長(DC、ECDHに分けた値もあるが円グラフ表示はされてない)

脆弱性対応の推移


01vuln1
今月からPOODLE攻撃を緩和する「TLS_FALLBACK_SCSVをサポートしていない率」の情報が追加されています。45%近いサイトが対応しているようです。

SSL/TLSプロトコルの推移


02proto
POODLEの影響でSSLv3の無効化が順調に下がっていますが、下がり方が鈍化しているようです。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


03key
Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、順調にSHA1からSHA2証明書への移行が進んでいていて、SHA2が42%、SHA1が57%ともう少しでクロスしそうな所まで来ています。

新しい技術のサポートの推移


04func
今月からOCSP staplingのサポート状況がグラフに記載されるようになりました。20%のサイトがOCSP staplingに対応しているようです。意外と多いなという印象です。

鍵交換の最低鍵長


05keyex
SSL Pulseで鍵交換の最低鍵長が今月から表示されるようになりました。 証明書はRSA 2048bit以上の証明書になっているので、 グラフ中の2048bitはRSAで鍵交換しているケース、 1024bitおよび512bitはDH(Diffie-Hellman)かDHEで鍵交換しているケース、 であると言えます。NISTの暗号アルゴリズム移行のガイドラインによれば、 鍵長1024bit以下のRSA、DH、DSAなどの共通鍵暗号は使ってはならないことになっており、 DH、DHEを使った暗号スイートが使えるサイトはかなりあり、 あえてDH、DHEを使うのは安全ではないことはよくわかります。 サーバー側で止めたり充分な鍵長となる設定をしていないので、 クライアント側で配慮するしかないのでは?という気がしています。 特に、PFS(Perfect Forward Secrecy)のために、DH、DHEを使おうとする 傾向がありますが、そのような場合にはECDH、ECDHEを選択するべきだと思います。

DH鍵交換の最低鍵長


06dh
このグラフを見ても明らかな事に、DH、DHEでは十分な安全性を持たない鍵長1024bitか512bitがほとんどであることがわかります。 怖いですね〜〜。このグラフはSSL Pulseのサイトでは見られない値になっています(つまり、データだけある)。

ECDH鍵交換の最低鍵長


07ecdh
ECDH、ECDHEが使える場合にはほとんどが鍵長256bit(RSA 3076bit相当)になっており、 一般に安心して利用できることがわかります。 go.jpドメインの調査でも 紹介したように571bitのECC鍵が少し使われていることも驚きます。256bit未満だと224bit、163bitがごくわずかに使われており、192bitが無いということも意外でした。 このグラフも、SSL Pulseのサイトでは見られない値になっています(つまり、データだけある)。

おわりに

以上、今月のSSL Pulseのデータからいろんな推移を見てみました。 今日はこの辺で。

関連記事

go.jpドメインのHTTPSサイトの状況について私もみてみました(2015年3月4日時点)

慶応義塾大学とレピダムさんで共同調査された「日本政府機関Webサイト(.go.jp)のTLS対応状況について(2015.03.04)」を大変興味深く拝見し、もうちょっと知りたいことも多々あったので、私も調べてみるかなぁと思い、今日はそのご報告を、と。

調査対象

.go.jpドメインのサイトには省庁、外局、独立行政法人、政府系のイベントで作られたサイトなどがあり、そのうちパブリックなサイトのSSLサーバー証明書の枚数は2015年3月4日時点で累計1,819枚のようでした。そのうち、ユニークなコモンネーム(FQDNもしくはワイルドーカード証明書のドメイン)の数は877ありました。
gojp-01
省庁、それらの外局、それらが所管する独立行政法人の数で分類すると以下のような構成になっています。(実はこの表を作るのが一番大変だった。証明書はあるからFQDNはすぐに集まるんだけども、FQDNの独法や局や委員会なんかがどこの省庁が所管しているのかとか、イベントサイトはどこで管理されているかなどをGoogle先生やブラウザで開いたりなんかして、ちまちま調べるわけです。いや〜、独法っていっぱいあるんすねorz)
gojp-02
独立行政法人を除いたものの比率は以下のようになっていました。これには最高裁判所、内閣官房、会計検査院、国会図書館なども含まれています。
gojp-03

ワイルドカード証明書を使っている場合には、そのワイルドカード証明書を使っている任意の1つのサイトが見つかれば、そのサイトを調査対象としました。

イベントで一時的に立ち上がってたサイトや停止したサーバーなどがあり、インターネットからアクセス可能なgo.jpドメインのHTTPSサイトは882中、722であり、 今回は722のgo.jpドメインサイトを調査対象としました。

SSL/TLSプロトコル

まず最初に、go.jpドメインのサイトのSSL/TLSプロトコルのサポート状況を見てみたいと思います。ダウングレード攻撃やPOODLE攻撃で問題となるSSLv2、SSLv3をサポートしているサイトがかなりあることがわかります。まず最初に、全ての*.go.jpドメイン、つまり省庁と独法を合わせた接続可能な722サイトに対して、対応プロトコルをグラフにしました。
gojpa-1
独法を除いた場合、333サイトが接続可能で、同様に対応プロトコルをグラフにしました。
gojpa-2
ダウングレード攻撃で脆弱なSSLv2はかなり少ないですが、POODLE攻撃で脆弱とされるSSLv3が使えるサイトは未だに3、4割のサイトで利用可能になっていることがわかります。

暗号スイート(共通鍵暗号)

次に、暗号スイート(CipherSuite)のうち、使用可能な共通鍵暗号アルゴリズムについて見ていきましょう。最初に全*.go.jpドメインに対してです。
gojpa-3
独法を除いた場合のグラフは以下の通りです。
gojpa-4
どちらもAESはほとんどのサイトで利用できるようになっており、弱い暗号である3DESやRC4も8、9割のサイトで利用できるようになっています。また、国産の暗号であるCamelliaも2割程度のサイトで使えますが、SEEDやIDEAも同程度しかないというのは少し残念ですね。

ブロック暗号モードについては、GCMとCBCしかありませんが、全*.go.jpでのサポート状況は以下の通りになります。
gojpa-5
また、独法を抜いた場合以下のようになります。
gojpa-6
ブロック暗号を一切サポートせず、ストリーム暗号の暗号スイート、つまりRC4しかサポートしないサイトは無かったため、全数は722、333で同じになっています。

暗号スイート(鍵交換)

次に、暗号スイートで使われている鍵交換についてみてみましょう。

まず最初に気になるのが、スノーデンの暴露したNSAの盗聴問題をきっかけに、PFS(Perfect Forward Secrecy)をサポートする暗号スイートを使うことを推奨されるようになりました。 具体的にはDH、DHE、ECDH、ECHDEのいずれかを鍵交換に使う暗号スイートが推奨されています。 PFS、DH、DHE、ECDH、ECDHEの*.go.jpドメインでのサポート状況は以下の通りです。
gojpa-7
独法を除いた場合、以下のようになります。
gojpa-8
DHEやDHは処理パフォーマンスが悪かったり、長い鍵長をサポートする実装が少ないので、ECDHやECDHEを使えるようにして欲しいですね。

DH、DHEの暗号スイートで不十分な鍵長の脆弱なサイトが無いか確認するために、DHの鍵長別にサポート状況をみてみましょう。まずは全*go.jpドメインで見てみます。
gojpb-01
独法を除いた場合、以下のようになります。
gojpb-02
RSA 1024bit以下の証明書が使えなくなったのと同様にDiffie-Hellman(DH) 1024bit以下による鍵交換をするべきではないそうです。ただ、DH 1024bit以下しかサポートしない実装が多かったり、デフォルトでDH 1024bitであったりすることから、リスク回避のためにDHやDHEを使わないようにするのが良いと思います。

ECDH、ECDHEでは鍵パラメータ(=曲線名)はどうなっているでしょうか。まずは、全*.go.jpドメインで見てみましょう。
gojpb-03
独法を除いた場合、以下のようになります。
gojpb-04
ECDH、ECDHEをサポートする場合に、鍵交換で使われる名前付き曲線がNIST P-256(=secp256r1)なのは一般的だし、ブラウザでサポートされている事が多いのでいいですが、NIST B-571(=sect571r1)って世の中で使ってるところを見た事がなかったのでビックリしました。省庁の1サイトと独法の9サイトは先進的というか、デフォルトでは設定されず、意図的にやってるに決まってるので凄いなぁと思いました。そこにブラウザで繋いでみたんですが、TLS_RSA_WITH_RC4_128_SHAで接続してしまい残念orz。

暗号スイート(メッセージ認証(MAC))

世の中では、メッセージ認証に関してはMD5はダメ、SHA1からSHA2に移行している過程にあるのかなと思います。まず、全*.go.jpドメインについて見てみましょう。
gojpb-05
独法を除いた場合、以下のようになります。
gojpb-06
脆弱なHmacMD5を使った暗号スイートが利用できるサイトが4割近く残っているのは問題かなと思います。

SSL/TLS攻撃に脆弱なサイト

BEAST攻撃、POODLE攻撃、FREAK攻撃など、SSL/TLSプロトコルや暗号スイートの設定による脆弱性の影響をみてみましょう。全*.go.jpドメインでのこれらの攻撃の影響は以下のようになっています。 (少しグラフにゴミが入ったけど、まぁ、いっか)
gojpb-07
独法を除いた場合、以下のようになります。
gojpb-08

その他のSSL/TLSサーバーの設定

SSL/TLSでは接続する際、デフォルトではクライアントが提示する暗号スイートのリストの優先順位に基づいて、サーバーと使用する暗号スイートがされますが、これだと酷いクライアントの場合、脆弱な暗号スイートが使用されてしまう可能性があります。これを防止するために、設定によりサーバー側の持つリストを優先して使うようにすることができます。これが「サーバー側暗号スイート優先」です。ApacheであればSSLHonorCipherOrder "on"で設定できます。

OCSP Staplingとは、TLSの拡張でプライバシー保護と証明書失効検証の誤りへの対策です。 まずは全*go.jpドメインで見てみましょう。
gojpb-09
独法を除いた場合、以下のようになります。
gojpb-10
OCSP Staplingの導入はなかなか進んでいない現状がよくわかります。ただ、先進的な設定をしている政府系サイトもあることがわかります。

SSLサーバー証明書

全*.go.jpドメインのアクティブなサイトのサーバー証明書の発行元の 証明書発行サービスで分類したのが以下です。
gojpb-11
独法を除いた場合、以下のようになります。
gojpb-12
やはりVeriSignの比率がかなり高く、GPKI Application CA、GlobalSign、Cybertrustなども頑張っています。特に独法を除いたには、GPKI Application CA 2の比率もかなり高いです。 珍しい所ではServision、KAGOYA、Firstserver、AlphaSSLなどを使っているところもありました。 822枚のうちワイルドカード証明書は19枚、EV SSL証明書は24枚でした。

次に接続可能な全*.go.jp 723ドメインにおける、証明書の公開鍵アルゴリズムと鍵長についてみてみましょう。全てがRSA鍵であって、ECC鍵やDSA鍵はありませんでした。また、鍵長は2048bitがほとんどで、ほんの少し1024bitが残っており、4098bitなどの長いものはありませんでした。
gojpc-01
また、723のRSA鍵について公開指数は全て65537(0x10001)でした。公開指数に3などが使われているために秘密鍵が入手できるといった問題があるサイトは0でした。
gojpc-02

署名アルゴリズムについてはSHA256withRSA、SHA1withRSA、MD5withRSAのいずれかしかなく、SHA256withRSAの移行が30%以上とChromeやWindowsのSHA1の無効化が2017年1月に迫っていることから、SHA1からSHA2への移行はかなり進んでいます。
gojpc-03

証明書の有効期間については、1年物、3年物、2年物の順に多く、10年物は1サイトのみでした。
gojpc-04

Google Chromeが2017年1月までにSHA1証明書に対して段階的に警告を出していき、SHA2証明書への移行を促すというマイルストーンがアナウンスされていますが、有効期限がどの時期であるかを調べてみました。
gojpc-05
有効期限が2017年1月を超える証明書が144サイトであり、Chromeでの警告表示を避けるためにSHA2証明書へのリプレースが必要になります。

また、証明書のOCSPによる失効検証、EV SSLサーバー証明書、Certificate Transparency(CT)のための組込みのSigned Certificate Timestamp(SCT)拡張のサポート状況について調べてみました。CTサポートが11サイトもあったのには、少し驚きました。
gojpc-06

おわりに

以上、*.go.jp ドメインのHTTPSサイトについて自分なりに調査してみました。SSL Pulseとの状況と比較して、以下のポイントで若干コンサバティブというか古い設定になっているなという感じはします。

  • GCMがあまり使われていない
  • ECDHEよりもDHEが使われる
  • EXP、DESなどの古い暗号スイートがかなり残っている
  • SSLv2などもかなり残っている感じがする
サーバーがきちんと対応してくれないなら、クライアント側で最新のブラウザを使うなどで自衛するしかないのかなと思います。

今日はこの辺で。

追記

  • 2015.03.11 08:34 - 3/4から3/11 0:00頃の更新を確認したらgo.jpドメインのHTTPSサイトは3つしか増えていないようです。そんなに頻繁に更新確認しなくてよさそうなので、ちょっと安心しました。現時点では証明書の調査項目が十分でないので、そのうち追加しておきたいと思います。
  • 2015.03.12 00:11 - *.go.jpドメインのSSLサーバー証明書について調べた事を追記しました。
  • 2015.03.12 07:55 - 証明書の調査でなぜ722から723に増えたかというと、HTTPS通信はできて証明書は取れるんだけど、対応暗号スイートを調べようとするとタイムアウトしちゃうサイトが一つあったため、こんなことになってます。

SSL Pulseの統計情報で見るSSL/TLS (2015年1月版)

前にもお話した通り、 SSL Pulse (https://www.trustworthyinternet.org/ssl-pulse/)サイトは、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 以前、2014年11月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましたが、 2ヶ月たってどうなったのか、また今月もグラフ化してみました。

脆弱性対応の推移


pulse201501-vuln2
BEAST対応(CBC対応?)を除いて、全体的に順調に良くなる方向にあります。 悪い状態が上、良い状態が下になるようにグラフを統一したので、見やすくなったかと思いますが、どうですかね。

SSL/TLSプロトコルの推移


pulse201501-proto

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


pulse201501-cert

新しい技術のサポートの推移


pulse201501-adv
このあたりは、どれも普及が10%未満のままだと、、、

関連記事

最新記事
Categories
Archives
Twitter
記事Google検索

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