SNI 支援 (單一 IP 多個 SSL Certificate)

Twitter 上看到 yllan 提到 SSL certificate 的問題:

這是看 client 對 Server Name Indication 的支援程度而決定的。

在維基百科說明中「Browsers with support for TLS server name indication」這段裡面列出來的瀏覽器,可以看出來其實最大的問題就是 Windows XP 上的 IE{6,7,8} 不支援。(但 Windows Vista 以及 Windows 7 的 IE{7,8} 支援 SNI)

手上一時間找不到 Windows XP + IE{6,7,8} 的數量,但 gs.statcounter.com 上有幾個數字可以參考。

首先是台灣 IE8 的用戶數量:

再來是 Windows XP 數量:

以這兩個圖的資料來看,還是不太能用啊... :o

AWS CloudFront 可以用自己的 SSL Certificate 了...

以往 CloudFront 只能用 *.cloudfront.net 當作 SSL domain,但在今天公告的「Custom SSL Domain Names and Root Domain Hosting for Amazon CloudFront」這篇說明內,宣佈可以上傳自己的 SSL certificate 使用了。

目前的價錢是 USD$600/month,不過是以小時計算。即使拋開錢的問題,在 CloudFront 已經支援 SSL 的前提下 (而且因為是 *.cloudfront.net,理論上是 cookie-free domain),技術面上暫時想不到什麼好處... 在 DNS 端自己混合多家 CDN 是個可能的方向?

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

這次 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 就差了不少...

安裝 Certificate Patrol 增加對最近 SSL Certificate 問題的抵抗性...

這只能掙扎,但還是要掙扎啊!

Certificate Patrol 是一個 Firefox 延伸套件,你可以設定在新看到 SSL Certificate 的時候跳出一個視窗來告訴你這個 SSL Certificate 的資訊:

如果你平常有在用 https://mail.google.com,結果突然發現有天跳出視窗,你就應該要有所警覺了...

這下可包大了,居然有一堆 "localhost" 這類的 SSL Certificate 被發出來...

這些 CA 是怎麼管理下面的單位的啊...

Slashdot 報導了 EFF 的 Chris Palmer 發現有大量 Unqualified Name 被 sign 過:「Thousands of SSL Certs Issued To Unqualified Names」、「Unqualified Names in the SSL Observatory」。

依照原文中「You can also use the Observatory in an Amazon EC2 instance we created.」這句話,應該是直接掃整個 IPv4 network 了吧,反正以現在的各種技術來說,IPv4 address space 不大?

結果相當豐碩,包括了 2201 個 "localhost"、806 個 "exchange"、2383 個 /^\w*exchange\d+$/、5657 個 /^\w*exch\d*$/。光是可以在 Internet 上被觀察到的 Unqualified Name 就有 37244 個。

甚至連 EV Certificate 都有 Unqualified Name 被 sign:「www.prism.gatech.edu/~gmacon3/ssl-observatory/unqualified_local_rfc1918_ev.txt」。(那個 VeriSign 你太誇張了,"CN=Bownedev" & "CN=qa-sescib-web1" & "CN=tc-teweb01-s" 你也能過?EV 的文件檢查根本沒再看的喔?)

在「www.prism.gatech.edu/~gmacon3/ssl-observatory/unqualified_local_rfc1918_all.txt」這邊有張表列出出包單位的數量可以看...

雖然一月就做完這份資料,但不得不說 EFF 補刀的時間真棒... 趁這陣子 CA 架構問題正熱的時候寫一篇來補一刀 XD