Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動),後來提供的方法是變成可以設定的選項,但預設是關閉的,這樣一來就可以改善 Root name servers 的壓力:「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出),在繼續觀察幾個月後,上個禮拜 Verisign 的人在 APNIC 這邊更新了消息:「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料,可以看到趨勢往上:

這是後續的資料,從 87 版釋出後開始往下:

另外我覺得比較好玩的是這個,在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明:

看起來沒什麼問題,先 merge 再說... 是這樣玩嗎 XDDD

Google Chrome 對 Symantec 全系列憑證的不信任計畫

Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫:「Chrome’s Plan to Distrust Symantec Certificates」。

這包括了一卡車的品牌,像是 ThawteVeriSignGeoTrustRapidSSL,不過 Equifax 跟 Symantec 的關係我沒查到...:

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

反正整個計畫會在 Google Chrome 70 推出時告一段落 (變成完全不信任),會是 2018/09/13 (預定時間) 與 2018/10/23 (預定時間) 在 beta channel 與 stable channel 上推出。

中間比較重要的時間點是 2018/03/15 (預定時間) 與 2018/04/17 (預定時間),Google Chrome 66 在 beta channel 與 stable channel 上推出,這個版本不會信任 2016/06/01 前發出的憑證:

Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.

整個計畫的時間軸清楚多了...

Google 宣佈對 Symantec 發行的 SSL Certficiate 的不信任計畫

GoogleRyan Sleevi 宣佈了對 Symantec 所發佈的的 SSL Certificate 的不信任計畫:「Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates」。

這邊講「不信任計畫」,主要是因為 Google Chrome 不是打算移除,而是限制 Symantec 發出的 SSL certificate 的有效期限。這有種 too big to fail 的感覺...

以市占率來看,無論是「Usage of SSL certificate authorities for websites」這邊算出來的 15.4%,或是「SSL Market Share Report」這邊算出來的 24%,移除的影響都是巨大無比,再加上歷史上最早一批 CA 公司幾乎都被 Symantec 買進去 (像是 VerisignThawte):

This compatibility risk is especially high for Symantec-issued certificates, due to their acquisition of some of the first CAs, such as Thawte, Verisign, and Equifax, which are some of the most widely supported CAs. Distrusting such CAs creates further difficulty for providing secure connections to both old and new devices alike, due to the need to ensure the CA a site operator uses is recognized across these devices.

所以不信任計畫將會不會採取移除,而是其他方式:

To balance the compatibility risks versus the security risks, we propose a gradual distrust of all existing Symantec-issued certificates, requiring that they be replaced over time with new, fully revalidated certificates, compliant with the current Baseline Requirements. This will be accomplished by gradually decreasing the ‘maximum age’ of Symantec-issued certificates over a series of releases, distrusting certificates whose validity period (the difference of notBefore to notAfter) exceeds the specified maximum.

也就是後面的每一個新版的 Google Chrome 都會降低對 certificate 可以設定的有效期限,直到降到九個月 (279 天):

The proposed schedule is as follows:
Chrome 59 (Dev, Beta, Stable): 33 months validity (1023 days)
Chrome 60 (Dev, Beta, Stable): 27 months validity (837 days)
Chrome 61 (Dev, Beta, Stable): 21 months validity (651 days)
Chrome 62 (Dev, Beta, Stable): 15 months validity (465 days)
Chrome 63 (Dev, Beta): 9 months validity (279 days)
Chrome 63 (Stable): 15 months validity (465 days)
Chrome 64 (Dev, Beta, Stable): 9 months validity (279 days)

另外安全標示也將會被拔除:

Therefore, we propose to remove such indicators, effective immediately, until Symantec is able to demonstrate the level of sustained compliance necessary to grant such trust, which will be a period no less than a year. After such time has passed, we will consider requests from Symantec to re-evaluate this position, in collaboration with the broader Chromium community.

接下來看 Mozilla 端會不會有類似的動作了...

Symantec 的 SSL Certificate 醜聞繼續爆發...

tl;dr:目前的外部稽核還沒有完成,有可能會有更慘烈的情況。如果你最近要買 SSL certificate,不要碰 Symantec 旗下的產品,包括了 VerisignThawteGeoTrust、Equifax (GeoTrust 下)、RapidSSL

