Google Chrome 要推動預設使用 HTTPS 連線

Google Chrome 從 90 版要把 https:// 變成網址輸入時的預設值:「A safer default for navigation: HTTPS」。Hacker News 上的「Chrome’s address bar will use https:// by default (chromium.org)」也可以看一下。

也就是說,沒有輸入 schema 的網址,預設會用 https:// 方式連線,以往這點需要透過 HTTPS Everywhere 這種套件,然後開啟「Encrypt All Sites Eligible」這樣的參數,像是這樣:

這樣會再推一把...

Google 釋出網頁版的 Spectre 攻擊 PoC,包括 Apple M1 在內

在大約三年前 (2018 年年初) 的時候,在讀完 Spectre 之後寫下了一些記錄:「讀書時間:Spectre 的攻擊方式」,結果在 Bruce Schneier 這邊看到消息,Google 前幾天把把 PoC 放出來了:「Exploiting Spectre Over the Internet」,在 Hacker News 上也有討論:「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。

首先是這個攻擊方法在目前的瀏覽器都還有用,而且包括 Apple M1 上都可以跑:

The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.

即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度,也還是可以達到 60 bytes/sec 的速度:

While experimenting, we also developed other PoCs with different properties. Some examples include:

  • A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
  • A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.

比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨,目前在瀏覽器上只能靠各種 isolation 降低風險,像是將不同站台跑在不同的 process 裡面:

In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.

Apple M1 也中這件事情讓人比較意外一點,看起來是當初開發的時候沒評估?目前傳言的 M1x 與 M2 不知道會怎樣...

Firefox 在 Strict Tracking Protection 模式下閹割 Google Analytics

Twitter 上看到 Firefox 在 Strict Tracking Protection 模式下會閹割掉 Google Analytics

剛好可以跟另外一篇「Google Analytics: Stop feeding the beast」一起看,這篇主要是對網站管理端的說明,你可以使用其他對隱私保護比較好的服務,或是考慮自己架設。

回到使用者端的部份,在 Firefox 裡面 Browser Privacy 預設是 Standard,換成 Strict 後就會觸發這個行為:

不是直接擋掉到 google-analytics.comgoogletagmanager.com 的連線,而是把 javascript 抽換掉,讓呼叫的程式碼完全不會做事。

在 Strict 模式下,除了會閹割 Google Analytics 外,也有其他的 js 會被閹割 (像是 Facebook 的),可以在 GitHub 上的「gecko-dev/browser/extensions/webcompat/shims/」這邊翻到。

這個功能很明顯在 Google Chrome 上不會內建,但很久前就有套件可以用了。目前比較常見的作法是透過 uBlock Origin 做,而且是在內建的「uBlock filters – Privacy」這組定義裡面就有實做,對應到 GitHub 上的 privacy.txt 這邊可以看到:

! Redirect to neutered Google Analytics 
||google-analytics.com/analytics.js$script,redirect=google-analytics.com/analytics.js

! Redirect to neutered Google Analytics Experiments
||google-analytics.com/cx/api.js$script,redirect=google-analytics.com/cx/api.js

不過 Firefox 上的 uBlock Origin 與其他套件也有類似的功能,真的在意的人應該早就使用了...

今天釋出的 Firefox 86 推出了 Total Cookie Protection

Firefox 86 (新推出的 standard 版本) 推出了 Total Cookie Protection:「Firefox 86 Introduces Total Cookie Protection」。

每個站的 cookie 都有獨立的空間:

Our new feature, Total Cookie Protection, works by maintaining a separate “cookie jar” for each website you visit. Any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to that website, such that it is not allowed to be shared with any other website.

然後對於需要跨站類的應用另外處理,像是 3rd-party login:

In addition, Total Cookie Protection makes a limited exception for cross-site cookies when they are needed for non-tracking purposes, such as those used by popular third-party login providers. Only when Total Cookie Protection detects that you intend to use a provider, will it give that provider permission to use a cross-site cookie specifically for the site you’re currently visiting. Such momentary exceptions allow for strong privacy protection without affecting your browsing experience.

