> 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.
Do 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?
> Do 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.
It's a modification that has already been made to software and widely deployed. The RFC was back in 2003. Are there even any TLS implementations that don't support SNI that aren't also so horribly out of date that they're full of since patched vulnerabilities?
Also it sounded like you cared a ton about getting "these stupid hostnames", and if you don't I'm not even sure what your objection is. That you can't browse some websites on Windows XP anymore? If you care enough about security to complain that TLS sucks compared to CurveCP, you definitely shouldn't be using it anyway.
I do not use Windows. I do not use the kernel or the browser you use. It is not your business what I use anyway. Notice I never said TLS sucks, you did.
Maybe I do not care about security and I just like carefully written software by people who do not make many mistakes? Is there something offensive about that? Am I allowed to make my own choices of software?
This is all beside the point. I care about having to use SSL and now with SNI. It is a hassle. Whether one likes SSL or not. It makes everything more complicated.
I believe there are too many websites encrypting content that honestly does not need to be encrypted. But I am sure they have their reasons.
I know how old the RFC is, but only in recent years has SNI become widespread. Probably because of all the hype around https adoption.
It is obvious that some people must care about privacy and/or security, or maybe they are just pretending to care? How else to explain the growth of https?
> I do not use Windows. I do not use the kernel or the browser you use. It is not your business what I use anyway.
I just said that because it's the only one I can think of people still having around that doesn't support SNI. OpenSSL, NSS, etc. have all supported SNI for a decade. In fact, I can't find any TLS implementation that supports even TLS 1.1 that doesn't support SNI. So unless you have an example I'd say SNI reached fixation a long time ago.
> Notice I never said TLS sucks, you did.
From another one of your comments: "I would not use SSL. Why spend time learning and fiddling with something that is so flawed?". Using TLS definitely counts as fiddling with SSL (TLS is a derivative).
> Maybe I do not care about security and I just like carefully written software by people who do not make many mistakes? Is there something offensive about that? Am I allowed to make my own choices of software?
Sure, write your own SSL/TLS/CurveCP implementation. But you started with "Just say no to SNI" and claimed privacy advocates should push back on it, which obviously doesn't only apply to you.
Do you like to make all sorts of assumptions about users, what software they use, what software they "should" use and what software "no one uses"?
I don't. Unlike many forum commenters, I do not try to convince people what software to use. I am not telling any users to stop using SSL. (Even though I strongly dislike it myself.) I am only addressing SNI, an extension to SSL that has become widespread in recent years.
Unlike you, I am not making presumptions about other users (except perhaps that some value privacy). They might know about some software I don't. I do not conclude "Well, that's all I can think of, so it must be everything that is worth considering."
If someone asks me how to do something using SSL libraries I am always going to say I would not use those. I am just being honest. Next time I will not mention CurveCP. Then they will ask: So what would you use? If I say anything other than SSL/TLS, they will attack my choice even if they know nothing about it.
A lot of very popular software is poor quality. That is my opinion. I do not choose software based on popularity. Sorry for not comporting to your assumptions.
Pre-SNI: Domainnames encrypted. Post-SNI: Domainnames unencrypted. Fact. That is not the only reason a user could dislike SNI. But it is the one that is applicable to this news event.
I think it is for users to decide whether they like SNI or not. And in my opinion silence does not necessarily mean they approve.
I really don't care what you do, my only "assumption" was that you claimed, repeatedly and loudly, that privacy advocates should step away from SNI and that SSL was "so flawed". You didn't start making your statements only apply to yourself until you ran out of arguments that people should do just that.
Also I went looking for TLS libraries released in the past ~10 years without SNI, my only "assumption" about users was that there were myriad of other reasons why you wouldn't want a decade old TLS implementation (the biggest one being security). If you have a more recent example, I'd love to hear it.
If you don't want people to ask for evidence when you make general statements like you did for quite a while before you decided this must be a personal attack, then don't tell people quite clearly what they should do if they care about privacy.
Then why comment? One user expresses dislike for SNI and you feel compelled to respond? If you have your own reasons for liking SNI you could have stated them, but you did not.
If I do not like SNI, then why would you care? My reasons are my reasons.
SSL-enabled software has to be "updated" because SSL-enabled software did not support SNI since 2003. It spread more recently. The reasons behind this I leave as an exercise for the reader.
As a user, I have no need for SNI. It is annoying for multiple reasons. Leaking hostnames is among them.
I am still able to use many websites that do not require SNI.
They are no less "secure" by virtue of not enabling it. And the software I use is no less secure for not supporting SNI.
I say it one last time: because you didn't just say what you do, you told other people what to do if they cared about privacy. If someone (not you, or me, this isn't a private chat) took that seriously, and you are wrong, you are at best spreading FUD. Don't expect me (or anyone else) to assume you are right that SNI is a significant threat to privacy based on your super-secret reasons that totally exist but you refuse to share.
Whether leaking the domainname in the Client Hello packet bothers a user or not is up to them. I simply brought it up as a consideration. I have a particular dislike for SNI because it requires modifying software that works just fine without SNI. I happen to like this software better than complex programs like "modern" browsers or command line programs with hundreds of thousands of lines of code and vast arrays of "features". Whether anyone else cares about such things, I have no idea. With HN, there may be some readers there with a similar aesthetic to mine. But probably very few if any.
As a user, I do not need SNI. I am not very motivated to modify software to support it. Especially when it moves the hostname out of the encrypted stream.
Secret reasons? FUD? Are you kidding?
Information about SNI is all over the web, in well-known places, from GitHub to StackExchange to Wikipedia. One does not have to chase up RFCs and dissect pcap files to verify what it does.
I am the last person to tell other users what software to use. No one would want to use my selections. I work in VGA textmode.
Everyday I see people telling other what software to use or not use, ad nauseum, in forum comments. I see little respect for users, especially from the large tech companies who assume all users are like lumps of clay to be molded however it suits them.
That you think I am doing this I find amusing. Again, my "desktop" is a VGA textmode console. The number of users who would choose such a working environment in the face of tech company marketing is minute.
Now, that is not to say I do not think they could easily adapt to textmode. I know they could because I saw many users do this in the 90's. I do not make assumptions about what users can handle. I am not trying to delibrately sell anyone on my software aesthetic.
More accurately, what I was trying to do in my original comment, before getting suckered into arguing over inane comments (and I apologize for this), was to make a whimpering plea to the folks who are driving the SSL/TLS bandwagon. The IETF types. I think they deplore unconventional users like me so the idea of pleading with them is probably futile to begin with. Maybe other users would care, too? I have read that someone has proposed a draft solution to exposing the hostnames in plain text. That is a start. Perhaps they are begginning to acknowledge they can do better.
The bizarre nature of your concern with my dislike for SNI actually suggests you are wielding some sort of FUD. Why do you care about what users know? You do not want users to question the merits of SNI? As far as I know, the sole purpose SNI is for virtual hosting. Maybe you work for a hosting company? Maybe you are a small website owner who does not have a dedicated IP address? And you want to run multiple https sites from the same IP? There are reasons to defend SNI but no one in these comments raised them.
To conclude, judging by the comments from openasocket, it may be that ISPs will be mining DNS requests as the primary means of profiling users for marketing their data to third parties.
If that is the case, there are solutions for users. Avoiding third party DNS, or even DNS altogether, is easy. Encrypting DNS packets is also easy.
Avoiding SSL/TLS on the www is probably impossible. It has spread like the plague, with hordes of staunch defenders who will not tolerate any experimental ideas that could be used as alternatives. For them it is SSL/TLS or nothing.
The biggest threat to privacy is probably ignorance and blind faith.
You appear to have forgotten to read your first comment:
"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."
The grammatical form of the last sentence is called imperative[0]. It is not a misnomer. The previous sentence quantifies over "privacy advocates". The first tells people who are not you what to do, the previous one tells people who are not you what they have reason to believe. You were the first person "telling others what software to use" in this thread.
> 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.
I'm talking about a hypothetical ISP that wants to extract all the hostnames its customers are connecting to. It has to analyze the traffic off a live stream and re-construct the TCP stream to do this. Rebuilding the TCP stream on a 100Gbps switch is pretty hard to do. Something like "sniproxy" is only extracting the hostname for all traffic connecting to it, so it doesn't have to try and re-build the tcp stream.
For the reverse DNS stuff, yeah you can't count on PTR records. The easiest thing is to use a third party like Domain Tools (https://www.domaintools.com/), or you can roll your own. The quick and dirty way to do this is to get your hands on regularly updated zone files with all the hostnames, do a DNS lookup for that domain name, and store that data in an index. Assuming you get regular updates to your zone files the daily load is manageable. From memory, for .com you only need to evaluate about 400K domain names a day.
tcpdump does TCP sessionization, yeah. But we're talking about ISPs extracting the hostnames in bulk for all their customers' traffic live, right? Maybe you're talking about something else, but I figured, based on the article we're having this conversation about, the attacker is these scenarios is an ISP, which only cares about doing these things at scale. You can't put tcpdump in front of a 100Gbps switch and do sessionization live.
> Assume DNS is not used and there is no reverse DNS information available that gives the specific domainname requested by the user.
If it's a hostname it has to correspond to a valid domain name, right? You can always use a third party or roll your own reverse DNS entry, as I described in my other answer. As long as the domain name actually has a DNS A record, we can get it.
"If it's a hostname it has to correspond to a valid domain name, right?"
If it is listed in the ICANN DNS, maybe.
DNS is not mandatory for a website to work.
Most of the time I do not use DNS when reading the www. I have my own databases of the info I need to reach websites. Not that I expect anyone else would do this, but it is very fast and reliable.
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.