Bittorrent over Tor isn't a good idea

An increasing number of people are asking us about the recent paper coming out of Inria in France around Bittorrent and privacy attacks. This post tries to explain the attacks and what they imply.

There are three pieces to the attack (or three separate attacks that build on each other, if you prefer).

The first attack is on people who configure their Bittorrent application to proxy their tracker traffic through Tor. These people are hoping to keep their IP address secret from somebody looking over the list of peers at the tracker. The problem is that several popular Bittorrent clients (the authors call out uTorrent in particular, and I think Vuze does it too) just ignore their socks proxy setting in this case. Choosing to ignore the proxy setting is understandable, since modern tracker designs use the UDP protocol for communication, and socks proxies such as Tor only support the TCP protocol -- so the developers of these applications had a choice between "make it work even when the user sets a proxy that can't be used" and "make it mysteriously fail and frustrate the user". The result is that the Bittorrent applications made a different security decision than some of their users expected, and now it's biting the users.

The attack is actually worse than that: apparently in some cases uTorrent, BitSpirit, and libTorrent simply write your IP address directly into the information they send to the tracker and/or to other peers. Tor is doing its job: Tor is _anonymously_ sending your IP address to the tracker or peer. Nobody knows where you're sending your IP address from. But that probably isn't what you wanted your Bittorrent client to send.

That was the first attack. The second attack builds on the first one to go after Bittorrent users that proxy the rest of their Bittorrent traffic over Tor also: it aims to let an attacking peer (as opposed to tracker) identify you. It turns out that the Bittorrent protocol, at least as implemented by these popular Bittorrent applications, picks a random port to listen on, and it tells that random port to the tracker as well as to each peer it interacts with. Because of the first attack above, the tracker learns both your real IP address and also the random port your client chose. So if your uTorrent client picks 50344 as its port, and then anonymously (via Tor) talks to some other peer, that other peer can go to the tracker, look for everybody who published to the tracker listing port 50344 (with high probability there's only one), and voila, the other peer learns your real IP address. As a bonus, if the Bittorrent peer communications aren't encrypted, the Tor exit relay you pick can also watch the traffic and do the attack.

That's the second attack. Combined, they present a variety of reasons why running any Bittorrent traffic over Tor isn't going to get you the privacy that you might want.

So what's the fix? There are two answers here. The first answer is "don't run Bittorrent over Tor". We've been saying for years not to run Bittorrent over Tor, because the Tor network can't handle the load; perhaps these attacks will convince more people to listen. The second answer is that if you want your Bittorrent client to actually provide privacy when using a proxy, you need to get the application and protocol developers to fix their applications and protocols. Tor can't keep you safe if your applications leak your identity.

The third attack from their paper is where things get interesting. For efficiency, Tor puts multiple application streams over each circuit. This approach improves efficiency because we don't have to waste time and overhead making a new circuit for every tiny picture on the aol.com frontpage, and it improves anonymity because every time you build a new path through the Tor network, you increase the odds that one of the paths you've built is observable by an attacker. But the downside is that exit relays can build short snapshots of user profiles based on all the streams they see coming out of a given circuit. If one of those streams identifies the user, the exit relay knows that the rest of those streams belong to that user too.

The result? If you're using Bittorrent over Tor, and you're _also_ browsing the web over Tor at the same time, then the above attacks allow an attacking exit relay to break the anonymity of some of your web traffic.

What's the fix? The same two fixes as before: don't run Bittorrent over Tor, and/or get your Bittorrent developers to fix their applications.

But as Tor developers, this attack opens up an opportunity for a third fix. Is there a way that we as Tor can reduce the damage that users can do to themselves when they use insecure applications over Tor? We can't solve the fact that you'll shoot yourself in the foot if you use Bittorrent over Tor, but maybe we can still save the rest of the leg.

One approach to addressing this problem in Tor's design is to make each user application use a separate circuit. In Linux and Unix, we can probably hack something like that up -- there are ways to look up the pid (process ID) of the application connecting to our socket. I suspect it gets harder in Windows though. It also gets harder because many Tor applications use an intermediate http proxy, like Polipo or Privoxy, and we'd have to teach these other proxies how to distinguish between different applications and then pass that information along to Tor.

Another answer is to separate streams by destination port. Then all the streams that go to port 80 are on one circuit, and a stream for a different destination port goes on another circuit. We've had that idea lurking in the background for a long time now, but it's actually because of Bittorrent that we haven't implemented it: if a BT client asks us to make 50 streams to 50 different destination ports, I don't want the Tor client to try to make 50 different circuits. That puts too much load on the network. I guess we could special-case it by separating "80" and "not 80", but I'm not sure how effective that would be in practice, first since many other ports (IM, SSH, etc) would want to be special-cased, and second since firewalls are pressuring more and more of the Internet to go over port 80 these days.

We should keep brainstorming about ways to protect users even when their applications are handing over their sensitive information. But in the mean time, I think it's great that these researchers are publishing their results and letting everybody else evaluate the attacks. (If you're a researcher working on Tor attacks or defenses, check out our new research resources page.) The attacks in this paper are serious attacks if you're a Bittorrent user and you're hoping to have some privacy.

