For those trying to keep their identity secret, there are few tools better than Tor. Its use of onion routing with one of the world's largest networks makes it difficult for an adversary to deanonymize users. That said, this anonymity comes at a cost. Namely, Tor's bandwidth and latency leave much to be desired.
In a world where data is increasingly bought and sold, many internet users are looking to hide their browsing habits from their ISPs and web trackers. For these relatively small or disinterested adversaries, Tor is drastic overkill. An alternative for these users is a VPN, but they have their own set of drawbacks. In particular, most VPNs are either paid or ad-supported.
For my intern research project, I chose to bridge the gap between Tor and VPNs.
Background
The project, dubbed Torantula (for reasons that will be apparent by the end of this post), was started as a more general implementation of Tor Button's domain isolation, which sends traffic to different domains through different Tor circuits. What I wanted to do was implement something like this that could be put transparently in front of any SOCKS-capable application, even if they do not support isolating Tor streams themselves.
To do this, I leveraged features added to Tor through Proposal 171.The implementation of this proposal added the ability to isolate streams in 6 ways. Each of these isolation methods can fall into one of two categories: backchannels or routing information.
Implementation
Backchannels
The backchannel methods for isolating streams are those that can more or less be controlled by applications connecting to Tor. Tor enables them by default. They are:
- SOCKS port
- Implemented implicitly
- A user can set up multiple SOCKS ports from a single Tor client. These SOCKS ports will not share streams
- SOCKS authentication
- Implemented through IsolateSOCKSAuth
- Streams with different SOCKS username/password combinations will go through different Tor circuits
- Client address
- Implemented through IsolateClientAddr
- Streams from different users of the same Tor client will go through different circuits. Ex: 192.168.1.13 and 192.168.1.42 will never use the same circuit
- Client protocol
- Implemented through IsolateClientProtocol
- SOCKS5 connections will go through one circuit; SOCKS4 connections through another
Of the back channels, SOCKS port and SOCKS authentication are generally the easiest to configure (And you should totally make use of them if you're using multiple applications through the same Tor client!). SOCKS authentication can be configured solely through the client application, so that's what Torantula uses.
Routing Information
Using routing information for isolation is on the sketchy side, and so is disabled by default in Tor. Routing information based methods of isolation are:
- Destination port
- Implemented through IsolateDestPort
- Connections to different ports each go through their own circuit. Ex: HTTP (Port 80) and SSH (Port 23) each go through their own circuit
- Destination address
- Implemented through IsolateDestAddr
- Connections to different addresses each go through their own circuit. Ex: google.com and reddit.com do not go through the same circuit
At first glance, simply configuring Tor to isolate on destination address is what I want. However, Tor Button decides not to use this, since it has some issues. For one, a new circuit must be created for each new address. For a connection to google.com, this means another new circuit for www.google.com, images.google.com, gstatic.com, and so on.
To solve this problem, Tor Button isolates based on the page that requests came from. For example, since the request to gstatic.com was made from google.com, they both go down the same circuit. This is close to ideal, since traffic from the same session will go down the same circuit. However, such a scheme requires operating at Layer 7, which Torantula does not.
Instead, Torantula takes an approach about halfway between Tor Button and IsolateDestAddr. It will isolate streams based on second-party domain names. In essence, google.com, images.google.com, and www.google.com will all go down the same circuit, but gstatic.com will not. Similarly, when given an IP address as routing information, Torantula will compare masked off portions of the IP address to see if the first n-bits (As determined by the CIDR suffix) are the same, and send those down the same circuit. This is a weak heuristic at best, but as our target audience does not need the full strength of Tor, it works well enough. Plus, it's still better than no isolation at all.
Another problem with using routing information for isolation is that it tends to create a lot of circuits. This increases latency the first time a user connects to an address. To mitigate this latency increase, Torantula can be configured to restrict itself to a finite number of circuits that do not need to be set up again for each connection to a new address. Again, this is a weak heuristic, but it can decrease first-time load of web pages by a couple seconds and is still better than having no isolation at all.
The Unethical Bit
With Torantula successfully acting as an intermediate proxy and able to control the circuits that streams go through, a thought entered my head: what if I added the ability to also send streams over different Tor processes.
Intuitively, I didn't think this would do much at first. However, I knew Tor throttled clients at guard nodes to keep the network less saturated, so I figured it was worth a shot to see if I could get better bandwidth by using multiple processes.
The results were better than I expected.
Yup, that's 12.7 MiB/s, about 100 Mb/s, through Tor. Granted, this type of speed can only be realized when it is one client talking to many, independent clients. This limits the use-cases where such bandwidth can be achieved to things like torrenting, large-scale port scanning, and web crawling. Still though, that's almost 100 Mb/s through Tor.
All that said, I'd be remiss to not mention the downsides of this. For one, torrenting over Tor is notoriously prone to leaking information about the user. Further, you're abusing the network pretty badly. That bandwidth you're using to download Arch Linux could ethically be better utilized by a political dissident or whistleblower.
Risks
I set out to tune Tor for speed and there were definitely some improvements in that realm. That said, in all cases where Torantula yields better performance, it is at the cost of a more relaxed security measure. If you absolutely need security and anonymity, stick to using Tor directly or through Tor Browser. Torantula is for those with little to hide, who are facing weak adversaries, and want some more speed.
Torantula is available for download and use at https://github.com/SecurityInnovation/Torantula. I was only able to test it on Linux, but it'll probably work fine on OS X, too (Maybe with minor tweaking).
Written by Garrett Marconet, Security Innovation Intern
Comments
Post a Comment