[tahoe-lafs-trac-stream] [Tahoe-LAFS] #517: make tahoe Tor- and I2P-friendly

Wed Jul 6 19:39:14 UTC 2016

#517: make tahoe Tor- and I2P-friendly
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  warner
         Type:           |     Status:  new
  enhancement            |
     Priority:  minor    |  Milestone:  1.13.0
    Component:  code-    |    Version:  1.2.0
  network                |   Keywords:  privacy anonymity anti-censorship
   Resolution:           |  i2p tor-protocol usability
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 In talking with Leif and David today, we found out that they're
 discouraging the use of the `debian-tor` unix group (and of opening the
 Tor control port to non-admin users in general). They're concerned that it
 exposes to much authority to programs that don't really need it.

 Instead, they recommended that we just try SOCKS on both localhost port
 9050 (which is where a system Tor usually listens) and port 9150 (where
 the Tor Browser Bundle listens). Not coincidentally, this is exactly what
 `txtorcon.endpoints.TorClientEndpoint` does by default. We had previously
 worried that this would enable some other local user to camp out on these
 ports and intercept the connections (whereas they couldn't camp out on a
 unix socket that lives in /var/run without being root). But Leif pointed
 out that if somebody malicious is already running enough code on your box
 to listen on a local socket, then you've already lost (for example they
 could make their own outbound connection and leak your IP address) (note
 that Foolscap is still encrypting the connection and verifying the TLS
 cert, so this local attacker couldn't violate your confidentiality, but
 the one thing they *can* violate is your anonymity)

 So the new "Hopefully Just Works" default will be to use SOCKS on
 9050/9150, rather than to use a control port to discover a SOCKS port.
 That changes the above plan as follows:

 * `enable = true`
 * `socks.port =` (empty, but uses 9050/9150 if `control.port` is empty and
 `launch` is false)
 * `control.port =` (empty)
 * `launch = false`
 * `tor.executable =` (empty)
 * `data.directory =` (empty, or a subdir of tahoe's NODEDIR)

 The highest-priority setting is `enable`. If `enable` is false, all other
 settings are ignored, and nothing uses Tor.

 The next-highest priority is `socks.port`. If set, the client attempts to
 import `foolscap.handlers.socks` (which needs `txsocksx`) at startup, and
 if that is successful, it installs a Foolscap connection handler for
 `tor:` hints which route them to a SOCKS handler with the given port (note
 that `txtorcon` depends on `txsocksx`). This doesn't enable the use of
 multiple SOCKS port: the `socks.port` value is a twisted client endpoint
 descriptor, which only permits specifying a single SOCKS port. The
 9050/9150 fallback behavior is buried inside `TorClientEndpoint` and not
 exposed in the API (in fact, `TorClientEndpoint` doesn't accept an
 arbitrary endpoint for the SOCKS port: just a hostname and integer
 portnum, so we may need to define `socks.port` to be strictly
 `tcp:HOST:PORT`).

 (if `control.port` or `launch` are set too, we'll still launch a new Tor,
 but outbound Tor connections will use `socks.port` rather than anything
 involving the new Tor instance. However we might use the new Tor for
 *listening* purposes)

 If `socks.port` is not set, but `control.port` is empty and and `launch`
 is false, then we'll use `TorClientEndpoint`'s default behavior (use SOCKS
 on 9050, if that fails fall back to 9150).

 If `socks.port` is not set and `control.port` *is* set, then the client
 attempts to import `foolscap.handlers.tor` (which needs `txtorcon`), and
 if that is successful, installs a connection handler that:

 * uses `txtorcon` to connect to a Tor process via the control port
 * asks that Tor for its SOCKS port
 * routes the `tor:` hint through the SOCKS port

 If `launch` is true, the client uses `txtorcon` to start a new Tor
 process. If `control.port` is empty, it asks Tor to allocate a suitable
 control port, otherwise it tells Tor to use the specified port.
 Connections are made through the new Tor's SOCKS port as above.
 `tor.executable` can be used to specify the exact Tor binary to run (if
 empty, the default behavior is to search $PATH for `tor`).
 `data.directory=` can be used to provide a persistent datadir, which
 reduces startup time (from tens of seconds to a few seconds).

 || `enable` || `socks.port` || `control.port` || `launch` ||
 || false || * || * || * || no Tor ||
 || (true) || (empty) || (empty) || (false) || SOCKS on 9050/9150 ||
 || (true) || (empty) || (empty) || true || launch Tor, ask new Tor to
 allocate a control port, ask it for SOCKS port ||
 || (true) || (empty) || set || (false) || connect to pre-configured Tor on
 `control.port`, ask it for SOCKS port ||
 || (true) || (empty) || set || true || launch Tor, tell new Tor to use
 `control.port`, ask it for SOCKS port ||
 || (true) || HOST:PORT || (empty) || (false) || SOCKS on HOST:PORT ||
 || (true) || HOST:PORT || (empty) || true || SOCKS on HOST:PORT, launch
 Tor, ask new Tor to allocate a control port (for server) ||
 || (true) || HOST:PORT || set || (false) || SOCKS on HOST:PORT, connect to
 pre-configured Tor on `control.port` (for server) ||
 || (true) || HOST:PORT || set || true || SOCKS on HOST:PORT, launch Tor,
 tell new Tor to use `control.port` (for server) ||

 Note that all of this merely controls *how* we use Tor, not *when* we use
 it. By default (unless `enable = false`), Tor-based connection hints (for
 external servers, which we learn through the Introducer) will use Tor, as
 specified by this config. To make regular TCP hints use Tor too, see the
 `connections.yaml` "Connection Policy" in #2788. To make the local storage
 server listen on a Tor hidden service, we'll use something else (#2733).
 To make the connection to the introducer(s) use Tor, see something in
 #2788.

 So, as far as use cases go:

 * Leaving everything set to the defaults will Just Work (i.e. outbound
 `tor:` hints should connect) when:
  * the (system) `tor` package is installed (and thus a Tor process is
 running), or the Tor Browser Bundle is running
  * and (python) `txsocksx` is installed
 * If you know you have some other Tor running, set `socks.port=` to use
 it, and install at least `txsocksx`. Use this if you want more control
 over the Tor config.
 * If you have Tor installed but not running, use `launch = true`, and
 maybe `tor.executable=` if your Tor lives in an unusual place
 * If you have Tor/txtorcon installed, but for whatever reason (company
 policy?) do *not* want to use Tor, set `enable = false`.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:78>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage