> The technique is heavily used by bad actors

Evidence?

It's in the OSEP course. :)

OffSec Experienced Pentester (OSEP)

Appeal to authority. Yellow card

When I last looked, the intent was that eventually ECH endpoints offer the same effective service that you got with Domain Fronting, but without messing with the backend in a way which is disruptive for the cloud providers so they support it.

Encrypted Client Hello is the in-progress work to have even the client's initial contact to an HTTPS server be encrypted. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

Why would ECH be fine when Domain Fronting isn't? The problem with Domain Fronting is that we get surprised too late with the actual request. We get what appears to be a legitimate request for this-thing.example, so we do all the work to respond to a this-thing.example request and then... swerve, sorry I changed my mind, my request is actually about hidden-service.example.

With ECH we (but not an adversary snooping the connection) know immediately that the request is for hidden-service.example and so we don't waste our time setting up for the wrong work.

I think the primary problem with domain fronting that ECH would solve is that ECH doesn't involve using a third party's domain name, potentially dragging a single third party into the censorship muck. My read of the support email signal shared is that AWS was unhappy that a domain they owned would likely become entangled. While ECH will still increase everyone else's risk that is sharing the same load balancer as a censorship target, it is at least a fully distributed risk, rather than requiring the client pick a specific domain or set of domains to pull into their fight.

ECH is a good idea on paper but will never work in the real world.

Oppressive regimes just drop any connection lacking a plain text SNI. The browser will either retry without ECH, or the user will retry with a browser that does not support ECH.

I think people in the Western world don't exactly understand how internet censorship works. They don't give a shit about blocking large legitimate sites or breaking connectivity for large swaths of users if it helps them avoid losing power.

> ECH is a good idea on paper but will never work in the real world.

Uhuh.

> Oppressive regimes just drop any connection lacking a plain text SNI.

All of the connections will have a plain text SNI. Many of them will have ECH. In some of them, at least at first the ECH will just be GREASE, in others it's real. For the server it's apparent which is which, for a snoop it's impossible to know. Indeed that's sort of the point of GREASE.

> They don't give a shit about blocking large legitimate sites or breaking connectivity for large swaths of users if it helps them avoid losing power.

We heard basically the same thing for TLS 1.3. But of course we actually rolled out TLS 1.3 with no major problems, even the anti-downgrade provision which was the part I was most sceptical about delivering. Google's Chrome GREASEs a bunch of TLS 1.3 already.

I ran a Snowflake server at home for a while. I shut it off because it used too much CPU for my liking, but I haven't seen any kind of negative impact whatsoever.

Domain fronting is not exactly a holy grail. Signal and Tor ran into issues when cloud providers blocked domain fronting (or rather, stopped supporting a feature that never was meant to work anyway) but I don't think that was intended to interrupt anything. "Load balancers are written to make sure they serve the correct certificates for their configured domains" isn't exactly a problematic feature on its own.

Domain fronting is trivial, all you need is a call to openssl and an nginx server. It's also trivial to bust, all you need to do is actually validate the certificate. These certificates are either self signed or are part of a random CA chain that no real system would ever trust.

It's not "a spy having their secret meetings inside an unsuspecting friend's house". It's someone putting a sign saying "white house, home of the American president, do not enter" in front of a random warehouse in Brazil.

Software that falls for domain fronting either doesn't care about the certificates and their validity, or is buggy and should get patched. Some of that software will probably be security software, but if bad actors manage to trick your security software into trusting a few readable strings, domain fronting is probably the least of your worries. I can't imagine what kind of shitty security software would possibly fall for that.

Thanks for contributing to anti-cesnsorship, I respect anyone who puts that effort it.

> when they tried to roll it out on a wide basis for fear that countries like Iran and China would just block all of AWS

That is the whole point: make it so they have to block vast swatches of the useful internet in order to defeat it. Ideally, we should be able to make it so they have to block the entire internet to censor anything.

There must be some kind of limit to the amount of tyranny they're able to muster, right? Eventually the collateral damage will be too great and they'll give up on trying to censor anything. Alternatively, they will become such tyrannical societies that people won't accept it.