Main menu

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.

Agreed. I use torrents on a regular basis, downloading everything save movies and music available in the United States with it. Never gotten caught, never used protection until very recently (protection being in the form of Peerblock).

I think that a lot of people are worrying too much over this and/or are using ISP's that are too freaking nosy for their own good.

I2P is a "darknet" that supports Torrents very well. Nowadays one can easily get speeds up to 50 Kilobytes/s in good swarms. There are 2 good trackers with lots of uploads per day. Anomos is an option too but the tracker traffic is still "in the open" from what I know and there does not seem any good tracker around.

There is a simple way to distinguish bittorrent tracker traffic from everything else.

It always sends a GET request with info_hash peer_id and port variables.
So tor could use this to identify it, its much better then using port 80, alot of trackers run on port 80 too so you cant use the port method to seperate trackers from websites.

If the tracker communication is SSL you cant see the request, but then the exit node cant read it either so no attack.

Everyone using BT over TOR should be using a firewall to make sure their torrent app can only communicate with tor.

"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."

Instead of separating ports by 80 and !=80 couldn't each port below 1024 get's own and >=1024 share one (since only root can open <1024 these are proper servers)? Obviously this doesn't help with the everything on port 80, but basically fixes the rest.

Safe from what?
The encryption on bittorent is good if your ISP is throttling bittorrent traffic. (It hides your use of bittorrent from them) Your ip address is still shared with the tracker and other users.
PeerGuardian blocks known lowlife ip addresses from connecting to you. (RIAA MPAA, etc.) But it will _never_ get them all. (not possible)

What do you need to be "safe" from anyway? (with bittorrent)
There are more important things to use Tor for.

In the US, where i live, almost no ISP will disconnect you for downloading copyrighted material. It's a major reason for having an internet connection in the first place.

