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

TLS

2020年11月29日09:46

カテゴリ: SSLTLS; PKI

Mozilla FirefoxのCRLiteで遊ぶ (moz_crlite_queryの話)

OCSPによる失効検証は、先日のApple macOS Big Burrのソフトウェアコード署名の大量の検証で、OCSPレスポンダ高負荷による失効検証の障害が出たのではと推測されるように、通信障害、サーバー障害などでOCSP応答が取れないなどのことがあって、最近非常に評判が悪いです。そのため、ウェブブラウザの世界では、Chromeでは CRLSet、Firefox ではCRLiteという別の失効検証方法を使おうとしているそうです。ChromeのCRLSetについては2013年2月に、CRLSetで本当に大丈夫なんだろうかと思い「将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話」というブログエントリを書かせていただきました。(が、その後、Chrome CRLSetがどうなっているのかよくわかっていません。)

で、Firefox CRLiteについてですが、先日、「Querying CRLite for WebPKI Revocations」(2020.11.26)という記事が公開されました。Firefox Nightly バージョンで実装されているCRLite失効検証の機能を確認するためのPythonのツール moz_crlite_query が合わせて公開されています。Firefox Nightly 85.0 で実装されているということなので、2021年1月26日リリース予定のFirefox 85正式版ではCRLite失効検証が使われているということなのでしょう。(間違っていたらごめんなさい。) おお、FirefoxのCRLiteがいよいよ実運用されるんだなぁ、、、とwktkしながら、今日はこの moz_crlite_query を試してみたいと思います。

インストール

Python 3.7 以上の環境で


% pip install moz_crlite_query

とすればインストールすることができます。依存するPythonモジュールをビルドするのにgcc、g++が必要になるみたいです。

私のMac Book Airは古くから使っていてPython環境が汚れていて、OSで提供されるPython2.7、Python3?、macportsのPython2、Python3などあり、切り替えがうまくいかず、インストールでとてもハマりました。古いPython setuptoolsだと、2.7等、バージョンが古くてもインストールエラーにならないようで、これでハマりました。最初からpyenv使っときゃよかったんだよなぁ、、、。pyenvでPython 3.9を入れ直して、Windows 10 WSL2でインストールしたmoz_crlite_queryスクリプトをコピーし戻してやっと動くようになりました。pyenvでインストールしたときmoz_crlite_queryスクリプトはどこにインストールされるんだ？？？

Windows 10 WSL2のUbuntuに入れるのは、それほど大変ではありませんでした。aptコマンドで足りてなかった、gcc、g++、python3-devを入れてpipでインストールできました。

サイトで紹介されてる実行例は、いちいちPEM証明書ファイル持ってきてますが、「moz_crlite_query --hosts 調べたいTLSサイトFQDN」で調べられます。例えばMacでwww.nist.govを調べればこんな感じ、
crlite-mac
Windows WSLでec.europa.euを調べればこんな感じで実行できます。
crlite-win
(絵文字使うんじゃね～～！！！)
PEM証明書を指定して「moz_crlite_query PEM証明書ファイル」でも調べることができます。

で、ちょっと見てみるぞ、と

CRLiteのデータベースは一日に4回更新して配布されるそうで、moz_crlite_queryコマンドは、データベースを確認して新しいのがあれば~/.crlite_dbにデータベース一式をダウンロードして使用します。ファイルの一覧はこんな感じ。


2020-11-24T00:08:12+00:00Z-full		2020-11-26T18:08:13+00:00Z-diff
2020-11-24T06:08:12+00:00Z-diff		2020-11-27T00:08:16+00:00Z-diff
2020-11-24T12:08:14+00:00Z-diff		2020-11-27T06:08:13+00:00Z-diff
2020-11-24T18:08:15+00:00Z-diff		2020-11-27T12:08:20+00:00Z-diff
2020-11-25T00:08:23+00:00Z-diff		2020-11-27T18:08:11+00:00Z-diff
2020-11-25T06:08:05+00:00Z-diff		2020-11-28T00:08:14+00:00Z-diff
2020-11-25T12:08:22+00:00Z-diff		2020-11-28T06:08:12+00:00Z-diff
2020-11-25T18:08:11+00:00Z-diff		2020-11-28T12:08:12+00:00Z-diff
2020-11-26T00:08:11+00:00Z-diff		2020-11-28T18:08:21+00:00Z-diff
2020-11-26T06:08:17+00:00Z-diff		intermediates.sqlite
2020-11-26T12:08:14+00:00Z-diff

コマンドを実行すると表示されている通り、2457のパブリックな中間CAが登録されているようで、FAQでは「すべてのCA」とか言っちゃってますが、そういうわけではなさそう。エンドエンティティがSSLサーバー証明書を発行しているような中間CAは概ね登録されているようですが、SSLサーバー証明書発行用でないCAや、中間CA証明書の検証に使うCAは登録されていないようです。登録されてない中間CAに対してクエリをかけると「Enrolled in CRLite: ✕」のように表示され登録されてないことがわかります。(絵文字ヤメロw)

「intermediates.sqlite」が中間CAのSQLiteデータベースになっており、中にはテーブルは一つしかなく、こんな感じでスキーマ定義されています。なんとなく想像つきますね。


CREATE TABLE intermediates (
  id TEXT PRIMARY KEY,
  last_modified TEXT,
  subject TEXT,
  subjectDN BLOB,
  derHash BLOB,
  pubKeyHash BLOB,
  crlite_enrolled BOOLEAN, -- crlite_enrolled = FALSEな中間CAは1656なので、対応してるのは801 CA?
  whitelist BOOLEAN); -- whitelist = TRUEな中間CAは登録されてなかった

とまぁ、こんな感じなんですが、CRLSetのときに書いた疑問は払拭されず、本当に信用できるのかモヤモヤしますね～～～。なんかヤベーーーの見つけちゃった気もするし。ブラウザでどう使われているのか見ないと何ともいえないですが、、、、

今日はこんなとこで。環境も汚れてきたしバッテリーも酷い状況なのでM1 Mac Book Air買うかなぁ、、、

タグ：: #PKI; #Firefox; #SSL; #TLS; #CRL; #失効検証; #OCSP; #Chrome; #CRLite; #CRLSet

2017年08月11日04:43

カテゴリ: Chrome; SSL証明書

(小ネタ) Chrome 60で証明書を表示させるフラグ設定

