Tag: stapling

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 後無法被利用，真正的完全失效。

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

換到 nginx 1.6 後把 OCSP stapling 與 SPDY 打開...

剛剛把 nginx 換到 ppa 的版本 (目前是 1.6)，然後打開 OCSP stapling 與 SPDY，速度明顯有感覺提昇...

OCSP stapling：

SPDY：

目前有想到而且能處理的都做的差不多了 :p

OCSP stapling

OCSP (Online Certificate Status Protocol) 是用來檢查 SSL certificate 是否被撤銷的方法。OCSP server 接受 HTTP POST 後，回答 client 這個 SSL certificate 是否仍然有效。

對於 client 來說，這主要有兩個問題：

  • client 需要多花時間連到 OCSP server 確認。
  • 隱私問題：OCSP server 會知道「這個使用者試著連到使用這個 SSL certificate」的資訊。

而對於 OCSP server 來說，這個方法的 scalability 很差，熱門的站台會產生大量的流量打進 OCSP server。

OCSP stapling 則是解決這個問題的方法。藉由 server 向 OCSP server 要一次 OCSP response 後，直接傳回 OCSP response 給 client (通常是 browser) 避開了上面的問題。這個方法也逐漸在普及了：(取自英文版維基百科文章內的說明)

OCSP stapling has not seen broad deployment to date, however this is changing. The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.

Apache HTTP Server supports OCSP stapling since version 2.3.3, the nginx web server since version 1.3.7, and LiteSpeed Web Server since version 4.2.4. and Microsoft's IIS since Windows Server 2008

On the browser side, OCSP stapling was implemented in Firefox 26 and in Internet Explorer since Windows Vista.

所以已經有不少 client 與 server 都支援了...