4 ms·

You 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

by gwu78 10y ago

You 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 ago
  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?
  - 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.
    - gwu78 10y ago
      Are you saying that programs that extract hostnames like "sniproxy" cannot scale? And you are saying that all hosts have set up reverse DNS and the data is complete and accurate?
      - openasocket 10y ago
        No and No. 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/ 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.
  - johncolanduoni 10y ago
    > 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.
    - gwu78 10y ago
      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?
      - openasocket 10y ago
        What browser are you using that makes SSL "a hassle," with or without SNI?
        gwu78 10y ago
        Any sslclient that has not been modified to accomodate SNI. As someone else commented, SNI appeared in 2003. Was all SSL-enabled software written after 2003 SNI-enabled? Why not? There are still many https websites that do not require SNI. God bless them. Perhaps they can afford a dedicated IP and do not need to engage in virtual hosting.
- gwu78 10y ago
  "Getting the hostname from SNI requires TCP sessionalization and at least some form of DPI." I have done it with tcpdump. What does getting the hostname from an encrypted packet require? Assume DNS is not used and there is no reverse DNS information available that gives the specific domainname requested by the user.
  - openasocket 10y ago
    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.
    - gwu78 10y ago
      "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.

by gwu78 10y ago

You 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 ago
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?
- 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.
  - gwu78 10y ago
    Are you saying that programs that extract hostnames like "sniproxy" cannot scale? And you are saying that all hosts have set up reverse DNS and the data is complete and accurate?
    - openasocket 10y ago
      No and No. 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/ 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.
- johncolanduoni 10y ago
  > 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.
  - gwu78 10y ago
    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?
    - openasocket 10y ago
      What browser are you using that makes SSL "a hassle," with or without SNI?
      - gwu78 10y ago
        Any sslclient that has not been modified to accomodate SNI. As someone else commented, SNI appeared in 2003. Was all SSL-enabled software written after 2003 SNI-enabled? Why not? There are still many https websites that do not require SNI. God bless them. Perhaps they can afford a dedicated IP and do not need to engage in virtual hosting.
gwu78 10y ago
"Getting the hostname from SNI requires TCP sessionalization and at least some form of DPI." I have done it with tcpdump. What does getting the hostname from an encrypted packet require? Assume DNS is not used and there is no reverse DNS information available that gives the specific domainname requested by the user.
- openasocket 10y ago
  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.
  - gwu78 10y ago
    "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.