Chrome 56からGoogleの「素人はすっこんでろ」UI/UXポリシーによりHTTPSで接続した際に使用しているSSLサーバー証明書の表示が鍵アイコンから簡単にできなくなってしまいました。証明書大好きっ子にはなんとも辛い仕打ちでした。開発ツールからは証明書が表示できるので、メニューを辿って操作するか、ショートカットキーを素振り100回していた方も多いのではと思います。

Windows: Ctrl + Shift + I or F12
Mac: ⌘ + Opt + I

今日は、やっとChrome 60からフラグ設定で証明書が簡単に表示できるようになったので、今日はその設定について紹介します。

何も設定していないと、HTTPSサイトを見ている際の、鍵アイコンをクリックして見られるメニューはこんな感じ。
before
そこで、アドレスバーで以下のように入力します。

chrome://flags/#show-cert-link

すると、このようなフラグ設定が表示されます。
flag

「有効にする」をクリックし、指示に従ってブラウザを再起動します。すると、HTTPSサイトを表示した場合このように
after

「証明書、有効」というリンクが表示されるようになり、クリックすると証明書が表示されるようになります。いや～～、よかった、よかった。

タグ：: #Chrome; #SSLサーバー証明書; #証明書; #SSL; #TLS; #HTTPS; #フラグ; #設定フラグ

2017年02月23日20:00

カテゴリ: SSL証明書; PKI

HPKP(HTTP Public Key Pinning)公開鍵ピニングについて考える

もくじ
1. はじめに
 2. HPKPが生まれた背景
 3. HPKPの仕組み
 4. ピンの設定の考察
　 4.1. ピンの値の取得方法
　 4.2. 証明書チェーンに一致するピンの選択
　 4.3. 証明書更新とHPKPヘッダの設定変更の運用方法
　 4.4. バックアップピンという名前のイケてなさ
　 4.5. CA鍵のバックアップピンのオススメの値
　 4.6. 証明書チェーン中で複数ピンをつけても意味はない
　 4.7. 同じCA証明書にPinし続ける場合の課題
　 4.8. 2つのCA証明書にPinする場合の課題
　 4.9. max-ageのオススメ値を考える
 5. HPKPはどの程度使われているのか
 6. 今のHPKPの何がいけなかったのか
 7. おわりに
 8. (参考) HPKP関連の勉強になるリンク
 9. 追記
　 9.1. 追記(2017.02.26) HPKPのブラウザサポート状況
　 9.2. 追記(2017.02.26) smashingmagazine.comで発生したHPKP障害

1. はじめに

HPKPとはHTTP Public Key Pinningの略で、RFC 7469 Public Key Pinning Extension for HTTPで規定されており、ウェブサイトのオーナーが、ニセのサイトで意図しない証明書チェーンが使われないように保護するための仕組みです。

日本語解説は少ないですが、敬愛する jovi0608さんの記事やJxckさんの記事などでも解説されています。

私も3年ちょい前、IPAのガイドを書いていた前あたりから、HPKPの運用上の課題について、何かブログ等で書きたいと思っていたのですが、なんか日頃のヘンなことに忙殺されて、これまでまとめて書くことができませんでした。(なんか書こうと思ってたらjoviさんのが出ちゃって、まぁいいかと思っちゃったっていうのもありますw) IPAのガイドの時も書かせてもらおうとしたんですが、なんだか大人の事情で追加させてもらうことができませんでした。とほほ。

今回は、HPKPとは何かといった基本的なことは、他の方のブログに譲るとして、HPKPの現状やHPKPの運用上の課題についてフォーカスして書きたいと思っています。長くなりそうですが、ごめんなさいね。

結論から言えば、本番サイトで安易にHPKPを使うのはやめた方がいいと考えています。それは、HPKPの仕様自体が運用をしっかり考えて設計されておらず、一般的なサイトでは大したセキュリティ上の効果が無い割に、長期の運用でサービスを提供できなくなる期間が発生するリスクが高すぎるし、証明書のコストも余計にかかるからです。

おそらく、HPKPの運用について深く突っ込んでかいた、世界では初めての解説資料かなと思います。ご笑納くださいw

2. HPKPが生まれた背景

2011年頃から、認証局を対象にしたサイバー攻撃や、認証局の運用上の不備などで、攻撃に利用しやすいGoogleやFacebookといった有名サイト向けのワイルドカード証明書(*.google.com等)を取得されてしまうという事件が増えてきました。Googleを怒らせちゃったのは2011年のオランダの認証局DigiNotarが不正侵入を受け、*.google.comのワイルドカード証明書を発行され、イランのプロバイダの盗聴や攻撃に使われたという事件がありました。
hpkp-digi
このような事件を防ぐためには、ウェブサイトに対して、サイトオーナーの意図しない証明書が使われた場合に、警告を発する仕組みが必要です。そこで開発されたのが、HPKPです。HPKPでは、証明書チェーンの証明書公開鍵のハッシュの一致を確認することにより、ウェブサイトオーナーの意図した証明書かどうか検証することができます。
hpkp-hpkp1
joviさんのブログの1章で背景と仕組みをわかりやすく解説されているので、そちらもご覧頂ければと思います。

3. HPKPの仕組み

HPKPの実装方法には2つの方法があります。

1) Google、Facebook、Twitterなどの有名サイト向けの、Chrome、Firefoxなどブラウザに組み込まれたピンのリスト(Preloaded Known Pinned Host List)と照合する方法
2) HTTPSで通信する際に、サーバーからピン情報のHTTPヘッダを取得し、それをブラウザに保管しておき、以降の通信で照合に使う方法

1) の方法は、ブラウザを最新になっているならば何も設定しなくても、有名なサイトについてはHPKPを使って安全に接続することができます。今回の記事で議論したいのは2)のサイトオーナーが設定する場合についてなので、2)の仕組みについて説明します。
hpkp-sethead

ウェブサーバーに不正な証明書チェーンに接続させないためのHPKP HTTPヘッダを設定するのですが、これはウェブサーバーのHTTPS設定で使用するルート証明書からSSLサーバー証明書までの証明書チェーンを元に設定します。HTTPヘッダとその値の書式は以下のようになっています。


Public-Key-Pins: \
　　pin-sha256="チェーン中の公開鍵のどれかのSHA256ハッシュ値のBase64"; \
　　pin-sha256="チェーン中の公開鍵のどれにも一致しないSHA256ハッシュ値のBase64"; \
　　[pin-sha256="その他ハッシュ値1"; ...; ] \
　　max-age=ブラウザにこのHPKPヘッダが保管される秒数; \
　　[includeSubDomain;] \　　　　サブドメイン(example.comならsub.example.com)もHPKPの対象にするか
　　[report-uri="JSON形式のエラーレポートがPOSTされるURL"; ]

[...]はオプション

pin-sha256は証明書チェーンを元に設定しますが、その設定方法や考察については後で述べます。
max-ageの保存期間はRFCの4.1節で考察しており60日(=5184000秒)が良いのでは？としていますが、その考察も後で述べさせて下さい。
includeSubDmainは、サブドメインまで含めるか、例えば example.com にHPKPを設定したら、sub1.example.comも、www1.sub2.example.comもHPKPの対象にするというフラグです。現時点で持っていないなら安易に設定しない方が良いように思います。
HPKPは、CSPなどと同様ににブラウザ側で検証するので、サーバー側にはエラー原因が把握できず困ることがあります。report-uriを使えば、ブラウザでHPKPのエラーが発生した際に、指定したURLのウェブサーバーにJSON形式のエラーレポートをPOSTすることで送信しますので、設定上の問題を知るのに役立つかもしれません。Jxckさんのブログで設定を試してみたという詳しい報告がされているのでご覧になると良いでしょう。ブログでも書かれていますが、レポートが出力される条件がよくわからず、ブラウザやバージョンにも依存するようで、私もレポート生成がうまくできていません。

また、HTTPヘッダについて "Public-Key-Pins" ではなく、"Public-Key-Pins-Report-Only" と設定すれば、ブラウザではエラーを発生させることなく、エラーレポートの収集はできますので、テストの際にこれを使うと良いでしょう。

4. ピンの設定の考察

pin-sha256属性を使ってピンを設定することにより、サーバーオーナーが意図しない証明書が使われることを防ぐことができます。ピンの値は、証明書チェーンの証明書の何れかの証明書に一致するものを最低一つ、どれにも一致しないものを最低一つの計2つ以上により構成されます。
hpkp-intersect

4.1. ピンの値の取得方法

さて、一番簡単なハッシュ値の取得方法ですが、すでにウェブサーバーのHTTPS設定が完了しているならば、Scott Helme氏のHPKPハッシュの所得ページを利用するのが良いです。自分のでも他人のでもHTTPSサイトのURLを入力すれば、証明書チェーンの各証明書のピンのハッシュ値を計算してくれます。

SSLサーバー証明書から順にルート証明書まで、ピンのハッシュ値が

pin-sha256="hUIG87ch71EZQYhZBEkq2VKBLjhussUw7nR8wyuY7rY="

のように表示されますので、どのピンを使うのかを決めてHTTPヘッダに設定するだけです。

一つのピンのハッシュ値の計算ですが、証明書からでも、証明書発行要求(CSR/PKCS#10)でも、秘密鍵と鍵アルゴリズムによっては鍵パラメーターから抽出されたPKCS#8公開鍵からでもハッシュ値を計算することができます。ただ、いろんな人のブログでは、わざわざCSRを作ってからハッシュ値を計算しているようですが、特に証明書のまだ無いバックアップピンの場合には、そんなことをしなくとも、公開鍵からハッシュ計算するのが良いように思います。先ほどと同様に、Scott Helme氏のツールでPEM形式のPKCS#8公開鍵、CSR、X.509証明書を入力すれば、ピンのハッシュ値を計算してくれるページがあるので、これを使うのが簡単です。

手作業でピンを取得する場合には、以下を実施すれば公開鍵のSHA256ハッシュであるピンの値が取得できます。他の解説記事では、base64コマンドを使ったり、CSRをいちいち生成するのを強制させたりしているようですが、ここで紹介する方法はOpenSSLコマンドしか使わず、いろいろなケースに対応して、ピンの取得ができるように、例を示しておきました。


X.509証明書からsubjectPublicKeyInfoフィールドにあるPKCS#8公開鍵のピンの入手
% openssl x509 -in PEM証明書 -pubkey -noout | openssl rsa -pubin -outform DER |  \
    openssl dgst -sha256 -binary | openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

CSRからsubjectPKInfoフィールドにあるPKCS#8公開鍵のピンの入手
% openssl req -in PEMCSRファイル -pubkey -noout | openssl rsa -pubin -outform DER |  \
    openssl dgst -sha256 -binary | openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

PKCS#8秘密鍵からピンの入手
% openssl rsa -in PKCS#8秘密鍵 -pubout -outform DER |  \
    openssl dgst -sha256 -binary |  openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

PKCS#8公開鍵からピンの入手
% openssl rsa -pubin -in PKCS#8公開鍵 -pubout -outform DER |  \
    openssl dgst -sha256 -binary | openssl enc -base64
te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU=

得られた値を
pin-sha256="te4kc4F/5BhtIosKLOS9sy049x7a/LQHNRRG1WHfvyU="
のようにヘッダに設定する。

値を取得したら、ウェブサーバーのHTTPヘッダに設定します。例えば、Apache HTTP Serverの場合には、以下のように設定します。


<VirtualHost _default_:443>
...
Header set Public-Key-Pins \
  "pin-sha256=\"MRnxhYBVCMAxZHwalTJ7ZVl6P2005lll4ttWr+RN1Ro=\"; \
   pin-sha256=\"633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q=\"; \
   max-age=2592000; \
   report-uri=\"https://report.example.com\""
...
読みやすさのためにバックスラッシュと改行を入れています。2592000秒は30日です。

4.2. 証明書チェーンに一致するピンの選択

HPKPでは、証明書チェーンに一致するピンを1つ以上設定する必要があります。本節では、次の2つに分けて考察してみたいと思います。

1) 証明書チェーン中のどれか一つのみを選択する場合の比較検討
2) 証明書チェーン中の2つ以上、または全部を選択する場合の考察

4.2. 証明書チェーンに一致するピンの選択

証明書チェーンで、SSLサーバー証明書、中間CA証明書、ルート証明書のような3段の証明書になっている場合、不正な意図しない証明書チェーンになっていないかどうか検証するために、どれか一つのピンを選ぶとすれば、どれを選べば良いでしょうか。これら3つのケースで、それぞれ長所、短所があるので、考察してみたいと思います。 SSLサーバー証明書については、数年後証明書更新の際に使用する鍵ペアがあらかじめ決まっている場合(=鍵事前生成)、決まっていない場合(=鍵事前生成なし)のケースに分けて考察します。

