anonymous friendly tahoe create-node/create-client

[dawuud]

subset of tasks from ​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:29

• change tahoe create-client to make a tahoe.cfg that doesn't listen on anything
• change "tahoe create-node" to require --listen and --location
• change "tahoe create-node" to handle the new Tor/I2P arguments, once we figure out how they should be spelled

[dawuud]

rough sketch of create-node cli here: ​https://github.com/david415/tahoe-lafs/tree/2490.anonymous-create-node-client.0

[user@tahoe-dev1 tahoe-lafs]$ ./bin/tahoe create-node -h

Usage: tahoe [global-options] create-node --listen=... --location=... [options] [NODEDIR]
(use 'tahoe --help' to view global options)

Options:
      --no-storage   Do not offer storage service to other nodes.
  -C, --basedir=     Specify which Tahoe base directory should be used. This has
                     the same effect as the global --node-directory option.
                     [default: '/home/user/.tahoe']
  -n, --nickname=    Specify the nickname for this node.
  -i, --introducer=  Specify the introducer FURL to use.
  -p, --webport=     Specify which TCP port to run the HTTP interface on. Use
                     'none' to disable. [default: tcp:3456:interface=127.0.0.1]
      --listen=      Specify a Twisted server endpoint descriptor string to be
                     used for our storage service listener.
      --location=    Specify a foolscap client connection hint string to
                     advertise as our storage service.
      --version      
      --help         Display this help and exit.

Create a full Tahoe-LAFS node (client+server).

/home/user/tahoe-lafs/support/bin/tahoe:  option -h not recognized

[user@tahoe-dev1 tahoe-lafs]$ 

[str4d]

--listen and --location docs should be at the top of the list if they are required (since the list has no defined ordering at present). They should probably be above the Options section to emphasize this, although that would likely require more backend changes to the config flag handling code.

I agree with ​daira's comments on the commit - the distinction between the two arguments is unclear. Examples for each would help, as well as something to clarify the difference between them, or connecting them to the corresponding tahoe.cfg variables. Again, maybe a section above "Options" would help. (This is stepping into man-page territory though.) Alternatively, maybe --location could be renamed --advertize (or --broadcast for something with consistent spelling) to better convey its meaning.

​warner's email mentioned additional arguments like --tor-only and --listen-on-tor. As I say in ticket:517#comment:33, I don't think these scale. Additionally, they duplicate information from --listen:

