Hacker News Reader

Comment by icebraining | Hacker News Reader

Arguably it's no longer domain fronting, it's just connecting to a server that serves both sites without saying which one you want. So it's better, because it doesn't break any rules. That requires AWS et all to support SNI encryption, though.

What I wonder is about downgrade attacks. Browsers will probably have to support clear-text SNI for a long time - could censors abuse this by making it seem that no server supports encrypted SNI? Or is there a digitally-signed way for servers to prove that they support it, before the browser sends the host?

View on HN

The intent is that you'd be using a secured DNS channel such as DoH or DoT to obtain your DNS results - so an adversary can't rewrite the DNS records.

This proposal supposes that when we've decided to talk to example.com we may as well ask a DNS query that requests not only 'A' and 'AAAA' records (IPv4 and IPv6 address) but also an encrypted SNI key. If such a key is available we can use it to prove to the server (which set that key) which name we wanted, while eavesdroppers are none the wiser.

If the adversary can eavesdrop DNS they can already speculate from our query which host we wanted to talk to, but securing DNS is a problem for which there are known solutions.

So censors can stop this by preventing the use of (non-controlled) DoH and DoT servers?

No, the owner can sign the dns records and also sign the absence of a record, and if the censor tries to tell the browser that there is no SNI key, without being able to produce the signature to prove that, the browser can just treat this as an MITM attack. This only work on signed DNS entries though.

But they just want to block it, so if the browser and/or app treats it as a MITM attack, that's fine from the censor's POV.

There is a difference between inciting end point devices to drop down to less secure protocols, and alerting the user that you are running an active attack.

This solution is already solved through things like HSTS preloads.

Apps and other machine to machine can require encrypted SNI pretty easily. Pinning of various other kinds (not just in the binary, but via headers or a list in a browser) solves it too.

Apps and other machine to machine can require encrypted SNI pretty easily.

Yes, but then the censor can distinguish these apps from a regular client, and block them. This only works if browsers do it too, so that the app can't be distinguished.

I remember in TLS 1.3, a middle box can not modify a single byte in the negotiation, or otherwise, the connection fails (a checksum validation on server and client side). TLS 1.2 somehow has this but the coverage is less (it only happens for chipers etc).

Reply on news.ycombinator.com