這樣的確把 cookie 的追蹤能力壓低很多,不過應該也會有不少站台掛掉...

Waterfox 可以裝 chrome web store 的 extension 了

這幾天玩 Clubhouse 玩太兇了,來清一下累積在 tab 上的東西...

在「Waterfox G3.1.0 introduces support for installing Chrome and Opera extensions」這邊看到的東西,以 Firefox 為基底的 Waterfox 可以裝 chrome web store 裡的 extension 了。也就是說,現在除了可以裝 Firefox 自家的 Add-Ons 外,現在也可以裝 chrome web store 的套件了,但注意的是,畢竟底層用的 engine 不同 (以及支援的 API 也不同),不保證 100% 會動。

把自己之前寫過的套件裝起來,在套件頁大概長這樣,不確定自動更新的機制會怎麼跑就是了:

另外一個小問題是,裝完後在 chrome web store 的網站上也不會顯示已經安裝了,這個設計應該是為了隱私,不讓網站有機會偵測到:

加減來測試看看...

AWS 推出 CloudShell

AWS 推出了 CloudShell,讓使用者可以繼承 IAM 的權限,在瀏覽器裡面用 command line 操作 AWS 資源:「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單,在 web console 上方的 icon 點下去就可以用了,只是第一次使用的時候會看到需要建立環境的訊息,會等比較久:

連進去後測了一下,看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來,/dev/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器,以這個資訊來查,看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通,但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些,之後應該會陸陸續續再開放:

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份,官方是說不需要另外的費用,只需要付出用到的 AWS 資源,但這邊沒給範例啊,到底是怎麼算的... 看了一圈 EC2ECSEKS 都沒有機器,應該是不會算到這邊?

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是,對於已經習慣跳板機的人來說好像還好,尤其是 command line 已經用熟了,太習慣用 Ctrl-W 刪字串,而在瀏覽器裡面按下去就會直接出事的情況,還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限,所以在 awscli 下的權限是一樣的,另外對於有些 web console 沒支援的操作可以用這個方法補強,而不需要自己弄機器出來跑。

Cloudflare 拔掉使用 Cookie 分析的功能

這兩則應該可以一起看,雖然相差了兩個多月。

首先是今年九月底的時候提供隱私優先的分析系統:「Free, Privacy-First Analytics for a Better Web」,接下來是最近 (十二月) 宣佈要把 __cfduid 這組 cookie 拔掉:「Deprecating the __cfduid cookie」。

文章裡面沒有提到現在是怎麼偵測的,但我猜是瀏覽器的 fingerprint 資料已經足夠辨識了,不需要用到 cookie,這點可以參考 EFF 的「Cover Your Tracks」。

所以 privacy-first 這件事情也只是程度上而已,為了要防禦 bot,還是得正確辨識出不同的使用者,也就是說,現在不用 cookie 不代表 privacy 就高很多。不過這的確是試著在技術上努力降低疑慮就是了...

真的想要在 internet 上隱藏身份的人還是用 Tor 吧,基本上最少應該拿 Tor Browser,更小心一點應該用 Tails 這類軟體。

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?

Cloudflare 也要支援 AVIF

Cloudflare 針對 Image Resizing 增加了 AVIF 的支援:「Introducing support for the AVIF image format」。

We've added support for the new AVIF image format in Image Resizing.

照 comment 的地方看起來是 Business 功能,之後有機會下放到 Pro,但免費版應該不會出現:

Kornel Ian K Homan • 15 hours ago
This is part of the Image Resizing feature, which is currently available for Business plans. It's coming to Polish in the near future, which is a Pro plan feature.

這跟「Chrome 85 支援 AVIF」應該有些關係,加上其他瀏覽器也陸陸續續打算要支援,是個先做不虧的感覺...

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 演化來的演算法,對於演算法判斷不重要的部位會掉比較多細節...