Defining an Interface to Arti

Arti Development
7

Hi arti people!

At Tails, we looked at this forum topic in order to understand whether/how much this will be enough for our specific needs.

The short summary is: the plan seems very good, will probably account for 99% of our needs. Thanks for that!

Still, there are some things we’d like to check so that we can plan our work better.

Can we get rid of onion-grater?

Right now, Tails has something called onion-grater. It is a proxy which acts as an application-level firewall; tis goal is allowing specific applications to run specific commands on the Tor Control Port.

It seems arti will make onion-grater (and control filtering in general) mostly obsolete:

  • an application that uses the control mechanism will only get a limited “view” of internals (circuits, streams) that are associated to that application
  • there are unprivileged control sessions that seem like they mostly have access to the stream/circuit state of the associated application; a privileged session is needed to actually configure arti (e.g. set a bridge)

These are the main issues that onion-grater tries to solve, so yay. However, there are still some things that are unclear:

  • will unprivileged sessions still have access to some sensitive global state/configuration? E.g. getinfo address which leaks “the best guess at our external IP address”.
  • what about onioncircuits? It would ideally use an unprivileged control session so it cannot change the configuration, but it would need access to all circuit/stream state, which seems like something unprivileged sessions won’t have by design. Could there be something like a privileged session that is read-only?

Knowing this kind of details is important for us, because it impacts whether we’ll need to reimplement onion-grater for the new protocol, or just drop it altogether.

Tor Connection Assistant

Tails has its own way of configuring access to Tor (this includes, but not limited to, letting the user choose whether they want to use bridges or not).

That’s the main thing we want to migrate.

Restarting tor

Right now, we restart tor when connectivity changes. This is for two reasons:

  • Sometimes tor doesn’t connect automatically after changing the network. Restarting it is a workaround for that.
  • tor doesn’t reset it’s bootstrap status when the network is changed, which we use to display the progress to the user.
    But when we restart tor, we lose all the options we set via ControlPort (ie: Bridge). So we use SAVECONF before restart to persist those options.

So, we either need to remove the need for restarting, or a way to save the configuration.

Other needs

Here you can find the authoritative list of how Tor Connection Assistant uses the Control Port:

  • We need status/bootstrap-phase and status/circuit-established to display a progress bar / know which bootstrap phase tor is in. That’s probably already accounted for.
  • Currently we need to disable the sandbox (and restart tor) when the user chooses to use obfs4. This is because we want to enable Sandbox, but you can’t use Sandbox when you use obfs4. This might be very tor-specific, but still, we need some way to configure obfs4 bridges.
  • Network Configuration:
    • Bridge
    • Socks4Proxy
    • Socks5Proxy
    • HttpsProxy
    • Socks5ProxyUsername
    • Socks5ProxyPassword
    • HttpsProxyAuthenticator
  • Currently we start tor with DisableNetwork 1 to configure things via the control port before setting DisableNetwork 0 to make it connect. From arti we need some way to configure it before it makes connections. We understand this is the normal way of operating arti, but still, please keep this in mind :slight_smile:
  • We need to be able to configure the above network settings globally, for all sessions (i.e. if a user configures a bridge in our Tor Connection assistant, it should be used by all applications which use Tor).

Once there is an early version of arti available which includes this API, we would like to test it and could then tell you what’s missing for our needs.

Our +1 on the Summarized/Collated API Requirements

The previous chapter boils down to us adding our +1 to this:

  • network configuration; firewall, proxy, etc
  • using tor through PTs
  • bridge configuration
  • standalone PTs for anti-censorship

Onioncircuits

OnionCircuits is a Tails application that let you see Tor circuits.

Current onioncircuits needs are explained in onioncircuits.yml. Specifically:

  • circuit-status
  • stream-status
  • STREAM events
  • CIRC events

We understand that this might be part of all circuits details overview (currently required by Orbot only, so +1 for that!) and circuit information: IP, geolocation, etc

It would be good if we could have it, but Onioncircuits is not critical for Tails.