DigiCert 考慮開放 .onion 的 SSL certificate 簽章

前陣子 Facebook 提供 Tor 的 hidden service 時還提供了 SSL certificate,是由 DigiCert 簽的:「Supporting the Anonymous Use of Facebook via Tor」。

而 DigiCert 打算開放給一般人申請 .onion 的 SSL certificate:「DigiCert Considering Certs for Hidden Services」。

這件事情除了在技術的角度很特別外,在政治面的角度也值得被拿出來討論,也就是 DigiCert 承認 .onionTLD

各家搜尋引擎 (像是 GoogleDuckDuckGo) 開始爬 .onion 的資料也應該是遲早的事情?

設定 CloudFront 的 Wildcard SSL (SNI)

不知道為什麼網路上一堆文章寫的超複雜 XD

目前必須使用 CLI 才能上傳 key 與 SSL certificate,所以乖乖的裝上 aws-cli 吧 :p

而通常在買 Wildcard SSL 時會 *.example.com 的時候會簽成 example.com + *.example.com,這時候用 example.com 當名字掛進去:

aws iam upload-server-certificate --server-certificate-name example.com --certificate-body file://server.crt --private-key file://server.key --certificate-chain file://intermediate.crt --path /cloudfront/

一樣可以確認:

aws iam get-server-certificate --server-certificate-name example.com

會改到的幾個部份用粗體標出來了。

上傳完成後就可以到 Web Console 上的 CloudFront 部份設定了。

主要是參考「Building a CDN over SSL with CloudFront and SNI」這篇文章的說明,再加上一些亂試後去翻文件確認的結果 :o

產生 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.

Ubuntu 下強制 Google Chrome 使用 TLS 1.0+

在「How do I patch/workaround SSLv3 POODLE vulnerability (CVE­-2014­-3566)?」這篇文章裡提到了強制 Google Chrome 使用 TLS 1.0+ 的方法。

打開 /usr/share/applications/google-chrome.desktop,把這行:

Exec=/usr/bin/google-chrome-stable %U

改成:

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

然後重新啟動 Google Chrome 就可以了...

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 的網域裡面是不受到直接傷害...

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