SSL/TLS 以及 PKI 的歷史 (加上各種風風雨雨)

Twitter 上看到 Let's Encrypt 轉了這則講 SSL/TLS 與 PKI 的時間線:「SSL/TLS and PKI History」。

這幾年的資料比較完整,看著這些時間線剛好可以拿來複習一下。

而 2013 年 Snowden 的事情也被放進去了,這使得這三年各種 SSL/TLS 化的進展急劇加速 (包括各種 HTTPS 的進展,甚至是郵件的 STARTTLS 加密等等),也因此推動了像是 Let's Encrypt 這樣更方便提供 SSL/TLS certificate 的組織成立。

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

建一個 Root CA 的開銷...

cryptography mailing list 上有人問了這個問題,結果 Entrust 的 CTO,Jon Callas 跑出來回答:「How much does it cost to start a root CA ?」。

答案是,第一次的費用大約 25 萬美金,其中人事費用佔很大一塊。另外每年還有固定的維護費用 (設備與稽核):所有的行為都必須被稽核,而且所有的的控管都必須是雙重認證,以確保一個人無法破壞 CA 的安全性。

還蠻有趣的回覆...

這次 TURKTRUST 誤發 *.google.com SSL 憑證...

這次 TURKTRUST 誤發 *.google.com 憑證被 Google 當初佈下的網子抓到:「Enhancing digital certificate security」。

首先是每次 CA 出問題後都會對目前的 PKI 提出質疑的文章 (像是「TURKTRUST Incident Raises Renewed Questions About CA System」),在沒有有效的方法可以取代目前的 PKI 前,都是吵一吵之後就沒有結論,所以先不管這個題目。

想要提出來的是 Google 這次抓到的機制:「Public Key Pinning Extension for HTTP」,目前狀態仍是 draft。不過 Google 在 Google Chrome 13 就已經實作一部分了,並且把一堆 domain 寫死進去:「View of /trunk/src/net/base/transport_security_state_static.json」,可以看到 Google 的 domain 只允許這些 CA 簽:

      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA",
        "GeoTrustGlobal"
      ],

任何想要在太歲爺上動土的都會被抓包 XD

另外 Google Chrome 還是沒有 Certificate 相關的 API,目前只有 API Proposal 掛著:「webRequest SSL Hooks」,相較於 Firefox 有不少 extension 可以用,這方面 Google Chrome 就差了不少...

SSL Certification 驗證問題中 Google 提供的改善方法...

Google 在愚人節在 Google Online Security Blog 上發表的方法:「Improving SSL certificate security」,試著提供一些資源幫助解決 SSL certification 目前遇到的問題...

前陣子 Comodo 的下游被破台後 (還不只一家),有不少人又開始在探討現有 SSL certification 所用的 PKI 架構 (公開金鑰基礎建設),也就是 CA (數位證書認證中心) 的問題。

Google 給的方法是拿 SSL certification 的 SHA1 hex string,加上 .certs.googlednstest.com 組合成一個 domain 名稱,接著拿這個 domain 去查 TXT record,Google 會傳回三個數字讓你判斷這個 SSL certification 的可靠度。

這三個數字分別是:

  • Google 的網頁機器人第一次看到這個 SSL certification 的天數。
  • Google 的網頁機器人最近一次看到這個 SSL certification 的天數。
  • Google 的網頁機器人看過的次數。

雖然文章裡面沒提,不過以數字推算,這邊的「天數」應該是指 1970 年 1 月 1 日到現在的天數...

使用 DNS 查詢的好處在於 DNS 有 cache (Google 把 TTL 設為 86400),而資料的正確性可以靠正在推廣的 DNSSEC 建立。

接下來應該會有人實做 extension 測試了,過一陣子再回頭來看看發展。