7 ms·
"... thanks to SNI, this doesn't give us any privacy." Assumption: All sites use SNI or will use SNI. True? Experiment: List all domains posted to HN (pages
by aplorbust 9y ago
"... thanks to SNI, this doesn't give us any privacy."
Assumption: All sites use SNI or will use SNI.
True?
Experiment: List all domains posted to HN (pages 1-20) that require https on any given day. Try accessing each one without SNI.
Result: Most do not require SNI.
- kuschku 9y agoWrong. SNI has to be sent without any previous negotiation. Therefore the client does not know if a site will require SNI or not. Assumption 1: browser vendors do not want to break sites relying on SNI (Confirmed by WHATWG) Assumption 2: at least one major site will continue to use SNI Conclusion: browsers will continue to send SNI.
- aplorbust 9y ago"Therefore the client does not know if a site will require SNI or not." The client that I use assumes no SNI required. (It intentionally does not support SNI.) If it fails because the website is on a shared host and requires SNI, then it retries via a local SNI-enabled proxy bound to localhost. "Conclusion: browsers will continue to send SNI." Some clients/browsers will continue to send the domainname in the clear for every https url, even when it is not required. Some users might consider that as sacraficing their privacy even when it is not necessary. But not the client I use. It assumes no SNI is required, by default. It never sends the domainname in the clear for https when it is not necessary.
- kuschku 9y agoThat is awesome (and I personally also always err on the side of safety/privacy there), but I don't think this will help much. Anyone that can set your setup up can also just openvpn to a remote server, and redirect all DNS queries over that connection (which is quite easily doable, actually). Everyone that can't do this would still use SNI, so DNS-over-HTTPS wouldn't provide any security win for them.