[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Torrents real-time and dynamic blocklist
On Tue, Oct 06, 2015 at 11:47:40PM +0200, Aymeric Vitte wrote:
> Most of the study is now here:
> https://gist.github.com/Ayms/f2da9f860775ead2066e but some parts remain
> undisclosed.
> For those that don't like the 'paid' aspect of the blocklist, see the TF
> comments:
Historically, there is nothing new. There have been so many
attempts to interfere or obstruct filesharing. It seems a little more
orchestrated.
If one still uses a non-free BitTorrent client consider a change. If
you haven't updated your client, consider an update or change. There
is no need to run an antique client, because it was adfree that time.
Use a libre implemetation of the BitTorrent protocol that supports
DHT, PEX and LPD too. Enforce encryption on all bittorrent traffic,
if it doesn't strain your cpu too much.
If you use or used, binary only, dedicated torrent clients, that are
hardwired to popular sites, these recommendations are of no use to you.
We can't help you. Please consider your OS compromised and yourself
part of the problem (that is basically the result of our observation).
For curious folks:
Observe and analyze, by announcing arbitrary hashes to the DHT and
request said hashes with a client we can observe who claims to have either
clients (DHT/PEX/LPD) or data for your hashes - we have observed approx.
1500 nodes showing such behavior (with literally no resources and
restriction by location protocol and available bandwidth).
Impact, for Tor folks:
Given a Tor context, don't use BitTorrent and Tor, it is trivial to
deanonymize BitTorrent, so there is no benefit to that.
For people who run a BitTorrent-Tracker or a private community:
To Operators of HTTP-Trackers and Private-Tracker-Communites we recommended
blocking Tor-Exits on your HTTP-Trackers a long time ago. It is beneficial
to you and your often authenticated members. Keep your torrents and it's
seeders and leechers private (no DHT/PEX/LPD) and all is well.
Bonus points if one doesn't use static tracker addresses.
If you still use stuff like Gazelle, that works suprisingly well as a
countermeasure, allowing only authenticated announces and scrapes
to your tracker works well too. The real pros have also endorsement
schemes in place, which are awesome.
For folks using hidden services or proxies w/BitTorrent:
If you use magent-links from hidden services, or proxies keep in mind
that an adversary may offer you crafted hashes and is able to correlate that
hash very easy to your non-Tor/non-proxy endpoint. He may lure you into a
fake swarm and starve you. You are basically better off sticking to
well known sources that let users rate torrents or have some basic reputation
scheme in place. Same for downloading torrent-files, if an adversary
controls either hash or tracker it is trivial to deanonymize or deny you.
For folks who use BitTorrent (with or without vpn):
If your client gets starved, increase the number of client
connections per torrent. A side effect of what Ayms describes, is
that public torrents in the long tail (fewer seeders, less popular)
sometimes starve much easier if one moves or merges into a swarm
of fakes.
Popular Torrents with many seeders seem to have some or pretty good
resilience (that is what we can observe, ymmv). If your client is being
starved, stop it, delete/empty the DHT cache, works well in cases with
less/fewer trackers and without DHT/PEX/LPD.
If you are constantly being starved, try using magnet-links with
a trustworthy tracker (no DHT, no PEX, no LPD) or use magnet-links with
DHT (w/o PEX and w/o LPD) - if you seed many torrents disable PEX and
and LPD choose a trustworthy tracker along with DHT.
If you are still being constantly starved, don't rush, allow many
clients for less torrents (downloading one torrent after another
works in some cases better than trying to download many torrents at once).
It takes a little longer to gather clients, so no harm done this way.
Starving is limited to receiving lots of fake peers, that claim to have
80-100% data, but don't contribute, accept or download anything at all.
For a client-implmentation, this is easy to remedy:
Simply remove nonaccepting, noncontributing, nondownloadng peers and
refill free slots until we achieve at least 40%-70% of the clients
allocated bandwidth.
Another approach is to prefer responses that contain small amounts of peers
or simply discard responses with a configurable threshold of nodes.
In our observations, fakes basically vomit nodes and trustworthy peers
often present much smaller amounts of good resources.
Taking this into consideration, changes are quite minimal and noninvasive.
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk