もくじ
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です。HPKPでは、証明書チェーンの証明書公開鍵のハッシュの一致を確認することにより、ウェブサイトオーナーの意図した証明書かどうか検証することができます。
joviさんのブログの1章で背景と仕組みをわかりやすく解説されているので、そちらもご覧頂ければと思います。
3. HPKPの仕組み
HPKPの実装方法には2つの方法があります。
- 1) Google、Facebook、Twitterなどの有名サイト向けの、Chrome、Firefoxなどブラウザに組み込まれたピンのリスト(Preloaded Known Pinned Host List)と照合する方法
- 2) HTTPSで通信する際に、サーバーからピン情報のHTTPヘッダを取得し、それをブラウザに保管しておき、以降の通信で照合に使う方法
ウェブサーバーに不正な証明書チェーンに接続させないための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さんのブログで設定を試してみたという詳しい報告がされているのでご覧になると良いでしょう。ブログでも書かれていますが、レポートが出力される条件がよくわからず、ブラウザやバージョンにも依存するようで、私もレポート生成がうまくできていません。
4. ピンの設定の考察
pin-sha256属性を使ってピンを設定することにより、サーバーオーナーが意図しない証明書が使われることを防ぐことができます。
ピンの値は、証明書チェーンの証明書の何れかの証明書に一致するものを最低一つ、
どれにも一致しないものを最低一つの計2つ以上により構成されます。
4.1. ピンの値の取得方法
さて、一番簡単なハッシュ値の取得方法ですが、すでにウェブサーバーのHTTPS設定が完了しているならば、Scott Helme氏のHPKPハッシュの所得ページを利用するのが良いです。自分のでも他人のでもHTTPSサイトのURLを入力すれば、証明書チェーンの各証明書のピンのハッシュ値を計算してくれます。
SSLサーバー証明書から順にルート証明書まで、ピンのハッシュ値が
のように表示されますので、どのピンを使うのかを決めてHTTPヘッダに設定するだけです。pin-sha256="hUIG87ch71EZQYhZBEkq2VKBLjhussUw7nR8wyuY7rY="
一つのピンのハッシュ値の計算ですが、証明書からでも、証明書発行要求(CSR/PKCS#10)でも、 秘密鍵と鍵アルゴリズムによっては鍵パラメーターから抽出されたPKCS#8公開鍵からでもハッシュ値を計算することができます。 ただ、いろんな人のブログでは、わざわざCSRを作ってからハッシュ値を計算しているようですが、特に証明書のまだ無いバックアップピンの場合には、 そんなことをしなくとも、公開鍵からハッシュ計算するのが良いように思います。 先ほどと同様に、Scott Helme氏のツールでPEM形式のPKCS#8公開鍵、CSR、X.509証明書を入力すれば、ピンのハッシュ値を計算してくれるページがあるので、これを使うのが簡単です。
手作業でピンを取得する場合には、以下を実施すれば公開鍵のSHA256ハッシュであるピンの値が取得できます。他の解説記事では、base64コマンドを使ったり、CSRをいちいち生成するのを強制させたりしているようですが、ここで紹介する方法はOpenSSLコマンドしか使わず、いろいろなケースに対応して、ピンの取得ができるように、例を示しておきました。
値を取得したら、ウェブサーバーのHTTPヘッダに設定します。例えば、Apache HTTP Serverの場合には、以下のように設定します。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=" のようにヘッダに設定する。
<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証明書 |
|
|
低 | 高 |
| ��中間CA証明書 |
|
|
中 | 中 |
| ��SSLサーバー証明書(鍵事前生成) |
|
|
中 | 中 |
| ��SSLサーバー証明書(鍵事前生成なし) |
|
|
高 | 中 |
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の対応) 証明書更新に際し、ウェブサーバーのHPKPヘッダの設定は変更しなくてよい
- bの対応) max-ageをはあまり気にせず、証明書更新後の、ウェブサーバーの証明書設定、HPKPヘッダを設定変更してよい
- cの対応) もっとも神経を遣う、max-ageに配慮した、証明書更新、HPKPヘッダ設定が必要。証明書の更新の前後で、有効期間のオーバーラップが必要
- dの対応) このケースではHPKPは使えない。他の証明書、証明書発行サービスへのピン設定の変更を検討する必要がある。使っても、一部ユーザにサービス接続不能障害がmax-age程度発生する。
4.4. バックアップピンという命名のいけてなさ
先に述べたように、何か一つ、証明書チェーンとはマッチしないピンを必ず含めなければいけません。SSLサーバー証明書にピンをする場合は、現在使っているSSLサーバー証明書の秘密鍵に対して、将来、証明書更新で使う予定の秘密鍵も事前に生成しておけるなら、その公開鍵をバックアップピンとして設定しておけば、まさしくバックアップとして使用でき、(後述の問題ありありですが)スムースな証明書とピンの移行が可能です。
しかしながら、秘密鍵を移行先のバックアップとして事前生成しておき、これが利用できるというケースはレアケースです。例えば以下の一般に起こりうるケースでは、証明書更新の際に、その事前生成した秘密鍵を使用することはできません。
- CA証明書のバックアップPin
- 認証局が行う証明書更新もしくは鍵更新において、事前に移行先の秘密鍵が存在するということもありませんし、移行先の公開鍵のPinをユーザに公開してくれる認証局もありません。
- HSMを使っている場合のバックアップ
- 認証局やSSLアクセラレーターを使っているケースでは、秘密鍵を取り出し不可能なハードウェアセキュリティモジュール(HSM)で管理するのが一般的です。HSMを使用した鍵更新、証明書更新では、事前に秘密鍵を幾つか生成しておき、更新時にそれを指定して更新に使用するということができません。更新時には、新たに鍵ペアを生成して、これを使用します。このために、認証局ではバックアップPinを公開することができないのです。
- ウェブ画面で鍵ペア生成してSSLサーバー証明書発行する認証局の場合
- 認証局によっては、ウェブブラウザの機能を使用して、ボタンを押せば自動で鍵ペア生成を行い、これを用いて証明書を発行し、新しい証明書を格納するものがあります。そのような認証局では、事前に生成しておいた鍵を発行時に使用するということができません。
- Let's Encryptを使う場合
- 無料で世界一の発行数を誇る証明書発行サービスであるLet's Encryptでは、証明書の発行プロセスがスクリプトにより自動化されていますが、これも証明書の更新時には自動で鍵ペア生成されるので、事前に生成していた鍵ペアを使用することができません。
- SSLサーバー証明書に対してPinをする場合で、かつ、
- OpenSSLなどのコマンドで鍵ペア生成し、マニュアルで証明書発行要求を生成して、証明書発行してもらえる認証局を使用する場合
4.5. CA鍵のバックアップピンのオススメの値
ルート証明書や中間CA証明書にピンを設定する場合、 一致しないピンは、将来の更新先がわからない場合には何でもよく、 さらには、本物の公開鍵のハッシュである必要もありません。 SHA256なので、単に32バイトの値であれば何でも良いわけです。
ただ、HPKPヘッダで一見して一致しないピンだとわかったほうが、 誤って削除するなどの運用ミスを防ぐ意味でも良いと考えており、 そこで、オススメしたいのが、以下の値です。
となります。流行るといいなと思っていますwpin-sha256="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="; これは、16進数で 0000000000000000000000000000000000000000000000000000000000000000 (32バイト)
4.6. 証明書チェーン中で複数ピンをつけても意味はない
これまで、証明書チェーンと一致するピンの数は1つを前提に議論してきましたが、 これを複数、例えば、ルート証明書と、中間CA証明書と、SSLサーバー証明書のピンを一致させた場合には、 どうなるのかを考察したいと思います。
まず、SSLサーバー証明書にピンを打って、次に中間CA証明書、次にルート証明書のピンを追加していく ことを考えてましょう。 同じ鍵ペアを複数の認証局からのサーバー証明書発行で使用しないという、当たり前の事を前提とします。 SSLサーバー証明書にピンを打つ事が最も、範囲が限定的でニセHTTPSに対する 最も強い対策であると、4.2節����で述べました。
そこに中間CA証明書の一致するピンを足してみたらどうでしょうか。ピンで特定する証明書の範囲は全く変わりませので、中間CA証明書のピンを足すことで、ニセHTTPSサイト作りが難しくなったりはせず、セキュリティの強度も上がりません。また、運用面では、ピンの一致の配慮がピン一つと比べて難しく、また、ウェブサイトオーナーだけで管理できない範囲となるので証明書やピンヘッダ変更の運用は格段に複雑で面倒になります。これに対し、ルート証明書のピンを加えた場合でも全く同じことです。セキュリティ強度は上がらず、移行の運用は複雑になるのです。
従って、証明書チェーン中で複数のピンをつけても意味がなく、かえって運用が複雑になるだけなので、止めたほうがよいということが言えます。
4.7. 同じCA証明書にPinし続ける場合の課題
今後当面は、同じルート認証局、中間認証局から発行してもらう場合に、その認証局の証明書の公開鍵にPinすることができます。その場合には、バックアップPinは、認証局から移行先のPinを教えてもらえるわけではないので、なんでも適当な値で良いことになります。公開鍵のハッシュである必要もなく、32バイトの値のBase64表現であれば(衝突しなければ)何でも良いことになります。
ただし、「当面は」と書きましたが、SSLサーバー証明書を発行する使用していた中間認証局が、次の証明書発行時にも同じ中間認証局、同じ公開鍵であるという保証がありません。以下の理由により、同じ中間CA証明書が使われない可能性があります。
- 中間CA証明書の有効期限は、5年から10年程度です。その有効期限の半分程度から、最長でも2、3年を残して、その中間認証局からは証明書が発行されなくなり、利用者は別のCAから証明書を発行してもらうようになります。
- 証明書の発行数枚数が多くなると、それだけ、証明書失効リスト(CRL)のサイズも大きくなりますので、一つの中間CAから発行枚数を制限して、以降の証明書発行は、新しい中間CAから発行させるケースがあります。
- 近年、認証局の運用上の不備、サイバー攻撃などから証明書発行サービス全体や、特定の中間CAが運用停止、サービス終了になることがあります。
有効な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とするのは、なかなか賢い方法だと思います。
しかしながら、前述の理由により、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 よりただ、5章のScott Helme氏のHPKP対応ドメインリストに基づいた私の調査では、 まともな運用をしている設定の中では、 30日が26%、次いで60日が19%と多いです。
However, a value on the order of 60 days (5,184,000 seconds) may be considered a balance between the two competing security concerns.
max-ageの値が長すぎると、
- 設定ミスによる障害発生時に長期間接続できないユーザが出てしまう
- 有効期間のオーバーラップが必要な場合、実質的な証明書有効期間が目減りして運用コストに影響する
簡単には、ニセのHTTPSサイトに乗っ取られる可能性が高くなるという事かと思います。
本物サイトのmax-ageが短くて、有効期限が切れたタイミングで、ドメイン乗取り等の被害にあって
偽サイトが作られ、そこで1年等長いmax-ageのHPKPヘッダ対応のニセサイトが作られたとすると、
一度そのようになれば、当面1年間は、ニセサイトにしか繋げないようなユーザが発生することがあります。
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属性が一つしかない、など様々です。例えばこんなものがありました。
|
| 次に、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では
サポートされていますが、それ以外ではサポートされていません。
9.2. 追記(2017.02.26) smashingmagazine.comで発生したHPKP障害
その後、HPKPについて継続して調べ物をしていたら、 smashingmagazine.comのブログで、 HPKPにより発生した接続障害についての考察が書かれていました。 ここでは、以下のように書かれていました。
- HPKPは中間者攻撃に対して有効な機能だが
- HPKPの設定ミスで2016年10月21日から25日にかけHTTPS接続障害が発生
- 証明書期限切れでHPKPヘッダを更新したらエラーになった
- すでに証明書は期限切れでロールバックはできない
- 金融サイトなどならば、HPKPを使う価値はあるが、単なる情報提供サイト なら、その必要もない。HPKP設定ミスによるサービス停止は、中間者攻撃よりも大きな脅威だ
- max-ageを短くすることにより問題を緩和できる
