5 ms·

The 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 thin

The 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 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.
    - 10y ago
  - 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.

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.
  - 10y ago
- 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.