Home » Posts tagged "ct"

Facebook 的 Certificate Transparency Monitoring 工具

前幾天找資料才發現原來 Facebook 很早就有提供 Certificate Transparency 相關的服務,可以用網域名稱搜尋查詢,甚至是訂閱:「Introducing our Certificate Transparency Monitoring tool」。

服務在「Certificate Transparency Monitoring - Facebook for Developers」這邊,搜尋與訂閱都可以在這邊處理。

tp.edu.twntpc.edu.tw 可以看到不少學校都用 Let's Encrypt 的服務,像是「臺北市內湖區碧湖國小全球資訊網」這個 (雖然一進去就看到 flash...)。

Cloudflare 的 CT Dashboard

Cloudflare 發表了他們的 CT (Certificate Transparency) Dashboard:「Introducing Certificate Transparency and Nimbus」。前面的篇幅解釋 CT 是什麼,以及為什麼要存在,另外也大略解釋了一下 Google 要求要帶有 SCT (signed certificate timestamp) 的新規定 (基於 Browser 方,也就是 Google Chrome 的立場)。

再來就是講 Cloudflare 推出的 Dashboard,也就是 Merkle Town。這個網站提供了網頁操作界面,讓大家可以了解現在 certificate 的情況。

點了 Current 後,可以看到 Let's Encrypt 的比率相當高,但 Comodo 的量不算差 (以收費的情況來說),再來是 DigiCert

話說回來,當所有的 SSL certificate 都需要 SCT 後,相當於一般人就能夠很精確的統計市占率了,商業的憑證公司應該不是很開心... (當初 EV 也有類似的問題,不過現在 DV 已經被 Let's Encrypt 打趴了...)

掃網域下主機名稱的方式...

原文是講滲透測試的前置作業,需要將某個特定 domain 下的主機名稱掃出來:「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR),如果管理者沒設好 DNS server 的話,這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。

看了一下有幾種方式:

應該有人可以提到所有的東西再寫成程式 XD

Let's Encrypt 的 Embed SCT 支援

翻到 Let's EncryptUpcoming Features 時看到:

Embed SCT receipts in certificates
ETA: February, 2018

對 Embed SCT 不熟,所以查了查這個功能。

這指的是在簽發 SSL certficiate 後,把資料丟給 Certificate Transparency (CT) 伺服器後,伺服器會提供 signed certificate timestamp (SCT);而這個資料放到 SSL certificate 內叫做 Embed SCT:(出自 CT 的 FAQ)

What is an SCT?
An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

當使用 ECC 時會小於 100 bytes:

How big is an SCT?
SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

這樣才能試著解釋前幾天提到要拔掉 HPKP 的事情:「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」,也就是為什麼他們是提 CT 解,而不是 DNS CAA 解...

不過我記得 CT server 可以自己架自己 submit 不是嗎?後來有另外規定一定要用第三方的嗎?這樣又很怪...

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

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.

這樣就有個開頭了...

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.

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

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 內的資料會有嚴重偏差,拿這個判斷影響力是很有問題的。

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

Archives