証明書	長所	短所	安全性	運用負担
①ルートCA証明書	有効期間が長いためピン変更の頻度が少なくて済む。おそらく10年程度は変更不要ブラウザ組み込みのプリロードピンではルート証明書を使用	鍵更新後の公開鍵は事前にはわからずバックアップピンは使えない新しいSSLサーバー証明書を購入した場合に、同じルート認証局とは限らず、その際はピンの移行が必要ルート証明書配下の証明書の数は非常に多く、その認証局が不正な証明書を発行された場合に、攻撃を防げないリスクは高い。例えば、シマンテック社がGoogleに許可なくGoogleの証明書を発行する事件があった。証明書更新でルートCAが変更になる可能性は低いが、変更になった場合には、max-ageに配慮した面倒な移行が必要で運用負荷が高い	低	高
②中間CA証明書	有効期間がやや長いためピン変更の頻度が若干少なくて済む。おそらく5年程度は変更不要安全性と運用負担の面でバランスが取れているか？ピンする中間CAの公開鍵に変更がなかった場合のSSLサーバー証明書の更新は比較的楽	ピンしている中間CAの公開鍵が、次回のSSLサーバー証明書更新時に同じであるという保証はない。 SSLサーバー証明書の更新時に、中間CA証明書が変更になるリスクがあるが、それが事前周知されないために、SSL接続不具合によるサービス停止リスクが高い中間CA証明書が変更になった場合の移行に係る運用負担は、回数も、作業負荷も非常に高い同じ中間CAから、不正に同じドメインに対する証明書が発行された場合にも検証有効となってしまうリスクがある。①よりはリスクは低いが、③④よりは高い証明書更新で中間CAが変更になる可能性はある程度あり、①よりは確率が高い。変更になった場合には、max-ageに配慮した面倒な移行が必要で運用負荷が高い	中	中
③SSLサーバー証明書(鍵事前生成)	SSLサーバー証明書の更新時に、ピンした公開鍵のマッチング設定に失敗する可能性が低く、HPKP設定不備によるサービス停止のリスクは最も低い HPKPのRFCでは、(さらっと簡単にできると取れるような記述がされており)推奨されているように取れる方法不正証明書チェーンが使われるリスクは、(秘密鍵漏洩のリスクを除けば)④と同程度に、①②より高い証明書更新の前後で、変更されるピンがあらかじめわかっているので、(max-age内に再度証明書更新をすることをしなければ)max-ageをあまり気にせずに証明書の更新ができる	SSLサーバー証明書の更新時に、鍵ペアの事前生成が可能なのは、OpenSSL等により手作業で鍵ペア生成した場合のみであり、証明書の発行時に、CSRを自前で生成する必要がなく、ブラウザのコンポーネントで自動的に鍵ペア生成するような証明書発行サービスの場合には、本方式は使えない Let's Encryptは使えず、SSLサーバー証明書自動更新に係る運用負担の軽減は見込めない鍵ペアは一般に、証明書の更新時に行われるものだが、それを2年程度前に実施することになる。事前生成しておくと、その分、SSLサーバー証明書の秘密鍵が漏洩するリスクは高く、機密保管の運用負担は大きい証明書の更新時には、それなりに設定変更に気を使う必要がある。また、その回数も2年弱程度おきであり、運用負担は比較的高い	中	中
④SSLサーバー証明書(鍵事前生成なし)	全てを自己制御でき、設定不備によるサービス停止リスクは③と同程度に高い ③に比べてSSLサーバー証明書の秘密鍵が漏洩するリスクも低い不正証明書チェーンが使われるリスクは、(秘密鍵漏洩のリスクを除けば)④と同程度に、①②より高い	SSLサーバー証明書を使える期間が、必ず (max-age + α)×2 分だけ減る。2年物証明書の場合、max-ageを2ヶ月とした場合、テストや余裕も含め4～5ヶ月程度は短くなることになり、証明書の費用負担が増える証明書更新の前後で証明書の有効期間をmax-age+αでオーバーラップさせれば、必ずmax-ageに配慮しながらピンの変更を行うことになる。運用の負担はあるが、ピンが変更になるか認証局次第でどうなるかわからない①②に比べて、必ずmax-ageに配慮した、証明書更新、HPKP設定変更のスケジュールが組めるので、定型運用にできるため運用の心理的負担は①②よりは若干少ない	高	中

では、①～④では、何を選択するかですが、ブラウザ組み込みのピンが使えない一般サイトの場合は、 ②～③のいずれかが妥当だと思いますが、どれも運用の負担や、サービス提供不能になるリスクがあり、個人がテスト目的で設定する場合は何でも良いとして、自分が商用サイトの運用を任されているならば、もっとも懸念すべきは長期間サービス提供不能になりクレームが起きることなので、 HPKPは使わないという判断をすると思います。

4.3. 証明書更新とHPKPヘッダの設定変更の運用方法

4.2節では、証明書チェーンのどこにピンを設定するかで、どのような違いがあるのかについて考察しました。

本節では、4.2節の考察を受けて、設定不具合によるサービス利用不能を防ぎながら、HPKPを使ったサイトの証明書更新、HPKPヘッダの変更を、どのように運用すればよいのかについて考察します。

HPKPを使った場合の証明書更新の運用の仕方は4つのケースにわけることができます。

a)証明書更新のmax-ageより前に確認し、ピンを行っている鍵に変更がない場合
b)証明書更新のmax-ageより前に証明書更新の前後でピンを行う公開鍵が何に変更されるかわかっている場合
c)証明書更新のmax-ageより前に証明書更新の前後でピンを行う公開鍵が何に変更されるかわからない、もしくは変更が明らかだが、更新の前後の証明書の有効期間をmax-age + αオーバーラップできる場合
d)証明書更新のmax-ageより前に証明書更新の前後でピンを行う公開鍵が何に変更されるかわからない、もしくは変更が明らかだが、更新の前後の証明書の有効期間をmax-age + αオーバーラップできない場合

このような説明では、具体的なイメージがわかないと思いますので、証明書チェーン中の証明書に分けて具体例を示してみましょう。

