Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com