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

[Tahoe-LAFS]

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

Comment (by warner):

 From today's meeting, folks seemed comfortable with the following
 tahoe.cfg syntax to configure the client side:

 {{{
 [node]
 anonymous = true

 [connections]
 tor.socks-proxy = HOST:PORT
 tor.(otherstuff)=??

 tcp.socks-proxy = HOST:PORT

 i2p.connect-proxy = URL
 }}}

 The presence of `[connections]tor.socks-proxy=` will cause Tahoe to
 install a Foolscap connection plugin that handles FURL connection-hints
 which begin with `tor:` by sending them to the given SOCKS5 proxy. The
 presence of `tcp.socks-proxy=` makes it remove all plugins and then
 install a similar plugin that handles `tcp:` connection hints. And the i2p
 plugin is similar, but uses an HTTP "CONNECT" proxy instead of SOCKS,
 since apparently that's how the I2P client does it.

 If `[node]anonymous` is true, we'll enforce two things, as per #1010:

 * `[node]tub.location` does not contain "AUTO"
 * `[connections]tcp.socks-proxy` is set

 (We could make this stronger: require tub.location to only contain `tor:`
 or `i2p:` hints, require the hostnames in tub.location to end in `.onion`
 or `.i2p`, and maybe require the tcp.socks-proxy to point at 127.0.0.1
 instead of some potentially-exterior host. But for now I think these two
 are sufficient)

 We'd like to allow tub.location to be empty. We need to make sure Foolscap
 can handle that (on both server and client sides), and then eventually we
 want `tahoe create-client` to leave tub.location and tub.port (meaning
 "don't listen at all").

 For this first step, we'll just do the client side, and only in tahoe.cfg.
 This should be enough to:

 * use a previously-configured (and running) Tor/I2P client
 * manually configure Tor/I2P to forward inbound connections to a tahoe
 server
 * advertise `tor:` or `i2p:` connection hints (via `tub.listen`)
 * utilize `tor:` and `i2p:` connection hints from others

 In a second phase, we'll use the `tor.(otherstuff)` fields (which might
 not want to live in `[connections]`, I dunno) to launch a Tor daemon at
 node startup (maybe using a pre-configured base directory under
 `~/.tahoe/`, maybe with a config file that's built from the tahoe.cfg
 options). Then in the third phase, we make changes to the `tahoe create-
 client`/`tahoe create-node` arguments, to configure that Tor daemon (and
 allocate onion servers, etc).

 But for now, I think these tahoe.cfg changes will enable manual Tor/I2P
 setup without needing to figure out the `--tor-only` / `--listen-on-tor` /
 etc arguments just yet.

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