自堕落な技術者の日記

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を調べればこんな感じ、

Windows WSLでec.europa.euを調べればこんな感じで実行できます。

(絵文字使うんじゃね〜〜！！！)
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買うかなぁ、、、

サーバーの入れ替えに伴いウェブサーバのログデータを退避しました。今のウェブサーバーのソフトウェアは2004年10月頃から使っていますが、その辺りからテスト用にCRL(証明書失効リスト)を公開しています。
(途中、サーバーを停止させたりしている時期もありました。)

・2004年度後期 JNSA S/MIME WGのメーラー毎のS/MIME署名メール検証テスト
・2005年度後期 ECOM 2005年度 CAdES/XAdES長期署名相互運用性テスト
・2007年度 ECOM 2007年度 CAdES/XAdES長期署名相互運用性テスト
・実験後、テスト用署名データをECOMサイトで公開

2004年10月からのCRLの月毎のアクセス数をグラフにするとこんな感じ。





ECOMのテストはテストケース毎にCRLファイルを分けていたので、それなりのアクセス数になっています。ECOMのテスト後にテスト用の署名データや証明書などを公開するようにしたので、テスト後もちらほら継続的にアクセスはあったりします。

2004年10月からのCRLのアクセスの国内からの割合はこんな感じ。国内実験がメインなので7割が日本っていうのは当然ですが、国外からも意外にあったりします。





国外からのアクセスの内訳を見てみるとこんな感じ。





フランス、スペインはECOMの2007年度の実験に参加してもらっているので、それなりにアクセスがあるのは当然なんですが、トルコ、ハンガリー、スウェーデンなどECOMテストに参加していない国からのアクセスも結構あったりします。ECOMの英語版のページでテスト用長期署名をダウンロードできるようにしてあるんですが、これを観て実際に長期署名検証をしようとしてみてくれてるんだろうと思います。

トルコはトルコ政府がETSIのリモートテストにも参加していたりして長期署名に真剣に取り組んでいるみたいですね。

しかし、パキスタンって本当かなぁ、、、ログ取得時期とGeoIPのデータの時期が間違っているのかなぁ、、、本当だとしたらちょっとびっくりですね。

これらのCRLは、ふらっとサイトに来てダウンロードして帰るような代物ではないので、署名の実装があって検証しようとしてみたという所では割と信憑性のある数字なのかな、、、とも思います。

SSH - Company - News

＜以下、引用＞
The Innovative Patent Increases Security and Efficiency by Managing Certificates in a Public Key Infrastructure
SSH Communications Security Corp. (OMX:SSH1V), a world-leading provider of enterprise security solutions and end-to-end communications security, and the original developer of the Secure Shell protocol, today announced the issuance of a key patent covering a new, streamlined process of issuing certificate revocation lists (CRLs) and eliminating the need for private keys to be present during the periodic publishing of CRLs.

The U.S. Patent No. 7,356,693, “Method for Producing Certificate Revocation Lists,” is designed to create an easier way to operate a Public Key Infrastructure (PKI) hierarchy while reducing the practical work needed to produce and distribute CRLs. Producing multiple CRLs in volume at one time, keeping them secure until needed and publishing them in the directory, is a cost-effective and more efficient best-practice than creating individual CRLs at various times, also, easing the burden on administrators.

2008年9月23日にSSH社からCRLを事前にいろんなパターンでCRLを生成しておき、
そのうちのCRL本当にLDAPに置いて配布するという特許が出たそうです。

なんかRFC 5019 Lightweight OCSPみたいな話ですね。

CAの秘密鍵がいつどんな目的で使われたか監査ログに残ると思うんですが、ずら〜〜っと無駄なものまで出てログなんか取ってられないので、むしろどれを配布に使ったかのログだけを見ないといけないんでしょうね、、、、、、

OCSPの時と違ってちょっと怪しい気がします、、、、

JPKI認証局の運営に関する情報(自己の電子証明書の有効性確認にかかる障害発生のお知らせとお詫び)

証明書シリアル番号が(16進数)00で始まる証明書の場合、
失効していたとしても「失効していない」と表示されてしまう障害が起きているそうです。2008年7月18日(金)には復旧するそうです。

証明書のシリアル番号はASN.1 INTEGER型でRFC 3280では非負でなければ
ならず、INTEGER型は2の補数表現されるので例えば先頭が"7F"より大きくなることはなくそのような場合には先頭の"00"がつきます。

RFC 3280 4.1.2.2 Serial number

The serial number MUST be a positive integer assigned by the CA to
each certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer name and serial number identify a unique
certificate). CAs MUST force the serialNumber to be a non-negative
integer.

当時者でないので、よくわからないのですが証明書失効リストの方で先頭"00"のケースで正しく失効リストに記載されていなかったか、失効検証のロジックに不具合があるか、、、っていうところなんでしょうか、、、、

いずれにせよ証明書失効リストは誰でも取得できるわけではないので、これ以上のことはわからないですね、、、･ﾟ･(ﾉД`;)･ﾟ･