Turns out using google-meek made users especially vulnerable to this type of attack. Where should warnings about this be included? in the vpn endpoint warning page? the bridges page?
Good question. I see you already added it here:
Bridges: Difference between revisions - Whonix
Should suffice?
Yes 
1 Like
Abstract (my emphasis throughout)
Previous attacks that link the sender and receiver of traffic in the Tor network (“correlation attacks”) have generally relied on analyzing traffic from TCP connections. The TCP connections of a typical client application, however, are often accompanied by DNS requests and responses. This additional traffic presents more opportunities for correlation attacks.
This paper quantifies how DNS traffic can make Tor users more vulnerable to correlation attacks. We investigate how incorporating DNS traffic can make existing correlation attacks more powerful and how DNS lookups can leak information to third parties about anonymous communication. We (i) develop a method to identify the DNS resolvers of Tor exit relays; (ii) develop a new set of correlation attacks (DefecTor attacks) that incorporate DNS traffic to improve precision; (iii) analyze the Internet-scale effects of these new attacks on Tor users; and (iv) develop improved methods to evaluate correlation attacks. First, we find that there exist adversaries who can mount DefecTor attacks: for example, Google’s DNS resolver observes almost 40% of all DNS requests exiting the Tor network.
We also find that DNS requests often traverse ASes that the corresponding TCP connections do not transit, enabling additional ASes to gain information about Tor users’ traffic. We then show that an adversary who can mount a DefecTor attack can often determine the website that a Tor user is visiting with perfect precision, particularly for less popular websites where the set of DNS names associated with that website may be unique to the site. We also use the Tor Path Simulator (TorPS) in combination with traceroute data from vantage points co-located with Tor exit relays to estimate the power of AS-level adversaries who might mount DefecTor attacks in practice.
Key Take Home Messages
I’ll save you reading the academic paper if you are time-poor:
1. Correlation Attacks using TCP flows are greatly enhanced by also doing DNS request traffic correlation.
2. Attackers observing occasional DNS requests may still be able to link both ends of the communication, even if they can’t observe TCP traffic between the Tor exit and the server.
3. Loading a single webpage can generate hundreds of DNS requests to many different domains.
4. The way Tor exit relays are currently configured means that Google (yes, your good friend Google) are in a central position to deanonymize Tor users if they so wished, as 40% of the Tor bandwidth uses Google’s public DNS servers to resolve DNS queries.
5. Note: simply increasing the scale of the Tor network itself is not much of a defense against this fingerprinting technique.
6. Less frequently visited websites - the kind that privacy-conscious people like to visit e.g. Wikileaks, Whonix etc. - are more prone to deanonymization.
7. Not all Tor client (browser) locations are equal. The data suggests you will be de-anonymized in a shorter average period due to network effects in France, Germany and Russia than in (ironically) the US or UK.
8. Website Tor fingerprinting defenses are needed now more than ever, due to the increased precision possible with this attack. That is, Tor developers need to ASAP implement padding as per Torspec #254. See:
https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-negotiation.txt*
*This comes with significant network overhead and requires specific fine-tuning, which is why it hasn’t yet been implemented.
Short-term solutions for Tor developers and Tor exit relay operators:
Exit relay operators should avoid public resolvers such as Google and OpenDNS. Instead, they should either use the resolvers provided by their ISP, or run their own, particularly if the operator’s ISP already hosts many other exit relays. Local resolvers can further be optimized to minimize information leakage, by (for example) enabling QNAME minimization.
In addition to making recommendations to exit relay operators, we can remotely influence the cache of each exit relay’s resolver. For example, using exitmap, we can continuously resolve potentially sensitive domains over each exit relay, right before its TTL is about to expire. In such a setup, an attacker gains no advantage from observing DNS traffic from the exit relays because the domain is always in every exit relay’s resolver cache. This approach scales poorly, considering the potentially large number of domain names that would need to be cached (recall that the long tail of unpopular sites are most vulnerable to DefecTor attacks), but it allows us to eliminate DNS-based correlation attacks for a select number of sites.
Finally, Tor can fix the Tor clipping bug we discovered and consider significantly increasing the minimum TTL for the DNS cache at exit relays to make DefecTor attacks less precise. This adjustment requires finding the longest acceptable TTL that does not have a notable negative detriment to user experience. Further, as soon as the clipping bug is fixed,website operators of sensitive websites can opt to increase the TTL of their DNS records.
Long-term solutions for Tor developers:
Zhu et al. proposed T-DNS, which employs several TCP optimizations to transport the DNS protocol over TLS and TCP. The TLS layer provides confidentiality between exit relays and their resolvers. Finally, site operators whose users are particularly concerned about safety should
offer an onion service as an alternative. Facebook, for example, set up facebookcorewwwi.onion. When connecting to the onion service, Tor users never leave the Tor network, and hence do not need DNS (as long as the onion service does not embed non-onion service content).
Deploying defenses against website fingerprinting attacks in Tor [noted in point 8 above] should be an important long-term goal, as well. Although growing the Tor network will help defend against DefecTor attacks to some degree, the most important change is to deploy defenses against these attacks in the first place. Since DefecTor attacks significantly increase precision of website fingerprinting attacks, defenses should be designed to significantly reduce the recall of website fingerprinting attacks, even when the website fingerprinting attack is configured to sacrifice precision for recall.
1 Like
I read the parts of the paper I could understand (meaning: not so much). Here’s what I took away as an end-user:
For a Tor user to be de-anonymized with a traffic correlation attack, we usually assume that an adversary has to have visibility on both endpoints (or related ISPs). According to the paper, it is sufficient for the adversary to have visibility on entry and visibility on some of the DNS traffic. Exit TCP traffic is not necessary.
In specific, real-world terms, this means that a US-based Tor user has a frighteningly high chance of being de-anonymized by an American intelligence agency who has cooperation from a large national ISP as well as a large public DNS provider, like Google. Where it might have been difficult for said intelligency agency to obtain cooperation from foreign ISPs or to capture a significant percentage of exit nodes to observe TCP traffic, the paper (if correct) would render that effort unneccessary. With just Google & OpenDNS cooperation, the agency would have visibility on 50% of the DNS requests coming from the Tor network. And the entry visibility could easily be provided by ISPs that have cooperated with the NSA in the past (ie PRISM).
What about Tor clients?
Is it possible to route DnsPort traffic to a personal hidden service hosting a DNS server? Of course, it’s possible for this server to come under surveillance. The idea is to avoid lookups via Google, OpenDNS, OVH, as mentioned in the paper - the big targets. If an adversary has the means to observe every packet everywhere, they could just as easily mount a TCP correlation attack.
Good day,
@HulaHoop actually already made a thread for this: Tor Exit DNS Harms Privacy
Therefore, I merged the two.
Have a nice day,
Ego
1 Like
Apologies! Don’t know how I missed it 
Just delete the other thread if you like.
In reply to @entr0py above re: safer Tor browser (client) use, the smarties out there suggest identifying the IPs directly for your favorite websites and avoiding DNS look-ups altogether.
- For instance, with whonix.org, you can run the following in a terminal:
host -t a whonix.org
Which provides the following output:
whonix.org has address 94.23.250.81
- Now, either bookmark this IP address or directly input it into the Tor browser to avoid DNS lookups (try it - it will resolve to https://whonix.org). Your hosts file can also be used in this manner.
I’ll also quote Mirimir to summarize (hi buddy!), since he/she appears to know their shit. He/she suggests:
They [researchers] posit an adversary that can 1) see your traffic to the Tor entry guard, 2) get (not just intercept) DNS requests from the Tor exit relay for websites that you visit, and 3) see what websites the Tor exit hits for you.
Apparently, the DNS lookup information enhances website fingerprinting, where adversaries correlate packet patterns of website loading between exit-relay and entry-guard traffic. Each website has a more-or-less unique packet pattern over time, as various scripts run on each end, and various resources are downloaded. Consider http://hubblesite.org/gallery/wallpaper/ for example. There are many images, with different sizes, that get downloaded in a particular order.
Longer term, .onions need to proliferate, DNS resolution needs to be done entirely within the Tor network somehow and 3rd party resolvers need to be ditched altogether.
Letting Google have this kind of (potential) influence is like entrusting your 10 year old with a child molester while you enjoy a leisurely movie and dinner. 
Even if you manually resolve DNS to a website. That alone cannot be a big help. Since once you visit a webpage, far most websites will instruct your websever to fetch content from other sources which requires dns resolution. So you’d have to disable DNS resolution in your browser somehow. [Or as a strange workaround,
- remove proxy settings ( Tor Browser Essentials )
- and disable Tor transparent DNS resolution ( Stream Isolation )
But even if you had all of this sorted out somehow, in this case unfortunately it does not help if you are one of a few super secure people. For one, you stand out more than other users. But let’s ignore this. Worse so, everyone else could be deanonymized easier. And with all of them not secure, there would be no crowd to hide within (as per anonymity loves company).
//cc @mirimir since mentioned above.