I installed Transmission on my Whonix workstation and tried to use it, but it never started downloading.
I don’t know for sure what the situation is with the I2P configuration
in Whonix, but I2P does have pre-configured torrent client which only
uses the I2P network. We are generally supportive of the use of I2P for
torrents in this way. I will investigate our DHT ID rotation strategies
as soon as I can, BiglyBT does offer this option and I think it’s
available in I2PSnark as well.
Patrick via Whonix Forum:
1 Like
the issue is likely that the trackers you are connecting to use the udp protocol. since tor is tcp protocol only, the torrent tracker will never receive a connection from you and, therefore, the download will not begin.
it used to be possible to work around this in whonix workstation with the openvpn client and a free openvpn based server using the tcp protocol. openvpn would be able to route the udp traffic over tor. basically, you’d start your torrent client and download the torrent while you were connected to the vpn. once you’ve connected to some seeds, you could pause the transfer, close openvpn, and then restart the transfer. it would work because the data transmission between you and the other seeding clients are using the tcp protocol and your client has a map of ip addresses to connect to for sharing the file.
there’s some issues with the whonix workstation firewall that is making this more complicated than in previous versions of whonix. i haven’t explored it enough to fix it. but, it’s doable.
3 Likes
@idk is that you? (@eyedeekay) Long time no see 
The I2P config we have tweaks some network settings including disabling UDP as a transport since Tor can’t carry it nayhow. However I think the torrent clients in I2P can contact seeding servers just fine in either case.
Disabling the workstation firewall should help until this is figured out.
1 Like
Never knew this being an issue.
Documented just now:
- Disable Whonix-Workstation ™ Firewall Until Reboot
- Permanently Disable Whonix-Workstation ™ Firewall
Obviously imperfect.
You could comment out that line
$iptables_cmd -A OUTPUT ! -p tcp -j REJECT --reject-with icmp-port-unreachable
from /usr/bin/whonix-workstation-firewall
sudoedit /usr/bin/whonix-workstation-firewall
Make that
#$iptables_cmd -A OUTPUT ! -p tcp -j REJECT --reject-with icmp-port-unreachable
(or delete the whole line)
This change will be lost after whonix-firewall upgrade.
I guess we’ll need a Whonix-Firewall option to allow outgoing UDP?
2 Likes
Sure is, finally figured out I could reply to all these e-mails lol.
I’ll be back around as much as I can.
If I’m understanding correctly, then I2P traffic is being transported
over Tor? If that is the case, then this would obviously still be a
torrents-over-Tor scenario with the attendant bandwidth issues, but one
with a reduced de-anonymization risk due to how our torrent client
operates. We are extremely unlikely to leak your IP address In-I2P
torrents should still work nonetheless in this scenario, whether it’s a
good idea to encourage it is another matter.
1 Like
Does this imply torrent over Whonix only has higher risks IP leaks? If so. No.
- Whonix ™ keeps your IP address hidden while BitTorrent and other file sharing/P2P programs are in use. Whonix ™ also protects against de-anonymization attacks outlined in the next section.
It was not my intention to imply that Whonix would not send the
bittorrent traffic over Tor, I was speaking solely in the context of our
application, not the wider Whonix environment in which it may reside. My
point was that application-layer type leaks, such as those in the 2010
paper, are accounted for by us in the case of I2PSnark.
Patrick via Whonix Forum:
2 Likes
commenting out the one line works fine. and if it’s done in live mode, it’s back to normal on reboot if one forgets to re-enable it.
it is somewhat hit or miss when needed. some trackers still accept tcp. but, those more focused on squeezing out as much revenue as possible moved to udp since it uses less bandwidth.
Yeah. The only thing to put them off is the performance. We recognize that we can’t stop people from torrenting so instead we document the most responsible way to go about it like disabling seeding. The other apps/usecases built into I2P also outweigh this potential misuse. Things like I2P-Bote are really unique.
1 Like
i’ve never been all that convinced that using torrents over tor was much more than a boogeyman. the pirate based site trackers all use udp. it’s not an easily recognizable workaround to get them functional. plus, most of the pirates i’ve been in contact with absolutely loathe the download speeds they get over tor if they can figure it out. the majority i’ve known have all gone the rather comical “paid vpn” route for protection. for the more patient that use tor for piracy, they’ve gotten a seedbox and cron jobbed dumps from the seedbox over tor.
it’s been pretty rare when i’ve needed to do a workaround to download a torrent due to udp. but, i’m not going for movies or wares. the trackers that host operating systems or other less legally problematic files don’t seem to care about accepting tcp. it appears to be mainly the multitude of piracy sites that blast people with ads that went udp only due to the traffic volume and their crappy business model.
particularly for perfectly legal and larger downloads, i’ve never subscribed to the notion that using torrents over tor is wrong, with the caveat that one does not seed. it can transform a download that would have taken an hour over tor into 10-15 minutes. i absolutely get it when it comes to movie/software pirates though.
1 Like
Apparently there is/was a legitimate anonymity threat from Tor-relay level adversaries when a user runs Bittorrent for an extended time.[1] The paper is old and padding may have significantly ameliorated this.
-
@Patrick Does an application’s exit choice stay static according to the destination’s IP staying the same or by connection lifespan? Trying to figure out if using a VPN for a torrent download’s lifespan limits the exit changing vs not using one.
-
@idk Do you know if I2P supports SOCKS proxies/ stream isolation easily?
The differences in security between user models is due primarily to two factors: (i) the amount of user activity and (ii) the destination addresses and ports. Creating many streams increases the number of opportunities to choose malicious relays, and thus the speed at which that occurs, while connecting to destinations that are disallowed by many exits increases the chance that a selected exit relay will be malicious.
EDIT: I edited my questions above because I was confusing IsolateDest behavior with stream isolation. Stream isolation limits all of an application’s traffic over the same three hop path while IsolateDestAddr would shard an apps traffic according to every IP it is contacting.
1 Like
I have no idea. That depends on the internals of torrent clients which I don’t know. Tor doesn’t close “dirty” circuits for long living connections such as IRC connections - because that would be disruptive (good visualization in IRC use case).
Btw for network load reasons: Tor Project wanted us to be careful when using IsolateDestAddr - certainly not for TransPort or torrent.
1 Like
MaxCircuitDirtiness NUM (Default: 10 minutes)
Tor will reuse the same circuit for new TCP streams for 10 minutes, as long as the circuit is working fine. (If the circuit fails, Tor will switch to a new circuit immediately.)
But note that a single TCP stream (e.g. a long IRC connection) will stay on the same circuit forever – we don’t rotate individual streams from one circuit to the next. Otherwise an adversary with a partial view of the network would be given many chances over time to link you to your destination, rather than just one chance.
Inferring based on the attack paper in my comment above and this info: recommending torrenting over VPN would greatly reduce the compromise of a user. A VPN would resemble a single long lived TCP stream where a torrent’s data (that would have opened many circuits on plain Tor) would be self contained. Performance would suck but this would provide more protection to the user and also the Exit from DMCA bullshit.
The paper also states that the BitTorrent model creates over 2.5times as many streams as the Typical model and over 50 times asmany as the IRC model. Seeding the file for days results in rapid compromise - yet another reason users should GTFO once done if not for consideration for others then for their own safety.
1 Like
An interesting attack. Please feel free to add this argument to Filesharing and Torrenting when you have a chance.
when i bring up the boogeyman, i wasn’t talking about the circuit dirtiness attack. it was the bandwidth sucking issue. length of time for a circuit for a large file download isn’t unique to torrents. a standard https download of a large file that will require more time than the length of the circuit faces the same issues.
1 Like