(Yes, there's an additional leak in the form of a DNS lookup that has to happen, but as a client that's usually easy to address if you care.)
(Yes, there's an additional leak in the form of a DNS lookup that has to happen, but as a client that's usually easy to address if you care.)
Edit: Actually now that I think about it, could they just sniff the certificate offered by the server and get the same info? If so that's unfortunate, but plenty of firewalls don't seem to be doing that, as I noted above with my youtube example.
The sites in question will likely be blocked soon enough, but it won't be because of SNI being less secure, it will be because more and more traffic will default to TLS - a development helped along by SNI, certainly - and the operators will notice and the gateway providers will add the required sniffing, covering both "old school" certts and SNI.
Something like this, perhaps?
1. Server sends a salt
2. Client sends hash of salt + target domain
3. Server computes hash of salt + target domain for all possible domains that it serves and compares to find out which one the client is requesting
That said, there's an argument going at the IETF list about encrypting SNI and the rest of the TLS handshake: http://www.ietf.org/mail-archive/web/tls/current/msg11823.ht...