DHT module should use the blocklist

[feross]

Currently, the DHT module has no notion of blocklists, so it will connect to any IP when doing lookups and announces.

The blocklist feature works correctly for determining whether to connect to a given peer.

[Ayms]

You can take a look at https://github.com/Ayms/torrent-live/blob/master/node_modules/bittorrent-dht/client.js where I am passing the blocklist to the DHT (look for 'blocked').

But this does involve some other modifications both in bittorrent-dht and torrent-stream that might not be compatible with webtorrent, let me know if I can help.

[feross]

@Ayms I think it would be pretty straightforward to just pass the list into the DHT constructor and use it to check IPs before connecting. PRs welcome :)

[Ayms]

OK, I forgot to mention that for my case the freerider option overrides the blocking, and that the blocklist is just for monitoring purposes in bittorrent-dht, I will pull something for this and mafintosh/torrent-stream#74 (unless you have other ideas @mafintosh @feross)

[feross]

Great news! It turns out that peers discovered via DHT are already being checked against the blocklist. This makes sense because we're calling the same _addPeer function that the tracker client calls when it discovers new peers. I added a test to confirm and preserve this behavior.

To use a blocklist, just specify it on the command line with --blocklist or pass the blocklist option to the WebTorrent constructor.

[feross]

So, we'll block bad peers discovered via the DHT, but what if a bad peer is a DHT node? Currently, we still talk to them (add them to the routing table, announce to them, etc.).

This would be easy to fix, but after reading this huge thread on the Transmission tracker, and this research paper on the problems caused by non-transitive connectivity in DHTs, I'm hesitant to use the blocklist on the DHT internals, lest we mess it up for everyone.

@fisch0920, @jhiesey, @mafintosh: If you have free time and care to dig into this issue (by reading the Transmission thread linked above), I'd value your opinion on this issue. My current thought is to not use the blocklist internally in the DHT. The truly paranoid can always disable the DHT (and I think many tutorials recommend this). But I could be convinced otherwise.

[Ayms]

You can take a look at torrent-live findspies and Monitoring and blocking the bittorrent monitoring spies but the study is undisclosed for now.

Talking about the DHT only, the dangerous spies are not those that you encounter in the DHT, because the messages sent do not prove anything (someone could have spoofed your ip), except maybe when you announce since the token mechanism and the check of your IP is more difficult to fake, this might depend on countries but as far as I know it's not enough to prove anything neither, the proof for the monitors is when you connect to them and start the bittorrent handshake, which is deemed by the spies to be enough while it's not since they usually don't answer correctly.

So, the dangerous spies are those returned as 'values' to get_peers request, they will be blocked by _addPeer

For PEX/client exchange we don't care I think, it's too easy to fake to prove anything.

So I would say that the blocklist is not necessary in the DHT but some might still worry and want it, although it's useless.

Beside blocklists, a good method to protect more privacy, detect, avoid and block the spies is the one described in the findspies link above, this makes the probability to be caught by a dangerous spy quasi null.

[feross]

@Ayms Thanks for your input.

I'm closing this issue now. To summarize: WebTorrent will never connect or handshake with blacklisted peers. However, it might send DHT traffic to blacklisted peers. FWIW, the Transmission client behaves the same way.