自堕落な技術者の日記

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

DigiCert

最近の証明書の話題(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対応してなかったんですよ。こりゃマズイなぁ、、、と。早速、対応させてみました。

最後のサンプルはいろんな証明書を簡単に作れるので、遊んでやってください。 そういう意味では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の解説」を見て勉強させてもらいました。ありがたや。ありがたや。

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

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のブランドの順序、発行日は以下のようになっていました。

認証局ブランド初プレ証明書発行日
DigiCert2013年11月01日
COMODO2014年01月23日
TAIWAN-CA2014年05月09日
Entrust2014年07月21日
AffirmTrust2014年10月27日
Symantec2014年11月11日
GlobalSign2014年11月28日
GeoTrust2014年12月08日
Thawte2014年12月08日
Buypass2014年12月10日
Network Solutions2014年12月15日
USERTRUST2014年12月16日
Trend Micro2014年12月22日
Starfield2014年12月23日
Go Daddy2014年12月23日
TERENA2014年12月29日
Trustwave2015年01月05日
Cybertrust2015年01月07日
VeriSign2015年01月12日
QuoVadis2015年01月14日
HydrantID2015年01月22日
Google UK2015年01月27日
Aetna2015年01月29日
IZENPE2015年02月04日
Certum2015年02月05日
Camerfirma2015年02月20日
NCC2015年03月30日
SECOM Trust2015年04月30日
Actalis2015年05月18日
WoSign2015年08月20日
CTの仕様策定や実装などでGoogleと協力関係にあったDigiCertが対応が早いのはいいとして、台湾のTAIWAN-CA(TWCA)が対応早かったんですねぇ。日本のベンダーさんも頑張っています。

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

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

認証局ブランドプレ証明書発行枚数
Symantec50760
DigiCert20856
GeoTrust17447
COMODO14573
Cybertrust13020
Go Daddy12635
Thawte9891
Entrust6616
GlobalSign6063
TERENA2363
QuoVadis1873
Google UK1861
Starfield1262
Network Solutions939
Trend Micro615
Certum367
VeriSign196
WoSign187
Trustwave177
SECOM Trust161
Buypass154
IZENPE116
TAIWAN-CA76
HydrantID37
Aetna34
NCC25
AffirmTrust10
Actalis7
USERTRUST7
Camerfirma4

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

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

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

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

おわりに

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

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

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