6

Over here, it came up that the operator of a web service can find out the real IP address of a Tor Browser user by simply letting the user resolve a subdomain via a HTML element and logging who (source IP address) tried to resolve that subdomain on the web service's name server.

I don't see why Tor's strategy of resolving TLDs would be any different from its strategy of resolving subdomains.

I was under the impression (googled it some time ago) that resolving DNS is none of the Tor Browser's business and if we only take a look at the Tor Browser's traffic, in fact none of the business of any application on the user's computer. The Tor Browser would just request the document http://stackexchange.com/ from the used exit node γ through α and β (α being the entry node) and then once it got it see that in order to display the website, it needs the document http://stackexchange.com/topbar/get-unread-counts?_=1475324641346 so it would request that from γ through α and β. Finding out that the IP address of stackexchange.com is 151.101.1.69 would be the job of γ. Now, if the document http://stackexchange.com/ embedded the resource https://security.stackexchange.com/image.png, the Tor Browser of course wouldn't go about asking the name server of stackexchange.com what the IP address of security.stackexchange.com is and figure out that it's 151.101.129.69. This, again, would be the job of γ.

However, according to George Y., this isn't true. Instead, as I took it from him (please correct me if I misunderstood him), the Tor Browser asks the name server of stackexchange.com about the IP address of security.stackexchange.com, finds out that it's 151.101.129.69, and then requests http://151.101.129.69/image.png from γ. (Yes, of course the Tor Browser probably doesn't to that itself but instead asks the local nameserver which then iteratively resolves the DNS entry but this doesn't really matter because (in the case of IPv4) it doesn't change the IP address.)

Similarly, I think this would mean that for the initial request (let's assume the .com nameserver is already known and we don't need to go ask a root name server for it) of http://stackexchange.com/ would require the Tor Browser to first resolve stackexchange.com to 151.101.1.69 and then to request the document http://151.101.1.69 from γ.

If this is correct, this would mean that the operator of the .com nameserver can create a list of all websites which were visited by a user with a certain IP address. A state authority can force the operator of the .com nameserver to keep and share with it a log of requests consisting of the domain resolved and the source IP address. That state authority of course can also force the user's ISP to tell it who was assigned that IP when the request was made, therefore revealing which servers which user communicated with.

Is this true? If (hopefully) not, where is the mistake?

Community
  • 1
UTF-8
  • 2,300
  • 1
  • 9
  • 24

1 Answers1

7

No, the Tor Browser never resolves hostnames itself. As you recognized, querying DNS servers directly would effectively allow an adversary to deanonymize you (a vulnerability known as DNS leak).

When your Tor Browser needs to open a new TCP connection, e.g. to load an embedded image over HTTP, you don't need to find out the IP yourself. The Tor protocol allows your browser to initiate the anonymized TCP stream giving the unresolved hostname. The exit node will then figure out the routing itself. This is also explained here.

I think the conversation you linked is just a misunderstanding about how Flash applets can theoretically bypass a Tor tunnel and lead to a leak.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • He talked about doing that using an embedded image which is available over a subdomain. – UTF-8 Oct 02 '16 at 01:56
  • It wouldn't matter if it's a subdomain. The Tor browser leaves all routing to the exit relay. – Arminius Oct 02 '16 at 02:15
  • It's not just that the browser does it, it's how the SOCKS4a and SOCKS5 protocol work in general. Tor supports both these protocols for interfacing with applications. – forest Nov 29 '17 at 07:14