証明書失効リストの新たな役割
今月、Let's Encryptは証明書失効リスト（CRL）による証明書の失効をサポートするための新しいインフラストラクチャを稼働させました。10年以上前にオンライン証明書ステータスプロトコル（OCSP）によってほぼ置き換えられたにもかかわらず、最近のブラウザのアップデートによりCRLは新たな役割を得ています。ブラウザはユーザーのためにCRLを収集・要約することで、証明書の信頼できる失効を現実のものとし、Webのセキュリティとプライバシーの向上に貢献しています。この新しいインフラストラクチャが具体的に何をするのか、そしてそれがなぜ重要なのかについて説明しましょう。
失効の簡単な歴史
証明書が信頼できなくなった場合（たとえば、秘密鍵が侵害された場合）、その証明書は失効され、その情報は公開されなければなりません。そうすることで、将来誰もそれを信頼しなくなります。しかし、Web公開鍵インフラストラクチャ（Web PKI）の世界では、「失効は壊れている」という有名な格言があります。Web PKIの歴史において、TLS/SSL証明書がもはや信頼すべきではないと宣言するための主要なメカニズムは、証明書失効リスト（CRL）とオンライン証明書ステータスプロトコル（OCSP）の2つでした。残念ながら、どちらも大きな欠点があります。
CRLは基本的に、特定の認証局（CA）が発行したすべての失効済みの証明書のリストです。つまり、多くの場合非常に大きくなり、映画1本分ものサイズになることもあります。現在閲覧しているサイトの単一の証明書が失効しているかどうかを確認するために、巨大な失効済み証明書のリストをブラウザがダウンロードするのは非効率です。このようなダウンロードと確認の遅延によりWebページの読み込みが遅くなったため、OCSPが代替案として開発されました。
OCSPは、「各証明書ごとに個別のCRLがある場合」のようなものです。特定の証明書が失効しているかどうかを確認したい場合、ブラウザはCAのOCSPサービスに連絡することで、その1つの証明書のステータスのみを確認できます。しかし、OCSPインフラストラクチャは常に稼働している必要があり、他のWebサービスと同様にダウンタイムが発生する可能性があるため、ほとんどのブラウザは応答がないことを「失効していない」応答と同様に扱います。つまり、攻撃者はOCSP情報の要求をすべてブロックするだけで、証明書が失効していることを検出できないようにすることができます。CAのOCSPサービスへの負荷を軽減するために、OCSP応答は有効であり、約1週間キャッシュできます。しかし、これはクライアントが更新を頻繁に取得せず、失効後1週間は証明書を信頼し続けることを意味します。そしておそらく最悪なのは、ブラウザが訪問するすべてのWebサイトに対してOCSPリクエストを行うため、悪意のある（または法的強制による）CAが閲覧行動を追跡する可能性があることです。OCSPリクエストを行ったサイトを追跡することで。
したがって、既存のソリューションのどちらも実際には機能しません。CRLは非効率すぎて、ほとんどのブラウザはチェックせず、OCSPは信頼性が低すぎて、ほとんどのブラウザはチェックしません。より良いものが求められています。
ブラウザで要約されたCRL
最近進展を見せている可能性のあるソリューションの1つは、独自のブラウザ固有のCRLというアイデアです。異なるブラウザがこの機能を異なる方法で実装しているものの（例：MozillaはCRLiteと呼び、ChromeはCRLSetsと呼んでいます）、基本的なアイデアは同じです。
各ユーザーのブラウザが失効を確認したいときに大きなCRLをダウンロードする代わりに、ブラウザのベンダーがCRLを一元的にダウンロードします。彼らはCRLをブルームフィルタなどのより小さい形式に処理し、既存の迅速な更新メカニズムを使用して、新しい圧縮オブジェクトをインストールされているすべてのブラウザインスタンスにプッシュします。たとえば、Firefoxは6時間ごとに更新をプッシュしています。
つまり、ブラウザは事前に失効リストをダウンロードできるため、ページの読み込み速度が速くなり、従来のCRLの最悪の問題を軽減できます。失効チェックはローカルに保持され、プッシュされた更新は、最大で数日かかる可能性のあるOCSPキャッシュの期限切れを待つことなくすぐに有効になるため、OCSPの最悪の問題をすべて回避できます。
これらのブラウザで要約されたCRLの約束のおかげで、AppleとMozillaのルートプログラムは、すべてのCAが2022年10月1日までにCRLの発行を開始することを要求しています。具体的には、CAは、そのCAによって発行されたすべての証明書をカバーする1つ以上のCRLを発行し始め、それらのCRLを指すURLのリストを共通CAデータベース（CCADB）で公開することを要求しています。これにより、SafariとFirefoxは、失効の確認にブラウザで要約されたCRLチェックを使用するように切り替えることができます。
私たちの新しいインフラストラクチャ
Let's Encryptが設立されたとき、私たちはOCSPのみをサポートし、CRLをまったく生成しないという明示的な決定をしました。これは、当時のルートプログラムの要件ではOCSPのみが義務付けられており、両方の失効メカニズムを維持すると、バグがコンプライアンス違反につながる可能性のある場所が増えるためです。
CRLインフラストラクチャの開発に着手したとき、私たちはスケーラビリティを構築し、効率性とシンプルさへの私たちの重点を反映した方法で行う必要があることを知っていました。ここ数か月で、新しいインフラストラクチャを開発し、今後の要件に準拠したCRLを公開できるようにしました。各コンポーネントは軽量で、単一のタスクを実行することに特化しており、現在のニーズをはるかに超えてスケーリングできます。
Let's Encryptは現在、毎日2億を超えるアクティブな証明書を保有しています。これらの証明書すべてを同時に失効する必要があるインシデントが発生した場合、結果として生じるCRLは8ギガバイトを超えます。扱いにくくならないようにするために、CRLを128のシャードに分割します。各シャードの最悪の場合の最大サイズは70メガバイトです。シャードの数が変わらない限り、すべての証明書がCRLの再発行時に同じシャード内に残るように、慎重に構成された数学を使用しています。そのため、各シャードは一貫した範囲を持つミニCRLとして扱うことができます。
証明書の発行に関して従っているのと同じベストプラクティスに従って、すべてのCRLはRFC 5280と基本要件に準拠しているかどうかが確認された後、発行中間証明書によって署名されます。一般的なlintライブラリzlintはまだCRLのlintをサポートしていませんが、独自のチェックのコレクションを作成し、将来zlintにアップストリームすることを期待しています。これらのチェックは、コンプライアンス違反を防ぎ、シームレスな発行と更新サイクルを保証するのに役立ちます。
これらの新しい機能を開発する一環として、CRLの生成とパースの実装であるGo標準ライブラリにもいくつかの改善を加えました。今後、私たちとGoコミュニティ全体がCRLをより頻繁に使用するようになるにつれて、さらに多くの改善に貢献することを楽しみにしています。
発行するすべての証明書を網羅するCRLを生成しますが、証明書のCRL配布ポイント拡張機能にはこれらのURLを含めません。現時点では、基本要件で要求されているように、証明書には引き続きOCSP URLが含まれており、誰でもそれを使用して各証明書の失効情報を取得できます。新しいCRL URLはCCADBのみに公開されるため、AppleとMozillaのルートプログラムは、インターネット全体の潜在的に大量のダウンロードトラフィックに公開することなく、それらを使用できます。
失効の将来
Web PKIにおける失効が真に修正されるまでには、まだ長い道のりがあります。OCSPに関するプライバシー上の懸念は、すべてのクライアントがOCSPへの依存を停止するまで軽減されず、非ブラウザクライアントが失効情報を確実に確認するための優れた方法を開発する必要があります。
Web PKIコミュニティ全体と協力して、失効チェックをすべてのユーザーにとってプライベートで、信頼性が高く、効率的なものにすることを楽しみにしています。
より堅牢でプライベートな失効メカニズムの開発に関する私たちの取り組みに関心をお持ちの場合は、寄付で私たちをサポートするか、あなたの会社や組織が私たちの取り組みをスポンサーするよう促してください。非営利プロジェクトとして、私たちの資金の100％はコミュニティとサポーターからの寄付によって賄われており、皆様の支援に依存しています。