[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