Cloudflare, Mozilla, Fastly, and Apple Working on Encrypted SNI

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by enitihas on Monday July 16, 2018 @03:45AM (#17539463)

Just curious, would it enable Signal and other tools trying to avoid censorship by doing domain fronting without the cloud provider (e.g AWS Cloudfront) noticing.

e.g. https://news.ycombinator.com/item?id=16970199

https://news.ycombinator.com/item?id=16868564

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by icebraining on Monday July 16, 2018 @03:53AM (#17539495)

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?

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by tialaramex on Monday July 16, 2018 @04:39AM (#17539667)

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.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by icebraining on Monday July 16, 2018 @05:16AM (#17539801)

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

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by namibj on Monday July 16, 2018 @05:38AM (#17539895)

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.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by icebraining on Monday July 16, 2018 @05:47AM (#17539933)

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.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by namibj on Monday July 16, 2018 @01:31PM (#17543094)

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.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by dannyw on Monday July 16, 2018 @04:07AM (#17539556)

This solution is already solved through things like HSTS preloads.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by rdl on Monday July 16, 2018 @04:18AM (#17539590)

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.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by icebraining on Monday July 16, 2018 @04:22AM (#17539602)

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.

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by buraktamturk on Monday July 16, 2018 @10:54AM (#17541738)

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).

[ Parent | on HN ]

Re:Cloudflare, Mozilla, Fastly, and Apple Working on Encrypt... by rjvbk on Monday July 16, 2018 @04:07AM (#17539558)

The cloud provider will notice when they get blocked in a country.

[ Parent | on HN ]