Tag: crl

Let's Encrypt 想要停掉 OCSP 服務

看到 Let's Encrypt 貼出來的文章，想要停掉 OCSP 服務：「Intent to End OCSP Service」，而打算以 CRLs 為主。

OCSP 是拿來驗證 certificate 是否有效的機制，由 CA 提供服務讓瀏覽器查詢，但這會有效能與 privacy issue。

前者比較容易理解，因為熱門網站所使用的 HTTPS certificate 會導致很多瀏覽器跑去 OCSP 服務查詢；後者則是因為 OCSP 服務就會知道哪個 IP 存取哪個網站。

不過這兩個應該都可以用 OCSP stapling 解決才對，也就是 web server 去 OCSP 服務拿有效的簽名 (證明你手上的是有效的)，然後在瀏覽器連上來的時候一起送出去，這樣瀏覽器就不用跑去煩 OCSP 服務，而且 OCSP 服務也不知道誰看了什麼網站。

不過跟 CRLs 相比還是不小的負擔就是了，尤其像是 Let's Encrypt 這種等級的量，光是 web server 固定時間去要 OCSP stapling 的簽名 (這又是個數位簽章的動作) 不容易 cache；反過來 CRLs 容易 cache 多了？

另外一方面，CA/Browser 在 2023 年的時候已經投票通過，將 OCSP 列為選擇性項目，而 CRLs 則變成必要項目：「Ballot SC-063 v4: Make OCSP Optional, Require CRLs, and Incentivize Automation」

看文章的語氣，應該是先放個風向？尤其故意不提到 OCSP stapling 這點...

Firefox 支援 OCSP Must-Staple

Firefox 宣佈支援 OCSP Must-Staple：「Improving Revocation: OCSP Must-Staple and Short-lived Certificates」。

先前的 SSL certificate 的 revoke 技術目前是透過 CRL 與 OCSP 兩個技術在支撐，前者是列出所有被 revoke 的清單，後者則是瀏覽器主動去指定的 server 確認這個 SSL certificate 是否有效。但這兩個方法都有嚴重的問題。

CRL 的問題是 revoke 清單會愈來愈多。這完全沒辦法 scale。

OCSP 的問題有幾個，一個是熱門網站的 SSL certificate 會讓 OCSP server 的負擔非常重 (不過還是有些辦法打散)。第二個問題是 OCSP server 會知道哪些 IP 造訪了哪些網站，使得隱私權受到嚴重侵害。第三個問題則是 client 需要再連線確認花掉很多時間，而且失敗機率超高：

However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed.

也因為極度不穩定，對於一般的 SSL certificate 在連不到 OCSP server 時，沒有瀏覽器敢直接 hard-fail (EV SSL certificate 是強制要求 OCSP 要過)，於是反而給了攻擊者一個很簡單的方法：取得 private key 攻擊時順便擋掉對 OCSP server 的連線。

後來 OCSP 技術改善而推出 OCSP stapling，由 server 定時去 OCSP server 取得「這個 SSL certificate 未被 revoke」的簽名認證後，一起在 TLS connection 裡傳輸給 client 端，這樣有許多好處：

  • 隱私問題直接解決了，因為 server 是固定時間去抓，OCSP server 完全不知道使用者端的資訊 (甚至連「有沒有來連線」都不知道)。
  • 穩定性提昇了，因為 OCSP server 的負荷量變低，可以預期 OCSP server 會變得比較容易 scale。
  • 用戶端的速度增加了，因為 client 不需要額外的連線確認。

而這次 Firefox 更進一步支援讓 SSL certificate 上標注 OCSP Must-Staple，表示這個 certificate 必須有 OCSP stapling 才行，這使得這類 SSL certificate 在 revoke 後無法被利用，真正的完全失效。

不知道其他家會不會跟進...

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability，然後發現各家 OCSP 的穩定性都不太好：「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫，當 HTTPS 連線建立中，client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制，因為已經發出去的簽名是無法被收回的，只好靠連線時再查詢。

另外一個機制比較舊，叫 CRL (Certificate Revocation List)，則是屬於清單類的機制，更新速度比 OCSP 慢。

目前是以 OCSP 為主，而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響，有的影響很明顯，有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣，有些是直接上 Akamai 解決，有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail，也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明，可以挑 OCSP 速度比較快的幾家簽，對速度會有幫助...