Google Chrome 對 WoSign 與 StartCom 的白名單要完全移除了

Twitter 上看到的:

WoSignStartCom 的移除會發生在 61 版,而依照「Final removal of trust in WoSign and StartCom Certificates」這邊的說明,stable 應該會在九月出 61 版而生效:

Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

Netflix 的 BetterTLS,推廣 CA 的 Name Constraints

Netflix 因為想用 Name Constraints,所以決定自己跳出來推廣了:「BetterTLS - A Name Constraints test suite for HTTPS clients」。

就是在 CA 上可以綁定條件,只允許哪些 domain 可以被發放:

網站在「BetterTLS: Name Constraints」這邊可以看。

Google Chrome 也宣佈不信任 WoSign + StartCom 的計畫

Google Chrome 也公開了對 WoSign + StartCom 的計畫:「Distrusting WoSign and StartCom Certificates」。

由於大家遇到的技術問題都一樣 (之前發出的量太大,無法窮舉表列出來),所以處理的方法也類似於 Mozilla 的作法,只信任 2016/10/21 前發出的 certificate:

Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted.

Google Chrome 目前是 54,所以這表示會在兩個版本後生效。另外特別提出來必須有 CT flag (Certificate Transparency),或是在白名單的網站:

Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom.

而因為安全考量,會有某些 certificate 是沒救的情況:(就上面的描述,看起來是指不在白名單內又沒標 CT flag 的)

Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance.

話說 www.kernel.org 從本來的 StartCom 換掉了 (之前都要打 badidea 進去看),剛剛看是 2016/10/11 簽的憑證...

這樣除了 Microsoft 還是沒動作外,其他比較大的瀏覽器都到齊了...

Mozilla 對 WoSign + StartCom 的正式處分

MozillaWoSign + StartCom 的不信任處分出爐了:「Distrusting New WoSign and StartCom Certificates」,最後處分的內容跟之前的討論差不多 (參考先前寫的「Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除」)。

Mozilla 台灣有放出中文版的說明 (差不多就是英文翻譯的版本):「取消對 WoSign 與 StartCom 新簽發憑證的信任」。

這次比較麻煩的地方在於要信任已經發出的 certificate,而且量太大無法窮舉。所以必須改增加程式碼處理,而這個方法無法對使用 Mozilla CA Certificate Store 的人生效 (因為這包套件只是一堆 pem 檔案,沒辦法放特殊的邏輯進去...)

另外現在 Firefox 是 49 版,要到 51 版才會生效,看起來還會花一陣子...

Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除

Okay,在 Mozilla 的人跟 WoSign + StartCom + 360 的人談過後有了新的進展。

幾個小時前 Mozilla 提了新版的草案出來 (對,還是草案):「Remediation Plan for WoSign and StartCom」。但由於 Kathleen Wilson 跟 Gervase Markham 都沒有太多意見,我猜這應該會接近定案了。

這次的處分草案由 Kathleen Wilson 發出來,會包括這些 root certificate,可以看到包括了所有 WoSign 與 StartCom 的 CA:

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

首先是認定這一連串的事件是惡意行為:

Based on the information that I have seen regarding WoSign, I believe that WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL certs, when they knew full well that was no longer allowed. I also believe that the deception continued even after Mozilla directly asked WoSign about this. WoSign has lost my confidence in their ability and intention to follow Mozilla's policies.

所以打算採取與 CNNIC 類似的處分方法,但很不幸的由於規模不一樣,所以被迫採用另外的方式來處理:

Therefore, I think we should respond similarly to WoSign as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the timescales involved are such that we prefer not to create a list of the domains for which previously-issued certs that chain up to the Affected Roots may continue to be trusted, so our approach will be a little different, as Gerv previously described[3].

這次處分的過程會包括四個項目,第一個是在 Firefox 51 會用黑名單的方式將這些 root certificate 擋下,但會信任 2016/10/21 前所發出的憑證以降低對目前網站的衝擊:

1) Distrust certificates chaining up to Affected Roots with a notBefore date after October 21, 2016. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train [4].
-- The code will use the subject key id (hash of public key) to identify the Affected Roots, so that the control will also apply to cross-certs of the Affected Roots.

然後將之前簽出來的 SHA-1 憑證列入 OneCRL:

2) Add the previously identified backdated SHA-1 certs chaining up to the Affected Roots to OneCRL.

另外一個非常大的事情是,Mozilla 將永久不信任安永香港的稽核報告:

3) No longer accept audits carried out by Ernst & Young Hong Kong.

Gervase Markham 做了補充「永久」的部份:

To be clear, this is a permanent ban, applicable worldwide, but only to the Hong Kong branch of E&Y. (If further issues are found with E&Y audits elsewhere, then we might consider something with wider scope.)

最後一個是移除 NSS 裡包的憑證:

4) Remove the Affected Roots from NSS after the SSL certificates issued before October 1, 2016, have expired or have been replaced.

在討論裡有提到 Firefox 與 NSS 的處置日期不太一樣的問題 (一個是 10/21,一個是 10/01),應該會在正式的定案時修正。

另外在「StartCom & Qihoo Incidents」這邊,Google 家的 Ryan Sleevi 也寫了一串,也許是他目前個人的看法 (但畢竟他是 Google 家主事的人之一),基本上的立場與 Mozilla 相同 (將 WoSign 與 StartCom 視為同一個單位,而且是刻意違反 Baseline Requirement),所以後續應該也會有動作了...

HPKP 遇到的阻礙

關於 HPKP,可以參考「HTTP Public Key Pinning 介绍」這篇介紹,寫得很清楚。

HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意),像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。

原理上來說,就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構,當 client 第一次連上的時候會記下資訊,之後就可以使用這個資訊來驗證。

但 HPKP 與 HSTS 不同的地方在於,HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS),而且通常 migrate 上去後就不會拔掉。

但 HPKP 則是要指定 Root CA,這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)

這使得 HPKP 的實作成本過高,而且得到效益太低,另外也因為替代的方案有不少 (像是 Certificate Transparency),導致 HPKP 根本沒什麼人用:「Is HTTP Public Key Pinning Dead?」。

在 comment 有人直接拉出來統計,使用的比率反而在下降:

From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.

不過我覺得算是平行發展吧,這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面,而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...

對某些應用程式隱藏 Android Root 狀態的 suhide

看到 suhide 這個工具:「Chainfire's SuHide — Now You Can Hide Your Android Root Status On Per-App Basis」,原報導出自「Experimental suhide Mod for SuperSU Hides su Binary from Applications」。

第一個應該是重點,針對特定應用程式隱藏:

- Hides root on a per-app base, no need to globally disable root
- Doesn't need Xposed
- Even supports SuperSU's ancient app compatibility mode (BINDSYSTEMXBIN)
- Passes SafetyNet attestation by default on stock ROMs (last officially tested on 2016.08.31)

不過可以想像到的,接下來的 detection 也會偵測 suhide,再加上 Google 的 SafetyNet 機制,作者在 forum 上也寫了這是個貓抓老鼠的遊戲...

Firefox 49 將可以吃系統的 Certificate Trust Store

在「Upcoming Changes to Root Certificates in Firefox on Windows」這邊看到 Firefox 49 將會有選項可以讓 Firefox 多吃系統的 Certificate Trust Store:

This feature is available in Firefox 49 and up (currently in beta). To give it a try, set the preference security.enterprise_roots.enabled to true. After that, Firefox should connect successfully to sites using certificates issued by 3rd party root certificates that have been added to the Windows trust database.

這對企業來說會比較方便管理。

These features are still in the early stages, so if you encounter any unexpected behavior, please feel free to file a bug.

然後正在測試階段,有問題的可以去戳...

Mozilla 在考慮移除 WoSign 的 CA Root

雖然平常早就把 WoSign 移除信任,但在「Mozilla考虑对沃通CA采取行动」這邊看到有趣的消息,翻了一下 Gervase Markham 發表的原文還蠻精彩的:「Incidents involving the CA WoSign」。

第一次事件 (Incident 0) 是在 2015/04/23,攻擊者只要能夠證明他能控制某個 TCP port,就會發出 certificate:

On or around April 23rd, 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.

設計不良造成的資安事件總是會發生。重點在於 Google 知道,但 Mozilla 完全不知道:(我講得很保守是因為這個句子在 thread 後面被澄清解釋的更慘,參考後文)

This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.

更嚴重的是,這次的事件在 WoSign 的稽核上沒有出現:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

第二次事件 (Incident 1) 是在 2015 年六月,也是資安設計的問題,當你可以拿到 WoSign 所指定的 subdomain 控制權後,你就可以拿到 parent domain 的 certificate,而這次甚至被拿到 GitHub 全系列的 certificate:

The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.

嗯,也沒通報:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been (see above).

嗯,稽核也沒出來:

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

嗯,被拿到的 domain (ucf.edu) 也沒 revoke:(可以從「crt.sh | 29647048」這邊看到)

They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.

第三次事件 (Incident 2) 則是在 2016 年七月,由於現在大多數的瀏覽器都會對 2016 後簽出的 SHA-1 憑證直接標示為不安全,而 WoSign 的 API 提供造假,讓簽名日期 (notBefore) 簽在 2015/12/20:

Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm.

嗯,然後否認造假:

* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "this date is the day we stop to use this code"[4]. If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.

嗯,然後還是沒有回報給 Mozilla:

* This misissuance incident was not reported to Mozilla by WoSign as it should have been.

稽核報告應該是因為這太新,還沒開始做?

另外在 thread 討論時,Google 的 Ryan Sleevi 澄清的更慘:

Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them.

It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread.

也就是說,是 Google 主動發現這些問題,並且通報 WoSign。後來過了許久發現 WoSign 沒有照規定通報其他 CA Root 管理單位 (以這邊來說是 Mozilla),於是 Google 決定主動通報其他單位,然後大~爆~炸~

在密碼學理論裡,CA 架構是靠著稽核建立信任的,這次的事情又再次證實這個問題 (但目前沒有其他好的機制可以做)。來猜測下場的話,我的預期是會像拔掉 CNNIC 的作法拔掉信任,但針對之前發出的 certificate 設為白名單 (直到過期):

Let's Encrypt 的 Root CA 進入 Mozilla 的信任清單了

Let's Encrypt 的 Root CA 進 Mozilla 的 CA 清單了:「Let's Encrypt Root to be Trusted by Mozilla」,Mozilla 增加的 ticket 則可以在「Add ISRG Root X1 root certificate to NSS」這邊看到。

目前的信任路徑是透過 IdenTrust 簽出來的,也就是下面那條。而現在 Mozilla 的產品線多了一條信任的路徑 (綠色粗線):

其他的單位 (以及瀏覽器) 也有提出申請,還在稽核驗證:

We have also applied to the Microsoft, Apple, Google, Oracle and Blackberry root programs. We look forward to acceptance into these programs as well.

除了 Oracle 應該是指 Java 用到的那包,其他的應該都是包含自家的系統。