[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:  warner
         Type:           |     Status:  new
  enhancement            |  Milestone:  1.10.3
     Priority:  minor    |    Version:  1.2.0
    Component:  code-    |   Keywords:  privacy anonymity anti-censorship
  network                |  i2p tor-protocol usability
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by leif):

 Thanks, David! It looks like the foolscap side has a usable SOCKS plugin
 now, and the other plugins should be relatively easy to write!

 On the Tahoe side, though, I think that it would be better to avoid
 requiring that Tahoe explicitly support specific foolscap plugins and
 their options (even if it does learn about some of them later to implement
 the anonymity options discussed in #1010).

 I can think of at least 5 or 6 possible client-side plugins so far; TCP
 (default), SOCKS, Tor (socks w/ automatic port selection: SocksSocket
 (unix domain socket), 9050, 9150, or discovered-via-control-port), HTTP
 Proxy, I2P (HTTP proxy with automatic port selection?), and perhaps UNIX
 domain sockets or other twisted endpoints - and I would like to be able to
 use any combination of them simultaneously.

 I'm not sure if I'd prefer that Tahoe specify (via a tahoe.cfg option)
 which plugins to load or if they should be loaded automatically like
 Twisted plugins, but in either case I think that Tahoe shouldn't need
 plugin-specific code.

 As previously discussed, using options obtained from connection hints
 would be dangerous when we are receiving the hints from announcements on
 the network.  But, it is also a convenient way to communicate arbitrary
 options to the plugin when the hints are coming from a local config file.

 So, I think we *should* allow arbitary options in connection hint strings
 (eg, a proxy servers's host, port, username, password, etc) but we should
 sanitize the hints we receive from announcements: only the type, host, and
 port are ever used from announcements.

 I propose eventually allowing per-server plugin configuration using my and
 David's "introducerless" branch (based on warner's work) discussed in
 ticket #68 which I hope to have rebased to master soon.

 Without that branch merged, we can implement less flexible plugin support
 (without per-server local configuration overrides) by mapping
 announcements' connection hint types to known plugins as discussed
 previously in this ticket.  This would even allow connecting to mixed tcp,
 tor, and i2p networks IFF the servers are announcing new-style connection
 hints with types, as the tor and i2p plugins should work with only a host
 and port.

 To enable connecting to an existing all-tor or all-i2p grids where some
 servers have not been upgraded, and also to provide the mode that connects
 to both onion and non-onion addresses over tor, and also to provide the
 ability to use arbitary socks or HTTP proxies with whatever options are
 desired, I propose an "announcement_rewrite" option which can accept a
 value like {{{tor:%h:%p}}} or
 {{{socks5:%h:%p:socksserver=127.0.0.1:socksport=1080}}} or {{{i2p:%h}}} or
 even {{{foo:%h:%p:origtype=%t}}}.

 So, to recap:

 * Without the introducerless branch, it will be possible to (a) connect to
 heterogeneous grids of new servers, or (b) connect to  homogeneous grids
 of old-and-new servers and route all connections over a specific proxy.

 * With the introducerless branch, it is possible to disregard
 announcements and specify unique connection plugin options for specific
 servers. (While still having a rewrite rule to coerce newly-announced
 servers to some default proxy connection.)

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