自堕落な技術者の日記 : SSL証明書 - livedoor Blog（ブログ）

SSL証明書

2018年04月11日23:39

カテゴリ: SSL証明書

最近の証明書の話題(2): CloudFlare DNS 1.1.1.1サイトのIPv6証明書

今日も、証明書ハンターネタの第二弾ということで、、、

4月1日に公開になったAPNICとCloudFlareが提供する、レスポンスが速くて、プライバシーに配慮した噂の1.1.1.1というパブリックDNSサービスが利用できるようになりました。DNSサーバーは、通信が暗号化されていても、どのIPからどのIPにアクセスしたかという記録が残るので、それをターゲティング広告などに使ったりするそうです。このDNSサービスは、プライバシーに配慮してログの保存期間を1週間とし、広告などに使われないようにしているそうです。

こんな記事見ちゃうと通信全体で早くなるのかどうかはよくわからないですね。で、このサービスの公式紹介サイトhttps://1.1.1.1/なんですが、FQDNでなく、IPアドレスで発行しているわけです。何やらおもしろそうじゃないですか。早速、証明書をダウンロードしてみて、内容を見てみましょう。


$ openssl x509 -in ip1.1.1.1.cer -noout -text
Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number:
      05:6c:de:b4:14:65:ff:27:07:16:c0:6e:91:16:2e:19
  Signature Algorithm: <font color=“orange”>ecdsa-with-SHA256</font>
    Issuer: C=US, O=DigiCert Inc, CN=DigiCert ECC Secure Server CA
    Validity
      Not Before: Mar 30 00:00:00 2018 GMT
      Not After : Mar 25 12:00:00 2020 GMT
    Subject: C=US, ST=CA, L=San Francisco, O=Cloudflare, Inc.,
             CN=*.cloudflare-dns.com
    Subject Public Key Info:
      Public Key Algorithm: id-ecPublicKey
        Public-Key: (256 bit)
        pub: 
          04:b2:45:0b:31:ac:50:63:ce:21:e6:7c:34:23:1a:
          c5:c1:53:45:96:97:7a:31:87:bb:e0:ea:1d:95:f5:
          ff:25:04:ca:75:f0:f6:3f:b5:df:51:e9:5b:c9:3d:
          ad:b4:03:05:73:20:92:3e:74:be:8e:4b:1b:e2:68:
          86:44:6e:62:bb
        ASN1 OID: prime256v1
        NIST CURVE: P-256
    X509v3 extensions:
      X509v3 Authority Key Identifier: 
        keyid:A3:9D:E6:1F:F9:DA:39:4F:C0:6E:E8:91:CB:95:A5:DA:31:E2:0A:9F
      X509v3 Subject Key Identifier: 
        DF:97:4D:E5:43:B3:B0:41:A7:42:F2:90:CF:89:7F:AE:12:57:84:E1
      X509v3 Subject Alternative Name: 
        DNS:*.cloudflare-dns.com,
        IP Address:1.1.1.1,
        IP Address:1.0.0.1,
        DNS:cloudflare-dns.com,
        IP Address:2606:4700:4700:0:0:0:0:1111,
        IP Address:2606:4700:4700:0:0:0:0:1001
      X509v3 Key Usage: critical
        Digital Signature
      X509v3 Extended Key Usage: 
        TLS Web Server Authentication, TLS Web Client Authentication
      X509v3 CRL Distribution Points: 
        Full Name:
          URI:http://crl3.digicert.com/ssca-ecc-g1.crl
        Full Name:
          URI:http://crl4.digicert.com/ssca-ecc-g1.crl
      X509v3 Certificate Policies: 
        Policy: 2.16.840.1.114412.1.1
          CPS: https://www.digicert.com/CPS
        Policy: 2.23.140.1.2.2
      Authority Information Access: 
        OCSP - URI:http://ocsp.digicert.com
        CA Issuers - URI:http://cacerts.digicert.com/
                         DigiCertECCSecureServerCA.crt
      X509v3 Basic Constraints: critical
        CA:FALSE
  Signature Algorithm: ecdsa-with-SHA256
     30:65:02:31:00:8e:8c:b2:d8:e8:21:d6:2d:7f:2a:1f:7e:a6:
     c3:1c:d4:e0:a1:95:02:2f:40:5e:80:92:88:d9:4b:cc:a5:89:
     aa:fa:9b:ca:b9:9e:a0:b7:a9:ed:21:1d:1d:1f:13:1c:0b:02:
     30:2e:79:64:67:1d:7e:10:27:d9:68:a8:c8:6c:3e:4d:cd:07:
     40:ac:d2:64:ad:b0:d0:cd:1b:af:c3:a4:26:30:ed:79:a3:a0:
     6d:f2:d4:b4:bb:66:46:59:9a:a3:67:d9:0f

この証明書の特徴はこんなとこ：

DigiCertが発行している
楕円曲線(ECC)の公開鍵証明書
主体者別名(subjectAltName)にIPv4アドレスとIPv6アドレスが記載されている

いや～～～、すごいですね。証明書ハンターなのでいろいろ証明書を探して見てますけど、IPv6アドレス向けのプライベートじゃない証明書を初めて見ましたよ。これは、早速コレクション対象ですよっ！！！

先日、データ通信協会のセミナーで総務省の方の講演を拝聴したんですが、「iPhoneとかスマホのおかげでIPv6って本当に普及しちゃった。」と仰っていました。ホント、その通りなんですねぇ。日本からGoogleへのアクセスは17%がIPv6なんだそうです。 Apple iOSでは、IPv4だと(わざと？)遅延させる仕組みが入るそうで、今後、IPv6への移行が加速されるだろうとの事でした。

実は、趣味で作ったjsrsasignというJavaScript実装の暗号/PKI関連ライブラリを公開しているんですが、よく考えてみたらIPv6対応してなかったんですよ。こりゃマズイなぁ、、、と。早速、対応させてみました。

ipv6tohexというIPv6アドレス表記文字列と16進数に変換する関数と
hextoipv6という16バイトの16進数からRFC 5952で推奨された正規化されたIPv6アドレス表記に変換する関数と
subjectAltNameなどで使われるGeneralNameクラスをIPv6対応にし
X509クラスのgetExtSubjectAltName2メソッドで、SubjectAltNameのパーザーをIPv6対応にし
証明書生成ツールのサンプルでIPv4、IPv6アドレスを主体者別名(subjectAltName)で使えるようにしました。

最後のサンプルはいろんな証明書を簡単に作れるので、遊んでやってください。そういう意味ではOpenSSLの証明書の表示は

IP Address:2606:4700:4700:0:0:0:0:1001

のような感じでRFC 5952で正規化されているわけではない、一意じゃない表記のやつなんですねぇ。正規化したらこうなりますよね。

IP Address:2606:4700:4700::1001

RFC 5952なんて知らなかったんですが、JPNICさんの「RFC5952-IPv6アドレスの推奨表記 IPv6アドレス表記の柔軟性が起こす問題とRFC5952の解説」を見て勉強させてもらいました。ありがたや。ありがたや。

てなわけで、今日もナイスな証明書をゲットだぜ。今日はこの辺で、、、

タグ：: #X.509証明書; #証明書; #SSL; #DNS; #IPv6; #jsrsasign; #IPv4; #DigiCert

2018年04月11日02:52

カテゴリ: SSL証明書

最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行

どうも、証明書ハンターです。最近、個人的におもしろい証明書の話題がポンポン出てきたので、何回かに分けてご紹介したいと思います。

山賀さんのFacebookのフィードを見ていたら、韓国政府PKIでまずい証明書を発行したというニュース(Google翻訳で読んでくださいw)を教えていただきまして、ハンターとしてはゲットしてコレクションに加えておきたいところ。

その問題というのは、韓国政府PKIが慶尚南道教育庁に不適切なワイルドカードSSLサーバー証明書を発行してしまったというもの。慶尚南道は韓国の南東、釜山のすぐ北にあるのだそうです。

韓国のサイトは日本と同じでセカンドレベルを組織種別とする属性型ドメイン名を採用していて、政府系ドメインは「go.kr」のようになっていますが、以下のドメインに対してワイルドカードSSLサーバー証明書を発行してしまいました。

*.hs.kr - 高校
*.ms.kr - 中学校
*.es.kr - 小学校
*.kg.kr - 幼稚園
*.sc.kr - その他の学校
*.or.kr - 非営利団体

すると、この証明書と秘密鍵があれば、韓国の任意の学校のフィッシングサイトを作ったり、暗号通信の盗聴や改ざんができてしまう可能性があり、韓国政府認証基盤(GPKI)の信頼が揺らいでしまったとニュースでは指摘しています。一体、どんなドメイン確認処理(validation)をしてたんですかねぇ？

Google先生に聞いてみてもすぐはそのマズイ証明書が見つかりませんでしたが、Certificate Transparencyのログを見てみたら。ココにありました。(CTありがと～～～～、昔非難しててごめんよ～～～(泣))

subjectAltNameを見てみると


X509v3 Subject Alternative Name: 
    DNS:www.haeseong.kr
    DNS:haeseong.kr
    DNS:www.gandhischool.net
    DNS:gandhischool.net
    DNS:www.milgo.org
    DNS:milgo.org
    DNS:*.go.kr
    DNS:*.co.kr
    DNS:*.sc.kr
    DNS:*.or.kr
    DNS:*.kg.kr
    DNS:*.hs.kr
    DNS:*.ms.kr
    DNS:*.es.kr
    DNS:*.gne.go.kr
    DNS:support.gne.go.kr

一部の特定の高校まで入ってるのもどうかと思いますが、バッチリワイルドカード入っちゃってますねぇ、、、って、あれれ？？？「*.go.kr」の政府向けドメインや「*.co.kr」企業向けのワイルドが入っちゃってるじゃないですか？？？ニュースにある証明書のキャプチャと違うぞ！！！学校サイトなんかど～～でもよくて、それより、全韓国政府系ドメイン向けや、全韓国企業向けのワイルドの方が、特大の問題で、盗聴なんかされたらマズイんじゃないですかねぇ。そのあたりは報道が忖度したんですかねぇ、、、

ただ、このSSLサーバー証明書は、ルートが韓国政府のルートCAで、ChromeでもFirefoxでも信頼されたルートに入っていないから、韓国の人以外が被害に合うことは、ほとんど無いんじゃないかと思います。

