Crate arti

source ·
Expand description

§arti

A minimal command line program for connecting to the Tor network

(If you want a more general Tor client library interface, use arti_client.)

This crate is the primary command-line interface for Arti, a project to implement Tor in Rust.

Currently Arti can run as a simple SOCKS proxy over the Tor network. It will listen on port 9150 by default, but you can override this in the configuration. You can direct programs to connect via that SOCKS port, and their connections will be anonymized via Tor. Note: you might not want to run a conventional web browser this way. Browsers leak much private information. To browse the web anonymously, we recommend using Tor Browser.

Arti is still advancing rapidly; we are adding features and eventually we hope it will be able to replace C Tor.

§Command-line interface

(This is not stable; future versions will break this.)

arti uses the clap crate for command-line argument parsing; run arti help to get it to print its documentation.

The only currently implemented subcommand is arti proxy; try arti help proxy for a list of options you can pass to it.

§Configuration

By default, arti looks for its configuration files in a platform-dependent location.

OSConfiguration File
Unix~/.config/arti/arti.toml
macOS~/Library/Application Support/org.torproject.arti/arti.toml
Windows\Users\<USERNAME>\AppData\Roaming\arti\arti.toml

The configuration file is TOML. For an example see arti-example-config.toml (a copy of which is in the source tree, and also in the Arti repository). That example config file documents the configuration options.

More detailed information about for the individual fields is available in the documentation for the Rust APIs ApplicationConfigBuilder and TorClientConfigBuilder.

§Using Arti with Tor Browser

It is possible to hook up Arti with Tor Browser.

To do so, we will launch arti independently from Tor Browser. Build arti with cargo build --release. After that launch it with some basic configuration parameters:

$ ./target/release/arti proxy -l debug -p 9150

This will ensure that arti sets its SOCKS port on 9150. Now we need to launch Tor Browser and instruct it to use that SOCKS port.

§Linux
$ TOR_SKIP_LAUNCH=1 TOR_SOCKS_PORT=9150 TOR_SKIP_CONTROLPORTTEST=1 ./start-tor-browser.desktop
§OS X
$ TOR_SKIP_LAUNCH=1 TOR_SOCKS_PORT=9150 TOR_SKIP_CONTROLPORTTEST=1 /path/to/Tor\ Browser/Contents/MacOS/firefox
§Windows

Create a shortcut with the Target set to:

C:\Windows\System32\cmd.exe /c "SET TOR_SKIP_LAUNCH=1&& SET TOR_SOCKS_PORT=9150&& SET TOR_SKIP_CONTROLPORTTEST=1&& START /D ^"C:\path\to\Tor Browser\Browser^" firefox.exe"

and Start in set to:

"C:\path\to\Tor Browser\Browser"

(You may need to adjust the actual path to wherever you have put your Tor Browser.)

The resulting Tor Browser should be using arti. Note that onion services and bridges won’t work (Arti doesn’t support them yet), and neither will any feature depending on Tor’s control-port protocol. Features not depending on the control-port such as the “New circuit for this site” button should work.

§Compile-time features

§Additive features

  • tokio (default): Use the tokio runtime library as our backend.

  • async-std: Use the async-std runtime library as our backend. This feature has no effect unless building with --no-default-features to disable tokio.

  • native-tls – Build with support for the native_tls TLS backend. (default)

  • journald – Build with support for logging to the journald logging backend (available as part of systemd.)

  • dns-proxy (default) – Build with support for proxying certain simple DNS queries over the Tor network.

  • harden (default) – Build with support for hardening the Arti process by disabling debugger attachment and other local memory-inspection vectors.

  • compression (default) – Build support for downloading compressed documents. Requires a C compiler.

  • bridge-client (default) – Build with support for bridges.

  • onion-service-client (default) – Build with support for connecting to onion services. Note that this is not yet as secure as C-Tor and shouldn’t be used for security-sensitive purposes.

  • onion-service-service – Build with support for running onion services. Note that this is not yet as secure as C-Tor and shouldn’t be used for security-sensitive purposes.

  • pt-client (default) – Build with support for pluggable transports.

  • full – Build with all features above, along with all stable additive features from other arti crates. (This does not include experimental features. It also does not include features that select a particular implementation to the exclusion of another, or those that set a build flag.)

  • rustls – build with the rustls TLS backend. This is not included in full, since it uses the ring crate, which uses the old (3BSD/SSLEay) OpenSSL license, which may introduce licensing compatibility issues.

  • static – Link with static versions of your system dependencies, including sqlite and/or openssl. (⚠ Warning ⚠: this feature will include a dependency on native-tls, even if you weren’t planning to use native-tls. If you only want to build with a static sqlite library, enable the static-sqlite feature. We’ll look for better solutions here in the future.)
  • static-sqlite – Link with a static version of sqlite.
  • static-native-tls – Link with a static version of native-tls. Enables native-tls.

§Cryptographic acceleration features

Libraries should not enable these by default, since they replace one implementation with another.

  • accel-sha1-asm – Accelerate cryptography by using an assembly implementation of SHA1, if one is available.
  • accel-openssl – Accelerate cryptography by using openssl as a backend.

§Experimental features

Note that the APIs enabled by these features are NOT covered by semantic versioning1 guarantees: we might break them or remove them between patch versions.

  • experimental-api – build with experimental, unstable API support. (Right now, most APIs in the arti crate are experimental, since this crate was originally written to run as a binary only.)
  • experimental – Build with all experimental features above, along with all experimental features from other arti crates.

§Limitations

There are many missing features. Among them: there’s no onion service support yet. There’s no anti-censorship support. You can’t be a relay. There isn’t any kind of proxy besides SOCKS.

See the repository README file for a more complete list of missing features.

§Library for building command-line client

This library crate contains code useful for making a command line program similar to arti. The API should not be considered stable.

License: MIT OR Apache-2.0


  1. Remember, semantic versioning is what makes various cargo features work reliably. To be explicit, if you want cargo update to only make correct changes, then you cannot enable these features. 

Re-exports§

Modules§

  • Configuration for the Arti command line application
  • Implement a simple DNS resolver that relay request over Tor.
  • Detect a “ctrl-c” notification or other reason to exit.
  • Configure tracing subscribers for Arti
  • Configure and implement onion service reverse-proxy feature.
  • Code to adjust process-related parameters.
  • Code to watch configuration files for any changes.
  • rpc 🔒 rpc
    Experimental RPC support.
  • Implement a simple SOCKS proxy that relays connections over Tor.

Macros§

  • Helper: Declare a series of modules as public if experimental_api is set, and as non-public otherwise.

Functions§

  • Create a runtime for Arti to use.
  • Return a (non-exhaustive) array of enabled Cargo features, for version printing purposes.
  • Main program, callable directly from a binary crate’s main
  • Inner function, to handle a set of CLI arguments and return a single Result<()> for convenient handling.
  • runexperimental-api
    Run the main loop of the proxy.

Type Aliases§