Tag: ocsp

看起來 Apple 是打算繼續蒐集 OCSP 資訊...

在「Apple memory holed its broken promise for an OCSP opt-out (lapcatsoftware.com)」這邊看到的，原文是「Apple memory holed its broken promise for an OCSP opt-out」。

Apple 的系統機制會在每次啟動應用程式的時候去 Apple 自家的 OCSP 伺服器確認這個應用程式是否被 Apple 註銷了：

When you launch an app, macOS connects to Apple's OCSP service to check whether the app's Developer ID code signing certificate has been revoked by Apple.

本來 Apple 有說要改善，但看起來吃書了...

這有明顯的 privacy 問題，所以我的作法是參考 Apple 自家的「Use Apple products on enterprise networks」這份官方資料，把裡面所有 ocsp 相關的 record 都設到 /etc/hosts 內，目前是：

127.0.0.1 ocsp.apple.com ocsp.digicert.cn ocsp.digicert.com ocsp.entrust.net ocsp2.apple.com

可以重開機確保生效，然後用 ping ocsp.apple.com (或是其他 domain) 看看是不是 127.0.0.1。

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 這點...

CloudFlare 的 Origin CA：保護 CloudFlare 到 Origin 這段的傳輸過程

CloudFlare 推出的 Origin CA 用來保護從 CloudFlare 到 Origin Server 這段的過程：「Introducing CloudFlare Origin CA」，也就是右半部這段：

CloudFlare 把這個新功能包裝得很神，但實際上只是弄個 CA 出來跑而已，僅此而已。

當然，由於他不需要處理 Public CA 的問題，所以有很多在一般 TLS 連線需要做的檢查步驟可以被簡化，藉此達到效能改善，包括了省掉 intermediate certificates、OCSP 以及 SCTs：

With Origin CA certificates, we’ve stripped everything that’s extraneous to communication between our servers and yours to produce the smallest possible certificate and handshake. For example, we have no need to bundle intermediate certificates to assist browsers in building paths to trusted roots; no need to include signed certificate timestamps (SCTs) for purposes of certificate transparency and EV treatment; no need to include links to Certification Practice Statements or other URLs; and no need to listen to Online Certificate Status Protocol (OCSP) responses from third-parties.

進而省下大量的連線成本：

Eliminating these unnecessary components typically found in certificates from public CAs has allowed us to reduce the size of the handshake by up to 70%, from over 4500 bytes in some cases to under 1300.

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 都支援了...

Netcraft 放出 OCSP 伺服器效能資訊...

Netcraft 開始放 OCSP 的效能資訊了。由於有個排名在上面跑，這對於 SSL 供應商應該會有一定的壓力去改善服務品質：「OCSP Server Performance in March 2013」。

前面十名幾乎都是 Verisign 與 Akamai，而 Verisign 都是用 Citrix Netscaler。繼續觀察看看好了...

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 速度比較快的幾家簽，對速度會有幫助...