自堕落な技術者の日記

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買うかなぁ、、、

自堕落な技術者の日記 : ETSI 3rd Remote XAdES/CAdES Plugtest - livedoor Blog（ブログ）

来年2009年2月にETSIで長期署名フォーマット CAdES/XAdES の相互運用実証実験を行います。ETSIの主催するXAdESのテストとしては３回目、インターネットを用い日本からもリモートで気軽に参加できるテストとしては２回目、CAdESのテストとしては初めてのテストとなります。

ETSI 3rd Remote XAdES/CAdES Plugtestのために参加者の皆さんに検証してもらう失敗系のテストデータを作っているんですが、手持ちのCAdES実装ではOCSPの扱いがかな〜〜〜り不十分であることが発覚しました。実装もかなりイケテない、だめだこりゃ、、、トホホ、、、、

機能を足す前にリファクタリングだな、、、、こりゃ、、、、

MS KB960549 Some third-party Online Certificate Status Protocol (OCSP) clients may reject a response from an OSCP responder if this OCSP responder receives a Response Signing certificate from a Windows Server 2008 certification authority

Some third-party OCSP clients require that the value of the NoRevCheck extension is an ASN null value. Therefore, these third-party OCSP clients reject the response from the OCSP responder.

Windows Server 2008ではOCSPをネイティブサポートするようになっているんですが、Microsoft CAが発行するOCSPレスポンダ用の証明書のNoRevCheck拡張(※これってNoRevAvail拡張の間違いじゃないっすか？)があるときに、サードパーティのOCSPクライアントではNoRevCheck拡張の値がASN.1 NULLであることをチェックするそうなんですが、Microsoft CAが発行する証明書は拡張の値オクテットはASN.1 NULLではなく空のオクテットになっていて、そのために検証に失敗することがあるようなんです、、、、、時間があるときに環境探して見てみたいです。

HotFixも出ているってことなんすよね、、、、

というわけで、メモメモ、、、、

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の時と違ってちょっと怪しい気がします、、、、