で、この証明書がちゃんと失効されているか知りたかったんですが、CRLDPが

URI:ldap://ldap.epki.go.kr:389/cn=crl1p1dp14256,ou=CRL,ou=GPKI,o=Government of Korea,c=kr?certificateRevocationList;binary

LDAP URIになっていて、このLDAPサーバーがどうも匿名アクセスができず、普通にはCRLを取得できなそうにないんです。ChromeもFirefoxもIEもLDAP URIによる失効検証は(IEとADサーバーの組み合わせ以外は？)サポートしていないので、CRL失効検証はできず、OCSPもないようなので、どうやってブラウザで失効検証すりゃいんですかね？韓国のPKIに詳しいお友達がいる方は、教えていただけると嬉しいです。

というわけで、韓国GPKIのマズイ証明書発行のニュースを紹介し、私は無事、おもしろい証明書「ゲットだぜ！」

今日はこの辺で、、、あと二本ぐらい、近日中に書きたいと思ってます。

追記(2018.04.11)

他の韓国GPKI発行の証明書を見ていたら、HTTPからCRLを取れるようになっているようで、LDAP URIの情報から当該のCRLを取得することができました。で、中身を見てみたところ、このマズイ証明書も含め、現時点で一枚も失効させている証明書はありませんでしたので、一応ご報告。

追記(2018.04.14)

ちょっと探しものをしていたところ見つけた、韓国GPKIが発行している

Subject DN: CN=e-csinfo.*.go.kr
SAN DNS: e-csinfo.*.go.kr

のこのワイルドカード証明書もとても怪しい。管理主体が全くわからず、全省庁の e-csinfo.*.go.kr サイトを保護しているって、これ何だ？？？具体的なサイトは jbe.go.kr、 sen.go.kr などがあるようで、共通管理はされているっぽいんだけど。

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年05月02日22:14

カテゴリ: SSL証明書; PKI

Amazon AWSの認証局が少し怪しい件

Amazon AWSのELBとCloudFrontで使えるらしい、無料の証明書発行サービスで、AWS Certificate Manager(ACM)というのがあるそうです。([参考1])。ちょっと気になったきっかけはJavaからHTTPSで繋ぐと検証失敗するケースがあった

はてブを垂れ流すだけのフレンズ@matsuu
ん？これJRE同梱のルート証明書にACMのルート証明書が含まれてなかったってことか。どのバージョンから対応してるんだろ。決済連携などで決済会社の環境が古くてACMが使えないパターンありそう。 / “JavaクライアントからAWS…” https://t.co/pf9J6QRSTD
2017/04/30 11:57:07

というので、ちょっと見始めたらドツボにはまったので、少しメモを書き残しておこうかとおもいます。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Javaで繋がらないとなると、ルート証明書や中間CA証明書が入ってないんだろうと疑ってみるとおもいます。とりあえず、ブラウザで繋いだりしてみました。Windows 7のChromeやIEだとこんなパス。
view-ch-ie
Mac OS X(や多分iOSも)だとSafariでもChromeだとこんなパス。
safari-view
FirefoxだとOSによらず、WindowsでもMac OS Xでもこんなパス。
view-ff-chain
クライアント毎に使われている信頼するルート証明書が違うようです。 Starfieldルートになっているケースもありますね。調べてみると、AmazonはGoDaddyからStarfieldルート認証局を一つ買ったのだそうです。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Amazonの証明書発行サービスはAmazon Trust Servicesというのだそうで、証明書ポリシ、認証実施規程などの文書、ルート証明書、中間CA証明書などが置いてあるリポジトリはこちらにあるようです。

リポジトリをよく見てみると、クロス証明書(片方向相互認証証明書、中間CA証明書)のリストがあるんですが、ハッシュと証明書のリンクが張ってあるだけで、大した説明もなくえらく不親切なページですよね。認証局の構成がよくわからなかったので、これを元に図にしたのがコレです。(かなりの力作だとおもいます。)
ca-structure

なんかCAの鍵使いまわしてないですか？

このクロス証明書のリストで気になったのが、各Amazon Root 1～4に対して、origとそうじゃないやつ、Starfieldに関してはv2とそうじゃないやつがある所です。例えば、Amazon Root 1のorigとそうじゃないやつを比較してみると以下の3点が違うだけで、

シリアル番号が違う
notBeforeが違う(origが2015年10月で、orig無しが2015年5月)
authorityInfoAccess拡張のcaIssuerのURLが少し違う。 http://{crl,crt}.rootg2.amazontrust.com/rootg2.cer となっている。origがcrlで、origなしがcrt。

とほとんど同じで、caIssuerを直したいだけのつまらない理由のために、中間CA証明書を再発行したようです。これって中間CAの鍵を使いまわしてますよね。マズくないんですかね？さらに問題なのは、

どちらが正しい証明書なのかわからない。
ファイル名からはorigが古いように見えるが、 notBefore的には逆にorigが新しいようにも見える。
どちらか一方を失効しているわけでもなく、どちらも有効。
パス検証としてはどちらを使っても検証成功となるが、そんな事でいいのか？
将来、{crl,crt}.rootg2.amazontrust.comのいずれかを無くす計画があると思うが、それが明らかになっていない。

