Why Bittorent via Tor is a Bad Idea
Good day. I don’t remember how and when, but once I wondered: what if I used a Bittorrent client over 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 for readers "Habrahabra." Corrections are welcome.
The number of people who ask us about the latest publication published in INRIA in France regarding Bittorent and personal information vulnerabilities is growing. 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 that makes it clearer).
')
It occurs in people who configure their bittorien client to work through a proxy when their traffic is proxied through Tor. These people hope that their ip-address will be secret from someone who watches the list of peers on the tracker.
The problem is that several popular bittorent clients (the authors call mostly uTorrent and, I think, Vuze can also be included here) simply ignore the socks proxy settings.
The choice to ignore proxy settings is quite understandable, since the modern tracker uses the UDP protocol for connections, and socks proxy, 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 mystically fell with an error, confusing the user. " As a result, bittorent applications use security implementation scripts other than those expected by the user of these applications.
The vulnerability is generally worse than that described above: it turns out, in some cases, uTorrent, BitSpirit and libTorrent simply write their ip-addresses directly in the 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 feast. No one knows where exactly you are sending your ip-address, 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 the belligerent feast can accurately identify you. This happens because the bittorent protocol (at least as is done in popular bittorent applications) communicates through an arbitrary port and speaks this arbitrary port to the tracker, as well as to other peers that are in contact with it.
This is what constitutes a 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) communicates with another peer that is on the tracker, that same feast can go to the tracker, see everyone who published the port in the listing of the tracker 50344 (with a high probability it will be only you) and - voila - other peers know your real ip-address. As a bonus, if the bittorent peer communicates via an unencrypted communication channel, the “exit relay” of the Torah that you have chosen will also be able to view the traffic and launch attacks on users.
This was the second type of vulnerability. Summarizing, they show various reasons why using Bittorent over Tor won't hide you.
So how do you fix this? There are several answers. The first is “don't run Bittorent over Tor.” We have been talking about this for years, because Tor does not withstand such a load. Perhaps these types of attacks will set people's brains and they will listen. The second answer is that if you want your bittornt client to be safe when using a proxy, you need to contact the developers of your application so that they fix the protocol and their applications. Tor will not protect you from leaking personal information in this particular case.
The third type of vulnerability from their report is where it becomes really interesting. For efficiency, Tor directs multiple application streams on top of each chain. This approach increases efficiency, because we don’t have to spend time and have an overhead, making a new chain for each small picture. This increases anonymity, because every time you create a new path through the Tor network, you increase the likelihood that the attacker is tracking this path. The disadvantage of this is that the “exit relay” can create small snapshots of user profiles, including all streams leaving a particular circuit.
If one of these flows identifies a user (for example, a bittorent client), the "exit relay" knows that the rest of these flows belong to that user too, thus identifying traffic from other applications.
How to fix it? We use the old tips: do not use Bittorent over the Tor-network and / or force the developers to fix their applications.
Is there a way in which we, as part of the Tor network, can reduce the danger of using insecure applications in Tor? We cannot solve the problem when you shoot yourself a leg using Bittorent through Tor, but maybe we can still save you the rest of your leg.
By addressing a problem with the Tor network infrastructure, you can force each application to use a different chain. On Linux and UNIX, we may be able to hack something like this — there are ways to view the process ID of an application connecting to a socket.
I suppose it's harder in Windows. It also becomes more difficult, as many Tor applications use an intermediate http proxy, like Polipo or Privoxy. We would need to teach these intermediate proxies how to distribute data between different applications and then send this information through Thor.
Another option is to separate streams by end ports. All streams that go to port 80 are in the circuit, and the flow for the other end port goes through another circuit.
We had been lurking this idea in the background for quite a long time, but everyone again rested against the fact that if a BT client asked us to make 50 streams to 50 different ports of destination, the Tor client would try to make 50 different chains. This is too much load on the network.
I think we could introduce a separation of behavior for “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, too, would 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 us to look more widely at possible vulnerabilities.
The number of people who ask us about the latest publication published in INRIA in France regarding Bittorent and personal information vulnerabilities is growing. 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 that makes it clearer).
')
First vulnerability
It occurs in people who configure their bittorien client to work through a proxy when their traffic is proxied through Tor. These people hope that their ip-address will be secret from someone who watches the list of peers on the tracker.
The problem is that several popular bittorent clients (the authors call mostly uTorrent and, I think, Vuze can also be included here) simply ignore the socks proxy settings.
The choice to ignore proxy settings is quite understandable, since the modern tracker uses the UDP protocol for connections, and socks proxy, 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 mystically fell with an error, confusing the user. " As a result, bittorent applications use security implementation scripts other than those expected by the user of these applications.
The vulnerability is generally worse than that described above: it turns out, in some cases, uTorrent, BitSpirit and libTorrent simply write their ip-addresses directly in the 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 feast. No one knows where exactly you are sending your ip-address, 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 the belligerent feast can accurately identify you. This happens because the bittorent protocol (at least as is done in popular bittorent applications) communicates through an arbitrary port and speaks this arbitrary port to the tracker, as well as to other peers that are in contact with it.
This is what constitutes a 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) communicates with another peer that is on the tracker, that same feast can go to the tracker, see everyone who published the port in the listing of the tracker 50344 (with a high probability it will be only you) and - voila - other peers know your real ip-address. As a bonus, if the bittorent peer communicates via an unencrypted communication channel, the “exit relay” of the Torah that you have chosen will also be able to view the traffic and launch attacks on users.
This was the second type of vulnerability. Summarizing, they show various reasons why using Bittorent over Tor won't hide you.
So how do you fix this? There are several answers. The first is “don't run Bittorent over Tor.” We have been talking about this for years, because Tor does not withstand such a load. Perhaps these types of attacks will set people's brains and they will listen. The second answer is that if you want your bittornt client to be safe when using a proxy, you need to contact the developers of your application so that they fix the protocol and their applications. Tor will not protect you from leaking personal information in this particular case.
The third type of vulnerability
The third type of vulnerability from their report is where it becomes really interesting. For efficiency, Tor directs multiple application streams on top of each chain. This approach increases efficiency, because we don’t have to spend time and have an overhead, making a new chain for each small picture. This increases anonymity, because every time you create a new path through the Tor network, you increase the likelihood that the attacker is tracking this path. The disadvantage of this is that the “exit relay” can create small snapshots of user profiles, including all streams leaving a particular circuit.
If one of these flows identifies a user (for example, a bittorent client), the "exit relay" knows that the rest of these flows belong to that user too, thus identifying traffic from other applications.
How to fix it? We use the old tips: do not use Bittorent over the Tor-network and / or force the developers to fix their applications.
Is there a way in which we, as part of the Tor network, can reduce the danger of using insecure applications in Tor? We cannot solve the problem when you shoot yourself a leg using Bittorent through Tor, but maybe we can still save you the rest of your leg.
By addressing a problem with the Tor network infrastructure, you can force each application to use a different chain. On Linux and UNIX, we may be able to hack something like this — there are ways to view the process ID of an application connecting to a socket.
I suppose it's harder in Windows. It also becomes more difficult, as many Tor applications use an intermediate http proxy, like Polipo or Privoxy. We would need to teach these intermediate proxies how to distribute data between different applications and then send this information through Thor.
Another option is to separate streams by end ports. All streams that go to port 80 are in the circuit, and the flow for the other end port goes through another circuit.
We had been lurking this idea in the background for quite a long time, but everyone again rested against the fact that if a BT client asked us to make 50 streams to 50 different ports of destination, the Tor client would try to make 50 different chains. This is too much load on the network.
I think we could introduce a separation of behavior for “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, too, would 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 us to look more widely at possible vulnerabilities.
Source: https://habr.com/ru/post/250851/
All Articles