拿到標著 Stripe, Inc. 的 EV Certificate

在「Nope, this isn’t the HTTPS-validated Stripe website you think it is」這邊看到利用一家同名的公司取得相同的 EV Certificate 的方法:

這個不是你想像中的 Stripe 網站在 https://stripe.ian.sh/ 這邊。這在 Safari 上攻擊的效果特別好,因為不會顯示出 hostname:

不過 EV Certificate 當初設計的目的本來就是墊高 phishing 的成本,並不是完全阻止... 這應該暫時不會解吧 :o

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」取得。

Symantec 的 Thawte 發出 Google 的 SSL certificate 的後續

照目前公開的報導說,幹這件事情的人被幹掉了:「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."

還是沒看到第三方單位介入稽核的消息。

Thawte (Symantec) 發出 www.google.com 的 EV SSL certificate

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.

GoogleCertificate 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 發現。

CNNIC 的根憑證 (包括 EV) 從 Google 全系列產品移除

在「Maintaining digital certificate security」這篇文章裡的更新:

Update - April 1: As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products. This will take effect in a future Chrome update. To assist customers affected by this decision, for a limited time we will allow CNNIC’s existing certificates to continue to be marked as trusted in Chrome, through the use of a publicly disclosed whitelist. While neither we nor CNNIC believe any further unauthorized digital certificates have been issued, nor do we believe the misissued certificates were used outside the limited scope of MCS Holdings’ test network, CNNIC will be working to prevent any future incidents. CNNIC will implement Certificate Transparency for all of their certificates prior to any request for reinclusion. We applaud CNNIC on their proactive steps, and welcome them to reapply once suitable technical and procedural controls are in place.

Google 的作法是將現有使用 CNNIC 發出的 SSL certificate 會以白名單形式放入,然後移除現有的 CNNIC 憑證。

Wildcard EV Certificate...

Netcraft 這篇「Wildcard EV certificates supported by major browsers」提到幾個重點...

首先是 EV 規範內禁止使用 Wildcard certificate (出自「Guidelines ForThe IssuanceAnd Management Of ExtendedValidationCertificates」):

Wildcard certificates are not allowed for EV Certificates.

然後還是有人發 *.cclearning.accenture.com,而且主流瀏覽器會正常照 EV 模式顯示出來:(這邊拿 Google Chrome 的範例,原文有所有截圖)

只有 Safari 的手機版本當作普通 certificate 處理的:(下面兩張圖,上圖是桌機版,下圖是手機版)

被抓出來鞭後應該會修正... 吧?

Update:感謝 comment 的糾正,Safari 的地方寫錯了...

這下可包大了,居然有一堆 "localhost" 這類的 SSL Certificate 被發出來...

這些 CA 是怎麼管理下面的單位的啊...

Slashdot 報導了 EFF 的 Chris Palmer 發現有大量 Unqualified Name 被 sign 過:「Thousands of SSL Certs Issued To Unqualified Names」、「Unqualified Names in the SSL Observatory」。

依照原文中「You can also use the Observatory in an Amazon EC2 instance we created.」這句話,應該是直接掃整個 IPv4 network 了吧,反正以現在的各種技術來說,IPv4 address space 不大?

結果相當豐碩,包括了 2201 個 "localhost"、806 個 "exchange"、2383 個 /^\w*exchange\d+$/、5657 個 /^\w*exch\d*$/。光是可以在 Internet 上被觀察到的 Unqualified Name 就有 37244 個。

甚至連 EV Certificate 都有 Unqualified Name 被 sign:「www.prism.gatech.edu/~gmacon3/ssl-observatory/unqualified_local_rfc1918_ev.txt」。(那個 VeriSign 你太誇張了,"CN=Bownedev" & "CN=qa-sescib-web1" & "CN=tc-teweb01-s" 你也能過?EV 的文件檢查根本沒再看的喔?)

在「www.prism.gatech.edu/~gmacon3/ssl-observatory/unqualified_local_rfc1918_all.txt」這邊有張表列出出包單位的數量可以看...

雖然一月就做完這份資料,但不得不說 EFF 補刀的時間真棒... 趁這陣子 CA 架構問題正熱的時候寫一篇來補一刀 XD

Perl 的 AnyEvent + EV

Coro 用起來不太順,於是跑到 freenode 的 #perl.tw 上問 Coro 是不是能用的東西,結果 clkao 建議了 AnyEvent,用了感覺反而比 Coro 順手,大概是因為平常對 event-based 的東西還算習慣吧...

與「Perl 的 Threading 實做:Coro」這篇同樣的東西,改用 AnyEvent + EV 寫: