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

Tahoe-LAFS trac at tahoe-lafs.org
Tue Sep 22 18:39:31 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):

 Notes from today's meeting:

 * We'll land str4d's docs from PR-189, plus some changes to make it clear
 that this is not-yet-implemented work, and that `tub.location` needs to
 have actual pre-generated .onion addresses
 * We'll add a foolscap server plugin scheme, so
 `tub.registerServerPlugin("foo", plugin)` means that
 `tub.listenOn("foo:stuff")` will use `endpoint =
 plugin.make_endpoint("foo:stuff")`. If there's no plugin, the Tub will
 always fall back to Twisted's server-endpoint parser. This plugin will
 have the opportunity to add arguments to the endpoint being created.
 * We'll define tahoe.cfg keys for the `[connections]` section to control
 how a tor/i2p daemon is configured. Some potential values:
  * tor.launch-global
  * tor.control-port
  * tor.socks-port
  * tor.bin-path
  * i2p.sam-port
  * i2p.sam-host
  * i2p.bin-path
 * Tahoe startup has three phases
  * first phase: read `tub.location`, call `tub.setLocation()`, register
 FURLs
  * second phase: read `[connections]`, launch tor/i2p daemon if necessary,
 build and install the foolscap client and server plugins.
  * third phase: read `tub.port`, call `tub.listenOn()`, start the tub
 * `tub.port` can be `onion:privkey=$KEYMATERIAL`, or maybe
 privkey=`private/onion.key` (to keep secrets out of tahoe.cfg). During
 `tahoe create-node` we generate the key, store the private key into that
 file, store the public .onion address in `tub.location`. i2p private keys
 are roughly 900 base64 characters, we don't know how large tor keys are
 (only relevant if we store them directly in tahoe.cfg).

 We *might* do verification: parse `tub.location` to find the .onion
 address, read the private key, compute the associated public address, make
 sure they match. It's an open question as to how much damage the tahoe
 config directory can tolerate before we can't recover usefully. It'd be
 nice if a deleted private key could be regenerated, at least manually.
 OTOH tahoe can be much more agnostic about `tub.port` and `tub.location`
 if we don't do this verification.

 An externally-managed tor daemon will use `tub.port =
 tcp:12345:interface=127.0.0.1` and `tub.location = tor:foo.onion:80`. An
 automatically-managed tor daemon will use `tub.port = onion:privkey=..`
 and `tub.location = tor:foo.onion:80`, and inside `tub.listenOn()`, the
 txtorcon server endpoint parser will do some setup work (maybe launch tor,
 ask it to register the pre-configured onion service), then return a
 tcp/localhost endpoint for Foolscap to listen on.

 One concern that should be noted in the docs: even if you don't advertise
 a real IP address, your node might be listening on something which could
 be probed externally, for a confirmation attack. Like if you use `tub.port
 = tcp:12345` (''without'' the `interface=127.0.0.1`), and configure tor to
 forward foo.onion to that, then someone might scan the entire internet for
 ports that react the same way as foo.onion, and find yours. The attack is
 made harder by NAT, also by restricting the socket to the local interface,
 but the only real defense would be for tor/i2p to learn to send some kind
 of secret handshake at the beginning of the connection, and for the local
 TCP endpoint to check the handshake before passing the socket up to
 Foolscap.

 `txtorcon` has a useful "global" feature, where it remembers a process-
 wide singleton object that can be used for all connections. So if tahoe
 tells txtorcon to create this during startup phase 1, then it will be used
 for the server endpoint in phase 3 (without any extra work, and more
 importantly without additional config strings in `tub.port`). I2P doesn't
 have a corresponding feature, so the foolscap server plugin for i2p will
 need to add the extra arguments when building the server endpoint.

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


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