• --tor-only is equivalent to --listen=tor:foo.
• --listen-on-tor is equivalent to --listen=tcp:0,tor:foo (or --listen=tcp:0 --listen=tor:foo, it's unclear which will be used).

If --listen is to be required and will be the authoritative source of what-to-listen-on information, then additional arguments for configuring the type of setup are IMHO unnecessary.

For arguments specific to configuring Tor/I2P/etc, I think --tor-*, --i2p-* etc. make the most sense. For clients, they can easily be collected and passed straight to the plugins; for servers, the relevant server code can just use them directly. I can't think of any arguments that a user might want to pass to both Tor and I2P.

[warner]

Note: this ticket (#2490) is about --listen=tor/i2p and automatic server setup. #2773 is just about --port/--location/--hostname, the non-automatic setup (well, it's automatic for plain TCP listeners, if you use --hostname=, since it'll allocate a TCP port for you. But it won't do any automatic tor/i2p stuff).

#2773 may include --listen=tcp and/or --listen=none, but should not block on the async-ification of node creation, or on anything involving onion server creation. All those Tor/I2P pieces belong here in #2490.

#2773 will be in 1.12 . This ticket doesn't need to be, and I've currently scheduled it for 1.13, but if it gets done early, we'll change the target milestone.

[warner]

pulling this forward into 1.12, it's looking likely

[warner]

From today's devchat:

CLI arguments:

• tahoe create-node --listen=tor will try to connect to the default control port (9051, 9151, or unix:/var/run/tor/control)
  • if that fails, it will try to launch tor
  • if that fails, the command fails
• the way we connect to tor can be overridden:
  • tahoe create-node --listen=tor --tor-control-port=ENDPOINT
  • tahoe create-node --listen=tor --launch-tor (or maybe --tor-launch to make all tor-related arguments start with the same prefix?)
• whatever technique succeeded will be written into tahoe.cfg for runtime: [tor] control.port= or ([tor] launch= and [tor] tor.executable=)

Then create-node will:

• allocate an external "port" number (which goes into the hint, not a real TCP port)
• use txtorcon to allocate an "ephemeral" onion service
• retrieve the .onion address and private key
• write the private key into NODEDIR/private/tor-onion-private-key (TODO: is there a special file suffix we should use?)
• write the following into tahoe.cfg:
  • tub.location = tor:XYZ.onion:EXTPORT
  • tub.port = disabled
  • [tor] control.port= or launch= / tor.executable=
  • [tor] onion.privatekeyfile = NODEDIR/private/tor-onion-private-key
  • [tor] onion.external-port = EXTPORT
• both of the onion.* keys must be present, or neither, but not one without the other

And at runtime (tahoe start / Client.__init__), if the onion.* keys are present, we do the following:

• assert that control.port/launch/tor.executable explicitly point to a Tor, and forbid the use of default search-for-tor behavior
• use the control.port/etc keys to tell txtorcon how we want to access Tor
• read the private key material from the named file
• ep = txtorcon.TorHiddenServiceEndpoint(key-material)
• tub.listenOn(ep)

This means we're adding an additional listener (using whatever localhost or unix-domain socket that txtorcon picked for its endpoint), on top of whatever tcp.port= specified (which is usually none, leaving us with just the one onion listener). It also means we don't need to commit to the local socket at create-node time, nor mention it in the config file.

We record EXTPORT separately in the config file do avoid needing to parse tub.location for it at startup time, which might be confused by manually-added hints.

We have tahoe.cfg record the private key as a filename, rather than putting the (moderately-sized RSA) key bytes inline inside the config file. We're trying to stick to a policy of not adding new secrets to tahoe.cfg.

We forbid search-for-Tor in the onion case because we're going to be revealing the onion private key to whichever Tor we use, and I don't want to enable a different user (on the same box) from being able to camp out on 9150 and steal these keys. For the use-Tor-for-outbound case, this isn't as big a deal, because 1: Foolscap provides the crypto and authentication, and 2: such an attacker already knows your IP address. An attacker who camps out on 9150 early enough to catch your tahoe create-node interaction will be the one to provide you with the onion key in the first place. So I think the only threat is when you spoke with a real Tor at create-node time, but are talking to a spoofed Tor at start-node time, which is why I'm thinking that it's sufficient to just record *how* we contacted Tor the first time and do the same thing the second time.

TODO: currently tahoe.cfg must either have both tub.location and tub.port, or neither, so the tub.port = disabled above won't work. We need to decide on a fix for that.

[warner]

tahoe.cfg key names should probably be:

• [tor] onion.external_port =
• [tor] onion.private_key_file =

(since almost everything else is using underscores, not hyphens)

[warner]

I think we'll need a Foolscap tor-connection-handler that takes a "call me to get a Tor control protocol object" function. Then tahoe-side code will be responsible for creating one (based upon it's config: either control.port= to use an existing one, or launch=true to spin up a new one). The function will remember the protocol object it created, so it will use the same one for both local onion-service listening and outbound connection-handling.

I've opened ​foolscap#270 for this.

[dawuud]

I've written a TorProvider? class, here: ​https://github.com/david415/tahoe-lafs/tree/2490.tor_provider.0

However this is a work in progress because I've yet to actually put the TorProvider? class to use... that is for node listen and client connect code paths.

[warner]

I'm working on a branch which changes dawuud's TorProvider to provide three methods:

• allocate_onion() (run at create-node time, launches/connects-to Tor, creates onion service, listens long enough to get .onion address)
• get_tub_handler() (run at start-node time): immediately returns a Tub handler for the configured tor-launch/connect method
• get_tub_listener() (run at start-node time): immediately returns an Endpoint which the Tub should listen on

But now I'm wondering if we should commit to the local port at create-node time, and then write the matching listener endpoint spec into tub.port=. That would:

• not require any changes to the "tub.port and tub.location must either both be provided, or both disabled" requirement
• remove the magic "surprise extra listener" that doesn't appear in tub.port

It would also require that if we're doing an e.g. unix-domain listener, it gets put into tub.port as a string. It prevents the use of listeners that can't be represented as normal strings.

So I think we'd either need to pick a TCP/unix-domain listening port at allocate_onion() time, or use some fancy onion: server endpoint string with enough arguments to rebuild it at start-node time (hopefully putting the private key in a file, rather than in the endpoint string).

meejah: is txtorcon equipped to use pre-allocated keys/ports/onion-names? The TCPHiddenServiceEndpoint I'm looking at seems keen on generating all those values at construction time.

[warner]

New idea. There are two objects involved:

The first object is the "creator". It's actually just a function that returns a Deferred. It's invoked with the twisted.python.usage.Usage "options" object (which records the --listen=tor, --tor-launch, and other CLI argument flags). Its job is:

• parse the options, figure out if we need to launch tor, or if we've been given a control port
• if we're launch tor: allocate a control port (maybe unix-domain?), launch tor, wait for it to start, build the control-port endpoint
• if not: build the control-port endpoint
• use txtorcon to build the control protocol from the control-port endpoint
• allocate a local port (maybe unix-domain?), build an entry for tub.port
• pick an external port (doesn't matter)
• use the control protocol to allocate an onion address. retrieve the private key and the .onion hostname
• build an entry for tub.location from the .onion hostname and the external port
• write the private key to BASEDIR/private/tor-onion.privkey
• return tub.port, tub.location, and a dictionary of key/values for the [tor] section of tahoe.cfg
• (maybe shut down the launched tor now? and/or delete the ephemeral onion service when using a pre-existing tor control port? in general it won't matter, the tahoe create-node process will terminate a moment later, but it might make a difference for tests, and we need to make sure the pre-existing tor won't get confused if we temporarily start the onion during create-node and then start it a second time at runtime)

The second object is the "provider". It's created with a synchronous function that's called with the [tor] portion of tahoe.cfg (not sure of the best way to manage this, maybe just give it a reference to Node.get_config, or maybe the whole Node). Its job:

• first, it has a synchronous function which returns a Foolscap connection handler (or None if tor/txtorcon is unavailable or disabled). This is called at node startup, inside Node.init_connections(), and subsumes Node._make_tor_handler. It needs to parse the tahoe.cfg data and decide if we're launching or control-port-ing or socks-port-ing. For control.port and socks.port, it can return a foolscap-provided handler. For "launch", it needs to prepare to launch Tor (but *not* actually launch it yet, since we're still in synchronous startup land). It will use the new foolscap.connections.tor.control_endpoint_maker() to build a handler that will launch tor on demand, and it will share that launched Tor with the onion listener.
• second, it is a MultiService, and when startService happens, *if* tahoe.cfg says to start an onion listener, it needs to launch Tor (if not already launched by the connection handler, probably because the IntroducerClient FURL was processed), wait for it to start, establish the control protocol, then use the control protocol to start the onion service that was allocated by the creator.
• note that tub.port and tub.location are *not* controlled by the provider. These values are written into tahoe.cfg like the user-provided --port= and --location= values. That means we're allocating the local port at create-node time, and making Tor re-use that same local port at runtime.

The last part (starting the onion service) might require something unusual from txtorcon.

All the information about the onion service to be started will be recorded in tahoe.cfg. We'll document the keys it uses, but mark them as normally generated by create-node, and thus not really intended for user modification.

I'm sketching this out in my github 2490-tor branch, in case anyone wants to take a look.

[warner]

I'm making good progress on this in my 2490-tor branch: I think all the code is in place. I'm writing unit tests now, and will try to do real (manual) tests today.

[meejah]

warner: regarding handling pre-allocated keys, in 0.15.1 txtorcon only really handles "HiddenServiceDir"-based ones. Then, you pass hidden_service_dir= to any of .system_tor, .global_tor or .private_tor class-methods.

In the 1.0 branch, ephemeral services are supported, and TCPHiddenServiceEndpoint learns about ephemeral= and private_key= kwargs. See ​http://txtorcon.readthedocs.io/en/release-1.x/txtorcon-endpoints.html#txtorcon.TCPHiddenServiceEndpoint

You can also pass privateKey= in the endpoint strings.

There may still be changes to the details/terminology (and e.g. some things are called *Onion* because tor is trying to encourage use of "onion services" vs. "hidden services").

[meejah]

Okay, I made a PR to your branch fixing a few things, and have tested against a small grid with 2 tor-only servers (one launched, one on system tor) and everything appears to work. I haven't checked for "outside Tor" traffic leaks.

[meejah]

You'll need "master" branch from txtorcon for now, to get the Unix-socket ControlPort stuff to work properly.

[Brian Warner <warner@…>]

In 5a195e2/trunk:

Merge branch '2490-tor-2'

This adds --listen=tor to create-node and create-server, along with
.onion-address allocation at creation time, and onion-service
starting (launching or connecting to tor as necessary) as node startup
time.

closes ticket:2490
refs ticket:2773
refs ticket:1010
refs ticket:517