SNI makes gettng the hostnames easier than if they were encrypted as they are without SNI.
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.
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?
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.
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 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.
> 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.
