September 24, 2017

The Effect of DNS on Tor’s Anonymity

This blog post is joint work with Benjamin Greschbach, Tobias Pulls, Laura M. Roberts, and Nick Feamster.

Counting almost two million daily users and 7,000 relays, the Tor network is the largest anonymity network operating today. The Tor Project is maintaining a privacy-enhanced version of the popular Firefox web browser—Tor Browser—that bounces its network traffic over the Tor network. By using Tor Browser, users can protect their web browsing from government surveillance, stalkers, advertisement-injecting ISPs, and nosy neighbors. Tor works by decoupling a user’s identity (i.e., the IP address, which reveals where in the world you are) from her activity (e.g., visiting Facebook). When using Tor, your ISP can no longer learn what websites you visit, but it does know that you are using Tor. The website you visit (e.g., Facebook) will also know that you are using Tor, but it will not learn your IP address. The EFF maintains a great interactive diagram, illustrating information leakage in several scenarios.

While the use of Tor constitutes a significant privacy gain over off-the-shelf web browsers, it is no panacea, and the Tor Project is upfront about its limitations. These limitations are not news to the research community. It is well understood that low-latency anonymity networks such as Tor cannot protect against so-called global passive adversaries. We define such adversaries as those with the ability to monitor both network traffic that enters and exits the network. Then the adversary can run a correlation attack, meaning that it can match packets that go into the network to packets that leave it, or in other words, it can link a client’s identity (her IP address) to her activity (e.g., visiting Facebook), and thus, break anonymity. By design, Tor cannot protect against these global passive adversaries. However, there is still merit in understanding which organizations are in a position to launch such attacks and how practical these attacks are. Only then can we gain an understanding of how much of a real-world threat these attacks constitute.

The research community has put a lot of effort into modeling correlation attacks and their effect on Tor users. To date, these studies have modeled mostly web traffic, i.e., HTTP over port 80 and HTTPS over port 443, which makes sense as web traffic likely constitutes the bulk of a typical Tor user’s online activity. However, there is more to network traffic than just web traffic. Before a browser can fetch a web page such as Facebook, it has to send out a DNS request to learn that the domain facebook.com is reachable via its IP address 173.252.120.68 (among others). DNS traffic is ubiquitous, both over and outside of Tor, so how does this relate to correlation attacks? DNS is a very different beast than HTTP, which is what most research has studied. HTTP traffic travels from a user’s exit relay directly to one or more web servers. DNS traffic, however, can traverse very different paths, depending on how exit relays (the relays in the Tor network that provide the link between Tor and the Internet) are configured. In particular, we find that DNS traffic traverses many networks that are entirely different than the networks that subsequent web traffic traverses. This means that past research likely underestimated the threat of correlation attacks because there are entities on the Internet such as ISPs, autonomous systems, or Internet exchange points that can monitor some DNS traffic but not web traffic coming out of the Tor network and potentially use the DNS traffic to deanonymize Tor users.

Overview of concept

Past traffic correlation studies have focused on linking the TCP stream entering the Tor network to the one(s) exiting the network. We show that an adversary can also link the associated DNS traffic, which can be exposed to many more autonomous systems than the TCP stream.

After many months of work, we have published a research paper on how DNS affects Tor’s anonymity. In our work, we show how an adversary can combine monitored DNS requests with well-understood website fingerprinting attacks to create a new type of DNS-enhanced correlation attack, or DNS-enhanced website fingerprinting attack, depending on how you look at it. We know of several organizations that are in a position to use these attacks, notably Google. Because it operates a popular open DNS resolver, the company can already observe many DNS requests. Additionally, Google can monitor some network traffic that is entering the Tor network: for example, via Google Fiber, via guard relays that are occasionally run in Google’s cloud, and formerly via meek app engine, which is now defunctOur results show that by monitoring DNS traffic, an attacker can enhance a website fingerprinting attack to be highly reliable. When our new, combined attack identifies a website, it is highly likely to be correct for a large number of websites on the Internet. Furthermore, we show that our new type of attack works well on websites that are infrequently visited over the entire Tor network globally. Presumably, this includes censored websites in different regions of the world and websites for whistleblowers and activists, who are in many ways Tor users in most need of protection. Beyond further motivating the deployment of website fingerprinting defenses in Tor, our attack has implications for the design of such defenses: they should probably be stronger than previously thought.

