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 (」。

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

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


Cloudflare 的「Speeding up HTTPS and HTTP/3 negotiation with... DNS」這篇裡面提到了一個新的標準 (目前是 draft):「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」。

從文件上可以看到這個標準是由 GoogleAkamai 的人提出來的,想要透過 DNS 的方式告訴瀏覽器這個網站可以直接用 HTTPS 連線 (以及其他資訊)。

這樣有兩個好處,第一個是安全性上的好處,HSTS 只保證了第二次以及之後的連線會強制用 HTTPS,但不能保證第一次連線時是 HTTPS。透過 DNS 查到後可以第一次就用 HTTPS 連線。

第二個是效能上的好處,降低了一個 3xx redirect 的時間,雖然 DNS 多了一些查詢,但 DNS 查詢這邊通常會比 TCP connection 建立連線來說快不少,再加上 HTTP protocol 需要先等瀏覽器端送出 HTTP header 後才有回應,這樣應該是快蠻多的。

文章裡有提到 iOS 14 好像有開始在嘗試,但我好像沒看到其他資料:

We began investigating and found these to be a part of Apple’s iOS14 beta release where they were testing out a new SVCB/HTTPS record type.


OpenSSH 8.4 預設停用 ssh-rsa

前幾天 OpenSSH 8.4 釋出了:「Announce: OpenSSH 8.4 released」。

比較重要的改變是 ssh-rsa 預設變成停用,因為是使用 SHA-1 演算法的關係:

It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.


  • The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These algorithms have the advantage of using the same key type as "ssh-rsa" but use the safe SHA-2 hash algorithms. These have been supported since OpenSSH 7.2 and are already used by default if the client and server support them.
  • The ssh-ed25519 signature algorithm. It has been supported in OpenSSH since release 6.5.
  • The RFC5656 ECDSA algorithms: ecdsa-sha2-nistp256/384/521. These have been supported by OpenSSH since release 5.7.

掃了一下 ~/.ssh/known_hosts,看起來目前大多都是 ssh-ed25519 了,還有少數還是 ssh-rsa

翻了一下 Ubuntu 這邊的版本,16.04 是 7.2p2,看起來目前有支援的版本都可以用這三個。

官方有提到可以在 command 上強制關閉 ssh-rsa 測試的方法:

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

現在看起來比較麻煩的是 Dropbear 的部份,我自己之前是有包 PPA 來用 (2019.78),但看起來還是不夠新支援 ssh-ed25519 (要今年六月的 2020.79 才支援),所以也許要找時間來把 PPA 更新到 2020.80...

另外一種方法是走 ecdsa-sha2-nistp{256,384,521} 這些演算法,不過從名字就可以知道裡面演算法的由來,卡個 NIST 在那邊看起來就不太舒服,但還是寫一下方法好了:

先用 dropbearkey 產生對應的 ecdsa host key:

sudo dropbearkey -t ecdsa -f /etc/dropbear/dropbear_ecdsa_host_key -s 256

再來在 /etc/default/dropbear 裡面把 DROPBEAR_EXTRA_ARGS 加上對應的 ecdsa host key 資訊,這邊直接用 -r 是因為他可以重複指定,不會影響到其他的 host key 設定:

# any additional arguments for Dropbear
DROPBEAR_EXTRA_ARGS="-r /etc/dropbear/dropbear_ecdsa_host_key"

然後重跑 dropbear 就可以了。

另外有興趣的人可以用 ssh -Q key 看 openssh client 支援的演算法。

Let's Encrypt 生了新的 Root 與 Intermediate Certificate

Let's Encrypt 弄了新的 Root Certificate 與 Intermediate Certificate:「Let's Encrypt's New Root and Intermediate Certificates」。

一方面是本來的 Intermediate Certificate 也快要要過期了,另外一方面是要利用 ECDSA 降低傳輸時的頻寬成本:

On Thursday, September 3rd, 2020, Let’s Encrypt issued six new certificates: one root, four intermediates, and one cross-sign. These new certificates are part of our larger plan to improve privacy on the web, by making ECDSA end-entity certificates widely available, and by making certificates smaller.

本來有 Let's Encrypt Authority {X1,X2,X3,X4} 四組 Intermediate Certificate,都是 RSA 2048 bits。

其中 X1 與 X2 差不多都到期了 (cross-signed 的已經過了,自家 ISRG Root X1 簽的剩不到一個月),不過這兩組已經沒在用了,這次就不管他了。

而 X3 與 X4 這兩組則是明年到期,會產生出新的 Intermediate Certificate,會叫做 R3 與 R4,跟之前一樣會被自家 ISRG Root X1 簽,以及 IdenTrust DST Root CA X3 簽:

For starters, we’ve issued two new 2048-bit RSA intermediates which we’re calling R3 and R4. These are both issued by ISRG Root X1, and have 5-year lifetimes. They will also be cross-signed by IdenTrust. They’re basically direct replacements for our current X3 and X4, which are expiring in a year. We expect to switch our primary issuance pipeline to use R3 later this year, which won’t have any real effect on issuance or renewal.

然後是本次的重頭戲,會弄出一個新的 Root Certificate,叫做 ISRG Root X2,以及兩個 Intermediate Certificate,叫做 E1 與 E2:

The other new certificates are more interesting. First up, we have the new ISRG Root X2, which has an ECDSA P-384 key instead of RSA, and is valid until 2040. Issued from that, we have two new intermediates, E1 and E2, which are both also ECDSA and are valid for 5 years.

主要的目的就是降低 TLS 連線時的 bandwidth,這次的設計預期可以降低將近 400 bytes:

While a 2048-bit RSA public key is about 256 bytes long, an ECDSA P-384 public key is only about 48 bytes. Similarly, the RSA signature will be another 256 bytes, while the ECDSA signature will only be 96 bytes. Factoring in some additional overhead, that’s a savings of nearly 400 bytes per certificate. Multiply that by how many certificates are in your chain, and how many connections you get in a day, and the bandwidth savings add up fast.

另外一個特別的修改是把名字改短 (把「Let's Encrypt Authority」拿掉),也是為了省傳輸的成本:

As an aside: since we’re concerned about certificate sizes, we’ve also taken a few other measures to save bytes in our new certificates. We’ve shortened their Subject Common Names from “Let’s Encrypt Authority X3” to just “R3”, relying on the previously-redundant Organization Name field to supply the words “Let’s Encrypt”. We’ve shortened their Authority Information Access Issuer and CRL Distribution Point URLs, and we’ve dropped their CPS and OCSP urls entirely. All of this adds up to another approximately 120 bytes of savings without making any substantive change to the useful information in the certificate.

這個部份讓我想到之前寫的「省頻寬的方法:終極版本...」這篇,裡面提到 AWS 自家的 SSL Certificate 太胖,改用 DigiCert 的反而可以省下不少錢 XDDD

另外也提到了這次 cross-sign 的部份是對 ECDSA Root Certificate 簽 (ISRG Root X2),而不是對 ECDSA Intermediate Certificate 簽 (E1 與 E2),主因是不希望多一次切換的轉移期:

In the end, we decided that providing the option of all-ECDSA chains was more important, and so opted to go with the first option, and cross-sign the ISRG Root X2 itself.

這算是蠻重要的進展,看起來各家 client 最近應該都會推出新版支援。

5 Eyes、9 Eyes 與 14 Eyes

{5,9,14} Eyes 是先前在其他地方看到的詞,後來在「Cutting Google out of your life」這邊在講 Google 的替代方案時又有提到,然後也有解釋:「Global Mass Surveillance - The Fourteen Eyes」。

這邊提到的 Eyes 起因是大多數國家對於監視自己公民都有法律限制,所以藉由與國外的情報單位「合作」,取得對自己國家公民的監視資訊 (即使各國之間有簽訂不監視其他國家公民),而這邊列出的 {5,9,14} Eyes 就是互相有簽訂合作的國家:

The UKUSA Agreement is an agreement between the United Kingdom, United States, Australia, Canada, and New Zealand to cooperatively collect, analyze, and share intelligence. Members of this group, known as the Five Eyes, focus on gathering and analyzing intelligence from different parts of the world. While Five Eyes countries have agreed to not spy on each other as adversaries, leaks by Snowden have revealed that some Five Eyes members monitor each other's citizens and share intelligence to avoid breaking domestic laws that prohibit them from spying on their own citizens. The Five Eyes alliance also cooperates with groups of third-party countries to share intelligence (forming the Nine Eyes and Fourteen Eyes); however, Five Eyes and third-party countries can and do spy on each other.

另外還有「Key Disclosure Law」這段,在講有哪些國家有法律可以強制個人交出金鑰。

回到本來提到的 degoogle 列表,裡面列出了很多替代的服務與軟體,其中服務的部份會列出所在地區是否在 {5,9,14} Eyes 的範圍內,以及發生過的爭議事件。

當作替代方案在看,至少可以把一些足跡從 Google 抽出來...

CloudFront 支援 TLS 1.3

看到 AWS 的公告,宣佈 CloudFront 支援 TLS 1.3:「Amazon CloudFront announces support for TLSv1.3 for viewer connections」。


TLSv1.3 is available today and enabled by default across all Amazon CloudFront security policies options. No additional changes are required to your CloudFront configuration to benefit from the security and performance improvements of TLSv1.3 for your viewer connections.

對使用者最大的差異應該還是改善 first byte 的時間 (主要是因為 handshake 時間縮短),這點 AWS 的人也有提到在內部測試時,美國區的改善情況:

In our own internal tests in the US region as an example, first byte latency for new negotiated connections saw reductions of up to 33% for TLSv1.3 compared to previous versions of TLS.

在 latency 更高的地區應該也會有大幅改善...

自己架設各種服務的 ansible playbook:Sovereign

來清個瀏覽器上的 tab,sovereign 是個 ansible playbook,幫你架設各種服務:

Sovereign is a set of Ansible playbooks that you can use to build and maintain your own personal cloud based entirely on open source software, so you’re in control.

裡面包了許多服務,但看下來比較麻煩的是郵件相關的服務,現在要自己搞一整包郵件系統一直都是痛點,這點在 Hacker News 上偶而就會看到分享...

這包 ansible playbook 裡面跟郵件相關的部份包括了 PostfixDovecot 搭出基本的 SMTP + IMAP + POP3,另外用 Solr (全文搜尋)、PostgreSQL (Virtual domain)、Rspamd (擋 spam),DKIMDMARC (郵件來源認證機制),以及 Roundcube (Webmail)。

非郵件相關的話包括了 VPN、cloud storage,以及一些管理、安全、備份有關的服務可以用,看起來的確是把常用的東西都放進去了。

不過這種東西自己架是有自己架的「樂趣」,而且對底層掌握度也比較高 (尤其是又有隱私與安全性的考量),對應的客群應該會看一看架構,然後自己動手?

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

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

文章作者 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.

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

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

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