Tag Archives: transparency

Mozilla 也在考慮對 Certificate Transparency 的掌握度

由於 Firefox 要支援 Certificate Transparency 的緣故,在「Mozilla CT Policy」這邊 Mozilla 在討論要建立自己的 CT policy 以及自己的架構:

CT is coming to Firefox. As part of that, Mozilla needs to have a set of CT policies surrounding how that will work. Like our root inclusion program, we intend to run our CT log inclusion program in an open and transparent fashion, such that the Internet community can see how it works and how decisions are made.

這樣就有個開頭了...

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 還是沒動作外,其他比較大的瀏覽器都到齊了...

iOS 阻擋 WoSign 憑證

mozilla.dev.security.policy 上看到有人行動了:「Apple's response to the WoSign incidents」。這使得 Apple 成為 WoSign 事件中第一個行動的單位。

Apple 這次先把 WoSign 放入 iOS 憑證清單的黑名單公告在這邊:「Blocking Trust for WoSign CA Free SSL Certificate G2」。

WoSign 在 iOS 產品線中是靠 StartComComodo 的交叉簽章,所以如果 Apple 只想擋 WoSign 憑證的話,必須以阻擋 Intermediate CA 的方式避開:

Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.

不過為了降低對 user 的影響,這次的阻擋會有例外。當 CT log server 在 2016-09-19 前收到的 SSL certificate 還是會信任 (要注意的重點是,這邊的日期不是簽發,是送到 CT log server 上):

To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19.

接下來會開始更深入的調查 WoSign 與 StartCom:

As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.

另外本來的棚子裡,Qihoo 360 與 StartCom 正式提出要求在 2016/10/04 與 Mozilla 的人面對面討論 (在英國):「WoSign and StartCom: next steps」:

Following the publication of the recent investigative report, representatives of Qihoo 360 and StartCom have requested a face-to-face meeting with Mozilla. We have accepted, and that meeting will take place next Tuesday in London.

繼續來看進度... 下個禮拜應該會有更多的資料出來。

Certificate Transparency 開始紀錄 Untrusted CA

Google 宣佈他們開始收 Untrusted CA 的 Certificate Transparency 記錄:「Certificate Transparency for Untrusted CAs」,主要是這兩種 CA:

  • Those that were once trusted and have since been withdrawn from the root programs.
  • New CAs that are on the path to inclusion in browser trusted roots.

也就是被幹掉的,以及申請中的... 這樣可以後續追蹤很多東西。

OpenSSL 1.1.0 的 Release Notes 先放出來了 (現在是 Beta 1)

雖然才 Beta 1,但 OpenSSL 先放出 1.1.0 的 Release Notes 了:「OpenSSL 1.1.0 Series Release Notes」。

有幾個新的功能以及重大的改變,包括了對 ChaCha20Poly1305 的支援,並且把 SSLv2、RC4、所有 40bits 與 56bits 的 cipher 拔掉,然後支援 Certificate Transparency

讓人頗期待... 不知道來不來得及跟上 Ubuntu 16.04

Let's Encrypt 對整個 SSL Certificate 的影響

Let's Encrypt 的人試著從多個資料來源分析 Let's Encrypt 對整個網路上安全性的影響力:「Early Impacts of Let's Encrypt」。

資料來源包括 Certificate Transparency (CT) 記錄與 censys (這個網站用 StartSSL,被我屏蔽掉了 XD)。

But I do have access to Certificate Transparency logs, as well as other data sources like Censys.io.

前者 CT 的部份會有嚴重的偏差,因為 CA/Browser Forum 只規定 EV certificate 要送 CT log,一般的 SSL certificate 可以不送 (幾乎都沒送),而 Let's Encrypt 發的是一般的 SSL certificate,還是有送 CT log。

把資料送上 CT 是好事,但這使得 CT log 內的資料會有嚴重偏差,拿這個判斷影響力是很有問題的。

所以這份資料就是看看就好...

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