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)?
That relies on the user knowing that they can trust the certificate they use as the front in lieu of the certificate for the domain they actually want. Which is sub-optimal from a security point of view -- unless you complete a handshake with a valid certificate for the domain you're actually visiting, how do you know that the server you're talking to actually has a valid certificate?
In ECH, we still only complete one handshake per session. If you've got the right key for the inner client hello, you'll complete a handshake with the certificate for the domain you're trying to visit. If not, you'll complete a handshake with a certificate for the domain in the outer hello and the server will send you the correct key so you can try again with a new session. The client gets to validate the right certificate.
This explanation makes sense, thanks! I mean other than the fact you’re still trusting cloudflare not to mess with the data since it’s terminating ssl =) but i agree that makes this somewhat cleaner from client perspective
As a visitor to the site, I need to decide whether or not to trust the site's operator. As the operator of a site, I need to work out which vendors I can trust. Cloudflare takes the role of a vendor here, it's exceptionally common for vendors to terminate SSL. And it's quite challenging to run a CDN without access to the plain-text request.
Cloudflare at least offers mutual TLS from the edge to your origin, I've yet to persuade either of the other major CDN vendors I've worked with that they should offer that feature. They've also pioneered the rather nifty ability to terminate TLS on a node that doesn't actually have direct access to the certificate it's using, which I'd quite like for some other use-cases.
None of which is to say that you shouldn't have any concerns about Cloudflare, but on the other hand if you're that worried then at least the server operators using Cloudflare are giving you a heads-up that you maybe don't want to trust their judgement?
For whatever reason, Domain Fronting is considered more of an attack behavior, used by red teamers and penetration testers. Doubling down on that behavior likely didn't seem as appealing from a PR perspective.
i find the OP rather amusing--one of the earlier incidents during my time at Cloudflare (circa 2015) was dealing with prolific domain fronting, where IIRC some third-party proxy tool had set something up to the effect of "send SNI query for unblocked site on CF network, send HTTP Host for blocked site" automatically. this was ultimately blocked less because it was strictly undesirable and more because it resulted in some sort of cache poisoning problem. the unintended use started serving those proxy hack results to regular, non-domain fronting requests for whatever reason, which is obviously bad--you want the CDN to serve normal requests correctly, so you squash abnormal requests that work on their own, but cause cascading problems for other not abnormal requests.
many years down the road this is now an actual (with the problem cases handled) feature!
I believe CF and others buckled under pressure from major websites which didn't want to be used as fronts for other website's traffic. ECH fixes this because individual sites get to opt-in to using it.
... and this is exactly what will happen to cloudflare-ech.com.
I'm really disappointed with how the ECH spec panned out. It's almost like "make sure middleboxes and GFW can block this" was a hard requirement. They should've made the handshake look like a session resumption (i.e. pre-shared key), since those aren't required to send a server name.