a-1) ルート証明書や中間CA証明書にピンを設定しており、顧客サポートに問合せたら、次回、max-age後の証明書更新では、使用するルート証明書、中間CA証明書には変更がないことがわかった場合。(顧客サポートに嘘をつかれたら、一部ユーザに2ヶ月(=max-age)サービス障害になるリスクあり。)
b-1) ルート証明書や中間CA証明書にピンを設定しており、顧客サポートに問合せたら、次回、max-age後の証明書更新では、使用するルート証明書、中間CA証明書がどれに変更されるか教えてもらえた場合。もしくはサポートページなどで告知されている場合。証明書発行サービスの変更、EVへの変更なども同様。
b-2) SSLサーバー証明書にピンを設定しており、OpenSSL等で次回の証明書更新で使用する鍵ペアがすでに事前生成され、保管されている場合
c-1) ルート証明書や中間CA証明書にピンを設定しているが、次回証明書更新後のルート証明書、中間CA証明書の変更について、顧客サポートからの回答が得られず、変更されるかどうか判断がつかないため、仕方なく、証明書更新をmax-age + α前に実施して有効期間を重ねるよう事前証明書発行したら、やはりルート証明書、中間CA証明書は変更になっていた場合(変更がなければa-1のケースとなる。)
c-2) SSLサーバー証明書にピンを設定しているが、OpenSSLを使わず、ブラウザの機能で鍵ペア生成するタイプの認証局であるため、事前に更新後の公開鍵はわからず、証明書更新をmax-age + α前に実施して有効期間を重ねるよう事前証明書発行できる場合
c-3) SSLサーバー証明書にピンを設定しているが、HSM機能を使うSSLアクセラレーターを使っており、事前に更新後の公開鍵はわからず、証明書更新をmax-age + α前に実施して有効期間を重ねるよう事前証明書発行できる場合。移行の図はc-2と同じになります
d-1) SSLサーバー証明書にピンを設定しているが、Let's Encryptや一部の認証局のように、証明書更新後、前の証明書は即時に失効処理がされ、max-age + αの期間の有効期間のオーバーラップができない場合

自分の運用がどのケースにあてはまるか、上記の説明でわかったでしょうか。さて、a～dのケースで、どのように対応するかを以下に示します。

aの対応) 証明書更新に際し、ウェブサーバーのHPKPヘッダの設定は変更しなくてよい
bの対応) max-ageをはあまり気にせず、証明書更新後の、ウェブサーバーの証明書設定、HPKPヘッダを設定変更してよい
cの対応) もっとも神経を遣う、max-ageに配慮した、証明書更新、HPKPヘッダ設定が必要。証明書の更新の前後で、有効期間のオーバーラップが必要
dの対応) このケースではHPKPは使えない。他の証明書、証明書発行サービスへのピン設定の変更を検討する必要がある。使っても、一部ユーザにサービス接続不能障害がmax-age程度発生する。

どんな証明書更新、HPKPヘッダ設定の移行を行うにしても、証明書の有効期限、max-age、秘密鍵の保管など、様々なことに気を遣いながら、移行計画を立て、移行しないとならず、きちんと考えないと長期のサービス障害発生するという運用上の負担やリスクは大きいと思います。

4.4. バックアップピンという命名のいけてなさ

先に述べたように、何か一つ、証明書チェーンとはマッチしないピンを必ず含めなければいけません。SSLサーバー証明書にピンをする場合は、現在使っているSSLサーバー証明書の秘密鍵に対して、将来、証明書更新で使う予定の秘密鍵も事前に生成しておけるなら、その公開鍵をバックアップピンとして設定しておけば、まさしくバックアップとして使用でき、(後述の問題ありありですが)スムースな証明書とピンの移行が可能です。

しかしながら、秘密鍵を移行先のバックアップとして事前生成しておき、これが利用できるというケースはレアケースです。例えば以下の一般に起こりうるケースでは、証明書更新の際に、その事前生成した秘密鍵を使用することはできません。

CA証明書のバックアップPin: 認証局が行う証明書更新もしくは鍵更新において、事前に移行先の秘密鍵が存在するということもありませんし、移行先の公開鍵のPinをユーザに公開してくれる認証局もありません。
HSMを使っている場合のバックアップ: 認証局やSSLアクセラレーターを使っているケースでは、秘密鍵を取り出し不可能なハードウェアセキュリティモジュール(HSM)で管理するのが一般的です。HSMを使用した鍵更新、証明書更新では、事前に秘密鍵を幾つか生成しておき、更新時にそれを指定して更新に使用するということができません。更新時には、新たに鍵ペアを生成して、これを使用します。このために、認証局ではバックアップPinを公開することができないのです。
ウェブ画面で鍵ペア生成してSSLサーバー証明書発行する認証局の場合: 認証局によっては、ウェブブラウザの機能を使用して、ボタンを押せば自動で鍵ペア生成を行い、これを用いて証明書を発行し、新しい証明書を格納するものがあります。そのような認証局では、事前に生成しておいた鍵を発行時に使用するということができません。
Let's Encryptを使う場合: 無料で世界一の発行数を誇る証明書発行サービスであるLet's Encryptでは、証明書の発行プロセスがスクリプトにより自動化されていますが、これも証明書の更新時には自動で鍵ペア生成されるので、事前に生成していた鍵ペアを使用することができません。

本当の意味での「バックアップPin」が使えるのは、以下の場合にのみ可能であるということです。

SSLサーバー証明書に対してPinをする場合で、かつ、
OpenSSLなどのコマンドで鍵ペア生成し、マニュアルで証明書発行要求を生成して、証明書発行してもらえる認証局を使用する場合

従って、証明書チェーンにマッチしないものを、「バックアップPin」と呼ぶのは、上述のほとんどのケースで適切でないので、名称には問題があると考えています。

4.5. CA鍵のバックアップピンのオススメの値

ルート証明書や中間CA証明書にピンを設定する場合、一致しないピンは、将来の更新先がわからない場合には何でもよく、さらには、本物の公開鍵のハッシュである必要もありません。 SHA256なので、単に32バイトの値であれば何でも良いわけです。

ただ、HPKPヘッダで一見して一致しないピンだとわかったほうが、誤って削除するなどの運用ミスを防ぐ意味でも良いと考えており、そこで、オススメしたいのが、以下の値です。


pin-sha256="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
これは、16進数で
0000000000000000000000000000000000000000000000000000000000000000 (32バイト)

となります。流行るといいなと思っていますw

4.6. 証明書チェーン中で複数ピンをつけても意味はない

これまで、証明書チェーンと一致するピンの数は1つを前提に議論してきましたが、これを複数、例えば、ルート証明書と、中間CA証明書と、SSLサーバー証明書のピンを一致させた場合には、どうなるのかを考察したいと思います。