Our study also provides new insight into the current state of exit relays in the Tor network: We find that a significant fraction of exit relays send DNS requests to Google’s public resolvers. Google sees about onethird of DNS requests that exit from the Tor network—an alarmingly high fraction for a single company, particularly because Tor’s very design avoids centralized points of control and observation. Although Tor is reasonably decentralized, our work shows that this does not hold for the wider ecosystem that Tor exists in. We also simulate the Internet-scale implications of our work using the Tor Path Simulator (TorPS). This allows us to understand what-if scenarios such as the implications for Tor users if all exit relays were to run their own local resolvers. Our results show that while running local DNS resolvers on exit relays has its benefits, it also means that DNS requests are very exposed to network-level adversaries.

So what does our work mean for Tor users? We believe that there is no immediate cause for concern. Adversaries that can already monitor large fractions of the Internet—for many people, the biggest threat—will not do any better with our attack. Instead, we investigate how “semi-global” adversaries can get the most out of the data they have. Finally, the Tor Project is already working on techniques to make website fingerprinting attacks harder.

Our project page has more information about our study. Together with the research paper that is now under review, we also publish our code, data, and detailed instructions to replicate our work.

Comments

  1. Patrick Lynch says:

    What happens if someone owns a tor node, can they play man in the middle?

  2. Tor is a well known project of the U.S. military, designed to promote the interests of the U.S. military and U.S. imperialism in general.

  3. Andrew McConachie says:

    I’m confused as to your suggestions.

    QNAME minimization is for use between a recursive DNS server and the servers they query. For example, Google’s public DNS might use QNAME minimization in communicating to the root servers, or to the authoritative servers for a TLD.

    Given this, I don’t see why you recommend Tor exit nodes use QNAME minimization? Do you expect Tor exit nodes to run recursive DNS servers? If so, then why also recommend Tor exit nodes to use a DNS service other than Google’s, since Google’s public DNS service is a recursive service?

    I recommend you check out DNSmasq if you are interested in a way for stub resolvers to play as recursive resolvers.

    • Yes, many exit relays run their own resolvers such as unbound. In that case, we want them to leak as little information to the network as possible. For example, nobody on the path between the exit relay and the root server needs to know the FQDN, e.g., that the exit relay is resolving http://www.example.com.

      As you mention, many exit relays also use Google’s public resolver. We consider this a risk because it currently enables Google to learn a significant fraction of DNS requests that Tor client send. We won’t be able to have all exit relay operators use the same setup, which is why we are trying to provide a diverse set of recommendations.

  4. Andrew McConachie says:

    Hi Philipp,

    Thanks for your efforts and research.

    If I understand you correctly then you would prefer exit node operators run their own recursive resolver and use QNAME minimization. If that’s not possible for some reason and they must act as a stub resolver, then you would prefer they not all use Google’s public resolver and use DNSoTLS. This seems reasonable to me.

    A possible further research avenue for your team might be to investigate how much QNAME minimzation actually minimizes query data transmitted. Because of caching recursive servers don’t actually send that many queries to the root servers. So if a given Tor exit node is sending lots of DNS queries for domains under the .com domain, or better yet under the example.com domain, then QNAME minimization buys you less. Since the queries won’t get sent anyways if they’re in the cache. I would be interested to know about this interplay between QNAME minimization and caching, and *how much* it really buys you in terms of privacy?

    –Andrew

    • Hi Andrew,

      “If I understand you correctly then you would prefer exit node operators run their own recursive resolver and use QNAME minimization.”

      At the moment, there does not seem to be a perfect setup for exit relays. In our paper, we compared three common setups (see Table V): a local resolver, Google, and the ISP’s resolver. All setups have disadvantages, but a local resolver using QNAME minimisation seems better than the use of Google. Then again, we are comparing apples and oranges, so it’s a bit tricky to make recommendations.

      “If that’s not possible for some reason and they must act as a stub resolver, then you would prefer they not all use Google’s public resolver and use DNSoTLS.”

      Yes, exactly.

      Regarding your last paragraph: That’s a great question. We have also been wondering about the actual benefit of QNAME minimisation, but haven’t gotten to measuring it yet.