といった所です。ちなみに、caIssuerに記載されたURLは、今の所はどちらもアクセス可能なようです。両方にアクセスできるなら、なおさら中間CA証明書再発行の必要があったんですかねぇ？単に、DNSの別名、CNAMEレコードの設定だけの問題なんじゃないですかねぇ。また、本当はどちらに寄せたいと思っているのかも明らかにされてませんよねぇ。

同様に、Starfield Class 2 CAからStarfield Services Root CA G2に発行している中間CA証明書も怪しくて、シリアル番号とnetBeforeだけが違う証明書があります。どちらも失効していません。こんなことして大丈夫なんですかねぇ？最近、Certificate Transparency(CT)でSSLサーバー証明書全ての発行履歴残されており、 (私は最初はCTは嫌いだったのですが、) 認証局が問題あると、 (シマンテックのように、、、、) いろんな人が指摘してくれます。中間CA証明書の発行についても、CTログに残しておかないと、ヤバイ運用があるんじゃないかなぁ、、、、と思います。

Amazonの認証局はWebTrust認定もしており、Ernst Youngが監査しているそうですが、こんなんで本当に大丈夫なんですかね？

Java 8?のcacertsのaliasについて

Amazon AWSやACMとは全く無関係ですが、最近自分は、Javaはめっきり触らなくなってしまい、今回の件でかなり苦労しました。Javaの信頼する認証局のためのキーストアファイルであるjre/lib/security/cacertsファイルなんですが、中のファイルを取り出そうとすると、そんなファイルは無いと怒られてしまいました。よく見ると使ってみた新しい8u121では、aliasはこのようになっており、


