Tag: transparency

用 Atom feed 訂閱 crt.sh 的 Certificate Transparency

本來打算自己寫個程式訂閱 Certificate Transparency 的資料，結果發現 crt.sh 本身就有提供 Atom feed。

舉我的例子「crt.sh | gslin.org」來說，對應的 Atom feed 就在 https://crt.sh/atom?q=gslin.org 這邊。

不過 crt.sh 的速度不快，我在使用 Slack 內建的 /feed add 加了很多次才成功，但設定好之後放著收更新就可以了，看起來還算方便。

官方應該是可以把 feed 的筆數壓低，降低對後端 PostgreSQL 的壓力才對，像是只丟最近 30 天的量就好，現在看起來是所有的 entry 都轉成 Atom feed 丟出來...

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率？

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA，以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄：「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的，沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例，用 SSL Labs 的工具就可以掃出來問題：「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s)，所以在 Android 上找不到一條完整的 trust chain：

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain，所以 Windows 上的 Microsoft Edge 與 Google Chrome 是不會有問題的 (這兩個都吃系統的 CA store)：

而 Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料，就是 Android 那包)。

交叉比對中華電信自家的網站，像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組，可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA，但有兩種不同的 SHA256，可以翻到是：「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」，點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽，但卻不是每一個 CA 都有被所有瀏覽器認可，所以在設定的時候就得注意...

話說回來，現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency)，的確是有辦法抓出所有的 Intermediate CA 沒錯，但瀏覽器幫使用者預載感覺好像怪怪的？

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料：

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack？

kernel.org 推動 git push 的簽名

在 LWN 上看到 kernel.org 解釋並且推動 git push 的電子簽名：「Signed pushes for kernel.org」。

在「Signed git pushes」這篇裡面解釋了除了 git commit 本身的簽名外，另外 git push 的簽名也有重要性。

而在「Introducing the kernel.org git transparency log」這邊則是公開了對應的 git transparency log。

這個方法讓 kernel.org 上的 git repository 會更透明，加上 kernel.org 上的 git repository 會被很多人 mirror，在真的出問題的時候，大家手上也都有資料可以交叉比對...

Cloudflare 提供 Certificate Transparency 的通知服務

Cloudflare 推出了 Certificate Transparency 的通知服務，當有任何新的 SSL certificate 發出時就會通知：「Introducing Certificate Transparency Monitoring」。

基本上就是一組 crawler 去各家記錄挖資料回來：

Business 與 Enterprise 版本的可以設定要通知誰，Free 與 Pro 版本則是固定會通知網域的擁有人 (這邊指的是 Cloudflare 上的)：

If you’re on a Business or Enterprise plan, you can tell us who to notify. Instead of emailing the zone owner (which we do for Free and Pro customers), we accept up to 10 email addresses as alert recipients. We do this to avoid overwhelming large teams.

剛剛把掛在上面的 domain 都開起來了，這樣在 Let's Encrypt 自動 renew 的時候應該會收到通知...

另外一個同名的工具則是 2016 年底時 Facebook 推出的 (需要登入才能使用)，可以搜尋有哪些 domain：「Certificate Transparency Monitoring」。

把 Google 服務拔乾淨的 Chromium

有人試著把 Chromium 裡的 Google 相關服務都拔乾淨，叫做 ungoogled-chromium：

Modifications to Google Chromium for removing Google integration and enhancing privacy, control, and transparency

有提供志願者包好的 pre-built binary，但看了一下版本有點舊，而且不能確定裡面有沒有什麼加料... 要用的人可能還是要考慮自己編一包出來。

在「Add a PPA or APT repo」這邊有人在討論要怎麼包 PPA 出來，不過看起來卡關了...

找子網域的 subfinder

在「subfinder – 找子網域的工具」這邊看到的，專案是用 Golang 寫的，需要 Golang 1.10+ 才能裝... 這類工具在 PT 找入口時還蠻好用的。

裝完後馬上跑個熱門的 ./subfinder -d teamkp.tw 可以看到不多：

Total 4 Unique subdomains found for teamkp.tw

.teamkp.tw
donate.teamkp.tw
www.donate.teamkp.tw
www.teamkp.tw

加上 -v 則可以看到來源。

Google Chrome 67 將可以在 DevTools 裡看到 SCT 的內容

在 Twitter 上看到 Google Chrome 67 (下一個版本) 的 DevTools 將會顯示憑證上的 Certificate Transparency 資訊：

現在要看這個資訊比較麻煩，之後可以在瀏覽器裡直接讀就會簡單一些了...

話說回來，Let's Encrypt 上個月也支援 SCT 了：「Engineering deep dive: Encoding of SCTs in certificates」，不過目前只能先用 command line 工具看... 我拉了 Let's Encrypt 官方網站的 certificate 可以看到 (Let's Encrypt 那篇文章裡的範例)，但我自己 blog 的 certificate (序號 04ef0022ed7d5417f1ccbc011acf7fea9830) 看起來是在 Let's Encrypt 支援 SCT 之前申請的，沒看到 SCT 資訊... 要等下一次的 renew 了。

Facebook 的 Certificate Transparency Monitoring 工具

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

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

打 tp.edu.tw 與 ntpc.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