Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

Dehydrated 使用 ZeroSSL 的方式

上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務,而各家 acme client 也都陸陸續續支援了。

Dehydrated 是在 2020/09/15 的時候實做:「EAB + ZeroSSL support」,我就抓了個新版,更新之前自己包的 PPA dehydrated-lite...

Dehydrated 的設定方式還蠻簡單的,在 /etc/dehydrated/config 裡面這樣寫:

CA=zerossl
EAB_HMAC_KEY=x
EAB_KID=y

其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得,然後其他就照舊跑...

ZeroSSL 也提供免費的 SSL Certificate (DV) 了

Facebook 上被朋友敲可以測 ZeroSSL,另外一個透過 ACME 協定提供免費的 SSL Certificate,不過目前只有支援單一網域名稱 (DV):「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」。

我先前就有在測 ZeroSSL,不過驗證一直過不去,當時有在 Twitter 上找 ZeroSSL 帳號問,但 ZeroSSL 的人說 ACME 的部份不在客服範圍,就先丟著...

剛剛發現是自己耍笨了,原因是 nginx 沒設好造成驗證卡住,一改好後就正常了。

SSL LabsSSL Server Test 翻了一下,他的 Root CA 看起來歷史更久,應該是有機會解決 Let's Encrypt 明年會產生的 Root CA 憑證信任問題,也就是先前在「Let's Encrypt 在 Android 平台上遇到的問題」提到的問題,在 Hacker News 上的討論也可以看到有人提到這點:

Good to know, and I'm glad there's an alternative to Let's Encrypt, just in case. Is ZeroSSL trusted by old Android devices? If so, that might be a work-around for Let's Encrypt's cross-signing from IdenTrust expiring.

不過也有些人有疑慮,畢竟提供這個服務後面的公司幹過不少壞事:

If zerossl is reselling/a subsidiary of sectigo, that’s enough reason to never use this.
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.

Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.

但看起來至少是多了一個選擇...

Firefox 83 推出 HTTPS-Only Mode

MozillaFirefox 83 推出了 HTTPS-Only Mode:「Firefox 83 introduces HTTPS-Only Mode」。

就如同名稱的說明,這個模式只會允許 HTTPS 的連線,主要的設計方式是把「開 HTTP 連線」當作一種特殊權限,就像 notification 之類的權限一樣:

When you enable HTTPS-Only Mode:

  • Firefox attempts to establish fully secure connections to every website, and
  • Firefox asks for your permission before connecting to a website that doesn’t support secure connections.

使用者會先在設定裡面開啟這個全域設定:

開了以後如果想要連 HTTP 網站,就會遇到阻擋:

這個功能真的不賴,馬上想到 Tor BrowserTails 應該都會改用這個,畢竟 Tor 的 HTTP 出口常常被搞...

我自己類似的保護措施是把 HTTP 頁面執行 JavaScript 的能力全部關掉,像是這樣 (這邊是 Brave 瀏覽器,是個基於 Chromium 的 fork):

然後對於需要 JavaScript 的 HTTP 頁面,我是透過「Simple JavaScript Toggle」暫時授權。

這樣至少在無法確認 integrity 的情況下不會執行 js,減少可被攻擊的面積...

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 EdgeGoogle 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?

Let's Encrypt 在 Android 平台上遇到的問題

同樣是「Standing on Our Own Two Feet」這篇文章,Let's Encrypt 預期明年九月後會在 Android 上遇到嚴重的相容性問題。

很舊的裝置主要是透過 IdenTrust 的 Root CA (DST Root CA X3) 對 Let's Encrypt 的 Intermediate CA (目前主要是 Let's Encrypt Authority X3) 簽名,從而建立憑證的信任鍊,而新的裝置除了 IdenTrust 的 CA 外,也信任了 Let's Encrypt 自家的 Root CA (ISRG Root X1):(出自「Chain of Trust」)

在 2016 年四月正式對外啟用時主要是靠 IdenTrust 的 cross-sign,而也是在 2016 年時 Let's Encrypt 自家的 Root CA (ISRG Root X1) 陸陸續續被各家收進 CA store。

所以這個時間點之前的 Android (大約是 7.1.1) 算是個相容性的分界線,在這個版本前 (而且系統無法更新的) 都只能靠 IdenTrust 的 cross-sign,這看起來大約有 33.8%,實際的流量大約是 1%~5%:

