Let's Encrypt 在 Android 平台上遇到的問題

同樣是「Standing on Our Own Two Feet」這篇文章,Let's Encrypt 預期明年九月後會在 Android 上遇到嚴重的相容性問題。

很舊的裝置主要是透過 IdenTrust 的 Root CA (DST Root CA X3) 對 Let's Encrypt 的 Intermediate CA (目前主要是 Let's Encrypt Authority X3) 簽名,從而建立憑證的信任鍊,而新的裝置除了 IdenTrust 的 CA 外,也信任了 Let's Encrypt 自家的 Root CA (ISRG Root X1):(出自「Chain of Trust」)

在 2016 年四月正式對外啟用時主要是靠 IdenTrust 的 cross-sign,而也是在 2016 年時 Let's Encrypt 自家的 Root CA (ISRG Root X1) 陸陸續續被各家收進 CA store。

所以這個時間點之前的 Android (大約是 7.1.1) 算是個相容性的分界線,在這個版本前 (而且系統無法更新的) 都只能靠 IdenTrust 的 cross-sign,這看起來大約有 33.8%,實際的流量大約是 1%~5%:

Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.

目前還有大約十個月左右的緩衝期,但大家都知道 Android 的更新速度,就十個月來說看起來不太樂觀...

官方有給他們不願意再取得一次 cross-sign 的原因,不過我覺得這個理由就很怪了,這個描述看起來是 IdenTrust 不願意再簽發一次?直覺覺得 IdenTrust 站在商業立場應該是很願意才對?而且除了 IdenTrust,應該也有其他家會有興趣?

Can we get another cross-signature? We’ve explored this option and it seems unlikely. It’s a big risk for a CA to cross-sign another CA’s certificate, since they become responsible for everything that CA does.

也有可能是放個話讓 IdenTrust 表態?先繼續看下去...

最差的情況應該就是沒有 cross-sign,然後也沒提供其他的 workaround,這樣就是買一般的 SSL certificate 來解了...

AWS 通過的認證的證書資料連結

在「Frequently Asked Questions About Compliance in the AWS Cloud」這邊 AWS 的人列出一張表,提供了 AWS 目前所通過的認證以及證書資料。

舉例來說,在「ISO 27001 Compliance」這邊就有提供證書的 PDF 版本:「https://d0.awsstatic.com/certifications/iso_27001_global_certification.pdf」。

但也有一些證書是沒有給出來的,應該是要另外跟 AWS 要...

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

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

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

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

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 測試了,過一陣子再回頭來看看發展。

addons.mozilla.org 的 Comodo SSL Certificate 被放出 Private Key

之前被人破台,利用 Comodo CA 生出 addons.mozilla.org SSL certification 的 private key 被放出來了:「Comodo Hacker releases Mozilla certificate」。借 Netcraft 的圖:

Firefox 的 revoke 機制不怎麼完善,對於用 Firefox 的人,直到 Mozilla 有新的方法解決之前都必須很小心了 :/