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

Tahoe-LAFS trac at tahoe-lafs.org
Thu Jun 30 21:42:42 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):

 Meejah and I were just working out what the tahoe.cfg syntax ought to be
 for controlling how Tor gets started (especially on the client side).
 Here's our current idea:

 `tahoe.cfg` acquires a `[tor]` section, with the following keys (and their
 defaults):

 * `enable = true`
 * `socks.port =` (empty)
 * `control.port =` (empty, but uses `unix:/var/run/tor/control` if
 `launch` is false)
 * `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 `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`)

 The lowest-priority settings are `control.port` and `launch`
 (`tor.executable` and `data.directory` are only used if `launch = true`).

 If `control.port` is set, and `launch` is false, the client will attempt
 to import `txtorcon` at startup, and if that is successful, installs a
 connection handler that:

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

 If `control.port` is empty and `launch` is false, the client uses
 `control.port = unix:/var/run/tor/control`. This will Just Work
 (opportunistically) for debian/fedora systems where the `tor` package has
 been installed and the user is a member of the appropriate unix system
 group (e.g. `debian-tor`).

 If `control.port` is empty and `launch` is true, the client uses
 `txtorcon` to start a new Tor process and allocate a suitable control
 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).

 If `control.port` is set and `launch` is true, `txtorcon` is asked to
 launch a Tor process as above, but the process is told to use
 `control.port` for it's control port, instead of allocating a new one.

 (we haven't decided what `data.directory` should default to: maybe a
 subdirectory of the Tahoe node directory? or maybe a new temp directory?)

 So, as far as use cases go:

 * Leaving everything set to the defaults will Just Work when the `tor`
 package is installed (and thus a Tor process is running), `txtorcon` is
 installed, and the user is in the right unix group
 * If you know you have a 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`.

 We'll need an additional flag to say "use Tor for TCP hints too", which is
 checked by the `anonymous = true` safety flag.

 On the server side, #2773 describes the CLI options for `tahoe create-
 node`. You'd provide `--location` and `--port` to use a pre-configured Tor
 hidden service (and would probably want to set `socks.port=` to point at
 the same Tor, for outbound connections, along with the "use Tor for TCP
 too" and `anonymous` flags). Or providing `--listen-tor` would tell `tahoe
 create-node` to get a Tor control port and create any necessary hidden-
 service keys, and write the `--location` and `--port` (and other how-to-
 start-Tor reminders) into tahoe.cfg. We might need CLI options for all of
 the `[tor]` controls listed above, since we'll have to start a Tor during
 `create-node`, before the user has a chance to edit their tahoe.cfg.

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


More information about the tahoe-lafs-trac-stream mailing list