Hacker News new | past | comments | ask | show | jobs | submit login

Am I the only one deeply disappointed by SNI? Having the domain going out over plaintext is a major step down in privacy from the way it was before.

(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.)

How is it a step down? Without SNI, the public IP you connected to also uniquely identified the domain/cert you were visiting.

You are absolutely correct, but in practice I believe it often works out differently. I imagine that under pre-SNI conditions, many hotels/free hotspots/university/work firewalls don't go to the trouble to actually connect to the IP to see if it matches their list of bad actors. And that guess has often been borne out for me where, for example, http://youtube.com is blocked but https://youtube.com is permitted. With SNI, they can easily passively sniff the domain you want and block and/or log it, no active measures like reverse lookups or probing connections required.

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.

If it's equally possible to sniff out the domain name, what makes you predict that more operators would go through the trouble under SNI than did before?

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.

Yeah, I think you're right. Then we'll have a proposal for SNI2 and a multitude of people wishing it had been done right the first time.

Wouldn't it be possible to engineer the protocol in such a way that the domain that you want to go to is not publicly identifiable?

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

Using DNS, you can usually find all the domains a certain IP hosts[1], so the attacker could just do the same as the server to find the target domain.

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...

[1] http://reverseip.domaintools.com/

You could do that, but who is going to want an extra round trip or two while making an HTTPS connection? Internet latency is often bad enough already.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact