Initial support for a native Tor proxy

[cvengler]

This commit implements native support for using Tor (i.e. not using an intermediate SOCKS5 connection) into Halloy, using Arti, the official Tor implementation in Rust.

It does so, by adding a third proxy type named Tor, that co-exists between Socks5 and Http. In order to achieve that change, a breaking change in the proxy syntax was necessary, as a native Tor proxy obviously does not need a host nor a port.

With this change, configuring a proxy looks like this:

[proxy]
Http = { host = "127.0.0.1", port = 9150 }
Socks5 = { host = "127.0.0.1", port = 9150 }
Tor = {}

Besides this, it also wraps the internally used TcpStream data structure behind an IRCStream enum which implements the AsyncRead, AsyncWrite and Unpin traits and also wraps the DataStream used by Tor into it.

It remains an open question how good this implementation is. Personally, I am a bit afraid that it will leak at a few places, namely the checking for updates as well as the file transfer feature. Further evaluation is needed here.

Regarding the usefulness of the feature: Primarily I think that this is a neat addition by having a monolithic binary that uses Tor without depending on any other system resources. Besides this, it may even be possible to drop support for Socks5 and Http proxies entirely if this feature matures even further, as Tor is basically the only reason why modern applications still include support for Socks5 (and maybe Http). Alongside it would probably also make Halloy the first IRC client ever with native Tor support. 🙂

As a disclaimer: Professionally I am a part of the team responsible for developing Arti. This pull request is a personal project however which I develop entirely in my free time.

[cvengler]

It might also be a worthy discussion whether we should disallow plain-text IRC when having the Tor proxy defined, as using a plain-text protocol over Tor is obviously a huge compromise of privacy.

[casperstorm]

Thanks for this PR! Will take a look at this during this week <3

[tarkah]

Hey @cvengler thanks for this! Sorry for the delay on review. I've been wrapping up url previews but I'll look at digging into this after we get that merged. Just wanted to give you a heads up that we haven't forgotten about this.

[tarkah]

Code looks good! A couple minor nits. I'll want to test this and assess the dependency used prior to merging. Thanks for this!

[cvengler]

@tarkah is there any release deadline or something coming closer? I would prefer to address the issues you have mentioned next week due to time issues.

[casperstorm]

@cvengler

@tarkah is there any release deadline or something coming closer? I would prefer to address the issues you have mentioned next week due to time issues.

Should be fine, we already decided to wait for a few big features so we can use the extra testing period before we release.
We can easily wait for this one as well.

[cvengler]

I have adressed the issues and rebased it to the current main branch.

[tarkah]

@cvengler Thanks! I've updated the dependency to use rustls since that's what we use for our TLS connection and I added the feature to compile sqlite statically since otherwise the build isn't as portable & also fails to build on windows.

I tested w/ ergo testnet and the proxied connection works 👍

I noticed Libera doesn't allow these tor proxied connections and instead suggests connecting to their onion service. It seems we can do that w/ arti-client by enabling the onion-service-client feature, but I wasn't able to get this working w/ libera. Maybe we can eventually get that enabled / figured out.

I think this is good to go!

Edit: I can get .onion to work but I need to enable dangerously_accept_invalid_certs because the TLS cert I believe has a common name for palladium.libera.chat. This is obviously not great (no way to validate I'm not actually hitting a middle-man) esp since we're trying to use tor. The workaround libera recommends is using a socks proxy to the tor client which can map palladium.libera.chat to the onion address which allows TLS common name of our connection to match, but I don't see a way to configure arti client for that workaround.

[tarkah]

@casperstorm can you confirm testing on windows & mac to testnet.ergo.chat?

Edit: He confirmed w/ me both work & I tested linux. We also tested otfc which works and I can even connect to my soju instance via the tor proxy