まず、SSLサーバー証明書にピンを打って、次に中間CA証明書、次にルート証明書のピンを追加していくことを考えてましょう。同じ鍵ペアを複数の認証局からのサーバー証明書発行で使用しないという、当たり前の事を前提とします。 SSLサーバー証明書にピンを打つ事が最も、範囲が限定的でニセHTTPSに対する最も強い対策であると、4.2節③④で述べました。

そこに中間CA証明書の一致するピンを足してみたらどうでしょうか。ピンで特定する証明書の範囲は全く変わりませので、中間CA証明書のピンを足すことで、ニセHTTPSサイト作りが難しくなったりはせず、セキュリティの強度も上がりません。また、運用面では、ピンの一致の配慮がピン一つと比べて難しく、また、ウェブサイトオーナーだけで管理できない範囲となるので証明書やピンヘッダ変更の運用は格段に複雑で面倒になります。これに対し、ルート証明書のピンを加えた場合でも全く同じことです。セキュリティ強度は上がらず、移行の運用は複雑になるのです。
hpkp-multipin

従って、証明書チェーン中で複数のピンをつけても意味がなく、かえって運用が複雑になるだけなので、止めたほうがよいということが言えます。

4.7. 同じCA証明書にPinし続ける場合の課題

今後当面は、同じルート認証局、中間認証局から発行してもらう場合に、その認証局の証明書の公開鍵にPinすることができます。その場合には、バックアップPinは、認証局から移行先のPinを教えてもらえるわけではないので、なんでも適当な値で良いことになります。公開鍵のハッシュである必要もなく、32バイトの値のBase64表現であれば(衝突しなければ)何でも良いことになります。

ただし、「当面は」と書きましたが、SSLサーバー証明書を発行する使用していた中間認証局が、次の証明書発行時にも同じ中間認証局、同じ公開鍵であるという保証がありません。以下の理由により、同じ中間CA証明書が使われない可能性があります。

中間CA証明書の有効期限は、5年から10年程度です。その有効期限の半分程度から、最長でも2、3年を残して、その中間認証局からは証明書が発行されなくなり、利用者は別のCAから証明書を発行してもらうようになります。
証明書の発行数枚数が多くなると、それだけ、証明書失効リスト(CRL)のサイズも大きくなりますので、一つの中間CAから発行枚数を制限して、以降の証明書発行は、新しい中間CAから発行させるケースがあります。
近年、認証局の運用上の不備、サイバー攻撃などから証明書発行サービス全体や、特定の中間CAが運用停止、サービス終了になることがあります。

このような場合には、同じ中間CAのPinを使うことができません。

有効なPinを設定した同じルートCAもしくは中間CAから、新しい証明書が発行してもらえないとわかった際に、別の証明書の移行は、すぐにはできず、max-ageで指定した期間、一般には1ヶ月から1年程度は、証明書の入れ替えができません。最悪の場合、その期間、有効なHTTPS通信ができないという事もありえます。

このような影響を、軽減する方法が無いわけではありません。証明書を更新すると判断し、同じ中間CAから証明書が発行できないとわかった時点Aで、そこからmax-age経過した時点Bを記録しておき、新しい証明書を取得します。(が使いません。)。バックアップPinとして、その新しい証明書の別の中間CA証明書の公開鍵のPinをウェブサーバーのヘッダに設定します。時点Bになって、初めて新しい証明書への入れ替えを実施します。この事から、max-ageを1年等、長くとれば偽サイトの防止には役立ちますが、今述べたような証明書更新のリスクもあり、半月から1ヶ月程度に設定するのが妥当なように思います。

4.8. 2つのCA証明書にPinする場合の課題

SSLサーバー証明書の更新の際に、2つの証明書発行サービス、例えばSymantecとGlobalSignを交互に乗り換えるとして、これら2つの中間CA証明書のPinをヘッダに設定し、使用してないない方をバックアップPinとするのは、なかなか賢い方法だと思います。
hpkp-two

しかしながら、前述の理由により、Symantecの次に発行してもらおうと予定していたGlobalSignの中間CA証明書のPinが使えないケースがあります。

以上のように、CA証明書にPinを打つケースでは、証明書発行サービスの気まぐれにビクビクしながら、ウェブサーバーのHPKPを運用するのはとても面倒だと思いませんか? それなら、まだ、自分でコントロールできるSSLサーバー証明書にPinを打つ方が、面倒でも良いような気もしてきます。

4.9. max-ageのオススメ値を考える

RFC 7469 4.1節のセキュリティ考察において、max-ageの最大値について以下のように記載されており、「60日がバランスの取れた値かもね」と言っています。

RFC 7469 4.1. Maximum max-age より
However, a value on the order of 60 days (5,184,000 seconds) may be considered a balance between the two competing security concerns.

ただ、5章のScott Helme氏のHPKP対応ドメインリストに基づいた私の調査では、まともな運用をしている設定の中では、 30日が26%、次いで60日が19%と多いです。

max-ageの値が長すぎると、

設定ミスによる障害発生時に長期間接続できないユーザが出てしまう
有効期間のオーバーラップが必要な場合、実質的な証明書有効期間が目減りして運用コストに影響する

というリスクについて、4.2節で説明させて頂きましたが、逆に、max-ageが短すぎるとどうなるのでしょうか？

簡単には、ニセのHTTPSサイトに乗っ取られる可能性が高くなるという事かと思います。本物サイトのmax-ageが短くて、有効期限が切れたタイミングで、ドメイン乗取り等の被害にあって偽サイトが作られ、そこで1年等長いmax-ageのHPKPヘッダ対応のニセサイトが作られたとすると、一度そのようになれば、当面1年間は、ニセサイトにしか繋げないようなユーザが発生することがあります。
hpkp-maxage
max-ageが短いと、それだけ攻撃のチャンスは増えるため、max-ageはある程度長くしておく必要があります。

様々な情報ソースから、ニセサイトを作られていたと気づくまでに、それほど時間はかからないと思います。数日から1週間もあれば問題に気づくと思います。半月や1ヶ月も気づかないままいる事はないでしょう。「ニセHTTPSサイト問題に気づくまでに遅くともどれくらいかかるか」によって max-ageの最小値を決めるのがよいと思います。

従って、攻撃と可用性のリスクのトレードオフで、私はmax-ageを15日か30日程度に設定するのが良いように思っています。

5. HPKPはどの程度使われているのか

2016年3月のNetcraft社のSSL利用調査によれば、世界でわずか0.09%の4100サイト以下ぐらいしか、HPKPを設定しておらず、設定の誤りも多いそうで、正しく設定できているのは、そのうち3000サイト程度なのだそうです。