Well, i ain't very sure about the headline!!! I think that it could be cool to have a new bit-torrent application made to work with TOR!!! You could even call it "TORrent"!!! It's very easy!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I think that something of missing in Tor is a robust publishing system to share documents, in a way to resist to the shut-down of a single server!!!! i think it to be the main flaw of WikiLeaks too!!! but also of Wikipedia, and every normal website: in the inner idea of a very well working Internet, there is the concept of decentralization!!!!!! but that concept has been almost forgotten!!!!
A super cool P2P system is another thing missing in TOR!!!!!!!
At this time, i don't think a P2P system internal to TOR to be very useful, but in the future it'll be very necessary!!!!!! So, you'd better to think about making one!!!!!!!!!!!!!!!!!!
I think that the bittorrent client for TOR should work only within the TOR network!!! You can have some "hidden services" (those addresses ending with ".onion") to work as HTTP-trackers!!!! So that all TORrent clients will have only tracker addresses to contact within the TOR network!!! All TORrent clients should be enabled as internal tor nodes, for the whole TOR network (to share the global network load too!!!) and every client should start one "hidden service" to accept incoming connections!!! Yeah, i think this could actually work!!!!! So, you can send your .onion address to the Tracker, and at the same time download the list of others peers sharing your same file!!!! You can then connect to the .onion hidden service of the others peers, and the others will do the same after having read your .onion address from the tracker!!!!!!
I'm sure, in this way, you'll have everything: a safe & secure bittorrent and a lot of bandwidth (because the lack of ExitNodes won't be important) to be used also for others purposes (so, when you are downloading/uploading something, but there is some free bandwidth, your node can be used also for the normal usage of TOR)!!!!!!!!!!!!!!!!!
You can have the torrent client to automatically set the upload and download speed limit to 1/4 of the bandwidth set to be used for the same upload and download channel of your node!!!!!! it's because i think that when you are using .onion addresses your connection pass through four nodes (or three?!!! i saw once they were four nodes!!!!!!!!!!!). In this way, you can avoid to have a congestion in the network!!! Because if you share a file at 1MB/sec... it'll take 1MB*4nodes=4MB/sec of bandwidth to handle the bits stream!!!!!! So you need to go 1/4 slower to don't break the balance!!!!!!
I've got this idea, after reading this blog entry and another one on torrentfreak i read yesterday!!!!
You should read this article too!!! It's on TF, and it's entitled «Child Pornography Is Great, Anti-Pirates Say» ( http://tinyurl.com/2cgp8xy ). the whole article can be summarized in these two quotes:
Johan Schlüter of the Danish Anti-Piracy Group enthusiastically said:

<br />

Child pornography is great. It is great because politicians understand child pornography. By playing that card, we can get them to act, and start blocking sites. And once they have done that, we can get them to start blocking file sharing sites.<br />

and Christian Engstrom (Pirate Party) heroically answered:

<br />

The big film and record companies want censorship of the net, and they are perfectly willing to cynically use child porn as an excuse to get it.<br />

Well, in don't want to enter in the discussion of child porn!!! (it's normal if pro-copyright organizations enjoy it!!!! they're usual to do the wrong things!!!!!!!!) But i want to very enter into the discussion of FILE SHARING and COPYRIGHT!!!!!! It isn't a fault of american people; but america's extremist capitalism and imperialism are evil, and they must be fought!!! this is what pirate parties are actually doing!!!! and the intellectual property is only one excuse to add filters, censorship systems, to the Internet!!! to allow politicians (read «puppets bribed by lobbyists»), to control the flow of information, and thus your life!!!!!!!! This is why i think that Tor, as it's a system made to be used against censorship and for political reasons, is perfect to be extended to be ready to be used as an alternative to the current centralized bit-torrent!!!!!!!!!!!!!!!!!!!!! I'm sure that the RIAA and the MPAA, won't be happy nor agree with me; but it's a their fault, they didn't bribed me yet!!!!!!!!!!!!! hahah!!!!!!!!!!!!!!!!!!!!!
~bee!!!!!!!!!!!!!!!

I want to implore the Tor people to _stop_ allowing this thing called bee from posting until it learns how to write, or maybe we should send it a keyboard without the exclamation point key, and even then it's words are a waste, it needs to grow up.

I find it odd that thing called bee didn't spam it's silly little program like it always does while claiming Tor-Browser Bundle is insecure. Maybe the thing called bee has learned part of it's lesson?

I think that's a very good post, bee. You make a lot of points that I agree with. I've been thinking for a while now that, you know, Tor and BitTorrent could almost be made for each over if they weren't so quick to dismiss each other (more so Tor because it rapes their exits). The Tor network looks pretty stagnant to me, not growing very fast, and as a consequence is quite vulnerable due to it's small size/capacity. Tor needs many more relays. A BitTORrent system could easily provide that as it would offer an incentive to everyday users to want to engage in the Tor network. I certainly would, if it was done right.

One comment from a Chinese Tor user in a recent blog post here said it quite well to me. To paraphrase it went something like: "How come they [GFW] can stop Tor, but file-sharing works fine?" I suggest the reason for that is that file-sharing 'technology' is HIGHLY popular, often with networks running containing 10's/100's of thousands, even millions of nodes. The total is certainly in the many millions out there. But what has Tor? Less than 2000 nodes at the moment?

BitTorrent shouldn't be dismissed so quickly if one's real aim is to create a network of strength, resilient to attacks from the controlling interests of a few.

But, about here is where things start to get political, I guess. This is where you're going to get a split in people's reaction to such an idea. It's highly likely that both government and business are NOT going to enjoy the thought of such a thing existing as it would threaten their interests (control, money, power, etc). If you really want to build a network that can survive, these such entities have to have their efforts DENIED. This could include Tor's masters, too (who pays the bills?).

bittorrent is not designed to be private nor anonymous. We've said for years to not use bittorrent over tor because it will screw the user in some way. Now we have an example of at least one of those ways.

This is secondary to the problem of any bulk file transfers over tor that cause pain for everyone in the network. We're addressing this problem with recent patches to the -alpha branch given to us by researchers at the University of Waterloo in Canada. This patch went in with 0.2.2.7-alpha, http://blog.torproject.org/blog/tor-0227-alpha-released. The goal here is to better weight circuits so busy ones (aka bulk file transfers) aren't dominating less busy circuits.

As for your conspiracy theory about Tor's masters. Tor's masters are the developers. We control the future of Tor. If someone wants to see certain features in Tor, they are welcome to discuss it with us. However, everything we do is released into the open, with source code, commit trails, and specifications.

There are other networks willing to take your bulk file transfer traffic, such as bitblinder, i2p, freenet, gnunet, etc. We haven't studied them in detail so we cannot make statements on their anonymity, safety, and functionality. However, they exist.

I know BitTorrent isn't anonymous. I know the technology, and I also know that those things the research here highlight are trivial fixes to overcome. Even now with the proper configuration of an appropriate client can these issues be overcome. 'bee' here suggests some rather interesting ideas here to fix those issues too, in my opinion. I wouldn't be so quick to dismiss them personally.

Your problem of users using BitTorrent over Tor is not going to go away short of you devising some technical cludge to try to strap it down, and to me that doesn't sound like the kind of freedom of information access network I had envisaged for the Tor network. You are, in effect, trying to stifle some aspect of users using the network to freely access and exchange information. The pain is that all this data is being pushed across the bridges, relays and, especially, exits, isn't it? Well if all those relays were 'BitTORrent' clients and nothing went into bridges or out the exits, then you'd have a great many more relays availiable for all Tor users, and considerably reduced load through bridges and exits. Lets see China attempt to block 100's of thousands/millions of relays run from domestic addresses...

By the way... I contribute relays myself. I'm quite aware that file-sharing over Tor is a problem. I totally support the idea of Tor, and appreciate the work that has gone into it. I will still criticise it though.

My bulk traffic? Who says *I* want to push bulk data over it? (the cheek, too, considering the bulk of the data I push here is RELAYING TOR USER TRAFFIC) If I wanted to do that I'd proxy µTorrent over the Tor socks interface, disable DHT/PEX/LPD, set bt.trans_disposition to "1", write in a fake address for the 'ip/hostname to report to tracker' field, force encryption, and run it on a separate Tor instance. There's nothing stopping me pushing that bulk data right now, phobos, just as there isn't for all those out there using BitTorrent+Tor right now that you're all complaining about.

Like I said, I think you're quick to dismiss the possibilities here. I suspect it's probably personal, actually, because you see BitTorrent/file-sharing as a threat to the health of your network. But maybe I'm wrong in that, in that you really have given it all a lot of thought and arrived at the conclusion that it wouldn't work for reasons xyz. I don't know that, though I'd be interested to hear why you think it wouldn't, or isn't a good idea.

You should know you're vulnerable right now. China/Iran has already demonstrated it's entirely possible to block all relays and the large majority of bridges, effectively denying those that want to use the Tor network for precisely what it was designed for. I see no reason they couldn't choose to mop it all up at any time if they wanted to. Personally I'd like to see them try that with 10,000,000 relays. :)

Why don't you use applications that _want_ to transfer BT and ones that can handle the traffic without reducing the experience for others who actually need the anonymity/security?

Are you trying to tell us that some jack off downloading porn so she/he can flap all day, or someone downloading movies instead of renting them should have the right to reduce the usability of the Tor network for those who need it to the Internet (e.g., HTTP/S) to avoid physical violence or imprisonment? If you answer yes I will tell you to grow up and realize your wish to use Tor for selfish reasons should not affect those who _need_ to use Tor for non-selfish reasons.

There are many options around that happily handle BT (and happen to have applications built around the protocol), namely I2P2, why not suggest everyone use that instead of focking with Tor and reducing the experience for the rest of us?

Are you incapable of reading the post I wrote? Why are you attempting to infer that I use Tor as it is now for BitTorrenting? Did you miss the part where I mentioned I run relays and am aware of the problem of BitTorrent (or heavy usage type in general)?

I'm not suggesting I have all the answers... that I know what will and will not work. What I am saying is that users will and do use Tor for bulk data exchange, and may possibly continue to do so in ever increasing numbers as a method of anonymising (to a sufficient degree) their file-sharing activities. Now you can try to fight that with clever technology in the binaries if you want, though I'm sceptical as to how effective that might be, and also where it may lead as Tor wanders off down the path to denying this, that, and the other, as it tries to fix its little problem. Why not have all the exits block the heavy sites you don't want people accessing, too? You could pop in code to block all of the file-sharing sites, video sites (most people only watch funny cat/cheesy pop/porn videos anyway), file hosts, ... and there you go, loads of bandwidth.

I think a problem with Tor is that there are not that many people willing to run systems for the purposes you mention. The Tor network has proven easy to block. It is probably also very easy for them to monitor who exactly is using it (if not what for). It seems to me that what's needed is a great deal more systems involved in the network. But what creates an incentive for people to want to do that? You talk of a problem here with people using the Tor network to file share, and hope for technological solutions to cure those ills, but I don't see any entertainment of the idea of creating a network that could satisfy those demands and potentially cure the whole problem of users file-sharing across the network, and create many more intermediate relays, and prevent easy blocking.

If such a network where to exist, comprising many 10/100/1000 thousands of nodes in the act of relaying 'bulk' data between themselves, then just what might that network provide in the form of bandwidth availiability for trivial http/s usage? Web browsing comparred to bulk data sharing is like a flea biting an elephant. The resources availiable could be huge for the purposes of providing a system for anonymous access to the Internet. Any user could fire up 'TOR' (whether as a dumb client or active 'file-sharing' relay), connect to any of a huge number of other similar relays, bounce through 3, and pop out an exit to the net. No government could block it if it was that popular. People would be happy to participate in the network if it satisfied their interests. Exits could enjoy far less loads placed upon them due to an internalised sharing system. Bridges may be entirely unnecessary.

Look how popular this blog post is. File-sharing is massively popular. Look at the size of those networks comparred to Tor. And the ambitions are not too disimilar either, I don't think. Both attempt to break down attempts to control access to, and the dissemination of, information through a system of decentralisation. Now times are changing a bit, new threats are emerging, and as a consequence popular file-sharing networks are being driven to look towards systems of anonymisation. One obvious way to achieve that is through proxying networks like Tor where data is relayed in and out of every participant leaving no indication as to what the data is and where it came from. The plausible deniability alone in acting within such a network could be enough to leave no indication to an outside observer as to whether a person is even engaged in such a thing as a 'Tor' network as the relays involved would no longer consist of a rather convenient handful of publically listed IP addresses. Users wanting to use a network like this to help prevent against "physical violence or imprisonment" would have a great deal more chance of avoiding so than to use the Tor network as it is now, assuming they're even able to if it hasn't already been blocked.

I think it's foolish to dismiss the potential. Maybe you're scared of what's necessarily required to create what you feel you want to create, because you know it could bring degrees of heat your cute politically correct ideologies might have trouble trying to defend when stood up to authority. A system that could really break systems, not pander to special interests. Freedom to publish. Freedom to access. Freedom to remain anonymous. Censorship resistant. A popularised, ubiquitous, system that cannot easily be controlled.

But hey, it's just an idea. Best of luck with your ambition of changing the way people use the Tor network. :)

I'm asking myself; why it's wrong to download a file through "Tor+BitTorrent", but it's ok if you download the same file via "Tor+HTTP"??????!!!!!!! I think that the application transfer protocol doesn't make any difference!!!!! Indeed, if you look into it, you'll find out that BitTorrent will improve the performance of the Tor network!!!!! If you download a file from one normal "hidden website", the max download speed you'll have is going to be the upload speed of that hidden service!!! and its upload bandwidth is shared among all the users downloading the same file and all the others files hosted at the same server!!!! With bittorrent, you'll share your upload bandwidth too!!! it's shared among all the "peers" and this will indeed improve the performances!!!!!! a single "tor hidden service" isn't able to host big files, because the Tor network isn't yet made like RAID disks are made: Tor isn't able to increase its performance exploiting the redundancy of files!!!!!!!! And, guess what BitTorrent is able to do?!!!!!! There isn't a single centralized HTTP server serving the file(s) using its upload bandwidth alone, but increasing the number of peers and seeders you'll also increase the bandwidth available to download the files!!!!!!! You won't download anymore from a single website, but from multiple sources!!!!!! bittorrent is also ok to automatically check if files were downloaded successfully (torrent clients check whenever the downloaded files hash values match against the hash keys memorized inside the `.torrent' file!!!!!!!!!!). I think that the main problem, always pointed out, about the Tor network load, is described in a very biased way!!!!!!!! What i wanted to say 1 second ago with my entry question is that if ten people will download a 600MB ISO image from one HTTP hidden service they won't cause "less network load" than the same ten people downloading the same 600MB ISO image using the "BitTORrent" system!!!!!!!!! Indeed, if you think about it, you'll find out that it's much more easy to ask to the ten people using bittorrent to share the Tor network load than asking to the ten HTTP-downloaders to do the same!!!!!! If you had a BitTORrent client made in the way i described in my first post here, you'll also have ten people running tor nodes, and downloading at a moderate speed to avoid the congestion of the network!!!!!!! Of course people could use their BitTORrent clients to leech files and bandwidth, but even in this pessimistic worst case scenario you'll have no more than the same effect of downloading files via the HTTP protocol without sharing anything!!!!!!!! so, in the same way as torrents are alive only if you `seed' them after downloading, also the network load will be balanced if people will begin to share it!!!!!! People using the «HTTP .onion protocol» alone (this is almost sure) won't share anything, and you'll have worse performance than in a "BitTORrent-ready network" and you'll put an heavier load on the Tor network because nobody will share neither the files (redundancy of files parts already downloaded) nor the bandwidth of the nodes!!!!!!!!! I really think that a "BitTORrent Bundle", made with a patched version of a BitTorrent-client made to work within the Tor Network, and made with the original idea to share ALSO the network load (and not just the files), to be a very good idea!!!!!!!!!!!!!!!!! Giving to all people the general idea that «Bittorrent over Tor isn't a good idea» is a bit deceiving!!!!!! BitTorrent is only a protocol!!!!!!!!!!!!! BitTORrent could be a great way to solve a lot of flaws related to TOR!!, allowing the Tor network to support big files, decentralizing the storage of hidden services (because the only hidden services you'll need, are very simple "Hidden BitTORrent Open-Trackers", similar to openbittorrent.com and websites indexing small ".torrent" files), increasing the performance at sharing big files (this is the typical improvement that BitTorrent gives also on the normal Internet!!!), increasing the number of nodes and the bandwidth for the whole Tor network (average case scenario: the BitTORrent-bandwidth is balanced 1:1!!! worst case scenario:-->), and yet nothing is gonna change about denial-of-service effects, because it's possible to overload the Tor Network even downloading DVDs ISO without BitTORrent!!!!!!!!! so, if you apply the Occam's razor principle to "Tor+Download(BitTorrent) = NetworkOverload", you'll find out that "BitTorrent" isn't required in that equation!!!!!!!! What about the bulk traffic and why are big files useful for the Tor Network?!!! Well, i don't know it!!!!!!!!!!!!!!!!!!!! Why were you asking it to me though?!!!!!!! Somebody could say that BitTorrent and Tor are both useless!!! Indeed, that's «right» for all the people that don't need them!!!! but it's very «wrong», for all the people using/needing them!!!!!! Also factorbee is useless for people using exclusively Windows, because it works only on Linux!!!!!!!!!!!!!!!!!!!!! So, it's a question i can't answer at, because it's something of personal, and i can't know what you're thinking and why you need Tor, BitTorrent or even BitTORrent!!!!!!! Finally, having a technology like BitTORrent cannot be wrong, if you don't need it, you won't use it!!! In the same way as, if you don't need Tor, you won't use it either!!!!!!!! But i'm sure that a lot of people will find it useful!!!! (mostly to laugh at the non-working copyright-justified censorship!!!!!!!!!) Ah, thinking about DVDs ISOs!!! this is funny!!! Linux systems cannot be "exported" to non-free countries (Cuba, Iran, Iraq, North Korea, Sudan, and Syria; actually the only places where LINUX+OpenSSL+Tor+... are useful for real), because the cryptographic software in Linux, which is regulated under US Export laws, cannot be redistributed there!!!!!! Anyway, there is Canada, south America, there is the Europe and good places in Asia; but if there weren't those free (for real) countries, used to share Linux ISOs, you could even had people with reasons to download LINUX!!!!!(the free and open source operating system!!!!!!) distros through TOR!!!!!!!!lol!!!!!!!!!! Now, this is off topic, but you've got to ask yourself, how such a brainless and useless restriction is possible in a so called "free country"!!!!!!!! The `US' is also the only problem i could think about BitTORrent!!!!!!!!!!!!!!!! Could the TorProject be liable for «helping the development of file sharing technologies»?!!!!!!!!!!!! Lets say communist software?????!!!! ha ha!!!!!!! this is funny too lol!!!!!!!!!!!!!!! though it's something of important to be aware of, because even websites like http://openbittorrent.com are now outlaw in the USA!!!!!!!(they could help copyright infringements!!!!) could it be something to be afraid of!!!!!!? In either case, i think that my BitTORrent idea is very nice, and it could work for real!!!!!!!!!!!!!!!!!! ~bee!!!!!!!!!!!

The problem in your logic is few(er) people download big files with Tor via. HTTP than do with Tor via. BitTorrent, just like how few(er) people download big files with naked HTTP than do with naked BitTorrent.

The nice thing about the instability of bee is he/she makes herself/himself look like such a douche bag that many people (I assume) read right past bee's posts, thus bee isn't even having the effect bee so obviously hopes to have.

I agree, why would anybody post anything more than 4 lines with out line breaks or paragraphs.. its hope less, I swear I tried, I couldn't get past line 4, now he's completely lost me.

Having said that I agree with this idea and its occurred to me as well, that bittorrent and tor can make things work very well if they can work cooperatively together. Where bittorrent traffic has to never exit the tor network, this will frustrate any attempts to eves drop on tor and make it much more resilient giving it protection of hiding in the crowd. And this is a huge crowd we are talking about about 16-28% of entire internet traffic, depending on who you are getting your stats from.

There was some work done in the last few years by a company making routers to identify and prioritize "data streams" as opposed to packets. They extolled the virtues of this new approach specifically with regards to improving video streaming and of easily throttling BT traffic - both without the need for deep packet inspection. Can't remember off hand who this was.

The concept hinged on creating a "stream" for every IP/Port destination, and optimized the allocation of packets into streams by not trying to create new streams if the TCP sequence number didn't indicate the start. I find this similar, conceptually, to your "separate streams per destination port" idea. What's most interesting was that throttling was introduced not as an overall rate limit, but as a limit to the total number of active streams.

If you go with the separate streams per destination port idea, skip the special casing, set an upper bound to the number of active circuits that can be created, and throw in a bit of circuit prioritization logic (default with high prioritization for circuits destined for 80/443, bonus priority for streams that are active), you'll probably end up hitting two birds with one stone - you'll not need create 50 different circuits, and you'll deter BT use of Tor.

Bittorrent is not just for illegal usages. Users of my linux distribution commonly download over tor using bittorrent. They will now be identified and possibly pushed to fake mirrors downloading infected versions of linux. We should update our instructions to block udp, force torrents over tcp over tor.

I do not have permission to say this by the company, so I will not name the linux distribution. However, I work for a commercial linux company.

Use Anomos! As of 0.9.2 there is a working client for Mac, Windows and Linux. It can even convert old torrent files to atorrents. It uses Tor-style onion layer encryption and the only weak point is the tracker must be trusted, however they run their own tracker as well, so one could expect a reasonable amount of privacy.

It's about freakin time someone spills this little bit of truth to all the ANOMOS fanBoi's out there, not to mention the ones in this thread.

The anonmos trackers could just as well be owned, operated or under orders from the entities you fear the most. ANOMOS is fail because of this.

The only real solution is standard bittorrent clients using strong anon networks.
Today that means I2P or Tor with OnionCat. Phantom is a strong future contender provided they interface with OnionCat.
I2P is sufficient today. Just fire it up, set your node to give whatever bandwidth you can give. The link your BT client to it and you're done.

There is no safe Bittorrent use with your home ip address, especially in the USA...

The best way to download illegal things its obviously just hacking some random chinese server, put rTorrent or cTorrent, download the torrent (maybe some seeding), download file from the hacked server using http or ftp or whatever u like, clean the logs, disappear for a while ;)

The problem with BT over Tor is not only anonymity issues, it's _bandwidth_ issues, it has been stated by Tor peopole many, many times that BT is a major reason Tor is so slow for HTTP/S, etc. Bittorrent _should not_ be used over Tor for the sake of bandwidth! People who really need Tor, e.g., Iranian and Chinese dissidents, 1st world citizens who wish to surf without being tracked, etc, _should not_ have to suffer extremely low latency because BT users want to download copyrighted movies and music and porn! Stop being so selfish!

If you want to use BT then use I2P2, they welcome BT traffic and have clients for such traffic. Stop using Tor for BT traffic!

BT over Tor may not be good for Tor itself but it isn't such a bad idea as the paper and the commentary try to portray it. In fact all of the discussed privacy leaks can be easily eliminated.

"The first attack"

No issue whatsoever, just enable proxy for both trackers and peers.

"The second attack"

It appears that arma got entirely confused here. Please read the paper again and perhaps quote some supporting paragraphs. This attack does not build on the first one, but simply exploits DHT correlations. Again, the solution is trivial - disable DHT.

"The third attack"

This one is not even interesting and there is no need to wait for developers to resolve the weakness. All you have to do is run a second instance of Tor on a different "SocksPort". Yes, it works on Windows too - flawlessly.

Those really paranoid should run BT/Tor always behind a NAT router, so BT must contact outside world to learn its public IP. Secondly, deploy an egress firewall and limit BT to localhost traffic only. On that note let's see what the authors of the paper think about it:

"Although we have not tested the behavior of those clients, we suspect that they use a service to determine their IP address as seen from the Internet. As they will contact that service through Tor, the service will report the IP address of an exit node."

No, there are no services involved, the clients learn their IPs from each other and exchange them on the extension protocol handshake.

Conclusion.

Just like Firefox needs Totbutton, so does Bittorrent require a few specific configuration settings.

BT over Tor may not be good for Tor itself but it isn't such a bad idea as the paper and the commentary try to portray it. In fact all of the discussed privacy leaks can be easily eliminated.

"The first attack"

No issue whatsoever, just enable proxy for both trackers and peers.

"The second attack"

It appears that arma got entirely confused here. Please read the paper again and perhaps quote some supporting paragraphs. This attack does not build on the first one, but simply exploits DHT correlations. Again, the solution is trivial - disable DHT.

"The third attack"

This one is not even interesting and there is no need to wait for developers to resolve the weakness. All you have to do is run a second instance of Tor on a different "SocksPort". Yes, it works on Windows too - flawlessly.

Those really paranoid should run BT/Tor always behind a NAT router, so BT must contact outside world to learn its public IP. Secondly, deploy an egress firewall and limit BT to localhost traffic only. On that note let's see what the authors of the paper think about it:

"Although we have not tested the behavior of those clients, we suspect that they use a service to determine their IP address as seen from the Internet. As they will contact that service through Tor, the service will report the IP address of an exit node."

No, there are no services involved, the clients learn their IPs from each other and exchange them on the extension protocol handshake.

Conclusion.

Just like Firefox needs Totbutton, so does Bittorrent require a few specific configuration settings.

Usenet is not the answer. Your Usenet provider must abide by the same laws that "force" Google and Yahoo to collect information about you for at least 90 days. Any Usenet posts sent unencrypted are either sniffed before they enter your computer or through trojans already planted in your PC. And, no, they don't need a warrant specifically for your activity. They can fish for data and then seize your computer anyway.

There is a TOR fork called BitBlinder specifically made for anonymous web and bittorrent traffic. Uses a "credits" system according to the amount of data you have relayed to others. Perhaps you should check it out: http://bitblinder.com/
Comes with its own anonymized clients, free open source.

The problem with BT over Tor is not only anonymity issues, it's _bandwidth_ issues, it has been stated by Tor peopole many, many times that BT is a major reason Tor is so slow for HTTP/S, etc. Bittorrent _should not_ be used over Tor for the sake of bandwidth! People who really need Tor, e.g., Iranian and Chinese dissidents, 1st world citizens who wish to surf without being tracked, etc, _should not_ have to suffer extremely low latency because BT users want to download copyrighted movies and music and porn! Stop being so selfish!

If you want to use BT then use I2P2, they welcome BT traffic and have clients for such traffic. Stop using Tor for BT traffic! sesli sohbet

Hi! There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.2-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series.

Changes in version 0.3.3.2-alpha - 2018-02-10

Major features (denial-of-service mitigation):

Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902.

Major bugfixes (netflow padding):

Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha.