[tor-dev] The future of Tor client software?

Mailing Lists tor-dev
1

Hi tor-dev,

In the past, there were generally two options for supporting Tor in an application.

1. Require the user to install the tor daemon (ex: apt install tor, Tor Expert Bundle, etc) and configure the application to use its SOCKS proxy.

2. Bundle the tor binary with the application (ex: Tor Browser) and have the application use the app-specific tor process as the SOCKS proxy.

I'm not clear on how this changes in an Arti world. Arti currently has a Rust Tor client library for applications, and a CLI application to run a SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd service) for clients like with the current tor package? In a future where Arti replaces the Tor client and relay code, or when Arti is recommended for all client-related use cases, will there continue to be a Tor daemon with client support?

I see various possibilities for developers who wish to use Tor in their applications:

1. Require users to install/run a Tor system service (whether it's tor or arti).
   - pros:
     - shared resource usage (mainly circuits) between applications
     - familiar to experienced Tor users
   - cons:
     - requires an additional installation step for users
     - easy to break by users (for example changing their SOCKS port)
     - can't modify the Tor client's configuration (ex: can't enable DNSPort, change SocksPort flags, etc)

2. Bundle tor/arti binaries with the application.
   - pros:
     - simple for users (no extra configuration needed)
     - more control over the Tor client's configuration
   - cons:
     - can be brittle (ex: an application is already using port 9150)
     - resources/circuits are not shared between applications
     - more work for the application developer (needs to build and bundle the tor binary)
     - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date

3. Use the arti-client library in the application.
   - pros:
     - simple for users (no extra configuration needed)
     - more control over the Tor client's configuration
     - easy to use for rust application developers
   - cons:
     - likely difficult to use in non-rust applications (writing an ffi for the async arti-client API doesn't sound fun)
     - resources/circuits are not shared between applications
     - (presumably) slower start-up times since there is no pre-existing pool of pending circuits, and descriptors may be out-of-date

4. Require users to install/run a Tor transparent proxy or TUN adapter.
   - pros:
     - should probably "just work" (ex: no SOCKS port that can change or need to be configured)
   - cons:
     - requires an additional installation step for users
     - can't modify the Tor client's configuration
     - users likely don't want to proxy all their traffic through Tor
     - slowdowns due to latency from DNS lookups (RELAY_RESOLVE instead of sending the hostname in the RELAY_BEGIN)
     - no stream isolation support (maybe?)

Are there any guidelines for what method should be used under different circumstances? For example using the arti-client library in an email client seems reasonable since a longer startup time while it builds circuits isn't a big deal. But it might be a bad idea to use the arti-client library in cURL, which would need to build circuits each time curl is invoked in a shell script.

- Steve

···

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

2

Hi, Steven!

We’re looking at a timeline more or less like this:

In the short term, both implementations will coexist.

In the medium term, we will deprecate the C Tor client implementation. This will not be until some time after Arti is a complete tor client with support for onion services, with a *complete *embedding/FFI/RPC solution.

In the long term, we intend that Arti will replace the C tor implementation completely. This means we’ll have to implement relays and directory authorities with Arti. (We won’t be starting this for a year at least, and it will probably take some while to achieve.)[1]

We intend that Arti will be usable in multiple deployment environments, including as a daemon that they talk to over an RPC-like protocol (analogous to the current control port) and as an embedded library. We want applications written in most any reasonable language to be able to use Arti, and to be more or less agnostic about whether they’re doing it with an in-process library or over an RPC channel. Of course, this involves a lot of API work, and there will be a lot of design and prototyping to do. Our plan is to have this part ready for experimental use this year.

Right now, we’re starting a working group of interested people to talk about getting all of these APIs right. You can see an initial thread at https://forum.torproject.org/t/defining-an-interface-to-arti/6432 with links to different design sketches; pretty soon we hope that there will be a new subforum to work on the issue and discuss more. I’ll follow up with a link once there is (unless somebody else does).

[1] (A note for the anxious: We don’t plan to stop C Tor support immediately when any of these phases is done, but we do plan to do it after a reasonable time for migration and making sure that the migration issues are solved. We haven’t committed to a schedule for this. Whatever we do decide on will definitely be annoyingly long from some points of view, and annoyingly short from others.)

best wishes,

···

On Mon, Feb 13, 2023 at 4:20 AM Steven Engler <opara@sengler.ca> wrote:

Hi tor-dev,

In the past, there were generally two options for supporting Tor in an
application.

  1. Require the user to install the tor daemon (ex: apt install tor, Tor
    Expert Bundle, etc) and configure the application to use its SOCKS proxy.

  2. Bundle the tor binary with the application (ex: Tor Browser) and have
    the application use the app-specific tor process as the SOCKS proxy.

I’m not clear on how this changes in an Arti world. Arti currently has a
Rust Tor client library for applications, and a CLI application to run a
SOCKS proxy. Is there any plan to offer an Arti daemon (ex: a systemd
service) for clients like with the current tor package? In a future
where Arti replaces the Tor client and relay code, or when Arti is
recommended for all client-related use cases, will there continue to be
a Tor daemon with client support?

–

Nick

3

The forum section is at : https://forum.torproject.org/c/arti-development/30

···

On Mon, Feb 13, 2023 at 9:40 AM Nick Mathewson <nickm@torproject.org> wrote:

Right now, we’re starting a working group of interested people to talk about getting all of these APIs right. You can see an initial thread at https://forum.torproject.org/t/defining-an-interface-to-arti/6432 with links to different design sketches; pretty soon we hope that there will be a new subforum to work on the issue and discuss more. I’ll follow up with a link once there is (unless somebody else does).

4

Thanks Nick!

We intend that Arti will be usable in multiple deployment environments, including as a daemon that they talk to over an RPC-like protocol (analogous to the current control port) and as an embedded library. We want applications written in most any reasonable language to be able to use Arti, and to be more or less agnostic about whether they're doing it with an in-process library or over an RPC channel. Of course, this involves a lot of API work, and there will be a lot of design and prototyping to do. Our plan is to have this part ready for experimental use this year.

Ah okay, this sounds interesting. Having an agnostic interface seems nice for applications. If I'm understanding correctly, this would make it easy to included an embedded Tor client which is used by default, while optionally allowing users to configure it to use a Tor client daemon instead, without requiring many code changes in the application.

Right now, we're starting a working group of interested people to talk about getting all of these APIs right. You can see an initial thread at Defining an Interface to Arti with links to different design sketches; pretty soon we hope that there will be a new subforum to work on the issue and discuss more. I'll follow up with a link once there is (unless somebody else does).

The forum section is at : Arti Development - Tor Project Forum

Thanks for the links, I'll keep an eye on them.

- Steve

···

On 2023-02-13 09:40, Nick Mathewson wrote:
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev