GoDaddy 將 Lavabit 的 SSL Certificate 撤銷了...

在「美國法院可以強制公司交出 SSL Private Key...」這篇提到法院文件顯示 Lavabit 的 SSL Certificate 已經被 FBI 拿走。

消息公開後幾天,GoDaddy 終於記得要依照程序,主動把 Lavabit 的 SSL Certificate 撤銷:「GoDaddy Pulls Lavabit's Security Creds Because The FBI Got Ahold Of Its Encryption Keys」。

巡迴庭的消息好像還沒出來...

美國法院可以強制公司交出 SSL Private Key...

前幾天解密的文件證實了先前的傳言:美國法院可以以協助犯罪搜查的名義,強制商業公司交出 SSL Private Key 給 FBI,並且可以用「偵查犯罪中」的理由要求公司不得公開這件事情。

報導在這:「Edward Snowden’s E-Mail Provider Defied FBI Demands to Turn Over Crypto Keys, Documents Show」,解密的文件 (整個系列的文件) 則在「Redacted Pleadings Exhibits 1 23」這邊可以讀到。

Edward Snowden 的 E-mail 服務提供商 Lavabit 在七月時被法院要求配合調查,其中被要求交出 SSL Private Key:

A week later, prosecutors upped the ante and obtained the search warrant demanding “all information necessary to decrypt communications sent to or from the Lavabit e-mail account [redacted] including encryption keys and SSL keys.”

而且「交出 SSL key 這件事情」不得公開:

The judge also rejected Lavabit’s motion to unseal the record. “This is an ongoing criminal investigation, and there’s no leeway to disclose any information about it.”

而 Lavabit 最後決定以紙本形式提供:

In an interesting work-around, Levison complied the next day by turning over the private SSL keys as an 11 page printout in 4-point type. The government, not unreasonably, called the printout “illegible.”

在法院要求提供電子格式後,Levison (Lavabit 的頭) 決定讓 Lavabit 停止服務,同時因為受限封口令,網站上只能寫得很隱晦,表達對美國的不信任:

這件事情預定要到第四巡迴庭去打:「Let's rally for Lavabit to fight for the privacy rights of the American people. | Rally.org」。

用 StartSSL 申請免費 SSL 憑證的說明...

鑑於 NSA 監聽的關係 (國內最近也很流行這套?),最近國外介紹 StartSSL 的文章又熱門起來了:「Switch to HTTPS Now, For Free」。

不過因為 StartSSL 多了憑證驗證的問題,使得一般人申請變得相當麻煩,所以就有很多文章介紹 :o


這邊的 Generate Private Key 並不是你打算申請的 HTTPS 要用的,而是個人憑證...

這次這篇介紹文用了大量的圖片截圖,並且把產生 private key 以及 csr 的指令都列出來,後面還教你怎麼設定 nginx,相較於其他文件,應該是很清楚了...

Wildcard EV Certificate...

Netcraft 這篇「Wildcard EV certificates supported by major browsers」提到幾個重點...

首先是 EV 規範內禁止使用 Wildcard certificate (出自「Guidelines ForThe IssuanceAnd Management Of ExtendedValidationCertificates」):

Wildcard certificates are not allowed for EV Certificates.

然後還是有人發 *.cclearning.accenture.com,而且主流瀏覽器會正常照 EV 模式顯示出來:(這邊拿 Google Chrome 的範例,原文有所有截圖)

只有 Safari 的手機版本當作普通 certificate 處理的:(下面兩張圖,上圖是桌機版,下圖是手機版)

被抓出來鞭後應該會修正... 吧?

Update:感謝 comment 的糾正,Safari 的地方寫錯了...

Imgur 支援 HTTPS...

Imgur 宣佈支援 HTTPS:「100 million uniques, higher upload limits, and HTTPS support」。

以這張 http://i.imgur.com/X3L4U.jpg 範例:

同樣的 https://i.imgur.com/X3L4U.jpg 也會動,所以之後就可以使用 //i.imgur.com/X3L4U.jpg

看了 DNS 記錄,目前 i.imgur.com 是透過 CloudFlare 的 CDN 加速。

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

SSL/TLS 的 Perfect Forward Secrecy...


寫這篇順便測試 MathJax 的效果...

因為 NSA 的惡搞,這陣子 PFS (Perfect Forward Secrecy) 突然被拿出來討論:

在講 PFS 前,得先講 Diffie-Hellman key exchange (D-H)。

D-H 是利用這個等式:

$$(g^a)^b \equiv (g^b)^a \mod p$$

其中 \(p\) 是大質數,而 \(g\) 是 \(p\) 的 primitive root (即不存在任何 \(n < p\) 可以使得 \(g^n \equiv 1 \mod p\))。 而因為當 \(p\) 夠大時,要從 \(g^a \mod p\) 計算 \(a\) 就是離散對數問題,而離散對數問題是已知沒有有效率計算的問題,所以我們會假定當 \(p\) 夠大時,傳輸 \(g^a \mod p\) 是無法用合理資源計算得知 \(a\)。

因此,Alice 與 Bob 就可以產生自己的 private secret \(a\) (Alice) 與 \(b\) (Bob),計算出 \(g^a\) 與 \(g^b\) 後公開傳輸給對方,當 Bob 收到 Alice 提供的 \(g^a\) 時就計算 \((g^a)^b \equiv g^{ab} \mod n\),而 Alice 收到 Bob 提供的 \(g^b\) 後可以計算 \((g^b)^a \equiv g^{ba} \equiv g^{ab} \mod n\)。

而攻擊者只拿到公開的 \(g^a\) 與 \(g^b\) 以及 \(g\),無法計算出 \(g^{ab}\),於是就雙方就建立一組 shared secret 了。

回到 SSL/TLS 的問題上,由於 RSA 加解密的速度並不快,所以 SSL/TLS 是在 RSA 的保護下交換 RC4 或是 AES 所需要的金鑰 (key)。

交換 key 這件事情除了可以直接交換以外,還可以利用 D-H 交換。

D-H 交換可以確保當 RSA key 被破解時還要再破每個 session 的 D-H 所產生出來的 key,而直接交換的話,只要破一把 RSA key 就可以解出所有 traffic 了。

而 PFS 會被提出來,是因為目前消息指出 NSA 其實有在錄下 SSL/TLS 流量,等哪天有機會取得 RSA key 的時候 (無論是硬解,或是其他方式),就有機會能夠一次破一卡車資料... (因為目前大部分的 SSL/TLS 流量都沒有上 PFS)

雖然 PFS 會慢一些,不過已經確認 NSA 打算來搞了,所以還是乖乖加上去吧... @_@

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