Hacker News Reader

Comment by josephcsible | Hacker News Reader

> ACT is using SNI-sniffing to block raw.githubusercontent, unlike most other blocks, which are DNS based.

This is why TLS ECH can't come soon enough, and why there should be no fallback if the browser and server both support it.

View on HN

Here in China the GFW block any traffic with encrypted SNI.

Hence the "no fallback" point. Bad guys can always block entire IPs, and by not having a fallback to insecure SNI, that's their only choice.

As someone who doesn't want untrusted devices on my network, I'd want to be able to encrypt SNI at my firewall.

How do you propose things be set up such that it's possible for you to enforce that at your firewall without censorious governments being able to at theirs?

What do untrusted devices have to do with this? You should be able to block them at lower layers already, and if not, I don't see how decrypting the FQDN of a request would help. Am I missing something?

Doesn't that mean that places like AWS will be fighting ECH, then? Right now, evil governments can block sites based on their domain; so if irrelevant-aws-customer.com does something controversial, super-important-customer-also-on-aws.com can still receive traffic. If evil governments lose this ability and irrelevant-aws-customer.com needs to be blocked, then they just block all of AWS, forcing super-important-customer-also-on-aws.com to move to Azure or GCP. As a result, I imagine that big cloud providers to whine loudly about this, unless they have some other plan. (I also think we should ignore their whining, but the #1 browser is made by the #3 cloud provider, so I have my doubts. What hurts AWS hurts GCP, probably.)

> to move to Azure or GCP

Who will also be blocked following the same logic.

Not if Azure or GCP never allow ESNI (in this imagined scenario).

I suppose this plan does indeed put a lot of faith in Big Tech uniformly deciding to do what's right.

Reply on news.ycombinator.com