有風聲說司法部會把 Chrome 拆出 Google

看到這則新聞時決定讓子彈飛了一陣子,但好像沒看到什麼新消息:「Feds may target Google’s Chrome browser for breakup」,Hacker News 上也有討論可以翻翻:「Feds may target Google's Chrome browser for breakup (politico.com)」。

GoogleChrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站」這樣的事情),會直接先把 Google Chrome 拆出來的消息不算太意外。

不過大家對反壟斷調查更有興趣的應該是 YouTube 會怎麼被處理。網路上經常會看到「如何逃離 Google」之類的文章,Google 很多服務都有其他平台可以提供,或是 open source 軟體可以使用,但每次一講到 YouTube 時大家都很頭痛,都會提到 YouTube 的難以取代性,因為目前其他平台沒有一個是堪用的...

不知道什麼時候會發動調查...

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 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

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 時寫下一套方法,然後拿來擴大套用到整個瀏覽器...

Privacy Badger 預設關閉學習功能

Privacy Badger 是一個自動學習的 extension,可以學習 tracker 並且予以阻擋:

Privacy Badger automatically learns to block invisible trackers.

而這個自動學習功能在剛剛看到公告說明預設會關閉:「Privacy Badger Is Changing to Protect You Better」,主要是因為這個自動學習功能可以變成 fingerprint 資訊的一環:

The team also alerted us to a class of attacks that were enabled by Privacy Badger’s learning. Essentially, since Privacy Badger adapts its behavior based on the way that sites you visit behave, a dedicated attacker could manipulate the way Privacy Badger acts: what it blocks and what it allows. In theory, this can be used to identify users (a form of fingerprinting) or to extract some kinds of information from the pages they visit. This is similar to the set of vulnerabilities that Safari’s Intelligent Tracking Prevention feature disclosed and patched late last year.

所以現在變成會固定更新 pre-train ruleset 了:

From now on, Privacy Badger will rely solely on its “Badger Sett” pre-trained list of tracking domains to perform blocking by default. Furthermore, Privacy Badger’s tracker database will be refreshed periodically with the latest pre-trained definitions. This means, moving forward, all Privacy Badgers will default to relying on the same learned list of trackers for blocking.

當然這個功能還是可以手動開,但就有可能會被拿去 fingerprint 了,要開的人可以自己想一下... 不過不開的話就只是一個 ruleset 了 XD

有用的人可以自己考慮一下 XD

新的 TLS 攻擊:Raccoon Attack

這次看到的是針對 TLS 實做上的問題產生的 Raccoon Attack,反正先取個名字就對了,原圖有點大張,設個 medium size 好了 XDDD:

Why is the attack called "Raccoon"?
Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)

先講影響的產品,首先是經常中槍的 F5,這次連 timing measurement 都不需要太準確就可以打穿:

In particular, several F5 products allow executing a special version of the attack, without the need for precise timing measurements.

OpenSSL 的部份因為從 1.0.2f 之後因為其他的 security issue 所以改善了實做方式,就不會受到這次的攻擊手法影響。

剛剛翻了一下 Ubuntu 上的的資料,看起來 16.04 (xenial) 上的 OpenSSL 就已經是 1.0.2g 了,所以目前只要是有在 Ubuntu 支援的版本應該都不受影響:

OpenSSL assigned the issue CVE-2020-1968. OpenSSL does use fresh DH keys per default since version 1.0.2f (which made SSL_OP_SINGLE_DH_USE default as a response to CVE-2016-0701).

Firefox 直接拔了 DH 與 DHE 相關的 cipher suite,反正在這次攻擊手法出來前本來就已經計畫要拔掉:

Mozilla assigned the issue CVE-2020-12413. It has been solved by disabling DH and DHE cipher suites in Firefox (which was already planned before the Raccoon disclosure).

微軟的部份則是推更新出來:

Microsoft assigned the issue CVE-2020-1596. Please refer to the Microsoft Security Response Center portal.

回到攻擊手法,這次的問題是因為 DH 相關的實做造成的問題。

TLS 要求去掉 premaster secret 裡開頭的 0,造成會因為開頭的 0 數量不同而實做上就不會是 constant time,所以有了一些 side channel information 可以用:

Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server.

然後一層一層堆,能夠知道 premaster secret 開頭是不是 0 之後,接下來因為 server side 會重複使用同一組 premaster secret,所以可以當作一個 oracle,試著去計算出更後面的位數:

This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not.

Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri*ga, which lead to premaster secrets gri*b*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server.

