3 ms·
Wrong. 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 vendor
by kuschku 9y ago
Wrong.
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.