Anonymous

May 02, 2010

Permalink

Indeed, as our double-posting friend above has said, the problems identified in the paper are easily solvable. Most of them, anyway.

"3.2 Simple Inspection of BitTorrent control messages"
Two problems here:

#1. Inspection of Announce messages sent to trackers can reveal the IP that some torrent clients embed in these messages (e.g. uTorrent).
* NO SOLUTION THAT I CAN THINK OF (the Announce message is not affected by your torrent client's encryption settings, it's sent in plain text and it's readable by anyone who takes the time to set up a malicious TOR exit node).

#2. Inspection of Extended Handshake messages with other peers.
* No problem, just force your torrent client to encrypt all your inter-peer communications and you're safe from this.

"3.3 Hijacking Trackers’ Responses"
This is something that only works if your inter-peer communications are not anonymized (encryption makes no difference here).
* Solution: route all your torrent traffic through TOR, not just the tracker connections. Sorry to say this, but going against TOR recommendations is the way to stay safe in this case. All I can tell you is to at least have the decency to cap your torrent transfer rate to make it more similar to other normal web communications in order not to overload the TOR network with your torrenting. Learn to live with the fact that better anonymity comes at a higher price. Just like you learned to respect your torrent peers by sticking around to seed even after you got what you needed, you should learn to respect your TOR peers by not hogging all their bandwidth with your torrents.

"3.4 Exploiting the DHT"
*Solution: turn off DHT in your torrent client's settings, d'oh.

Anonymous

May 03, 2010

In reply to by Anonymous (not verified)

Permalink

"Inspection of Announce messages sent to trackers can reveal the IP that some torrent clients embed in these messages (e.g. uTorrent).
* NO SOLUTION THAT I CAN THINK OF "

BUT THERE IS NO PROBLEM

uTorrent does not announce IP info. The IP field is optional in BT announce protocol and not used by uTorrent. Tested on versions 1.8.2, 1.8.5, 2.0.0 and 2.0.1, behind NAT and on full proxy settings.

Otherwise, the solution would be to prevent BT from learning its public IP and firewall it of course.

Sorry, but the authors of the paper cited above say uTorrent is one of the clients that are the most consistent in doing just that: embedding your real IP in the announce messages. It's their word against yours until I can test this myself. :) (I'm not even sure how - Wireshark or something?)

Yes they did blame uTorrent. Perhaps it behaves differently with partial proxy and DHT enabled. Wireshark is ideal for testing uTorrent, but note that the announce protocol is a simple HTTP GET request, so a number of small, specialized net sniffers can do it too.

Anonymous

May 02, 2010

Permalink

BitBlinder:
Nope, sorry, not a solution. Since right now they're not taking money in the place of relay hosting, everyone who uses it is forced to run as a relay by default. It's all nice and fine that you're hidden as a peer by being routed through other people's machines, but the reverse is also true (unless you can disable it like in TOR): others can download torrents through your machine as well, and if you're an exit node, to the outside world it will again appear as though you're downloading torrents. Which is exactly what you were trying to avoid in the first place. *slaps forehead*

Anonymous

May 02, 2010

Permalink

Pay attention, it is a Tor fork. You don't have to run a relay, and they do have plans of accepting money instead or relaying traffic. Also, you do get to choose which type of traffic to relay: eg: web only, bittorrent only, all. Finally, you can choose not to be an exit node, just like Tor, and simply act as a "Bridge".

BitBlinder is solving the bandwidth issue with the incentive of credits. You can transfer the same amount you have relayed. Many people/countries have no issues with relaying anonymous traffic, the point is the one seeding the content is never found, as an exit node, you are not the source, the sender remains anonymous, just like Tor.

Anonymous

May 02, 2010

Permalink

"Tor is doing its job: Tor is _anonymously_ sending your IP address to the tracker or peer. Nobody knows where you're sending your IP address from. But that probably isn't what you wanted your Bittorrent client to send."

LOOOL. Maybe this will remove BitTorrent traffic from the Tor network, which is painfully slow to use. I've been running a relay occationally, pushing a few hundred K per second, but I find myself banned from many sites as a result even if I am not allowing anything to exit!

Anonymous

May 03, 2010

Permalink

I hope *We* will live enough to resist, making - and projecting - and making again a future:
the net as open as possible, with computers and with people , not the fake images taken from s**t like BigBrother show and reconstructed in one's mind.

I HOPE

Thx All of you/

Anonymous

May 04, 2010

Permalink

BitBlinder:
YOU pay attention. I said _right_now_ they're not accepting money in place of relay activity and this is what it says on their website:
"During our beta testing we are not accepting payments, so you have to be a relay to continue using the network."

