#clienthello

Firefox 也打算淘汰 ESNI，改推 ECH

Firefox 也打算放棄 ESNI，改推 ECH 了：「Encrypted Client Hello: the future of ESNI in Firefox」。 目前的 85 版 (目前的 beta) 支援了 ECH draft-08，想要玩看看的人就可以測試了： Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming. 另外一個要看的當然就是 Google 家的 Chromium 了，不過這個協定對 Google 的誘因應該是超大，有機會直接穿入中國市場… 只是不知道會不會自己搞一套 protocol。

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

Cloudflare 本來在推的 ESNI 現在變成 ECH 了：「Good-bye ESNI, hello ECH!」。 上面這張圖是 ESNI，下面這張是 ECH： 可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了，伺服器會先試著解內層的 ClientHelloInner，失敗的時候會用外層的 ClientHelloOuter： The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter. 看得出來 ECH…

中國開始先擋 ESNI 了…

這兩天陸陸續續都有一些新聞出來了，中國已經開始擋 ESNI 了：「China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI」。

ESNI (Encrypted SNI) 的重點就是在於把 TLS 裡 ClientHello 的 hostname 部分加密 (通常會需要配合 DNS-over-HTTPS 或是 DNS-over-TLS 的方式取得 key 相關的資料)，這個 hostname 的部分是目前 TLS 連線裡少數可以被看到的明文，也因此對於 GFW 過濾資料很有用，而 ESNI 等於是把這個洞補上，這次直接擋掉應該是預料中的事情…

但就算不管中國的部分，ESNI 對於 priavcy 的幫助還是很大，基本上 ISP 只剩下 IP 資訊可以分析，如果是有 CDN…

Cloudflare 降低 Workers 的 Cold Start 方法…

Cloudflare 改善了 Workers 的 cold start 時間：「Eliminating cold starts with Cloudflare Workers」。

傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑：

他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了：

這點利用了 TLS 啟動時的交換時間，把 cold start 的時間疊起來，不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來，不過因為只有 cold start 的部份，應該是還好…