在「Symantec 的 Thawte 發出 Google 的 SSL certificate 的後續」這邊有提到先前 Google 抓到 Symantec 發出 Google 憑證的問題,後續稽核時發現更多問題...

Google 在「Sustaining Digital Certificate Security」這篇提到了幾件事情。首先是基於 Symantec 第一版的稽核報告,發現有 23 個 SSL certificate 在 domain owner 沒有被通知的情況下被簽名,這包括了 Google 與 Opera 的五個單位:

Following our notification, Symantec published a report in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.

但 Google 光是透過 Certificate Transparency 認為問題不僅於此 (於是認為 Symantec 的稽核不確實),通報了其他主要的 Root Certificate 管理單位:

However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.

而 Symantec 再次稽核,這次就大爆炸,光是他們查出來的就有 164 個 SSL certificate 橫跨 76 個網域被簽出,並且有 2458 的不存在的 domain 被簽出:

Symantec performed another audit and, on October 12th, announced that they had found an additional 164 certificates over 76 domains and 2,458 certificates issued for domains that were never registered.

Symantec 這次提供的報告包括了比較完整的資料,爆發的品牌包括了 Symantec 所有的產品:Verisign、Thawte、GeoTrust、Equifax (GeoTrust 下) 以及 RapidSSL。

要不是 Symantec 的市占率高到爆炸,Google 大概就像 CNNIC 那樣直接拔掉了。(參考「CNNIC 的根憑證 (包括 EV) 從 Google 全系列產品移除」,市占率的部份可以參考「Usage of SSL certificate authorities for websites」這邊的資料,目前看到是 29.9% 第二高,僅次於 Comodo 的 39.1%)

由於沒辦法砍,所以 Google 直接下了幾個通牒,第一個是從 2016 六月開始所有簽出的 SSL certificate 都必須發紀錄到 Certificate Transparency (目前規範中只有 EV SSL certificate 有要求),否則之後的簽出的 SSL certificate 不保證會動:

It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.

After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.

再來是對報告要求補上為什麼稽核機制沒有偵測到,以及「每一次」為什麼沒有按照 Baseline Requirements (一般 SSL certificate 的規範) 以及 EV Guidelines (EV SSL Certificate 的規範) 的詳細資訊:

More immediately, we are requesting of Symantec that they further update their public incident report with:

  • A post-mortem analysis that details why they did not detect the additional certificates that we found.
  • Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.

同時要求第三方稽核確認這次事件,而僅非 Symantec 自己稽核:

Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit.

而且也清楚要求第三方稽核確認包括:簽的 public key 沒有任何時間點可以被 Symantec 員工取得 private key、Symantec 員工無法使用該項測試工具簽自己擁有 private key 的 SSL certificate、再次確認 Symantec 的稽核紀錄是無法被更改與刪除的。

The third-party security audit must assess:

  • The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
  • That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
  • That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.

最後還特地放話說,有新的消息時會再考慮更進一步的反擊:

We may take further action as additional information becomes available to us.

可以發現語氣非常硬,要不是 Symantec 的市占率這麼高,Google 大概也不會這麼費工...

Symantec 提供的報告可以在「Test Certificates Incident Final Report」、「Incident Report 1」、「Incident Report 2」取得。

D-Link 的 open source package 內包含了拿來簽名用的 Private Key

D-LinkDCS-5020L 的 open source package (因 GPL 要求) 裡放了簽名用的 private key:「D-Link spilled its private key onto the web – letting malware dress up as Windows apps」。

而這把 key 由 Verisign 所簽,因此被 Windows 所信任,所以這把 key 可以用來簽 malware:

而不幸的是,這把 key 已經洩漏出來超過半年了:

The D-Link key was leaked in late February, and expired on September 3, it appears.

又是一連串的 revoke 過程... orz

Netcraft 放出 OCSP 伺服器效能資訊...

Netcraft 開始放 OCSP 的效能資訊了。由於有個排名在上面跑,這對於 SSL 供應商應該會有一定的壓力去改善服務品質:「OCSP Server Performance in March 2013」。

前面十名幾乎都是 VerisignAkamai,而 Verisign 都是用 Citrix Netscaler。繼續觀察看看好了...