[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 str4d):

 Replying to [comment:34 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.

 That is how I2P does it ''now'', using duck's HTTP proxy patch. But that
 was only because it was the simplest patch; as I believe was raised in
 that ticket's thread, Tahoe / Foolscap isn't really an HTTP protocol. And
 I2P could just as easily use a SOCKS proxy. But this is only useful for
 clients.

 This line of discussion raises the question: for this initial client-only
 phase, is the intention to just use plain SOCKS (via `txsocksx`) and HTTP
 (via something like duck's I2P patch) proxies, rather than `txtorcon` and
 `txi2p`?

 If `txi2p` is going to be used, then the option needs to be `i2p.sam-
 api=`. I assume that `tor.socks-proxy` and `i2p.sam-api` would be allowed
 to be empty, which would mean "use the default value".

 >
 > 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

 Should this be "one of `tcp.socks-proxy`, `tor.socks-proxy`, or `i2p.sam-
 api`"?

 >
 > (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`)

 I assume that `tub.location` is meant, which would be empty for clients.
 And while only the SOCKS/HTTP proxy side is implemented, then with
 `[node]anonymous = True`, `tub.listen` would be empty because there would
 be no way to create a Tor HS or I2P Destination.

 > * 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.

 +1.

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