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 技術目前是透過 CRLOCSP 兩個技術在支撐,前者是列出所有被 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 staplingSPDY,速度明顯有感覺提昇...

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」。

前面十名幾乎都是 VerisignAkamai,而 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 速度比較快的幾家簽,對速度會有幫助...