% keytool -list -keystore jre/lib/security/cacerts
　　：中略
globalsigneccrootcar5 [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 1F:24:C6:30:CD:A4:18:EF:20:69:FF:AD:4F:DD:5F:46:
3A:1B:69:AA
starfieldservicesrootg2ca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63:
E8:25:6F:3F
ttelesecglobalrootclass2ca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF:
17:D8:94:E9
addtrustqualifiedca [jdk],2016/08/26, trustedCertEntry,
証明書のフィンガプリント(SHA1): 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E:
C5:4D:8B:CF
　　：後略

例えば「starfieldservicesg2ca」だけではだめで、表示されている通り「starfieldservicesg2ca [JDK]」のようにちゃんと[JDK]までつけないといけなくなったのだそうです。知らなかったし、ハマりました。

GWなもんで、今日はこんなとこで。

参考リンク

A look at AWS Certificate Manager: ACMを使い始めるときに参考になる。ACMを使ったサイト。
Free SSL With Amazon’s AWS Certificate Manager (ACM): ACMを使い始めるときに参考になる。(その2)
ACM FAQ: 公式サイトのFAQ

タグ：: #Amazon; #AWS; #ACM; #AWS-Certificate-Manager; #Starfield; #ルート認証局; #認証局; #証明書チェーン

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

2015年11月05日23:55

カテゴリ: SSL証明書

(小ネタ)Let's Encryptベータ証明書発行記念！11/5までの本番環境の証明書発行推移

無料で楽ちんポンのDV証明書発行サービスで話題のLet's Encryptですが、ベータプログラムが開始され、本番環境のルートを使用した証明書が発行されるようになり、申し込まなきゃと思っていたところ、自分のもっていたドメインも切れており、仕事もちょっと忙しくて完全に出遅れてしまい、こりゃInvitationくるのは無理かなぁ、、、と、半ば諦めてたんですが、今朝、何やらInvitationが来て、無事本番ルートを使ったベータの証明書に入れ替えることができました。ちょっとうれしい。

記念に発行枚数推移をグラフにしてみました。9/12に本番ルートとなる最初の証明書が発行され、10/26あたりにベータの証明書発行が開始され、11/4から急に発行枚数が増えているのがわかるかと思います。

Internet Week 2015で、今年のSSL/TLSのトピックやら、Let's Encryptの話なんかをしますので、よかったら来てください。

2015年10月03日12:44

カテゴリ: Certificate Transparency; SSL証明書

Deep Inside Certificate Transparency (その1)

Certificate Transparency(以下CT)には色々問題があって何だかな～～～と思っているわけですが、山がそこにあったら、登りたくなるのもまた人情（＾＾； CTログサーバーや格納されているデータについて、いろんなツールを作りながら調査をしています。何回かに分けて、CTについてわかったことを書いていこうと思ってます。

プレ証明書について

CTに対応していることを示すために、幾つか方法はあるのですが、実際に有効になっているのは発行する証明書にSigning Time Stamp(SCT)拡張を埋め込むことです。TLSの拡張やOCSPとついでに渡すという方法の実装を見たことがありません。

SCT拡張を含めるためにはプレ証明書なる証明書が必要になるんですが、プレ証明書がどんなものか、どんなフローで発行されるのかはこのスライドで説明しています。DigiCertさんの幾つかのページでもプレ証明書について解説されているのでよかったらご覧ください。 [1] [2] [3]

これまでにCTの仕組みが導入される前の証明書、CTに対応する予定のなかった証明書に関してはCTのログサーバーに普通にX.509証明書のチェーンが格納されるんですが、CTにまともに対応しようとしているベンダーの証明書は、プレ証明書のチェーンが格納されています。Chromeで「公開監査情報があります」と表示されるものについても、プレ証明書ベースのSCT拡張がX.509証明書に含まれているものしか、このように表示されないと思います。

今日の時点で、Google pilotのCTログサーバーには約670万の証明書チェーンが登録されていますが、そのうちプレ証明書として登録されているもの(=Chromeで公開監査ありと表示されるもの)は16万枚分しかありません。

プレ証明書の発行枚数推移

Google pilotログサーバーへのエントリの登録自体は2013年3月26日から、既存の証明書(パス)について登録が開始されていますが、CT導入以降のプレ証明書発行枚数推移をグラフで見てみましょう。
blog-pre
最初のプレ証明書がGoogle pilotのCTログサーバーに登録されたのが、2013年11月で、プレ証明書というかSCT対応の証明書発行をサービスとして正式にサポートし始めたのは2014年12月頃であることがわかります。

CTの対応が早かったのはどこの認証局(ブランド)か

2015年9月時点で、96の中間認証局(サブCA)、30のブランドがプレ証明書を発行しています。プレ証明書の発行が早かった30のブランドの順序、発行日は以下のようになっていました。

認証局ブランド	初プレ証明書発行日
DigiCert	2013年11月01日
COMODO	2014年01月23日
TAIWAN-CA	2014年05月09日
Entrust	2014年07月21日
AffirmTrust	2014年10月27日
Symantec	2014年11月11日
GlobalSign	2014年11月28日
GeoTrust	2014年12月08日
Thawte	2014年12月08日
Buypass	2014年12月10日
Network Solutions	2014年12月15日
USERTRUST	2014年12月16日
Trend Micro	2014年12月22日
Starfield	2014年12月23日
Go Daddy	2014年12月23日
TERENA	2014年12月29日
Trustwave	2015年01月05日
Cybertrust	2015年01月07日
VeriSign	2015年01月12日
QuoVadis	2015年01月14日
HydrantID	2015年01月22日
Google UK	2015年01月27日
Aetna	2015年01月29日
IZENPE	2015年02月04日
Certum	2015年02月05日
Camerfirma	2015年02月20日
NCC	2015年03月30日
SECOM Trust	2015年04月30日
Actalis	2015年05月18日
WoSign	2015年08月20日

CTの仕様策定や実装などでGoogleと協力関係にあったDigiCertが対応が早いのはいいとして、台湾のTAIWAN-CA(TWCA)が対応早かったんですねぇ。日本のベンダーさんも頑張っています。

プレ証明書の発行枚数順位

次にプレ証明書の発行枚数で見てみましょう。大手が多いのは当たり前として、 Cybertrustさん頑張っている感がありますね。そういえば、StartSSLはどうなってるんでしょうか。 10枚程度以下のところは、まだテスト中って感じですかね。

認証局ブランド	プレ証明書発行枚数
Symantec	50760
DigiCert	20856
GeoTrust	17447
COMODO	14573
Cybertrust	13020
Go Daddy	12635
Thawte	9891
Entrust	6616
GlobalSign	6063
TERENA	2363
QuoVadis	1873
Google UK	1861
Starfield	1262
Network Solutions	939
Trend Micro	615
Certum	367
VeriSign	196
WoSign	187
Trustwave	177
SECOM Trust	161
Buypass	154
IZENPE	116
TAIWAN-CA	76
HydrantID	37
Aetna	34
NCC	25
AffirmTrust	10
Actalis	7
USERTRUST	7
Camerfirma	4

どんなツールをつくったか

調べるにあたっては、PerlやNode(+jsrsasign)などで幾つかツールを作ったりぼちぼち環境を整備しています。公開してもいいんですけど、ドキュメント整備したり、コマンドラインオプションなどちゃんと作り込まないと、「ドキュメントがないから使いもんになんね～～！！」とか怒られて非常にヘコむんすよね。オープンソースなんだから、ちょっとコードみてくれりゃいいし、テストコード見りゃそのまま使い方ズバリなので、、、と思うんすけどね～～～。(jsrsasignの愚痴っぽくてすみません。)

ざっくりこんなツールを作ってみています。(他にもいろいろありますが、今回に関係する分だけ。)

プレ証明書とその解析情報だけを集めたSQLiteデータベース
ログエントリのleaf_input保存ツール
ログエントリのextra_data保存ツール
ログエントリからプレ証明書のチェーンを取り出して証明書として保管するツール
leaf_inputのデータファイルの解析ツール
プレ証明書のTBSCertificateからニセ署名をつけて適当な証明書に仕立てるツール (TBSCertificateビューアーって一般的に無いのでこれができると普通の証明書ビューアー(openssl x509コマンドなど)が使えるのでとても便利。)
ログエントリの登録日を表示するツール

おわりに

今回は、ログデータベースを調べてわかった、統計的な話を中心にレポートしました。次回はデータ構造、プレ証明書の内容なんかを中心に書けるといいなと思ってます。ではでは。

タグ：: #CertificateTransparency; #X.509証明書; #証明書; #透明な証明書; #証明書発行の透明性; #公開監査ログ; #Google; #DigiCert; #SSLTLS; #SSLサーバー証明書

2015年09月21日13:45

カテゴリ: Certificate Transparency; SSL証明書

Certificate TransparencyでわかったというThawteによるgoogle.com証明書の不正発行？？？

2015年9月19日(土)に「Symantec caught issuing rogue Google.com certificates」という記事が飛び込んできて、認証局、証明書、SSL関係のインシデントだとわくわくして飛びつくわけですが、ざっと読んでみると

大手セキュリティベンダーのSymantecの子会社で低価な証明書の発行サービスをやっている Thawteが、2015年9月14日にgoogle.com、www.google.com用のEV SSL証明書を、Googleに了解なく不正に発行していたことが、証明書の公開監査記録(Certificate Transparency)によりわかった。

という事のようです。厳格な審査で発行されるEV証明書でこのような問題が起きちゃうのはマズイですね～。Twitterではこのように言っている人もいて、

Alex Stamos@alexstamos
Big win for certificate transparency, which Symantec ironically resisted. Bravo @agl__ @BenLaurie and crew https://t.co/S0ytRkGxLe
2015/09/20 07:29:41

「Certificate Transparencyがあったおかげだね。よかったね。」みたいな雰囲気になっており、最悪だなぁと思っているわけです。今日はシルバーウィークで暇ですし、そのあたりの事を書いてみようと思います。

Certificate Transparencyとは

Certificate Transparency(以下 CT)とは、Googleの中の人が考えた仕組みで、全ての認証局から発行された過去から現在のSSLサーバー証明書(と証明書チェーン)を全て、ログサーバーと言われるサーバーに記録して公開し、不正な証明書の発行を世界中のみんなで早く見つけてましょうという仕組みです。一部の証明書発行サービスではもう対応が始まっており、「透かし入り証明書」などと言っている会社さんもありますが、「証明書発行の透明性」と言った方が意味を正しく伝えられると思います。

登録のためのプロトコル、保管されるデータフォーマット、仕組みは実験RFCにもなっており、ログサーバーやウェブブラウザや認証局の実装の実績が十分できたからという理由でスタンダードトラックに移す計画もされています。

CTに関しては、この1年ほど詳しく見ていて、様々な問題がある事からCTの利用について否定的な意見を持っていて、勉強会などでも数回お話させていただいています。

Certificate TransparencyによるSSLサーバー証明書公開監査情報とその課題の議論 from Kenji Urushima

関係者からのコメントを見てみる

今回の事件について、Googleのセキュリティ＆プライバシーとCT担当するプロジェクトマネージャーがブログで「Improved Digital Certificate Security」という記事を9月18日に発表しており、

9月14日19:20 GMT頃、Symantecの子会社ThawteのCAが google.comとwww.google.com用のプレ証明書(pre-certificate)を発行した。
このプレ証明書の発行は、Googleが要求したものではなく、Thawteが勝手に発行したもの。
Googleは、CTログからこの不正発行を発見した。
GoogleとThawte(Symantec)の情報交換により、Thawteの内部テスト目的の発行だとわかった。
GoogleはChromeに掲載される失効情報に使用された公開鍵を登録し無効化した。
現時点ではリスクは無い。

としています。これに対し、Thawte(Symantec)の関係者は同9月18日に「A Tough Day as Leaders」というブログを公開しており、

3つのドメインに対して数枚のテスト証明書を、内部で不適切に発行してしまった。
これらの鍵はThawteの管理下にあり、問題が発見されてからすぐに証明書を失効させた。
現時点ではインターネット上でいかなる危険もない。
当該のドメインのオーナーには報告した。
運用上のミス(human error)であったが再発防止に努める。

としています。この記事では「(我々は)セキュリティ業界のリーダーだから(云々)」という表現が何度もあって、コメント欄に「ちっともリーダーとしての対応じゃないじゃん」みたいな事が書かれていますが、その通りで、かなり無責任な報告だし、これで終わりにしてはならないと思います。報告は以下の点で不満が残ります。

いつ、不正証明書が発行され、問題が発覚し、Google等と協議し、証明書を失効させ、ブラウザの証明書ブラックリストに記載したか、時系列が明らかでない。
発行対象のドメインが明らかでない。google.com、www.google.comと一つは何か。
何のテストであったのか、テスト目的も明らかでない。
なぜ、テスト環境でやらなかったのか明らかでない。本来、本番環境でテストすべきでないのに。
なぜ、example.com等テスト用のドメインでやらなかったのか。特に、google.comは国家レベルでの盗聴に使われ問題になっているのに。
Thawte EV用認証局の運用規程違反である可能性が高いが、言及がない。
EV証明書を発行する認証局の監査基準である、 WebTrust for CA - EV監査基準と照らしてどうだったのか。

Thawteはこれまでにも幾つかの問題を起こしており、業界から「退場」頂いたほうがいいんじゃないかな、とも思ってしまいます。

さてさて、じゃぁCT覗いてみますか

先に、「プレ証明書」について簡単に説明しておきましょう。勉強会スライドのこのページをみるといいんですが、CTに証明書の発行ログが記録された証明書を発行するために以下の手順で発行されます。

認証局は発行予定の証明書のデータ(TBSCertificate)からプレ証明書を作ってログサーバーに送る。
ログサーバーでプレ証明書をログ登録し、登録の証拠としてSigned Certificate Timestamp(SCT)という署名データを認証局に送り返す。
認証局は、ログサーバーに登録された証拠であるSCTを証明書拡張領域に含め、証明書を発行する。

プレ証明書は、ログサーバーに登録される情報で、「認証局が証明書を発行しようとした証拠」としてログサーバーから公開されるものです。

Googleからの発表によると、プレ証明書が発行されたのは9月14日19:20 GMT頃だそうなので、 CTログサーバーにアクセスしてその時間あたりのログエントリをかき集めます。 CTのデータ構造やらアクセスAPIが全くイケてなくて、SSLサーバー証明書の発行対象ドメイン名や認証局から検索することは全くできず、とりあえず取り出してから調べてみないといけないんですよ。全く、検索させる気あるんですかねぇ？誰がこんな酷いAPI作ったんですかねぇ？

最悪なことには、ログサーバーのデータのミラーを会社に置いてきてしまい、家のMacでは、なぜか自作のPerlのツール群も動かないし(CPANモジュールが入らない)、 Rubyのツールもなぜか動かず(新しいバージョンだと動かない)、仕方ないのでNodeでちゃちゃっとツール作り直す始末、、、orz

とりあえず、Googleのpilotログサーバーに対して、9月14日の19:10～19:30頃の間のログエントリを取り出そうかとするわけですが、時間指定でエントリを取り出すこともできないので、まず、適当なインデックスのエントリを取り出して、時間のあたりをつけ登録時刻のタイムスタンプを調べ19:10のおおよそのインデックスの値を調べます。 Nodeで指定インデックスの時刻を調べるツールを作り、 9213980が19:09:03、9214310が19:31:22だとわかりました。その間のエントリ数は、 330個なんで、かなり絞れました。

その330個のログエントリを取り出して、X.509のちゃんとした証明書は除いて、プレ証明書だけをファイルに落とすツールを作り、19個のファイルを見ていくと、 19:20:01に発行されたインデックス9214148のものがgoogle.com用のプレ証明書そうだとわかりました。

なんでこんなに手間かっていうと、なんか、これらのプレ証明書用のログエントリが、 RFCで規定されているデータ構造と違うっぽくって、昔自分で作ったツールではパーズできないデータ構造になっちゃってるんですよね～～～～。多分、登録側がRFC違反しているのではと思うんですが、、、

次にプレ証明書を見てみます

目的のログエントリが見つかったので、プレ証明書を取り出して中身を見てみましょう。でも、データ見たらプレ証明書のASN.1構造じゃなくて、単に発行予定のTBSCertificateなんですよね。プレ証明書用の拡張も無いし、、、なんでだろ。RFC違反じゃないのかなぁ。 TBSCertificateの中身はこんな感じ。

シリアル番号：0A B4 C7 3C 41 3A 01 94 9F 23 78 F2 B2 29 F6 6C
署名アルゴリズム：SHA256withRSA
発行者名：CN=thawte EV SSL CA - G3, O=thawte, Inc., CN=US
有効期間：2015年9月14日 00:00:00 UTC～2015年9月15日23:59:59 UTC
主体者名：CN=google.com, L=Mountain view, ST=California, CN=US, SN=2158113, 
　　　　　businessCategory=Private Organization,
　　　　　organizationName=Symantec Corp, 
　　　　　jurisdictionOfIncorporationSP=Delaware, 
　　　　　jurisdictionOfIncorporationC=US
拡張領域：
　主体者別名：www.google.com, google.com
　基本制約：空
　鍵使用目的：digitalSignature, keyEncipherment
　CRLDP：http://ti.symcb.com/ti.crl
　証明書ポリシ：
　　OID：Thawte EV policy (2 16 840 1 113733 1 7 48 1)
　　CPS：https://www.thawte.com/cps
　　UNotice：https://www.thawte.com/repository
　拡張鍵使用目的：serverAuth, clientAuth
　発行者鍵識別子：F07051DAD32A914F5277D78677740FCE711A6C22
　AIA：
　　OCSP：http://ti.symcd.com
　　caIssuers：http://ti.symcb.com/ti.crt

いや～～、もろシマンテックが主体者になってるgoogle.comのEVSSL証明書になっちゃってますね～～。そりゃマズイですよね～～～。Thawteが勝手にSymantec主体者の証明書を発行しちゃっているのもマズイですよね。有効期間は1日とか言ってたけど、丸二日ですよね～～。

おわりに

結局は、Thawteのオペミスというか大失態で、本番環境で「神経がピリピリしてる最もマズイドメイン」の証明書を発行しちゃったってことなんですが、まともな認証局ソフトウェアを使っていれば内部の監査ログにも残るし、外に漏れなきゃ内部テストで済んでるんですが、認証局がしっかりしていれば、こんなことはあり得ないはずなんですよね～～～～。CTの運用だっていい加減だし、技術的にも完全性を持たない仕組みだし、プライバシーの問題もあるし、CT自体にもいろいろ問題があるのに、そんなことは全く注目されずに、「CTあってよかった。」みたいな論調になってて、つけいるスキを与えてしまいホント残念だな、と。他の証明書発行サービスというか認証ベンダーはThawteに対して怒っていいし、CA Browser Forumも、SSL Browser Forumみたいな実態になってるので全く当てにならないし、CA Security Councilあたりが厳しく問題にあたらないとマズイと思うんですけど、証明書発行サービスの及び腰には、ガッカリしてます。

追記1 (2015.09.21 20:05)

発行されているCRLを確認したところ、前述の google.com 不正証明書は、2015年9月16日 17:53:55 UTCに失効されていることがわかりました。どうせ有効期限切れなので失効させることもないと思いますけどね。

追記 (2015.10.01 20:00)

ログサーバーのプレ証明書の全ログエントリの解析用システムを作っていたので、報告遅くなりました。 Symantecの報告には

We learned on Wednesday that a small number of test certificates were inappropriately issued internally this week for three domains during product testing.

「3つのドメイン」とあったので、当該の証明書 www.google.comとgoogle.com以外にどこかもう一つあるのでは？と思い、プレ証明書のログエントリを全件調査し、また、当該の証明書が発行された時期を注意深く確認したところ、thawteから発行されたプレ証明書で、他に怪しいものはありませんでした。考えられる事として、

主体者識別名(DN)のCNのwww.google.com
主体者別名(subjectAltName)拡張のwww.google.com
主体者別名(subjectAltName)拡張のgoogle.com

を3つとして数えていて、結局は www.google.com、google.comの2つだけだったという事なんですかね。まぁ、良かったのかもしれません。

追記 (2015.11.01 23:59)

10月2日(or 10月13日)、Symantecが今回のインシデントに関して最終報告書を公開しました。
https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_10_13_2015v3b.pdf
レポートには大したことは書かれていないように見えます。

これに対してGoogleがブログに投稿しています。
Sustaining Digital Certificate Security (2015/10/28)
https://googleonlinesecurity.blogspot.jp/2015/10/sustaining-digital-certificate-security.html

タグ：: #X.509証明書; #CT; #CertificateTransparency; #Google; #Thawte; #Symantec; #EV証明書; #SSL証明書; #証明書不正発行

2015年05月03日10:19

カテゴリ: SSL証明書; Windows

Windowsルート証明書の更新プログラム(2014.09)と戯言など

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15～25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。

もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。
country

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。
keylen
RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね～～。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。
osroot
iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね？本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
Macのテキストエディタで開きUTF-16で保存する。
MacのExcelでインポートする。
インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
ルート証明書リストのExcelが完成！！！ (泣)
ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな！」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。
windialog
なんかこう、あれです、411もあるわけですから、フルコンプしたいですよねぇ？先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ？！！！

これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと！！！(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや～、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ～か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな？？？

ちょっと遠い関連記事

タグ：: #ルート認証局リスト; #トラストアンカ; #Windows; #Windowsルート証明書プログラム; #iOS; #Android; #MacOSX; #RootCAViewerLite

2015年03月19日20:57

カテゴリ: SSL証明書; Chrome

ChromeのSHA1証明書対応計画の一部延期(2015年3月12日発表)

2015年3月12日、Googleのフォーラムで、 Chrome開発チームでクロスプラットフォームの暗号・PKIコアの開発を担当しているRyan Sleevi氏から、 Chrome 41のリリースをSHA-1証明書の警告表示のマイルストーンとしていたものを Chrome 42に遅らせるとアナウンスがありました。

具体的にChromeバージョンとリリース時期と表示される警告アイコンは、以前の計画では以下のようになっていたものが
chromesha1-1
以下のようにChrome 41の箇所がChrome 42で変更が反映されるようになり、 1ヶ月半スケジュールが遅れるようになったという事です。
chromesha1-2

SHA1証明書警告表示の影響有無の簡単な確認方法

あるサイトがSHA1証明書の警告表示の影響があるかどうかは、簡単に確認できるツールを提供しているところが2つほどあります。

このDigiCertのやつはオススメで確認したいドメインを入力し「LOOKUP」ボタンを押せば、各Chromeのバージョンでどのように警告表示されるのかわかります。
chromesha1-3

(出典：DigiCert SHA-1 Sunset Tool)

証明書発行サービスの対応状況

2015年3月7日のGoogleからの発表を受けて、 2015年3月17日時点で証明書発行サービス各社が、掲載情報を更新したかどうか調べてみました。

おわりに

以上、3月12日のGoogleからの発表を受けて、遅くなりましたが、 Google ChromeのSHA1証明書警告表示の一部延期について説明しました。今日はこの辺で。

追記1

おっと、一言言い忘れた。GoogleのSecurity-devフォーラムでちょっと書かれたやつを以て、こんな大事な事を「アナウンスした」とするのは、Googleさんはちょっと誠意がなさすぎるし、ひどすぎるなと、、、せめてChrome Releasesのページなどでは紹介して欲しいし、ブログでも整理して解説して欲しいし、日本語の公式な情報も欲しいなぁと思いました。

タグ：: #Chrome; #SHA1withRSA; #SHA1証明書; #2017年1月; #警告表示; #HTTPS; #SSLTLS; #Chrome42; #延期

記事一覧(手作り)

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