7 ms·
This thread may grow long and maybe turn to the topic of HTTPS. SSL with SNI exposes plaintext hostnames/domainnames on the wire for anyone to read, aggregate
by gwu78 10y ago
This thread may grow long and maybe turn to the topic of HTTPS. SSL with SNI exposes plaintext hostnames/domainnames on the wire for anyone to read, aggregate and sell, not to mention tamper with. It should be an optional extension. For many users it adds no benefit. For some users, it breaks their software and adds needless complexity. Now the privacy advocates have a reason to dislike it too. Just say no to SNI.
- johncolanduoni 10y agoIf you don't have SNI, then the server's IP address is going to be tied to a specific domain name anyway (unless you do a shared certificate like CloudFlare does, which now makes actual data more vulnerable). A government or telecom company is definitely going to have precisely zero trouble linking IP addresses to domain names absent SNI.
- deleted 10y ago[deleted]
- Dylan16807 10y agoPlease describe a way to do SSL without the domain being visible that can work for most sites. What would you encrypt the hostname with?
- gwu78 10y agoI would not use SSL. Why spend time learning and fiddling with something that is so flawed? If I was serious about encrypting traffic I would use CurveCP. SSL is simply a nuisance I tolerate to read the www. Every minute I spend learning about it is wasted time... because I could be spending that time learning about something better, like CurveCP. The spread of SNI has just made SSL even more annoying.
- deathanatos 10y agoReading a bit about CurveCP isn't enlightening; it seems to be a UDP protocol that uses elliptic curve cryptography for encryption and authentication. But that, by itself, doesn't explain how it solves the problem that SNI solves better. Say a client is speaking CurveCP with another party; how do they authenticate the other end? What if the other end has limited resources (such as IPv4 addresses) and needs to serve multiple entities, how do the client and server distinguish or determine which entity to authenticate to/for/with?
- gwu78 10y agoI am not suggesting that anyone use something else besides SSL. Use whatever you want to use. I am suggesting that SSL users may want to consider the merits of the SNI extension. Website owners are unlikely to care let alone oppose it. As a www user, I do not like SNI and that is only an opinion, as a user. Why? Because all existing software that has to be SSL compatible now has to be modified to handle SNI. As a user, I derive no benefit from SNI. That is why I dislike it, first and foremost. But I believe there may be other reasons to dislike it. Perhaps privacy. Perhaps censorship. Maybe none of the above. I don't know. You decide. In any event, it seems there are at least a few folks that agree with me that the merits of SNI are at least questionable which is both surprising and encouraging.
- mjevans 10y agoEstablish an enciphered, unauthenticated, connection to an IP. This is now a tunnel. Over that tunnel: * If you've connected before attempt to reuse the cached credentials to further establish a connection to the requested certificate. This validates prior authorization of being the target host. * If the above fails or if it's a new host, ask for the certificate, perform extensive validation including REQUIRING that the external revocation check authenticates and confirms non-revoked.
- openasocket 10y agoHow do you create an encrypted connection to an IP address? Just a regular Diffie-Hellman key exchange? That's pretty easy to MitM, and then the attacker can view the certificate the server passes, which will contain the domain name. A little more involved than sniffing SNI, because now you need to scale out MitM-ing instead of DPI, but pretty much the same problem.
- cesarb 10y agoOnce the connection is MitM'd, the certificate validation would fail, since the MitM host cannot sign the "hash of everything that's been exchanged in this connection so far" with the correct server certificate. So the MitM would have to choose between either learning the domain name but failing the connection, or letting the connection pass but not learning the domain name.
- openasocket 10y agoDarn, that right. I guess I fall back to my other answer then: the ISP can always get the domain name from the server ip address and reverse or passive DNS, and there's nothing you can do about that.
- Aaron1011 10y ago> not to mention tamper with Modifying the SNI hostname in transit is pointless - the client still knows what hostname they sent. Changing the SNI hostname would only cause the server to send back a different certificate, which would immediately be noticed by the client.
- gwu78 10y agoAnd break the connection. Mission accomplished.
- deathanatos 10y agoIf you can tamper with the connection and "breaking the connection" is "Mission accomplished", SNI isn't going to make any difference. You can just drop all the packets, and be done w/ it.
- openasocket 10y agoThe ISP owns the transit of traffic between the client and the server. If they want to block people from accessing certain places they can just block it at the ip layer with packet filtering. Why would they go through all this rigmarole with mangling SNI data?
- deleted 10y ago[deleted]
- openasocket 10y agoThe IP layer already exposes the IP addresses they are contacting, and you can use reverse DNS or passive DNS to get the domain name. SNI doesn't even make things easier, because extracting that from traffic requires DPI and TCP sessionization.
- gwu78 10y agoYou assume that DNS is being used. What if the user already has the IP address and knows the hostname? SNI makes gettng the hostnames easier than if they were encrypted as they are without SNI.
- openasocket 10y ago> What if the user already has the IP address and knows the hostname? Then the ISP just does a reverse DNS lookup, which can be implemented a bunch of different ways, it's not particularly difficult. > SNI makes getting the hostnames easier Getting the hostname from SNI requires TCP sessionization and at least some form of DPI. Getting the hostname my way just requires single-packet inspection with a reverse DNS lookup. If anything, my way is easier.
- gwu78 10y agoDo you understand why I do not like SNI? It has nothing to do with getting these stupid hostnames. It is a modification that needs to be made to software to accomodate the spread of the use of the SNI extension. As a user, I have no need for SNI. Are you saying that doing reverse lookups on every IP address, where some of these IPs will have many virtual hostnames, is easier than extractng the plaintext hostname from a certain offset in a Client Hello packet? If there are many virtual hostnames, how do you know which one the user has requested? What if the reverse DNS data just lists an ambiguous subdomain and not the domainname in the user's HTTP request, or what if the rDNS data is missing?
- openasocket 10y ago> Are you saying that doing reverse lookups on every IP address, where some of these IPs will have many virtual hostnames, is easier than extractng the plaintext hostname from a certain offset in a Client Hello packet? If the SNI info was at a fixed offset in a packet, it would be easy. But, per the RFC, it goes at the end of the client hello, after the list of supported cipher suites and compression methods. Not only does that mean it's not at a fixed offset, the actual client hello message may not be contained in a single packet, but rather several. So the ISP has to gather the packets and put them in order to re-construct the TCP stream, and then compute the offset. That is not trivial to do, especially at scale. Reverse DNS lookups are much much easier. Trust me: in my work I've helped implement both TCP sessionization and reverse DNS lookup infrastructure, and the latter is far more scalable.