CloudFlare forcely enabled ECH for all websites hosted by users with Free Plan

[stevejohnson7]

CloudFlare forcely enabled ECH for all websites hosted by users with Free Plan. You can find this setting at Websites->SSL/TLS->Edge Certificates->Encrypted ClientHello. Does this cause problems? Given the history of ESNI being blocked in its entirety, it's a concern that ECH will eventually be blocked as well and result in all CloudFlare Free Plan users' websites being blocked.

[gaukas]

result in all CloudFlare Free Plan users' websites being blocked.

Encrypted SNI (ESNI) TLS Extension was blocked in some countries due to Deep Packet Inspection (DPI) against TLS ClientHello messages. However it is up to the client to choose whether or not to include the extension in its ClientHello message (and by default the most of web browsers simply choose not to).

And further, CloudFlare claimed to be supporting ESNI, and apparently no one's website has been blocked simply because of that. That said, I wouldn't be too worry about that.

it's a concern that ECH will eventually be blocked

This could be true if ECH does not get adopted rapidly and widely enough by a larger number of audiences (including both web browsers and HTTPS websites), or if it does not become a mandatory feature (if popular web browsers simply fall back to plain CH if connection cannot be established with ECH enabled). And that's basically what happened to ESNI.

Given that GFW of China have (allegedly) been trying to interfere with legitimate DNS-over-HTTPS by RST-injecting TLS connections to 1.1.1.1 in the past few weeks (#285), I believe we could not entirely rule out the possibility of them blocking ESNI again by blocking its successor ECH in either the same way (DPI+drop ClientHello) or a more innovative way (failing the prerequisite of ECH by disabling DoH).

[mmmray]

see previously: #280

to add to what gaukas said, all significant ECH rollout today comes with a ECH-free fallback (e.g. Firefox) -- we are very far from making ECH mandatory, even in uncensored networks.

what is more interesting is rollout on the client-side, such as: https://chromestatus.com/feature/6196703843581952 and https://bugs.chromium.org/p/chromium/issues/detail?id=1091403

it seems there is significant recent movement in the chrome ticket.

[UjuiUjuMandan]

They use cloudflare-ech.com universally as servername in SNI in OuterClientHello. Cloudflare: You think ECH is not identified fast enough?

[gaukas]

You think ECH is not identified fast enough?

I had an impression that ECH is not created nor designed for censorship evasion and therefore is (unfortunately) not being rolled out in a censorship resistant way...

[RPRX]

根据 https://t.me/DNSPODT/1903 及它的讨论区，2023.10.1 开始 https://1.1.1.1 被中国多个运营商屏蔽（除了部分地区的电信）。

“2023.10.1 开始”的说法隐晦地来自 https://t.me/vps_xhq/463 ，其实不一定是 2023.10.1 才开始的。

According to https://t.me/DNSPODT/1903 and its discussion forums, starting 2023.10.1 https://1.1.1.1 is blocked by multiple carriers in China (except for telecoms in some areas).

The phrase "starting on 2023.10.1" comes implicitly from https://t.me/vps_xhq/463, but it doesn't necessarily start on 2023.10.1.

[RPRX]

https://community.cloudflare.com/t/early-hints-and-encrypted-client-hello-ech-are-currently-disabled-globally/567730

Dear community,

This note is to inform you of the status of Early Hints and Encrypted Client Hello.

We have sadly had to disable both of these features globally whilst we address a number of issues with them. These issues are unrelated. We are in the process of adding a label to each of the toggles in dashboard to alert that they are disabled.

We expect to re-enable Early Hints in the coming weeks, with ECH re-enablement for Free coming later in the year with roll-out to those in the beta in early 2024.

We apologise for the inconvenience caused here and are doing our best to get these features back online ASAP.

• Sam