[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