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

Tahoe-LAFS trac at tahoe-lafs.org
Tue Sep 15 18:31:34 UTC 2015


#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):

 Updates from today's meeting:

 * We established four phases:
 * Phase 1: By adding `[connections]` entries to tahoe.cfg (and installing
 `txsocksx` and/or `txi2p`), Tahoe clients will become capable of
 connecting to Tor/I2P servers. Additional `[connections]` entries will
 make it use Tor for normal servers too. `tub.location=` will make the
 client not advertise a listening port. `[node]anonymous = true` will
 enforce all this.
 * users can manually configure a Tor/I2P server to route inbound
 connections to a localhost listening port, then set
 `tub.port=tcp:12345:interface="127.0.0.1"` and
 `tub.location=tor:abc123.onion:80` (or I2P equivalent) to offer hidden
 storage service. These hidden servers will only be useful to clients who
 have made the other phase1 changes, to enable tor/i2p connections
 * Phase 2: `tub.port=` will make the client not even open a listening
 port. The logport/controlport will be moved off to a separate Tub (which
 defaults to listening on 127.0.0.1, but can be configured otherwise), so
 it will listen even though the main Tub does not. `[node]anonymous` might
 enforce this.
 * Phase 3: Add CLI arguments to `tahoe create-client` and `tahoe create-
 node` to add the right `[connections]` settings. Maybe `tor.socks-proxy=`?
 * Phase 4: Automate the listen-on-Tor/I2P server settings: add CLI
 arguments to `tahoe create-node` that mean "please do whatever is
 necessary to listen on Tor, and/or I2P, and/or disable normal TCP
 listening". This will allocate services (keys, descriptors, etc) during
 create-node, then write whatever decisions have been made into tahoe.cfg.
 The implementation will not impose any new runtime requirements on the
 post-reactor-startup phase of node startup (i.e. the onion address must be
 determined by `create-node` and written into tahoe.cfg, so it will be
 available when `tahoe run` first constructs the Node object).

 Also, str4d cleared up my confusion about how I2P connections are made.
 str4d is completely right, the Foolscap plugin for "i2p:" hints should
 just ask `txi2p` to create an Endpoint that does whatever I2P-specific
 handshaking is necessary, then turns into a regular TCP socket (which
 means it should handle .startTLS too). There's no need for HTTP CONNECT
 proxies or SOCKS proxies, `txi2p` has its own protocol for talking to the
 I2P daemon, and knows what needs to be done.

 `txi2p` will also be used in phase 4 to allocate the i2p address: `tahoe
 create-node` will create an I2P listening endpoint (storing key material
 into a NODEDIR/private/ directory), tell it to start listening, use
 `.getHost()` to learn the .i2p address, then shuts it all down. The
 address is used to write the correct connection hint into tahoe.cfg
 `tub.location`, and the key material directory is used to create a server
 endpoint string to write into `tub.port`. As long as the i2p server-
 endpoint-parser plugin is available at node startup, Foolscap will just
 ask Twisted to parse `tub.port`, and that should create the right i2p
 server endpoint.

 I mentioned that, instead, it'd also be ok (in fact it might be faster) to
 have `tahoe create-node` call a `txi2p` convenience function that
 allocates the address without actually creating an endpoint. The normal
 endpoint.listen() process creates a tunnel, which involves a lot of
 network traffic. At create-node time, all we really need to do is generate
 the keys: we can put off creating the real Endpoint until the node is
 launched.

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


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