4 ms·
> Feels like placebo security to me. If the protocol is http, any attacker can still see the domain name through the host header. Plus it does nothing to stop t
by hannob 9y ago
> Feels like placebo security to me. If the protocol is http, any attacker can still see the domain name through the host header. Plus it does nothing to stop them from intercepting/modifying the request/response. If the protocol is ssl/tls the domain name is in the sni.
This is an interesting argument that people have been having over and over.
Whenever someone proposes to encrypt DNS someone will come up with "but SNI still leaks the host name". Whenever someone proposes to encrypt SNI then surely someone will point out "DNS still leaks the host name".
Yeah, you need to encrypt both. But that fact is no argument for not encrypting at all.
- vetinari 9y agoSNI works because it is not encrypted, that's the point why it was introduced in the first place. What key are you going to use to encrypt it?
- dullgiulio 9y agoIn theory you don't need a key if you do a DH exchange, but I suppose that's too many round trips and makes things generally much more complicated in the protocol later (unless you discard the first DH-exchange, wasting even more round-trips).
- hannob 9y agoSee lengthy discussions on the tls-wg list. What definitely works is opportunistic encryption of the SNI name. You could also build something where that is later authenticated with the server's key and you could raise an alarm if it isn't. Or you could re-use a previously used session key for at least all resumed sessions. Yeah, not perfect, but better than nothing.