また、CSP(Content Security Policy)やHPKPに詳しく、HPKPの検証やレポート先サイトを運営しているScott Helme氏のブログによれば、Alexa上位100万のサイトのうちHPKPを設定しているのは、わずか375サイトであったという報告もあります。

Scott Helme氏は、調査の際のデータも公開しており、2016年8月時点でのHPKP対応サイトのドメイン名リスト448件があったので、それをベースに2017年2月現在でもHPKPヘッダを返すサイト283件に対して少し調査してみました。

	まず、HPKPヘッダとして正しいフォーマットになっているか、また、仕様上PINのハッシュ値は2つ以上必要ですが、2つ以上あるかという観点で、ヘッダがどの程度正しいかを調べました。16%は設定が正しくないことがわかりました。間違っているものの中には、pin-sha256属性が無い、pin-sha256の値が不適切、pin-sha256属性が一つしかない、など様々です。例えばこんなものがありました。 `...` `pin-sha256="base64+info1="; max-age=3`
	次に、HPKPヘッダのPINのハッシュ値の個数です。一般にはPINのハッシュ値は2つで十分で、2つとなっているサイトが多く占めますが、1個しかない誤ったサイトや、3つ以上を設定しているサイトも相当数あります。15個設定しているという猛者もありました。
	HPKPで有効な公開鍵ハッシュの保存期間を定めているのが、max-ageの値です。RFCでは、60日を推奨しているようですが、実際には30日を設定するサイトが多いとわかります。また、テスト中なのか1日以下にしているサイトも相当数あります。短いとサイトを乗っ取られる可能性が高まりますし、長すぎると設定に失敗した場合その期間接続不能になってしまいます。1年などと設定すると、設定失敗していたら1年間接続できないユーザーが出てクレーム確実なのに恐ろしいですね。
	report-uriを設定すると、対応ブラウザならば、HPKPのエラーの際に指定したURLにレポートを送ることができます。Jxckさんのサイトでは設定されているそうですが、まだまだ設定しているサイトは少なそうです。
	HPKPヘッダの値には、includeSubDomainというプロパティをつけることができます。これをつけるとexample.comにHPKPを設定しておけば、sub1.example.comドメインに対しても適用されるようになります。
	HPKPヘッダとして、通常は"Public-Key-Pins"を使いますが、"Public-Key-Pins-Report-Only"を使えば、ブラウザはHPKPを検証せずに、エラーとなってもHTTPS接続は続けられるテスト用の機能があります。約10%のサイトがこのテスト用の設定を使っているとわかります。
	Scott Helme氏の2017年時点で接続可能なHPKP対応サイト283件のうちgTLD(com、org等)、ccTLD(de、ru、jp等)別に件数を調べてみると、comが多いのは当然でとして、実際の各TLDの登録件数に比較して顕著に多いTLDが見られました。comは1.3億、netとdeは1600万、ruは540万ドメインが登録されていますが、ドメイン登録数に比べて、比率的にru、org、deは突出して多くまた、グラフ上はその他としていますが、マイナーなccTLDの国についても、比較的HPKP設定が多い国があります。また、eduが異常に少ないのも気になりました。その他には、ar/br/cl/il/pt/nl/tn/skなど、マイナーなものが 50近くありました。

6. 今のHPKPの何がいけなかったのか

hpkpの発想自体は、不正発行された証明書を使った偽サイトを防ぐための仕組みとして有用であり、ChromeやFirefoxのブラウザ組み込みのプリロートピンはうまく機能しているように思えます。その一方でHPKPヘッダを使った方式は、かなり運用が複雑で難しく、失敗すると 2ヶ月といった、長期間、一部のユーザは接続できないという、障害が発生するリスクも高いことがわかりました。

個人や中小のサイトで不正証明書を使ってまで偽サイトを作るメリットは見当たらず、攻撃を受ける可能性も極めて低いため、HPKPを使ってサービス障害のリスクを取ってまでHPKPを導入する必要はないと思います。

では、一般サイト向けにHPKPの普及が進むためには、運用のしやすいサービス障害が起きにくい仕様の変更が必要だと思いますが、どうすればこれが可能になるでしょうか？

max-ageを2ヶ月と仮定して、 HPKPヘッダで運用上の課題なのは、証明書更新の2ヶ月前に、ピンが変更になるなら設定を事前設定しなければならず、間違えに気づいてヘッダ設定を直しても、2ヶ月は通信障害が発生するということです。

そこで、間違えに気づいた時には、すぐに設定変更が反映できたり、サーバー側で暫定的にブラウザのHPKP検証を無効化できるキルスイッチがあるとよいと思うのです。深く考察した訳ではありませんが、例えば、HPKP更新日をヘッダに記載するなどして、設定に更新があればmax-ageに関わらず更新し、無効化するなら、無効化するといった機能を提供すれば、運用はmax-ageや設定ミスの呪縛から解放されるように思います。

他にもこの問題の解決方法はあるかもしれませんが、何らかの手当てをしない限り、HPKPは普及しそうにはありません。

7. おわりに

以上、HPKPについて、どこにピンを打つか、max-ageはどうするかなど運用面から、いろいろ考察や整理をしてみました。現時点では、HPKPを導入するのは時期尚早で、運用に負担をかけ、サービス停止のリスクも高いということもご理解いただけたのではと思います。

これで、自分がHPKPについて前から書きたいと思っていたことを、落ち着いて整理でき、3年越しぐらいに吐き出せました。わかりにくかったり、理解が間違っていたらすみません。個人的には、HPKPについては、これでわだかまりとかモヤモヤ感というは概ね払拭されたように思います。まぁ、「ブログなんてそんなモノよね」ってことで、、、ｗ

8. (参考) HPKP関連の勉強になるリンク

