幹壞事是進步最大的原動力
先前就有提到 Chrome 與 Firefox 因為 Symantec 的信任問題太大，都有打算終止信任 Symantec 的憑證了，而其他瀏覽器也都有陸陸續續公佈了類似的計畫，大家的時間表都抓差得不多...
最近接近當時各家瀏覽器規劃的終止信任日，而在使用開發版本的 Chrome 與 Firefox 開始連不上一些網站了。我自己是走 beta channel 所以還沒中，不過好像也快了...
我拿了「Umbrella Popularity List」這邊提供的前一百萬網站測，以 .tw 結尾的網站看起來就只剩下兩個還沒換了：
在蘋果的網站上有清單可以翻：「Information for website operators about distrusting Symantec certificate authorities」。
Mozilla 旗下的產品 (包括 Firefox) 將在今年十月對 Symantec 簽出的 SSL Certificate 終止信任：「Distrust of Symantec TLS Certificates」。
Mozilla 有把發生的事情都整理出來：「CA:Symantec Issues」，另外 Firefox 的動作分成三個階段，目前 stable 是 58，但 nightly 是 60 了：
去年 Google Chrome 就有先丟出對 Symantec CA 的計畫 (參考「Google Chrome 對 Symantec 全系列憑證的不信任計畫」這篇)，看起來 Mozilla 的計畫也差不多，但時間有些差異...
Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫：「Chrome’s Plan to Distrust Symantec Certificates」。
這包括了一卡車的品牌，像是 Thawte、VeriSign、GeoTrust、RapidSSL，不過 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 的 Ryan 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 買進去 (像是 Verisign、Thawte)：
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 端會不會有類似的動作了...
在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的事情，隨著時間的發展，大家發現事情愈來愈誇張。
在兩個小時前 Mozilla 的 Gervase Markham 提出了對 WoSign + StartCom 處置的草稿：「WoSign and StartCom」，草稿在 Google Docs 上的「WoSign and StartCom」這邊可以看到。另外 Mozilla 在 wiki 上「CA:WoSign Issues」將 WoSign + StartCom 的事情都整理了出來，也是重要的資料。
文章很長，先講結論：目前 Mozilla 打算把 WoSign 與 StartCom 所簽出的 certificate 都照當年 CNNIC 的方式拔掉。
從頭說明，事情發生於八月底的時候 Google 通知了 Mozilla 一連串 WoSign 出包卻沒有主動通報的事件，當時知道的大約有三或四件。而在 mozilla.dev.security.policy 不斷的討論的情況下，由於關注度變得超高，在搜尋大量的資料下發現更多問題，到現在 Mozilla 的 wiki 上已經列出了 13 個。
而這邊以 Mozilla 最後整理的草稿，將 13 個事件整合起來成幾件來說明：
在瀏覽器會對 2016 後所簽出直接跳 error 的情況下 (像是「An update on SHA-1 certificates in Chrome」)，直接偽造是 2015 年簽出的 certificate。
Mozilla 的 CA program 要求當公司擁有權轉移時必須揭露：
[...], Mozilla’s program requirements say that a change of CA ownership must be disclosed. In this case, that was not done - and in fact, the change was directly denied a few months after it happened.
直到最近被抓到而揭露後，發現 WoSign 所揭露的也不正確，StartCom 已經開始使用 WoSign 的 infrastructure 了：
More recently, even after the evidence of total control was public, WoSign referred to their interest in StartCom in a press release as “an equity investment”, and maintain that the two businesses continue to be separate even today. They say “the original system ... of StartCom remains unchanged”.
However, there is technical evidence that around a month and a half after the acquisition, StartCom issuances switched to using WoSign’s infrastructure - either the same instance of it, or their own instance.
而 Mozilla 要求 WoSign 提供他們產生 serial number 的程式碼時：(在 WoSign 簽出重複的 serial number 問題時得到的)
Mozilla asked WoSign how they generated their serial numbers, and was told that they used the Java package java.crypto.SecureRandom. They supplied the following code snippet:
[...]
However, as can be seen from this simple test harness, this code snippet does not produce serial numbers matching WoSign’s idiosyncratic pattern.
再度發現 WoSign 給的程式碼對不上。(hey)
然後再多方面分析後發現 WoSign 宣稱跟 StartCom 只共用 CRL/OCSP (revoke 機制) 是假的。Mozilla 由多方面判斷發現，至少程式碼是共用的 (i.e. clone)，甚至猜測整個系統都是共用的 (在更後面提到)：
We believe that, taken together, all this shows that StartCom’s certificates are now being issued using either WoSign’s existing infrastructure or a clone of it, and that WoSign’s operational control of StartCom began straight after the November 1st 2015 sale date. This evidence should be compared against WoSign’s recent assertion that “Even now, it still independent in the system, in the validation team and management team, we share the CRL/OCSP distribution resource only.”
再來是講一些背景。因為金流產業到了 2016 年還是有系統不支援 SHA-256 certificate，而 CA/Browser Forum 已經禁止簽發 SHA-1 憑證了，所以 2016 年二月的時候 WorldPay 跑上來尋求例外：
This became clear in February of 2016, where a payment processor called WorldPay applied to the CAB Forum for an exception so they could acquire 8 SHA-1 certificates to keep SSL working for their legacy payment terminals. Their CA was unable to help them because of the ban in the CAB Forum Baseline Requirements, and to issue in violation of the ban would lead to a “qualified” (not clean) audit, which might lead to browsers no longer accepting their audit as valid to keep them trusted.
而在亞利桑那的 face-to-face meeting 中剛好就討論了這點，允許 Symantec 簽發，而要提出來的是，WoSign 的 Richard Wang 也在場：
This issue was discussed at length in the CAB Forum face-to-face meeting from 16th-18th February 2016 in Scottsdale, Arizona (where Richard Wang of WoSign was present). Mozilla then had a public discussion about it in our policy forum starting on 23rd of February. In the end, the browsers reluctantly agreed to let Symantec issue these certificates for Worldpay - or rather, they agreed to accept that Symantec’s next audit would be qualified in this way.
所以 Mozilla 再次強調，當下大家的結論是特別許可，簽發被禁止的 SHA-1 certificate 是很嚴重違反規定的事情：
Even at this point, in February 2016, it was (or should have been) clear to all CAs, including WoSign, that issuing SHA-1 certificates in violation of the ban was a Very Big Deal, and that permission had to be sought from the browsers in order for the CA not to face difficulty.
接下來是 Tyro，這是一家澳洲金流廠商，直接複製草稿上的時間表：
| Feb 3rd 2010 | GeoTrust issues a SHA-1 certificate for *.tyro.com from their Equifax root, valid until May 6th 2013. |
| Apr 6th 2013 | A month before their old cert expires, GeoTrust issues a replacement SHA-1 certificate for *.tyro.com from a GeoTrust root, valid until June 7th 2016. A simple roll-over replacement. |
| Jan 1st 2016 | SHA-1 issuance ban comes into effect. |
| May 24th 2016 | A month before their old cert expires, GeoTrust issues a SHA-256 certificate for *.tyro.com from a GeoTrust root, valid until June 23rd 2019. |
但 Tyro 在 2016 年五月拿到的 SHA-256 憑證很明顯不合用，於是試著找 SHA-1 憑證... 結果不管怎樣，後來拿到了 StartCom 所簽出來的 SHA-1 憑證，而藉由技術上的 pattern 可以發現這是 back-dated (偽造日期簽發)：
But the strong evidence is that this SHA-256 certificate did not meet Tyro’s needs. We can see a SHA-1 certificate for *.tyro.com which was logged in CT on June 8th 2016, a day after their previous SHA-1 certificate expired. This certificate is not issued by GeoTrust (who still provide the cert for their main website) or Comodo, tyro.com’s usual providers, but by StartCom. And the notBefore date is that magic date of 20th December, 2015 - a date on which, as noted above, StartSSL.com was closed for upgrading, and on which we have seen many Macau certificates issued by WoSign, which we believe are back-dated.
也可以很清楚的確認到現在還在使用：
The SHA-1 certificate in question is still in use today on https://iclient.tyro.com/.
最後 Mozilla 得到的結論：
同時他們認為最後一點是最嚴重的一點，你必須將 StartCom 視為與 WoSign 完全同樣的公司，所有對 WoSign 的檢查與處置都必須相同對應到 StartCom 上：
This last point is important; the practices at WoSign are now being seen at StartCom. Therefore, we conclude that all of ownership, infrastructure and control are sufficiently common between the two companies that it would therefore be reasonable for any action Mozilla chooses to take against WoSign to also be taken against StartCom and vice versa.
另外一個很嚴肅的問題，CA 架構是建立在稽核機制上，而 WoSign 所選擇的稽核單位無法稽核出應有的「多個問題」：
WoSign’s auditors, Ernst & Young (Hong Kong), have failed to detect multiple issues they should have detected. (Issue J, Issue X)
提案的處理方式類似於 CNNIC 當時被拔掉的方式，針對某個日期之後的都不信任。這同時包括了 WoSign 與 StartCom 的 certificate。這真是可喜可賀啊...
tl;dr：目前的外部稽核還沒有完成，有可能會有更慘烈的情況。如果你最近要買 SSL certificate，不要碰 Symantec 旗下的產品，包括了 Verisign、Thawte、GeoTrust、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」取得。
照目前公開的報導說，幹這件事情的人被幹掉了：「Symantec employees fired over fake security certificates」，也進一步透漏，發現有三個 certificate 被發出來：
Symantec's senior director of engineering Quentin Liu said it discovered three unauthorised certificates last week during product testing.
He explained that 'a few' employees who, it said, had passed the company's on-boarding and security training, failed to follow its policies and were therefore fired after a "thoughful review process."
還是沒看到第三方單位介入稽核的消息。
Google Online Security Blog 上公佈了一篇他們最近的發現，並且發佈 Google Chrome 的安全性更新：「Improved Digital Certificate Security」。
原因出自於 Thawte (Symantec) 發出 www.google.com 的 EV SSL certificate：
On September 14, around 19:20 GMT, Symantec’s Thawte-branded CA issued an Extended Validation (EV) pre-certificate for the domains google.com and www.google.com. This pre-certificate was neither requested nor authorized by Google.
Google 在 Certificate Transparency 上發現：
We discovered this issuance via Certificate Transparency logs, which Chrome has required for EV certificates starting January 1st of this year. The issuance of this pre-certificate was recorded in both Google-operated and DigiCert-operated logs.
對應的 certificate 紀錄可以在「crt.sh | 9314698」這邊看到，包括了 public key 資訊。
然後 Google 跟 Symantec 確認後認定是內部測試造成的 (...)：
During our ongoing discussions with Symantec we determined that the issuance occurred during a Symantec-internal testing process.
並且發出安全性更新把這把 key 放到 Google Chrome 的 revocation metadata 裡：
We have updated Chrome’s revocation metadata to include the public key of the misissued certificate. Additionally, the issued pre-certificate was valid only for one day.
一天的內部測試嗎？我怎麼覺得更像是 APT 攻擊？
最後補充一下，在 Google Chrome 裡面 *.google.com 的網段的 SSL certificate 是被特別保護的，可以參考「transport_security_state_static.json」這邊的 JSON 資料，裡面可以看到這幾段：
{
"name": "google",
"static_spki_hashes": [
"GoogleBackup2048",
"GoogleG2",
"GeoTrustGlobal"
],
"report_uri": "http://clients3.google.com/cert_upload_json"
},
以及：
// (*.)google.com, iff using SSL, must use an acceptable certificate.
{ "name": "google.com", "include_subdomains": true, "pins": "google" },
也就是只有 Google 自己的 CA 與 GeoTrust 的 CA 是被允許發出 www.google.com 的 SSL certificate (至少在 Google Chrome 裡面會被保護到)。而 GeoTrust 也是 Symantec 的牌子。
如果讓我以陰謀論的角度來猜，這更像是在測試有會有哪些管道通報會讓 Google 發現。