所以針對這個攻擊手法的解法就是用「新鮮的」premaster secret (像是完全不重複使用),然後保留開頭的 0,不需要去掉。而 TLS 1.3 在定義的時候把這兩件事情都做了,所以不會受到影響:

Is TLS 1.3 also affected?
No. In TLS 1.3, the leading zero bytes are preserved for DHE cipher suites (as well as for ECDHE ones) and keys should not be reused.

另外在這邊提到的 Hidden Number Problem (HNP) 也是個不熟悉的詞彙,網站上有提到論文,也就是「Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes」這篇:

Given an oracle Oα(x) that on input x computes the k most significant bits of (α * gx mod p) , find α mod p.

是個離散對數類的問題,之後有空再來翻一翻好了。

用 picture + source + img 替代本來的 JavaScript 替換

目前我在 blog 上使用 Imgur 的圖檔主要是用 WebP 格式,然後針對不支援 WebP 的瀏覽器 (主要就是蘋果家的 Safari) 是用 JavaScript 換回 JPEG 格式...

昨天早上看到「AVIF has landed」這篇,提醒我有 <picture> 這個原生支援的方式可以用,翻了一下 Can I Use 上面的支援程度,看起來除了 IE11 以外幾乎都支援了 (參考「Picture element」),而且 IE11 應該也會因為語法的關係走到正確的 JPEG fallback,大概是這樣:

<picture>
    <source type="image/webp" srcset="https://i.imgur.com/xxxxxx.webp" />
    <img src="https://i.imgur.com/xxxxxx.jpg" alt="" />
</picture>

換完後來觀察看看...

Chromium (Google Chrome) 實做對 Root DNS 的影響

前幾天在 APNIC 上的這篇文章受到社群注意:「Chromium’s impact on root DNS traffic」,在 Hacker News 上也有對應的討論:「Chromium's Impact on Root DNS Traffic (apnic.net)」。

文章作者 Matthew ThomasVerisign 的員工 (Verisign Labs),可以看出來主力在 DNS 的部份。

Chromium (以及 Google Chrome) 會隨機產生一組 hostname,確認所在的網路是否有 DNS hijack:

這導致了在 Root DNS 上會看到大量不存在網域的 DNS query,這點隨著 Google Chrome 的市占率愈來愈高,在 Root DNS 上這些 DNS query 甚至佔到 40% 以上:

不過 Root Server 有上千台在跑,就目前的效能來說應該是還 OK:

As of 2020-08-27, the root server system consists of 1097 instances operated by the 12 independent root server operators.

把這個問題丟到 bugs.chromium.org 上翻,看起來有三張票在進行中:

瞄了一下裡面的討論,目前的方向有兩類,一種是主張完全關掉,這樣確定可以大幅減少對 Root DNS 的壓力,另外一種是設計 cache,使得 Root DNS 的 loading 降低。

這次有不少新聞都有報導,受到 PR 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

Chrome 85 支援 AVIF

看到「How to Use AVIF: The New Next-Gen Image Compression Format」這篇在推銷用 AVIF 取代 JPEGWebP

首先是跑去 Can I Use 翻,發現 Google Chrome 85 之後支援了,另外在「Issue 960620: Support AVIF」這邊可以看到對應的 ticket,以及「AVIF Image Decode」這邊有狀態:

Enabled by default (tracking bug) in:
Chrome for desktop release 85

現在的 stabel channel 是 84,所以是下個 release 就會有了。以 Google Chrome 的市占率來說,推出來等於是支援度直接過半... 這點也的確有人批評,不過又是另外一個話題了。

對於不支援 AVIF 的瀏覽器,也有對應的 polyfill 可以上 (用 javascript 去補功能),不過因為是透過 AV1 codec,能夠向下支援的版本還是不多,除非連 AV1 都透過 polyfill 支援:「AVIF (AV1 Still Image File Format) polyfill for the browser」。

另外在寫「WebP 的檔案大小未必比 JPEG 小...」這篇時有提過 AVIF 其實也不是完美的,畢竟是從 video codec 演化來的演算法,對於演算法判斷不重要的部位會掉比較多細節...

GPU.js

前幾天在 Hacker News Daily 上看到的專案:「GPU.js - GPU accelerated JavaScript」,對應的 GitHub 頁面在 gpujs/gpu.js 這邊。

看起來是用 WebGL 接進去的,不過他用來 benchmark 的硬體頗暴力啊:

Hardware: Xeon Gold 5217 + 8 x RTX 2080ti

這邊用了八張 2080Ti,如果一張就大約是 1/8 效能的話,看起來好像還好... 一張 2080Ti 跟 Xeon Gold 5217 跑出來差不多?價錢也在同一個範圍區間...

暫時不知道用途...