I'm not seeing it. It looks contradictory what they're saying.
> This means that whenever a user visits a website on Cloudflare that has ECH enabled, no one except for the user and the website will be able to determine which website was visited.
But if you look at the inner/outer SNI part:
> The outer SNI is a common name that, in our case, represents that a user is trying to visit an encrypted website on Cloudflare. We chose cloudflare-ech.com as the SNI that all websites will share on Cloudflare. Because Cloudflare controls that domain we have the appropriate certificates to be able to negotiate a TLS handshake for that server name.
> The inner SNI contains the actual server name that the user is trying to visit. This is encrypted using a public key and can only be read by Cloudflare. Once the handshake completes the web page is loaded as normal, just like any other website loaded over TLS.
So Cloudflare sees it? That's definitely not the same as what they're describing, it's more of a wink-wink Applesque "trust me bro" style of "privacy" - a consolidation of traffic under the pretext of something else.
I also looked at the draft document they linked, and that seems to match up with what I'm understanding.
> If ECHClientHello.type is outer, then the server acts as a client- facing server and proceeds as described in Section 7.1 to extract a ClientHelloInner, if available.
If I understand this right, it is basically "cloudfare will appear like a huge web server for anybody watching".
This looks like one more attempt by cloudfare to recentralize the web. And it doesn’t address the issue that cloudfare still perfectly know which website you are visiting.
Did I miss something?
This is going to make it even more of a pain to do egress filtering on networks/systems we administer. I want to be able to allow list sites with dynamic IPs. The existing solutions for doing this by examining SNI are already often bypassable by forging the SNI (looking at you, AWS Network Firewall).
> The outer SNI is a common name that, in our case, represents that a user is trying to visit an encrypted website on Cloudflare. We chose cloudflare-ech.com as the SNI that all websites will share on Cloudflare. Because Cloudflare controls that domain we have the appropriate certificates to be able to negotiate a TLS handshake for that server name.
All this really means is operators that inspect SNI will now just block cloudflare-ech.com.
It’s a tug-o-war between cloud flare and the ISPs and network admins, essentially.
It seems like the same result could easily be achieved by widespread Domain Fronting support (e.g set sni to cloudflare-sekrit.com and Host: header to the actual domain). Can someone explain why this wasn't adopted more widely (I know CF, for example, disabled theirs)?
Everytime someone mentions Cloudflare, i think about this article [0].
If I host my website on a VPS, is ECH possible? Seems like it's only useful when IP addresses are shared across a bunch of sites.
Naive question, In 2023 how does DNS-over-HTTP (DoH) affect things like the Cisco Distributed Director / F5 3-DNS where DNS is used to control which datacenters customer traffic is going to? Is this still a technology smaller sites can use?
To my knowledge the only browser testing site for ECH - https://defo.ie/ech-check.php
ECH is still not working with Cloudflare in all regions. If someone from Cloudflare see this, please let us know the status of ECH rollout in all regions.
This just sounds like a less private Tor.
It is surprising that if you are on the free plan then
“Enabled by default for Free zones.”
I feel like this is only possible because Cloudflare is already so huge. If this becomes widely adopted, anyone who wants to offer "private" access to their site will have to move through Cloudflare. This can't be good.
[dead]
[dead]
[flagged]
I see a lot of confusion here, probably Cloudflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1].
The difference between ECH and SNI is that while SNI includes the hostname in the ClientHello (the first TLS record indicating connection initiation), ECH includes an encrypted section in the ClientHello called ClientHelloInner, and the hostname is moved inside it.
The ClientHelloInner is encrypted using a public key made available over DNS, which is queried over DNS over HTTPS providers such as Google or Cloudflare DNS; plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key.
Doing so prevents ISPs and governments from analyzing your traffic. However, a CDN operator such as Cloudflare terminates TLS for your website, and thus traffic would be visible to them either way.
Now, to the non-technical part of it: while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws.
If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China.
[1] https://blog.cloudflare.com/encrypted-client-hello/
[2] https://www.article19.org/resources/france-proposed-internet...
[3] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...