Currently, 66.2% of Android devices are running version 7.1 or above. The remaining 33.8% of Android devices will eventually start getting certificate errors when users visit sites that have a Let’s Encrypt certificate. In our communications with large integrators, we have found that this represents around 1-5% of traffic to their sites. Hopefully these numbers will be lower by the time DST Root X3 expires next year, but the change may not be very significant.

目前還有大約十個月左右的緩衝期,但大家都知道 Android 的更新速度,就十個月來說看起來不太樂觀...

官方有給他們不願意再取得一次 cross-sign 的原因,不過我覺得這個理由就很怪了,這個描述看起來是 IdenTrust 不願意再簽發一次?直覺覺得 IdenTrust 站在商業立場應該是很願意才對?而且除了 IdenTrust,應該也有其他家會有興趣?

Can we get another cross-signature? We’ve explored this option and it seems unlikely. It’s a big risk for a CA to cross-sign another CA’s certificate, since they become responsible for everything that CA does.

也有可能是放個話讓 IdenTrust 表態?先繼續看下去...

最差的情況應該就是沒有 cross-sign,然後也沒提供其他的 workaround,這樣就是買一般的 SSL certificate 來解了...

在視訊會議裡面,用肩膀的移動猜測輸入的字串

在「Determining What Video Conference Participants Are Typing from Watching Shoulder Movements」這邊看到的方法,利用視訊會議時肩膀的移動猜測輸入的字串,原始的論文在「Zoom on the Keystrokes: Exploiting Video Calls for Keystroke Inference Attacks」這邊可以看到。

就論文有提到的,單就這個資訊的準確度看起來不高,看起來主要是想驗證這也是一個攻擊手法... 但馬上想到視訊會議裡如果有聲音的話,可以透過分析鍵盤的聲音攻擊,這在 2005 年的時候就有類似的手法了,而且準確率很高,不過不知道過了視訊會議軟體後會差多少:「Snooping on Text by Listening to the Keyboard」。

算是個頗特別的方法就是了...

Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站

在「Chrome exempts Google sites from user site data settings」這邊看到的新聞,引用的網頁是「Chrome exempts Google sites from user site data settings」,然後這篇也有上到 Hacker News Daily 上,所以 Hacker News 上的討論也蠻熱鬧的:「Chrome exempts Google sites from user site data settings (lapcatsoftware.com)」。

作者實際在 macOS 上拿最新版的 Google Chrome (86.0.4240.75) 測試,發現就算你針對 Google 自家的網站選了「Clear cookies and site data when you quit Chrome」,只有 cookie 會清掉,但 database storage、local storage 與 service workers 都不會被清掉:

然後 Brave 那邊前陣子時做完 Sync v2 了,又是個機會看看那邊如何了... 結果發現在 2019 年的時候意外修正了一部分:「"Keep local data only until you quit your browser" only deletes cookies, not local storage #1127」、「Fixes: #870 Replaced logic to clear data with WebKit api. #883」。

Google Chrome 的 Cache Partition 生效

去年提到的「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」在最近推出的 Chrome 86 預設生效了:「Chrome changes how its cache system works to improve privacy」。

Google 的文章「Gaining security and privacy by partitioning the cache」這邊有提到不同瀏覽器都有打算要支援類似的架構,對應的差異:

Is this standardized? Do other browsers behave differently?

"HTTP cache partitions" is standardized in the fetch spec though browsers behave differently:

  • Chrome: Uses top-level scheme://eTLD+1 and frame scheme://eTLD+1
  • Safari: Uses top-level eTLD+1
  • Firefox: Planning to implement with top-level scheme://eTLD+1 and considering including a second key like Chrome

文章裡面看到了有趣的東西,是他提到了 Fetch 這個標準,然後是在「2.7. HTTP cache partitions」這邊出現了對應的說明:

To determine the HTTP cache partition, given request, run these steps:

Let key be the result of determining the network partition key given request.

If key is null, then return null.

Return the unique HTTP cache associated with key. [HTTP-CACHING]

所以看起來是訂 Fetch 時寫下一套方法,然後拿來擴大套用到整個瀏覽器...