Also, uploading torrent content could very easily be considered your fault even if you were just an exit node and not the actual source of the material. You can be held responsible for whatever is being done from your IP unless you can provide very solid proof that you were hacked or had a virus/trojan/whatever or were simply ignorant of what was going on. I very much doubt that purposely running an anonymizing application would qualify as proof of innocence.

Hmm you don't seem to get it, do you? I can be an exit node all i want and you can do nothing about it, your laws don't concern me period. Many people can be exit nodes safely in many countries, and its those people who help others in oppressed (and corporate controlled) regimes. That said, BitBlinder can act as a bridge, which will earn you credits more slowly, but you will anyway. Do you not know what a bridge is? It means you ONLY pass encrypted traffic between nodes, never directly to the net, thats the job of the exit nodes who can can show the middle finger to complains from other countries. There is no risk whatsoever in running a bridge.

The only reason Bittorrent traffic isn't going over plain Tor is bandwidth issues, which BitBlinder fixes. AND, BitBlinder also passes web traffic, just like Tor does.

In short, BitBlinder is Tor without bandwidth shortages.

First of all, they're not my laws, I hate those fucking anti-sharing laws as much as the next guy.

Secondly, the anti-sharing "regimes" are basically all the Western "civilized" nations and the only places where exit nodes can be run safely are probably the most backward/poor/uncivilized countries.

Thirdly, I've seen complaints on the BitBlinder forum that people are getting piracy notices from their ISPs or other agencies even though they're torrenting through BitBlinder! If that thing's got leaks, I'm not touching it with a tadpole.

And finally, there's plenty of information about which ports TOR uses for incoming and outgoing connections, so I have a good level of confidence that I can block everything I need to block with my firewall so that there's ZERO potential for me to be visible with any exit node activities. There's no such richness of port information about BitBlinder, so I can't take the chance, sorry.

Anonymous

May 05, 2010

Permalink

Hello, I don't know where I can ask about it...
Is it possible make ready to work portable pocket based on Iron Browser like that you made for FireFox? I want it.Thanks.

Anonymous

May 10, 2010

Permalink

It seems that all the bridges have been completely blocked in China by GFW, and the auto-block system may have been updated ,e.g.:

Before I run my tor program via the bridge "xxx.xxx.xxx.xxx:8043",this is bridge is telnetable (I can telnet xxx.xxx.xxx.xxx port 8043). But after I run the tor program, this bridge soon becomes untelnetable.

Anonymous

May 10, 2010

Permalink

bridges invalid
tor in China has not connect, even if added to the latest bridges can not connect, have been shielded by Great Firewall.

Anonymous

May 17, 2010

Permalink

hi, I tried to download a software online while using Tor and every time a prompt box pops out saying "An external is needed to handle.... External applications are not safe by default and can unmask you! If this file is untrusted, you should either save it to view offline or in VM or consider using a transparent Tor proxy like Amnesia LiveCD, Torsocks or TorVM" I have no idea what these suggestions mean and i don't know where to get them. Please if anyone can shed light on this issue, i will be very grateful, thanks - chimmy

Anonymous

May 18, 2010

Permalink

Hi,
I'm new to TOR, and thank you for the tip. I have NO experience with proxies.. ETC. What I was wondering though is if there is any way to create a new net-layer which only TOR is aware of, and actually blinds all software to the real ports (which only TOR is aware of) Thereby creating an outbound firewall which only TOR can get through. Actually, can this be done via firewall? Would this be a good way to make sure the only data to move around moves through TOR?

Anonymous

June 14, 2010

Permalink

How about you have TOR or the proxy application look over packets and if it contains your own IP address, physical address, name or other identifiable info to pop up a message saying what is about to be sent and to either accept or deny the sending of that info, similar to ZoneAlarm's privacy guard. Tho this would require more system resources to monitor all your outgoing packets.

We don't want to look at content of the packets or do any sort of deep packet inspection. Also, which "your own IP address?" The one assigned to the local interface? The one assigned to the internet gateway? Looking at content is fraught with complexities not to mention the legal liabilities.

@Phobos thank you for the good job you have been doing you and your crew God bless you all and give you guys more talent please can i get a I.P and port scanner software from you which i can use in extracting I.P and ports from my Network orders cause it kinda of hard using the internet here please need you help on this.....Hope to hear from you soon....

Anonymous

June 14, 2010

Permalink

@Phobos thank you for the good job you have been doing you and your crew God bless you all and give you guys more talent please can i get a I.P and port scanner software from you which i can use in extracting I.P and ports from my Network orders cause it kinda of hard using the internet here please need you help on this.....Hope to hear from you soon....

Anonymous

October 04, 2017

Permalink

Could someone offer an alternative? An anonymous file transfer system? You never know the real-ip of your sender. You just pop in a filehash and it goes out and looks for it and downloads the file. Tor but for filetransfers. This sounds like the next big thing if someone can build it.