摩斯拉公司 關於在 Firefox 的夜間版本中開始測試檢測已撤銷憑證的新機制 - 。 CRLite 可讓您針對使用者係統上託管的資料庫組織有效的憑證撤銷檢查。 Mozilla 的 CRLite 實現 根據免費的 MPL 2.0 許可證。 產生資料庫和伺服器元件的程式碼寫在 去。 新增至 Firefox 的客戶端部件用於從資料庫讀取數據 用 Rust 語言。
使用基於仍在使用的協定的外部服務進行憑證驗證 （線上證書狀態協定）需要保證網路訪問，導致請求處理有明顯的延遲（平均350ms）並且在保證機密性方面存在問題（響應請求的OCSP伺服器會收到有關特定證書的信息，可以用來判斷是否有什麼證書）用戶打開的網站）。 也可以根據清單進行本地檢查 （憑證撤銷清單），但這種方法的缺點是下載的資料非常大－目前吊銷憑證的資料庫佔用約300 MB，而且還在持續成長。
為了阻止已洩露並被證書頒發機構撤銷的證書，Firefox 自 2015 年起使用了集中式黑名單 與服務電話結合 識別可能的惡意活動。 一個CRL，例如 在 Chrome 中，充當中間鏈接，聚合來自證書頒發機構的 CRL 列表，並提供單個集中式 OCSP 服務來檢查已吊銷的證書，從而可以不直接向證書頒發機構發送請求。 儘管在提高線上憑證驗證服務的可靠性方面做了很多工作，但遙測數據顯示，超過 7% 的 OCSP 請求超時（幾年前這個數字為 15%）。
預設情況下，如果無法透過 OCSP 進行驗證，瀏覽器會認為該憑證有效。 該服務可能由於網路問題和內部網路限製而不可用，或被攻擊者阻止——要在 MITM 攻擊期間繞過 OCSP 檢查，只需阻止對檢查服務的存取。 部分為了防止此類攻擊，已經實施了一項技術 ，它允許您將 OCSP 存取錯誤或 OCSP 不可用視為憑證問題，但此功能是可選的，需要對憑證進行特殊註冊。
CRLite 允許您將所有已撤銷憑證的完整資訊整合到一個易於更新的結構中，大小僅為 1 MB，這使得在客戶端儲存完整的 CRL 資料庫成為可能。
瀏覽器將能夠每天同步其有關已撤銷憑證的資料副本，並且該資料庫在任何條件下都可用。
CRLite 結合了來自 、所有已頒發和吊銷證書的公共日誌以及互聯網上掃描證書的結果（收集證書頒發機構的各種 CRL 列表並匯總有關所有已知證書的信息）。 數據採用級聯方式打包 ，一種機率結構，允許錯誤檢測缺少的元素，但排除現有元素的遺漏（即，以一定的機率，可能會誤報正確的證書，但保證可以識別已撤銷的證書）。
為了消除誤報，CRLite 引入了額外的校正過濾等級。 生成結構後，將搜尋所有來源記錄並識別任何誤報。 根據此檢查的結果，建立一個附加結構，該結構級聯到第一個結構並修正由此產生的誤報。 重複此操作，直到完全消除控制檢查期間的誤報。 通常，創建 7-10 層足以完全覆蓋所有資料。 由於定期同步的原因，資料庫的狀態稍微滯後於 CRL 的當前狀態，因此使用 OCSP 協定對 CRLite 資料庫上次更新後頒發的新憑證進行檢查，包括使用 （在協商 TLS 連線時，由憑證授權單位認證的 OCSP 回應由服務網站的伺服器傳輸）。
使用布隆過濾器，來自 WebPKI 的 100 月份資訊片段（涵蓋 750 億個有效證書和 1.3 萬個已撤銷證書）能夠打包成 16 MB 大小的結構。 結構生成過程非常消耗資源，但它是在 Mozilla 伺服器上執行的，並且為用戶提供了現成的更新。 例如，以二進位形式，生成過程中使用的來源資料儲存在 Redis DBMS 中時需要大約 6.7 GB 的內存，而以十六進位形式，所有憑證序號的轉儲大約需要 40 GB 的記憶體。 聚合所有已撤銷和活動憑證的過程大約需要 20 分鐘，基於布隆過濾器產生打包結構的過程還需要 XNUMX 分鐘。
Mozilla 目前確保 CRLite 資料庫每天更新四次（並非所有更新都會傳遞給客戶端）。 增量更新的產生尚未實現 - 使用 bsdiff4（用於為版本建立增量更新）無法為 CRLite 提供足夠的效率，且更新量過大。 為了消除這個缺點，請規劃重新設計儲存結構的格式，以消除不必要的層重建和刪除。
CRLite 目前在 Firefox 中以被動模式運作，並與 OCSP 並行使用，以累積正確操作的統計資料。 CRLite 可以切換到主掃描模式；為此，您需要在 about:config 中設定參數 security.pki.crlite_mode = 2。
來源： opennet.ru