Netcraft: Secure websites shun HTTP Public Key Pinning: HPKPが流行っていないことの統計。なぜ流行らないかの解説。良記事。
Netcraft: HTTP Public Key Pinning: You're doing it wrong!: Netcraft社の、世の中のHPKP対応サイトの設定誤りに関する解説。良記事。
Scott HelmeさんのHPKPブログ記事: CSPやHSTSやHPKPなどSSL関連技術の専門家で、HPKPなどのレポート先サイト report-uri.io を運営しているScott Helmeさんのブログ。HPKP対応サイトのドメインリストなどのデータもあります。
Qualys Blog: Is HTTP Public Key Pinning Dead?: Ivan Ristic氏の、「HPKPが終わっているか？」に関する議論。
Raymii.org: HTTP Public Key Pinning Extension HPKP for Apache, NGINX and Lighttpd: 解説は充実。各サーバー毎のHPKPヘッダの設定例。
MDN: Public Key Pinning: MozillaによるHPKP解説。ChromeやFirefoxでのHPKP対応バージョンの記述。サーバー設定例レポート機能は新しいChromeしか使えない事の言及など、参考になる。
Public Key Pinningについて - Chris Palmer (原文): Chris PalmerによるHPKP解説。誤解もあるが、初めて証明書チェーンのどこにピンを設定するか、そのケース分けについて考察した記事。
ぼちぼち日記：不正なSSL証明書を見破るPublic Key Pinningを試す: joviさんによるHPKP(ドラフト)に関する詳細かつ広範な解説です。
Jxckさんのブログ：Public Key Pinning for HTTP(HPKP) 対応と report-uri.io でのレポート収集: Jxckさんの解説。特にreport-uriの機能を試してみた報告が貴重。
公開鍵ピンニングによるユーザ追跡 HPKP Supercookies: 今回の記事とはあまり関係ないですが、にしむねあさんのHPKPを使ったクッキーを使わないユーザー特定の面白い試みに関するスライド資料。
OWASP: Certificate and Public Key Pinning: OWASPの解説記事。無駄な情報も多い。

9. 追記

9.1. 追記(2017.02.26) HPKPのブラウザサポート状況

caniuse.comサイトでは様々なブラウザの機能のサポート状況を情報提供していますが、 2017年2月時点での HPKPのブラウザサポート状況についても記載されているので、示しておきます。Firefox、Chrome、Opera、Android版Chromeではサポートされていますが、それ以外ではサポートされていません。
hpkp-caniuse

9.2. 追記(2017.02.26) smashingmagazine.comで発生したHPKP障害

その後、HPKPについて継続して調べ物をしていたら、 smashingmagazine.comのブログで、 HPKPにより発生した接続障害についての考察が書かれていました。ここでは、以下のように書かれていました。

HPKPは中間者攻撃に対して有効な機能だが
HPKPの設定ミスで2016年10月21日から25日にかけHTTPS接続障害が発生
証明書期限切れでHPKPヘッダを更新したらエラーになった
すでに証明書は期限切れでロールバックはできない

教訓として、ブログでは、

金融サイトなどならば、HPKPを使う価値はあるが、単なる情報提供サイトなら、その必要もない。HPKP設定ミスによるサービス停止は、中間者攻撃よりも大きな脅威だ
max-ageを短くすることにより問題を緩和できる

私もサービス提供不能の方が、大きな問題だというのは同意ですが、前にも述べた通り、max-ageを短すぎる値に設定するのは懸命ではなく、注意が必要です。このサイトでは、max-ageを1年としているようですが、確かにこれは長すぎます。新しく設定されたHPKPヘッダを見てみましたが、現行のSSLサーバー証明書の他に 3つピンが設定されており、max-ageは1日に設定されており、いろいろと設定には問題がありそうです。

タグ：: #HPKP; #SSLTLS; #TLS; #Public-Key-Pins; #RFC7469; #X.509証明書; #証明書更新; #OpenSSL

k_urushima

2016年04月10日14:20

カテゴリ: SSLTLS; 脆弱性

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 文字化け"みたいなキーワードで検索すれば、方法が出てくるでしょう。

そして、一つ一つグラフを作っていくわけです。

で、Excelのグラフの凡例ではちょっと見づらいのでパワポで吹き出しをつけます。

どうです？結構面倒くさそうでしょう？

で、新しいサイトでは

とにかく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サポートプロトコルの推移のグラフも付け加わっています。

しばらくしたら英語ページの作成にとりかかりたいと思います。

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

タグ：: #SSL; #TLS; #SSLPulse; #脆弱性; #RC4; #BEAST; #POODLE; #サーバー証明書; #D3.js; #rickshaw

2015年12月16日06:09

カテゴリ: SSLTLS; 脆弱性

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; #TLS; #SSLTLS; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書; #SSLPulse

2015年10月24日13:47

カテゴリ: SSLTLS; 脆弱性

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; #TLS; #SSLTLS; #統計情報; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書

2015年08月12日19:20

カテゴリ: SSLTLS; 脆弱性

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

脆弱性対応の推移

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; #TLS; #SSLTLS; #統計情報; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書

2015年06月17日00:04

カテゴリ: SSLTLS; 脆弱性

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; #TLS; #SSLTLS; #統計情報; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書

2015年05月11日00:51

カテゴリ: SSLTLS; 脆弱性

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

脆弱性対応の推移

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サーバー証明書の件が書けなかったなぁ。今日はこの辺で。

タグ：: #SSL; #TLS; #SSLTLS; #統計情報; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書

2015年03月17日21:09

カテゴリ: SSLTLS; 脆弱性

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

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のデータからいろんな推移を見てみました。今日はこの辺で。

タグ：: #SSL; #TLS; #SSLTLS; #統計情報; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書

記事一覧(手作り)

はてなブックマーク
された記事

TLS

インストール

で、ちょっと見てみるぞ、と

新しいサイト

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

で、新しいサイトでは

関連記事

脆弱性対応の推移

SSL/TLSプロトコルの推移

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

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

鍵交換の最低鍵長

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

ECDH鍵交換の最低鍵長

おわりに

関連記事

脆弱性対応の推移

SSL/TLSプロトコルの推移

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

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

鍵交換の最低鍵長

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

ECDH鍵交換の最低鍵長

おわりに

関連記事

脆弱性対応の推移

SSL/TLSプロトコルの推移

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

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

鍵交換の最低鍵長

DH鍵交換の最低鍵長

ECDH鍵交換の最低鍵長

おわりに

関連記事

脆弱性対応の推移

SSL/TLSプロトコルの推移

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

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

鍵交換の最低鍵長

DH鍵交換の最低鍵長

ECDH鍵交換の最低鍵長

おわりに

関連記事

脆弱性対応の推移

SSL/TLSプロトコルの推移

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

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

鍵交換の最低鍵長

DH鍵交換の最低鍵長

ECDH鍵交換の最低鍵長

おわりに

関連記事

SSL Pulseのデータの追加

脆弱性対応の推移

SSL/TLSプロトコルの推移

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

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

鍵交換の最低鍵長

DH鍵交換の最低鍵長

ECDH鍵交換の最低鍵長

おわりに

関連記事