4 ms·
Encrypted SNI probably can’t make this version, as it requires a fair bit of new protocol infrastructure to support. The handshake would have to start with a ge
by hacknat 8y ago
Encrypted SNI probably can’t make this version, as it requires a fair bit of new protocol infrastructure to support. The handshake would have to start with a generalized untrusted assymetric exchange exchange to transfer the SNI field then “upgrade” the connection to be trusted and then retroactively tell the client what the initial “untrusted” key was so that the client can confirm it didn’t suffer a man in the middle attack during the SNI transfer phase.
All of this is possible and should be done, but I doubt it will make protocol 3.
- rocqua 8y agoAs far as I know, the SNI field is only used by the server to select what cert to use and site to serve. So if someone were to MitM the SNI exchange, presuming they don't have a valid cert, they could only cause the client to receive a different site (if served with a cert valid for both sites). We can presume the MitM doesn't have a valid cert, otherwise they could fully MitM the connection. To ensure your keys are indeed set up by the trusted party, you need to get that signed by the server cert, but that is already part of the TLS protocol. It seems I'm missing something.
- stanleydrew 8y agoThe danger is not that unencrypted SNI exposes clients to additional MitM attacks. It just exposes the client's intended domain to everyone on the connection route. It's an information leak, that's all.