Home » Posts tagged "tls" (Page 20)

產生 SHA256 的 SSL Certificate

在「Adding an (SHA256 signed) SSL certificate」這篇文章裡提到要如何簽出帶 SHA256 的 SSL certificate,重點在於要先生出有 SHA256 的 CSR,然後拿著這份給 CA 簽。

先照抄過來,看起來是有 encrypted 過的版本:

openssl genrsa -aes256 -out example-encrypted.key 2048
openssl rsa -in example-encrypted.key -out example-decrypted.key
openssl req -new -sha256 -key example-decrypted.key -out example.csr

如果不加密的話應該是:

openssl genrsa -out example.key 2048
openssl req -new -sha256 -key example.key -out example.csr

然後照著文章裡的說明輸入對應的資訊,然後拿著這份 CSR 檔給 CA 簽。

CloudFront 對 POODLE 的安全性更新

CloudFront 的進一步更新出來了,剛剛看到信件通知。分成兩種 case,一種是使用 dedicated IP 服務的人,一種是使用 *.cloudfront.net 的人。

使用 dedicated IP 的人仍然可以打開 SSLv3,不過 CloudFront 建議在 use case 允許下不要開:

If you are using the Dedicated IP Custom SSL Certificates to serve SSL traffic, you may configure whether your distribution accepts SSLv3 connections. We have added an option to select this in both the console and the API. For existing distributions that use Dedicated IP Custom SSL, the default value for this new setting will be to allow SSLv3, so you will need to update your distributions if you want to disallow SSLv3. We do recommend that customers disable SSLv3 if their use case allows it.

使用 *.cloudfront.net 預定在 2014/11/03 之後就會關閉 SSLv3:

Additionally, starting on November 3rd, 2014, we will begin disabling SSLv3 for ALL customers who use SSL with the default CloudFront domain name (*.cloudfront.net). If you believe that this policy will negatively affect your website or application, please contact us as soon as possible so that we can discuss your options: https://aws.amazon.com/forms/poodle_sslv3

而使用 SNI 的人不需要管這件事情,因為這代表你已經是用 TLS 了:

If you're using Custom SSL Certificates and Server Name Indication (SNI), you don’t need to take any action because, as SNI-Only Custom SSL distributions already did not allow SSLv3 connections.

SSL 3.0 爆炸,CVE-2014-3566,POODLE

這次的慘案是由 Google 的人找到 SSL 3.0 的問題:「This POODLE bites: exploiting the SSL 3.0 fallback」。

Google 提供的解法有兩種。一種是關掉 SSL 3.0,另外一種是關掉 SSL 3.0 的 CBC-mode cipher,但兩種解法都還是會痛:

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today.

提到相容性問題的原因是 Windows XP + IE6 的組合,在預設安裝下是不支援 TLS 1.0 的 (需要另外打開選項啟用),而看到那個 11.1%:


出自「Internet Explorer - IE 6 Countdown | Modern.IE

另外是 SSL 3.0 如果不支援 CBC-mode cipher 的話,也只剩下 RC4,而這早就千窗百孔了:


出自「Transport Layer Security

也因此,在 CBC-mode cipher 與 RC4 都不能用的情況下,CloudFlare 決定直接關閉 SSL 3.0:「SSLv3 Support Disabled By Default Due to POODLE Vulnerability」。

而其他廠商提供的方案也都差不多,像是 AWS 的「CVE-2014-3566 Advisory」裡建議的解法也是關閉 SSL 3.0:

This includes disabling SSLv3 on both server and client implementations.

新推出的 security policy (ELBSecurityPolicy-2014-10) 裡也直接關掉 SSL 3.0,讓真的有需要的人再手動加上去,或是選擇一月的版本。

SSL 3.0 推出 18 年後總算要被殲滅了...

CloudFlare 的 Keyless SSL 服務

CloudFlare 有兩篇公告出來:「Announcing Keyless SSL™: All the Benefits of CloudFlare Without Having to Turn Over Your Private SSL Keys」、「Keyless SSL: The Nitty Gritty Technical Details」。前面的一篇偏向公告文 (以及公關稿),而後面的一篇提到了實際運作的方式。

用兩張 Keyless SSL 的 flow 就可以知道差異了,一張是 RSA-based,一張是 DH-based:

把與 private key 相關的運算拆出來,由後方計算完成後再計算出 session key 與 client 溝通。如此一來,雖然速度比較慢,但 private key 管理在客戶自己手上...

Google Chrome 對只有 SHA-1 fingerprint 的淘汰過程

現在 Google Chrome 是 37 版,接下來的幾個版本會開始針對只有 SHA-1 fingerprint 的 SSL certificate 降低安全評價:「Gradually sunsetting SHA-1」。

這是 39 版預定的情況,會出現警告:

這是 40 版預定的情況,安全 icon 會消失:

而這是 41 版直接廢止的情況,當作不合法的 SSL certificate 處理:

另外,預先安裝的 root certificate 不受影響,因為並不是看 SHA-1 hash:

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

整個過程大約會在 2015Q1 告一個階段。

如果新的 TLD 都強制要求使用 HTTPS (HSTS)?

GoogleAdam Langley 在他的 blog 上提出了一個很特別的想法,是不是把現在這些新增加的 TLD 都預先在瀏覽器裡納入 HSTS:「HSTS for new TLDs」。

Here's an idea: why not ask me to set HSTS for the entire TLD? That way, every single site runs over HTTPS, always. It strikes me that could be useful if you're trying to build trust with users unfamiliar with the zoo of new domains.

只要任何一個比較大的 browser 這樣做,其實就相當於強制要求?看文章內的語氣,Firefox + Google Chrome 看起來會是可能會參與的單位?

NIC of India 簽發 Google 的 certificate

Google 昨天發出的公告,發現 NIC of India 發出了幾張 Google 網域的 SSL 憑證:「Maintaining digital certificate security」。

NIC of India 所取得的憑證權限是 India CCA 所發出的 Intermediate CA 權限。而目前 India CCA 只在 Microsoft Root Store 上面有使用,所以會受到影響的範圍是 Windows 上的 IE 以及應用程式,而因為 Google Chrome 有白名單保護,至少在 Google 的網域裡面是不受到直接傷害...

事情還在調查 (還在戳湯圓?),歷史總是不斷地重演...

最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...

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

Archives