Mozilla は問題のある TLS 証明書をチェックする CRLite を実装

モジラ社 発表した Firefox の夜間ビルドでの、失効した証明書を検出するための新しいメカニズムのテストの開始について - CRライト。 CRLite を使用すると、ユーザーのシステムでホストされているデータベースに対して効果的な証明書失効チェックを組織できます。 Mozilla の CRLite 実装 出版された 無料のMPL 2.0ライセンスに基づいて。 データベースとサーバー コンポーネントを生成するコードは次のように記述されています。 Python じゃ、行け。 データベースからデータを読み取るためのクライアント パーツが Firefox に追加されました 準備された Rust言語で。

現在も使用されているプロトコルに基づく外部サービスを使用した証明書検証 OCSP (オンライン証明書ステータス プロトコル) はネットワーク アクセスの保証を必要とし、リクエストの処理に大幅な遅延 (平均 350 ミリ秒) が発生し、機密性の確保に問題があります (リクエストに応答する OCSP サーバーは、特定の証明書に関する情報を受け取ります。この情報は、証明書が何であるかを判断するために使用できます)。ユーザーが開くサイト）。 リストに対してローカルでチェックする可能性もあります CRL (証明書失効リスト) しかし、この方法の欠点は、ダウンロードされるデータのサイズが非常に大きいことです。現在、失効した証明書のデータベースは約 300 MB を占有しており、その増加は続いています。

認証局によって侵害され失効した証明書をブロックするために、Firefox は 2015 年から集中ブラックリストを使用しています。 ワンCRL サービスコールと組み合わせて Googleセーフブラウジング 潜在的な悪意のあるアクティビティを特定します。 OneCRL のような CRLSセット Chrome では、認証局からの CRL リストを集約する中間リンクとして機能し、失効した証明書を確認するための単一の集中型 OCSP サービスを提供することで、認証局にリクエストを直接送信しなくても済むようにします。 オンライン証明書検証サービスの信頼性を向上させるために多くの取り組みが行われてきたにもかかわらず、テレメトリ データによると、OCSP リクエストの 7% 以上がタイムアウトになっています (数年前、この数字は 15% でした)。

デフォルトでは、OCSP 経由で検証できない場合、ブラウザは証明書が有効であるとみなします。 このサービスは、ネットワークの問題や内部ネットワークの制限、または攻撃者によってブロックされているために利用できない可能性があります。MITM 攻撃中に OCSP チェックをバイパスするには、チェック サービスへのアクセスをブロックするだけです。 このような攻撃を部分的に防ぐために、ある技術が実装されました。 必需品を使用すると、OCSP アクセス エラーまたは OCSP が利用できないことを証明書の問題として扱うことができますが、この機能はオプションであり、証明書の特別な登録が必要です。

CRLite を使用すると、失効したすべての証明書に関する完全な情報を、サイズがわずか 1 MB の簡単に更新できる構造に統合できるため、完全な CRL データベースをクライアント側に保存できます。
ブラウザは失効した証明書に関するデータのコピーを毎日同期できるようになり、このデータベースはどのような条件でも利用できるようになります。

CRLite は、次の情報を組み合わせます。 証明書の透明性、発行および取り消されたすべての証明書の公開ログ、およびインターネット上の証明書のスキャン結果 (認証局のさまざまな CRL リストが収集され、すべての既知の証明書に関する情報が集約されます)。 データはカスケードを使用してパッケージ化されます ブルームフィルター、欠落要素の誤検出は可能ですが、既存要素の欠落は除外する確率的構造です (つまり、一定の確率で、正しい証明書の誤検出は可能ですが、失効した証明書は確実に識別されます)。

誤検知を排除するために、CRLite は追加の補正フィルター レベルを導入しました。 構造を生成した後、すべてのソース レコードが検索され、誤検知が特定されます。 このチェックの結果に基づいて、追加の構造が作成され、最初の構造にカスケードされ、結果として生じる誤検知が修正されます。 この操作は、制御チェック中の誤検知が完全になくなるまで繰り返されます。 通常、すべてのデータを完全にカバーするには、7 ～ 10 個のレイヤーを作成するだけで十分です。 定期的な同期により、データベースの状態は CRL の現在の状態よりわずかに遅れるため、CRLite データベースの最後の更新後に発行された新しい証明書のチェックは、OCSP プロトコルを使用して実行されます。 OCSP Stapling (認証局によって認証された OCSP 応答は、TLS 接続をネゴシエートするときに、サイトにサービスを提供するサーバーによって送信されます)。

ブルーム フィルターを使用すると、100 億件のアクティブな証明書と 750 万件の失効した証明書をカバーする WebPKI からの 1.3 月の情報を 16 MB のサイズの構造に詰め込むことができました。 構造生成プロセスは非常にリソースを大量に消費しますが、Mozilla サーバー上で実行され、ユーザーには既成の更新が提供されます。 たとえば、バイナリ形式では、生成中に使用されるソース データを Redis DBMS に保存するときに約 6.7 GB のメモリが必要で、40 進形式では、すべての証明書のシリアル番号のダンプに約 20 GB が必要です。 すべての失効した証明書とアクティブな証明書を集約するプロセスには約 XNUMX 分かかり、ブルーム フィルターに基づいてパッケージ化された構造を生成するプロセスにはさらに XNUMX 分かかります。

Mozilla は現在、CRLite データベースが 4 日に XNUMX 回更新されることを保証しています (すべての更新がクライアントに配信されるわけではありません)。 デルタ更新の生成はまだ実装されていません。リリース用の差分更新の作成に使用される bsdiffXNUMX の使用では、CRLite に適切な効率が得られず、更新が不当に大きくなります。 この欠点を解消するために、ストレージ構造のフォーマットを見直して、不要なレイヤーの再構築や削除を排除することが計画されています。

CRLite は現在、Firefox でパッシブ モードで動作し、正しい操作に関する統計を蓄積するために OCSP と並行して使用されます。 CRLite はメイン スキャン モードに切り替えることができます。これを行うには、about:config でパラメータ security.pki.crlite_mode = 2 を設定する必要があります。

出所： オープンネット.ru