幹壞事是進步最大的原動力
從「Two UK Broadband ISPs Trial New Internet Snooping System」這邊看到英國的 ISP 開始記錄使用者的連線資訊，簡化後的 log 樣子像是這樣：
Two unnamed broadband or mobile ISPs are reportedly helping the UK Home Office and the National Crime Agency (NCA) to trial a new internet snooping system on their customers, which is being conducted as part of the controversial 2016 UK Investigatory Powers Act (aka – snoopers charter).
加上「T-Mobile US 打算要賣使用者的瀏覽記錄了」這篇，繼續推廣 DNS over HTTP、DNS over TLS，以及 ECH (Encrypted Client Hello)。
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 本來在推的 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 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣，這樣就能順便解掉 censorship 的問題...
其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI：
In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.
In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.
不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis)，目前看起來只處理了 ClientHello 本身，現在還是有機會分析 handshake 過程來擋，必須繼續改善 ECH 的協定，讓整個流程看起來都跟一般的 TLS 一樣...
可以等著看，到時候在中國的效果如何了，會不會讓國外的各大服務直接打進去呢...
Cloudflare 改善了 Workers 的 cold start 時間：「Eliminating cold starts with Cloudflare Workers」。
傳統的作法是連線結束後 application 層收到時去拉 worker 起來跑：
他們想到的方法是在收到 TLS 的 ClientHello 封包時就可以拉起來等了：
這點利用了 TLS 啟動時的交換時間，把 cold start 的時間疊起來，不過缺點應該就是同一個 domain 下的所有的 worker 都得拉起來，不過因為只有 cold start 的部份，應該是還好...
Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft，但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響，所以就找了方法讓兩者並存：「Know your SCM_RIGHTS」。
這個方法就是 SCM_RIGHTS，可以讓另外一個 process 存取自己的 file description。
You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.
所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料，如果裡面有看到想要使用 TLS 1.3 的訊息，就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑：
We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.
這樣本來的 stack 就只要修改一小段程式碼，將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑，就比較不用擔心本來的 stack 會有狀況了。