憑證撤銷列表的新生命
本月，Let’s Encrypt 將啟用新的基礎設施，以支援透過憑證撤銷列表撤銷憑證。儘管線上憑證狀態協定在十多年來已大致取代了憑證撤銷列表，但隨著最近的瀏覽器更新，憑證撤銷列表正在獲得新的生命。透過為使用者收集並總結憑證撤銷列表，瀏覽器正使憑證的可靠撤銷成為現實，從而改善網路上的安全性和隱私。讓我們來談談這個新的基礎設施究竟做了什麼，以及為什麼它很重要。
撤銷的簡史
當憑證變得不可信任時（例如，因為其私鑰遭到洩露），該憑證必須被撤銷，並且該資訊必須公開，以便未來沒有人再依賴它。然而，在網路公鑰基礎設施（Web PKI）的世界中，有一個眾所周知的說法：撤銷已損壞。在網路公鑰基礎設施的歷史中，有兩種主要的機制可以宣告 TLS/SSL 憑證不再應受信任：憑證撤銷列表（CRLs）和線上憑證狀態協定（OCSP）。不幸的是，兩者都有重大的缺點。
憑證撤銷列表基本上只是列出特定憑證授權機構（CA）已頒發且已撤銷的所有憑證。這意味著它們通常非常大 – 很容易就達到整部電影的大小。您的瀏覽器下載一個龐大的已撤銷憑證列表，僅僅為了檢查您現在訪問的網站的單個憑證是否被撤銷，這是沒有效率的。這些緩慢的下載和檢查會使網頁載入速度變慢，因此開發了 OCSP 作為替代方案。
OCSP 有點像「如果每個單一憑證都有一個單獨的 CRL 會怎麼樣」：當您想檢查給定憑證是否已被撤銷時，您的瀏覽器可以透過聯繫 CA 的 OCSP 服務來檢查該憑證的狀態。但是，由於 OCSP 基礎設施必須不斷運行，並且可能像任何其他網路服務一樣遭遇停機，因此大多數瀏覽器將完全沒有回應視為等同於收到「未撤銷」的回應。這表示攻擊者可以透過阻止您所有對 OCSP 資訊的請求，來阻止您發現某個憑證已被撤銷。為了幫助減少 CA 的 OCSP 服務的負載，OCSP 回應是有效的，並且可以快取約一週。但是，這表示用戶端不會很頻繁地檢索更新，而且經常在憑證被撤銷後一週內繼續信任這些憑證。而且，也許最糟糕的是：由於您的瀏覽器會為您訪問的每個網站發出 OCSP 請求，因此惡意（或受法律強制）的 CA 可以透過追蹤您請求 OCSP 的網站來追蹤您的瀏覽行為。
因此，現有的兩種解決方案實際上都行不通：CRL 的效率太低，以至於大多數瀏覽器都不會檢查它們，而 OCSP 的可靠性太低，以至於大多數瀏覽器也不會檢查它。我們需要更好的方案。
瀏覽器摘要的 CRL
最近取得進展的一種可能的解決方案是專有、瀏覽器特定的 CRL 的想法。儘管不同的瀏覽器以不同的方式實作此功能（例如，Mozilla 將其稱為 CRLite，而 Chrome 的則是 CRLSets），但基本概念是相同的。
瀏覽器廠商不是讓每個使用者的瀏覽器在想要檢查撤銷時下載大型 CRL，而是集中下載 CRL。他們將 CRL 處理成較小的格式，例如 布隆過濾器，然後使用預先存在的快速更新機制將新的壓縮物件推送到所有已安裝的瀏覽器執行個體。例如，Firefox 正以每 6 小時一次的速度推送更新。
這表示瀏覽器可以提前下載撤銷列表，保持頁面載入速度快，並減輕原始 CRL 的最糟問題。它使撤銷檢查保持在本地進行，並且推送的更新可以立即生效，而無需等待可能長達數天的 OCSP 快取過期，從而防止 OCSP 的所有最糟問題。
由於這些瀏覽器摘要的 CRL 的前景看好，Apple 和 Mozilla 根計畫都要求所有 CA 在 2022 年 10 月 1 日之前開始發行 CRL。具體而言，他們要求 CA 開始發行一個或多個 CRL，這些 CRL 一起涵蓋該 CA 發行的所有憑證，並且指向這些 CRL 的 URL 列表在通用 CA 資料庫（CCADB）中揭露。這將允許 Safari 和 Firefox 切換為使用瀏覽器摘要的 CRL 檢查進行撤銷。
我們的新基礎設施
在 Let’s Encrypt 成立時，我們明確決定僅支援 OCSP，而不產生 CRL。這是因為當時的根計畫要求僅強制使用 OCSP，並且維護兩種撤銷機制會增加錯誤導致合規事件的風險。
當我們著手開發 CRL 基礎設施時，我們知道我們需要為規模而建構，並且以反映我們對效率和簡化的重視的方式來進行。在過去幾個月中，我們開發了一些新的基礎設施，使我們能夠按照即將到來的要求發佈 CRL。每個組件都是輕量級的，致力於執行單一任務並出色地完成它，並且能夠擴展到超出我們目前的需求。
Let’s Encrypt 目前在任何一天都有超過 2 億張有效憑證。如果我們發生需要同時撤銷所有這些憑證的事件，則產生的 CRL 將超過 8 GB。為了使事情不那麼笨重，我們將把 CRL 分成 128 個分片，每個分片的最壞情況最大值為 70 MB。我們使用一些經過仔細建構的數學方法來確保 – 只要分片的數量不變 – 所有憑證在重新發行 CRL 時都將保留在其相同分片中，以便每個分片都可以被視為具有一致範圍的迷你 CRL。
與我們在憑證頒發中遵循的相同最佳實務一致，我們所有的 CRL 都將在由我們的頒發中間機構簽署之前，檢查是否符合 RFC 5280 和 基準要求。儘管流行的 linting 程式庫 zlint 尚未支援 linting CRL，但我們編寫了自己的檢查集合，並希望將它們上傳到 zlint。這些檢查將有助於防止合規事件，並確保無縫的頒發和更新週期。
作為開發這些新功能的一部分，我們還對 Go 標準程式庫的 CRL 產生和剖析實作進行了數項改進。我們期待在未來與 Go 社群的其他人一起更頻繁地使用 CRL 時，貢獻更多改進。
儘管我們將產生涵蓋我們頒發的所有憑證的 CRL，但我們不會將這些 URL 包含在我們憑證的 CRL 發佈點擴充功能中。目前，按照基準要求的規定，我們的憑證將繼續包含一個 OCSP URL，任何人都可以使用該 URL 來取得每個憑證的撤銷資訊。我們新的 CRL URL 將僅在 CCADB 中揭露，以便 Apple 和 Mozilla 根計畫可以取用它們，而不會將它們暴露給來自網際網路其他部分可能大量的下載流量。
撤銷的未來
在網路公鑰基礎設施中的撤銷真正修復之前，還有很長的路要走。只有在所有用戶端都停止依賴 OCSP 後，圍繞 OCSP 的隱私疑慮才會減輕，而且我們仍然需要開發出讓非瀏覽器用戶端可靠檢查撤銷資訊的優良方法。
我們期待繼續與網路公鑰基礎設施社群的其他成員合作，使撤銷檢查對每個人都具有隱私、可靠和高效的特性。
如果您對我們開發更穩健和私密的撤銷機制的工作感到興奮，您可以透過捐款來支持我們，或者鼓勵您的公司或組織贊助我們的工作。作為一個非營利專案，我們 100% 的資金來自我們的社群和支持者的貢獻，我們仰賴您的支持。