The client doesn't provide the hostname without SNI (yes, I realize almost every client follows RFC 3546 anyway), nor is it compelled to for the exception of the IPv4 servers that require it. However, the server always ends up sending back an unencrypted public certificate, with or without SNI, and that certificate will include the hostname.
I phrased my other post poorly, and should have pointed out the exact issue I was referring to; you can't hide hostnames just by ditching SNI.
Thanks to SNI and IPv4 forcing everyone to host multiple sites on one address (but I repeat myself) SSL does now leak the hostname you are attempting to request during the handshake so the server can select a certificate.
The hostname is leaked in the server response (it has to respond with the public certificate); the encryption doesn't start until after the server has disclosed who it is. Your frustration seems misplaced. Even if it was encrypted, a second connection can fish the certificate themselves.
Slashdot Mirror
The client doesn't provide the hostname without SNI (yes, I realize almost every client follows RFC 3546 anyway), nor is it compelled to for the exception of the IPv4 servers that require it. However, the server always ends up sending back an unencrypted public certificate, with or without SNI, and that certificate will include the hostname.
I phrased my other post poorly, and should have pointed out the exact issue I was referring to; you can't hide hostnames just by ditching SNI.
Thanks to SNI and IPv4 forcing everyone to host multiple sites on one address (but I repeat myself) SSL does now leak the hostname you are attempting to request during the handshake so the server can select a certificate.
The hostname is leaked in the server response (it has to respond with the public certificate); the encryption doesn't start until after the server has disclosed who it is. Your frustration seems misplaced. Even if it was encrypted, a second connection can fish the certificate themselves.