Various SOCKS proxy leaks

[shihiro09]

A few leaks I have noticed:

1. UDP trackers are still enabled when --socks-url is passed. There is no way to disable them without stripping them from magnet links and falling back to a trackers file filled with HTTP trackers only.
2. rqbit leaks the DNS resolution for HTTP trackers. This is because reqwest does local DNS resolution for socks5://. For proxied resolution, you must pass socks5h:// or socks4a://. Unfortunately, rqbit errors if passed a socks5h URI.
3. Likewise, rqbit (via reqwest) is leaking DNS resolution for downloaded torrent files and peer blocklists (for the same reason as the above issue).
4. This one is low severity, but reqwest currently has an experimental HTTP3 connector. After a quick audit of the reqwest code, it looks like there's no accounting for the proxy if HTTP3 is used (I could be wrong). In theory, an HTTPS tracker could be serving HTTP3 traffic (i.e. UDP traffic) which would not be proxied with reqwest in its current state. I'm not a very good rust developer so I don't know if http3 is enabled in rqbit's build of reqwest.
5. Minor: The DHT is still active when --socks-url is passed, but this is not as big of an issue as it can be disabled.

I'm not sure if the UDP tracker one was an intentional tradeoff: i.e. there aren't very many HTTP trackers present in magnet links. But if a user passes a proxy to an application, it's generally expected that all traffic will be tunneled through the proxy, even if it degrades usability (for example, firefox auto-disables HTTP3 and various WebRTC functionality if a SOCKS proxy is active).

Solutions:

1. Ignore UDP trackers if there is an active proxy (or perhaps add a flag --disable-udp-trackers).
2. Allow socks5h and socks4a for socks_url (or maybe even require them, lest users make a mistake).
3. Same as above.
4. Ensure reqwest is built without HTTP3 support. Never attempt to use HTTP3 on an HTTPS tracker.
5. Consider auto-disabling the DHT if a proxy is passed.

Temporary solutions (for anyone reading):

1. Strip all magnet links of all trackers. Fall back to a tracker file with HTTP trackers only.
2. Pre-resolve all domains in the trackers file to IP addresses (this may break things depending on the tracker -- the tracker might need a correct Host header for reverse proxying). Alternatively, write an LD_PRELOAD which returns no records for GAI (see below, this causes reqwest to silently pass the hostname to the proxy).
3. LD_PRELOAD is the only solution for this one.
4. Restricting oneself to HTTP trackers only (as opposed to HTTPS) is enough of a defense here.
5. Pass --disable-dht.

This LD_PRELOAD will cause reqwest to pass the real hostname to the proxy:

int getaddrinfo(const char *name, const char *service,
                const struct addrinfo *hints, struct addrinfo **res) {
  if (res != NULL)
    *res = NULL;
  return 0;
}

[shihiro09]

But if a user passes a proxy to an application, it's generally expected that all traffic will be tunneled through the proxy, even if it degrades usability (for example, firefox auto-disables HTTP3 and various WebRTC functionality if a SOCKS proxy is active).

I take back what I said. BT is unusable without the proper UDP trackers and DHT. 😢

Having played around with it more, I don't think all UDP should be disabled automatically when a proxy is active. Still, I think fixing a few things by allowing socks5h and adding --disable-udp-trackers is worthwhile.

[oooo-ps]

Related, I can't disable PEX without blocklisting, even that's not proxy-related: #469
I'm running rqbit from isolated container because of that - librqbit definitively is not about the privacy (at this moment).

[ikatson]

librqbit definitively is not about the privacy (at this moment).

It's certainly not, this was never the goal. All privacy related features are added later due to contributors either working on them or asking for them.

If you really want it to be constrained, just run it in a netns that is limited in where and how it can connect. E.g. a netns that goes through VPN, or netns that only connects to Yggdrasil etc.

[ikatson]

@shihiro09

A few leaks I have noticed

I think it's more of a documentation issue. All the "leaks" you mentioned are known - it was never stated anywhere that if you set "socks-url" then every single byte will go through it.

As you have figured out yourself, it's impossible to make it work like you want due to the nature of SOCKS proxy. It's not a VPN! It's just a TCP tunnel. So only TCP traffic can go through it, which in BT is limited to BT-TCP and HTTP trackers.

So most that can be done is README can be updated to indicate that SOCKS only proxies BT-TCP and HTTP tracker traffic, but everything else goes in plaintext. BT-TCP is the most important one though, as everything else is just metadata. So it's still useful!

The only "leak" I see here btw that should be patched - is if you set socks-url, you must disable tcp/utp listen (or rqbit should do this for you automatically).

[shihiro09]

As you have figured out yourself, it's impossible to make it work like you want due to the nature of SOCKS proxy. It's not a VPN! It's just a TCP tunnel.

SOCKS exposes a UDP tunnel (ASSOCIATE) in addition to the TCP tunnel (CONNECT). In particular, wireproxy supports ASSOCIATE via go-socks5. I haven't seen many clients that support it, but the functionality is certainly present in various pieces of software.

The only "leak" I see here btw that should be patched - is if you set socks-url, you must disable tcp/utp listen (or rqbit should do this for you automatically).

Not allowing for socks5h is a bug. Out of everything listed, it's probably the simplest to fix.

It's certainly not, this was never the goal. All privacy related features are added later due to contributors either working on them or asking for them.

If you're opposed to SOCKS as a privacy feature, it's not clear to me why it's present in the codebase in the first place. What is the intended use case? If this is your stance, it's probably best to remove it altogether. People will get the wrong idea otherwise.

[ikatson]

If you're opposed to SOCKS as a privacy feature, it's not clear to me why it's present in the codebase in the first place

That comment was about the design goals of rqbit as a whole, not about the proxy feature. I don't market rqbit as "privacy centric torrent client" or say anywhere that the socks feature will protect every byte on the network.

What is the intended use case?

It protects BT traffic. The actual data of the torrent, which is the most sensitive part.

I'm not opposed to adding the things you ask though, don't get me wrong! I just look at them as missing features vs high severity bugs - and that's a reflection of the "rqbit design goals".

That's why updating README and the text in --help would be the first thing to do, not DNS resolution over proxy.