Discussion in 'privacy technology' started by lotuseclat79, Sep 29, 2016.
The Effect of DNS on Tor’s Anonymity
Having substantive anonymity on the open Internet is a hard problem
Maybe move DNS resolution into onion services, and then hit exit relays from them. Then it becomes much harder to correlate DNS requests with site traffic.
The big question is, why do 33% of exit node operators choose to route Tor users DNS requests throught one of the biggest adwar...uh, I mean search company?
You mean do the resolution inside Tor network instead at it's edge? That's a very good suggestion. Shouldn't be too hard for Tor project to cook it.
I mean, there is already experimental way to make .onion addresses more user friendly with OnioNS (DNS for .onion addresses).
People could have more easier to remember addresses and there would also be little reason to try to bruteforce address generation for your liking like facebook did with their .onion address (shame on you Facebook!)
Various ways to fix this problem:
1. Implement DNS resolution service inside Tor network.
2. Continue using Tor network edge resolving from exit points but try to harden it. I would recommend ditching using 3rd party resolvers (like Google) and use just root DNS hints with DNSSEC optimized, qname minimisation supporting light weight resolver like unbound. Or maybe fork unbound and tailor it to suite for Tor project purposes. Currently Tor has, like what, 7000 exit nodes? So it shouldn't be too much purden for root DNS servers, especially if each exit node configure their local resolver to use caching too. Also, try to convise root DNS servers the importance of encryption support (a la DNSCrypt)
3. Try to convise other companies to follow facebook example and offer their content inside Tor network with .onion/.tor addresses. The more content available inside Tor the less reason to go outside it and expose yourself.
4. Completely replace the underlying OSI stack from layer 2 and below and make an alternative for current Internet infra, outside of it's current controllers. There is already a way to make this happen with current wireless hardware and protocols.
Problem is, it would take time, money and advertising for that network to grow so it would most definetely need some company/venture capitalist/foundation support for bootstrap it.
EDIT: About option 3. There could also be Tor nodes inside the network that only function to exists would be to act as mirror to content outside Tor. But these hypothetical "mirror nodes" would need option 1. to be user friendly to use.
And it's always better to try to convise companies to offer their content inside Tor in the first place.
I have no clue.
Yes, I was imagining caching DNS resolvers as onion services that exit relays could hit anonymously.
Right, but that's a different issue.
Right. But do that in DNS onion services that exit relays can use.
OR where possible just learn and use IP's and bypass DNS lookup completely. Some sites almost never change, and yes I know some of the pitfalls. Just saying, if you know the numbers you don't need DNS lookup. Works for me on the sensitive sites and I "live" on TOR. Lets use Wilderssecurity as an example:
open a terminal and key the inquiry (first line below)
host -t a wilderssecurity.com
wilderssecurity.com has address 18.104.22.168
Now you can save this IP address as a bookmark or however you'll have access to it and use the TOR browser to come here directly without any dns lookup. Fast, safe, simple
I am not trying to fracture this thread. I just thought some newer members here might not really know what a DNS lookup is doing behind the scenes.
Go ahead and give it a try. Paste & Go 22.214.171.124 above into your TOR browser. If its configured correctly it will automatically open the https version of this site.
I know this thread is about general surfing around. Still many of us have a small handful of sites we visit all the time and generally they are the ones where we want to remain anonymous. That being the case, why provide a domain name server a daily opportunity to log or catch something. My .02
Yes. And you can do that with the hosts file.
Let me see if I am understanding the problem. Can adversaries see your DNS requests, revealing the websites that you go to, but can't link the DNS to a particular user or location?
This is the key conclusion:
They 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.
related to DNS: I just found out that there is an actual official standard for DNS encryption on its way (late's proposed standard, may 2016). https://tools.ietf.org/html/rfc7858
And earlier draft of rfc7858 even mentions unbound as one of the resolvers already supporting this.
So now just have to wait till standard is finished and root DNS servers start supporting it like they already support DNSSEC.
Here's The Register article of it:
So, might not a solution be, for Tor to provide DNS lookup from a Tor intermediate node before reaching the Tor exit node, and then embedding the looked up numeric IP address into the request reaching the Tor exit node? I imagine in this kind of scheme that within the Tor network, a number of different Tor nodes would be used in this intermediate role with a different one for each request changing it on-the-fly. Is that possible?
What I would really be interested in is for different Tor entry, intermediate, and exit nodes to change dynamically for each user on-the-fly with each new browsing request from one's browser to make it more difficult for adversaries to track individual users of Tor.
I think so. Tor already has roles for client, relay, bridge (like a non-public relay for helping Tor blocked users to get into network), and exit so adding one or two new roles shouldn't be a problem.
But would that add too much burden for network? I mean, if you fire up packet sniffer and take a look of the average, so called "modern web 2.0", web page, there are huge amount of request going in the background, not just the main, visible html page that you see.
Currently Tor chain length is hardcoded to three and I believe reading from somewhere that it changes every 10 mins. If the chain has to be reconstructed with each and every browser request then it could make things to crawl...maybe. I don't know.
EDIT: But if all that you want is to trigger chain updating with each main url change (what will be shown in the urlbar) in the TorBrowser then I don't see a problem.
Thanks for your comments!
I suppose my description may not be able to be optimally implemented to provide several requirements that prevent a user from being linked to its DNS request.
Currently, the exit node is responsible for DNS requests if the remote DNS variable in the torrc file is set to True (by default - I believe).
It seems to me that moving the DNS lookup either dynamically to different Tor nodes (within the Tor network) specifically setup for that purpose or even statically (for x amount of time before switching the responsibility within the Tor network) would probably be able to offload the same work at the Tor exit node (DNS lookup) and threreby mix up and defeat the pinning that now allows associations to be made that apparently can reveal whom a particular Tor identity belongs to.
Just thinking out loud - probably could use some refinement as I may not be as familiar with the inner workings of Tor as I would prefer to be in order to even suggest this kind of a scheme could work at all!
No, no, no, it's good to throw ideas around. And I had another idea: Why not move the DNS resolution to client side instead of exit nodes? If Tor Project would bundle with next TorBrowser release some secure local DNS resolver (Im suggesting unbound for that) then every client would do it's own DNS-to-IP resolving, with cashing, qname minimization and optimized DNSSEC enabled, directly to root DNS servers.
And as a bonus, would also have total control of where their DNS queries go.
Unlike now, when 40% of Tor user DNS stuff goes, without their knowledge, to Google(!).
Unbound supports tcp tunnels for DNS queries
Separate names with a comma.