February 17, 2015 at 17:58Why Bittorent via Tor is a Bad Idea
Good afternoon. I don’t remember how and when, but once I wondered: what if I use the Bittorrent client through the Tor network? After searching the Internet for information on this topic, I came across an interesting article “Bittorrent over Tor isn't a good idea” , published on torproject.org. I decided to translate "Habrahabr" for readers. Corrections are welcome.
There is a growing number of people asking us about the latest publication published by INRIA in France regarding Bittorent and personal information vulnerabilities. That article tries to explain these vulnerabilities and tell what they are.
There are three types of vulnerabilities (or three different vulnerabilities that are based on one another, if you will be more clear).
It occurs in people who configure their bittorrent client to work through a proxy when their traffic is proxied through Tor. These people hope that their ip address will be kept secret from someone who is watching the list of peers on the tracker.
The problem is that several popular bittorrent clients (the authors mostly call uTorrent and, I think, Vuze can also be attributed here) simply ignore the socks proxy settings.
The choice to ignore proxy settings is quite clear, since the modern tracker uses the UDP protocol for connections, and socks proxies, such as Tor, only support the TCP protocol - the developers of these applications have to choose between “let it work, even if the user configures the proxy, which can not be used "or" to make it mysteriously fall out of error, confusing the user. " As a result, bittorrent applications use security implementation scenarios different from those expected by the user of these applications.
The vulnerability is generally worse than the one described above: in some cases, uTorrent, BitSpirit and libTorrent just write their IP addresses directly in packets that they send to the tracker and / or other peers. Thor does his job: he "anonymously" sends your ip-address to the tracker or peer. No one knows where exactly you are sending your ip address from, like this. In all likelihood, this is not at all what was expected.
This was the first vulnerability.
Based on the first. It consists in the fact that a belligerent feast can accurately identify you. This is because the bittorrent protocol (at least as done in popular bittorrent applications) communicates via an arbitrary port and tells this arbitrary port to the tracker, as well as to other peers that contact it.
This is precisely the vulnerability: the tracker remembers your real address and port. So if your uTorrent client selects an arbitrary port 50344 as its port and then “anonymously” (via Tor) communicate with another peer that is on the tracker, the same peer can go to the tracker, see everyone who published the port in the tracker listing 50344 (with high probability it will be only you) and - voila - other peers know your real IP address. As a bonus, if the bittorrent feast communicates via an unencrypted communication channel, then the “exit relay” of the Torah that you have chosen will also be able to view traffic and carry out attacks on users.
This was the second type of vulnerability. In summary, they show various reasons why using Bittorent on top of Tor will not hide you.
So how do you fix this? There are several answers. The first is “don't run Bittorent on top of Tor.” We've been talking about this for years, because Tor does not withstand such a load. Perhaps these types of attacks will set the brains of people and they will listen. The second answer is that if you want your bittorrent client to be safe when using a proxy, you need to contact the developers of your application to correct the protocol and their applications. Tor will not protect you from leakage of personal information in this particular case.
The third type of vulnerability from their report is where it gets really interesting. For efficiency, Tor routes multiple application threads on top of each chain. This approach increases efficiency, since we do not need to waste time and have an overhead, making a new chain for each small picture. This increases anonymity, since every time you create a new path through the Tor network, you increase the likelihood that an attacker tracks this path. The disadvantage of this is that “exit relay” can create small snapshots of user profiles, including all flows coming out of a particular circuit.
If one of these flows identifies a user (for example, a bittorrent client), “exit relay” knows that the rest of these flows belong to this user too, thus, traffic from other applications is identified.
How to fix it? We use old tips: do not use Bittorent on top of the Tor network and / or force developers to fix their applications.
Is there a way in which we, as part of the Tor network, can reduce the risk of using insecure applications in Tor? We cannot solve the problem when you shoot your leg using Bittorent via Tor, but maybe we can still save the rest of your leg to you.
Addressing the problem to the Tor network infrastructure, each application can be made to use different circuits. On Linux and UNIX, we can probably hack something like this - there are ways to view the process ID of the application connecting to the socket.
I suppose this is harder on Windows. It also gets more complicated as many Tor applications use an intermediate http proxy, like Polipo or Privoxy. We would have to teach these intermediate proxies how to distribute data between different applications and then send this information through Tor.
Another option is to split streams by end ports. All flows that go to port 80 are in the circuit, and the flow for the other end port goes through another circuit.
We lurked this idea in the background for a rather long time, but everyone again rested in the fact that if the BT client asks us to make 50 flows to 50 different destination ports, the Tor client will try to make 50 different circuits. This is too much network load.
I think we could make a separation of behavior for the “80” and “not 80” ports, but I'm not sure how effective this is in practice, since there are many other ports (IM, SSH, etc.). In this case, they would also have to be processed by separate logic, and secondly, firewalls today more and more control the 80th port.
We should continue to think about these issues - even though we cannot control applications that can send personal information over the network. At the same time, I am glad that such studies are being released that allow you to look more broadly at possible vulnerabilities.
There is a growing number of people asking us about the latest publication published by INRIA in France regarding Bittorent and personal information vulnerabilities. That article tries to explain these vulnerabilities and tell what they are.
There are three types of vulnerabilities (or three different vulnerabilities that are based on one another, if you will be more clear).
First vulnerability
It occurs in people who configure their bittorrent client to work through a proxy when their traffic is proxied through Tor. These people hope that their ip address will be kept secret from someone who is watching the list of peers on the tracker.
The problem is that several popular bittorrent clients (the authors mostly call uTorrent and, I think, Vuze can also be attributed here) simply ignore the socks proxy settings.
The choice to ignore proxy settings is quite clear, since the modern tracker uses the UDP protocol for connections, and socks proxies, such as Tor, only support the TCP protocol - the developers of these applications have to choose between “let it work, even if the user configures the proxy, which can not be used "or" to make it mysteriously fall out of error, confusing the user. " As a result, bittorrent applications use security implementation scenarios different from those expected by the user of these applications.
The vulnerability is generally worse than the one described above: in some cases, uTorrent, BitSpirit and libTorrent just write their IP addresses directly in packets that they send to the tracker and / or other peers. Thor does his job: he "anonymously" sends your ip-address to the tracker or peer. No one knows where exactly you are sending your ip address from, like this. In all likelihood, this is not at all what was expected.
This was the first vulnerability.
Second vulnerability
Based on the first. It consists in the fact that a belligerent feast can accurately identify you. This is because the bittorrent protocol (at least as done in popular bittorrent applications) communicates via an arbitrary port and tells this arbitrary port to the tracker, as well as to other peers that contact it.
This is precisely the vulnerability: the tracker remembers your real address and port. So if your uTorrent client selects an arbitrary port 50344 as its port and then “anonymously” (via Tor) communicate with another peer that is on the tracker, the same peer can go to the tracker, see everyone who published the port in the tracker listing 50344 (with high probability it will be only you) and - voila - other peers know your real IP address. As a bonus, if the bittorrent feast communicates via an unencrypted communication channel, then the “exit relay” of the Torah that you have chosen will also be able to view traffic and carry out attacks on users.
This was the second type of vulnerability. In summary, they show various reasons why using Bittorent on top of Tor will not hide you.
So how do you fix this? There are several answers. The first is “don't run Bittorent on top of Tor.” We've been talking about this for years, because Tor does not withstand such a load. Perhaps these types of attacks will set the brains of people and they will listen. The second answer is that if you want your bittorrent client to be safe when using a proxy, you need to contact the developers of your application to correct the protocol and their applications. Tor will not protect you from leakage of personal information in this particular case.
Third type of vulnerability
The third type of vulnerability from their report is where it gets really interesting. For efficiency, Tor routes multiple application threads on top of each chain. This approach increases efficiency, since we do not need to waste time and have an overhead, making a new chain for each small picture. This increases anonymity, since every time you create a new path through the Tor network, you increase the likelihood that an attacker tracks this path. The disadvantage of this is that “exit relay” can create small snapshots of user profiles, including all flows coming out of a particular circuit.
If one of these flows identifies a user (for example, a bittorrent client), “exit relay” knows that the rest of these flows belong to this user too, thus, traffic from other applications is identified.
How to fix it? We use old tips: do not use Bittorent on top of the Tor network and / or force developers to fix their applications.
Is there a way in which we, as part of the Tor network, can reduce the risk of using insecure applications in Tor? We cannot solve the problem when you shoot your leg using Bittorent via Tor, but maybe we can still save the rest of your leg to you.
Addressing the problem to the Tor network infrastructure, each application can be made to use different circuits. On Linux and UNIX, we can probably hack something like this - there are ways to view the process ID of the application connecting to the socket.
I suppose this is harder on Windows. It also gets more complicated as many Tor applications use an intermediate http proxy, like Polipo or Privoxy. We would have to teach these intermediate proxies how to distribute data between different applications and then send this information through Tor.
Another option is to split streams by end ports. All flows that go to port 80 are in the circuit, and the flow for the other end port goes through another circuit.
We lurked this idea in the background for a rather long time, but everyone again rested in the fact that if the BT client asks us to make 50 flows to 50 different destination ports, the Tor client will try to make 50 different circuits. This is too much network load.
I think we could make a separation of behavior for the “80” and “not 80” ports, but I'm not sure how effective this is in practice, since there are many other ports (IM, SSH, etc.). In this case, they would also have to be processed by separate logic, and secondly, firewalls today more and more control the 80th port.
We should continue to think about these issues - even though we cannot control applications that can send personal information over the network. At the same time, I am glad that such studies are being released that allow you to look more broadly at possible vulnerabilities.