Comment by johncolanduoni
6 days ago
In principle, it means you could run multiple sites from the same IP and someone intercepting traffic to that IP (but not the client’s DNS path) couldn’t tell what site each connection was to. It mostly makes sense for CDNs, where the same IP will be used for many sites.
If you don’t use a CDN at all, the destination IP leaks what site you’re trying to connect to (if the domain is well known). If you use a CDN without ECH, you send an unencrypted domain name in the HTTPS negotiation so it’s visible there. ECH+CDN is an attempt to have the best of both worlds: your traffic to the site will not advertise what site you’re connecting to, but the IP can still be shared between a variety of sites.
It’ll be interesting to see how countries with lighter censorship schemes adapt - China etc. of course will just block the connection.
Even for China so-called "overblocking" where to censor a small thing you have to block a much larger thing, is a real concern with these technologies. There's a real trade here, you have to expend effort and destroy potential and in some cases the reward isn't worth it. You can interpret ECH as an effort to move the ratio, maybe China was willing to spend $5000 and annoy a thousand people to block a cartoon site criticising their internal policies, but is it willing to sped $50 000 and annoy a ten thousand people? How about half a million and 100K people ?
That requires the client to only emit ECH, even if the ISP-provided (and therefore government controlled) DNS blocks HTTPS/SVCB records. China can easily make the default for a browser in China be to never even try to use ECH as well. Then they'll only annoy people trying to actively circumvent their system. They already do TCP sessionization to extract the SNI domain. Detecting ECH and then just dropping the connection at L3 is functionally equivalent.
In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.
> That requires the client to only emit ECH
So for example, Firefox since version 119. Or Chrome since 117
Now, for most services ECH doesn't have an encrypted target server. But the important choice in ECH was in this case it just fills that space with noise. An encrypted message also looks like noise. So you can block all the noise, in case it's secrets, or you can let through all the noise (some of which might be secrets) or I suppose you can choose randomly, but you can't do what such regimes want, which is to only forbid secrets, that's not a thing.
We've been here before. When sites starting going to TLS 1.3 lots of HN people said oh, China will just block that, easy. But the choice wasn't "Use TLS 1.3 or keep doing whatever China is happy with instead" the choice was "Use TLS 1.3 or don't connect" and turns out for a lot of the Web China wasn't OK with "don't connect" as their choice, so TLS 1.3 is deployed anyway.
4 replies →
> In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.
I doubt the Chinese government would care about that. They don't depend on the west for their online services any more than we depend on them. All that would happen is that the internet would bifurcate to an even greater degree than it already has.
It's extremely helpful at home in the west as a countermeasure against data monetization and dragnet surveillance. It certainly isn't perfect but at least it reduces the ability of ISPs to collect data on end users as well as forcing the government to formally move against the cloud providers if they want the data. Not that I want the cloud providers having my data to begin with but that's a different rant.