Fwd: removing IP-address autodetection, Tor integration

[David Stainton]

Dear Meejah,

I appreciate all the work you've put into the txtorcon project. I am
very excited about this Tahoe-LAFS integration.

> Cool, tahoe via Tor :)

free NAT penetration via Tor onions means Tahoe-LAFS will be *much*
more useable... and we can possibly change our thinking of all
Tahoe-LAFS participants as both client and server.

> If txtorcon is missing features needed for this, let me know what you
> need.

hmm yes I'd to take a detailed look and see what this Tor integration
project needs.

> Also, I just merged David's "tor:" endpoint stuff, which makes txtorcon
> depend on txsocksx now...

yay!

>> Anyway aside from epemeral HS... I was thinking that ideally the
>> Tahoe-LAFS user would select whether to launch a new tor process or to
>> use an existing tor process. Either the location of tor would be known
>> or guessed... or the socks port and control port must be known... and
>> we'd also want to provide the location of the tor control port cookie
>> auth file.
>
> Strictly speaking, just providing the control-endpoint should be
> sufficient; the client is told where the cookie is during
> "authentication" and the socks port (ports?) can be queried from
> Tor. e.g. I could add factory methods such as
> "TorClientEndpoint.from_connection()" to which you'd pass a
> control-protocol connection and get back a TorClientEndpoint ready to
> use it.

Oh yeah that makes sense.

I think Tahoe-LAFS "default Tor quickstart" settings would include
configuration parameters specifying to use a txtorcon launched tor
process. More advanced users may specify tahoe.cfg parameters to
utilize the tor control port of an existing tor process. Furthermore
we'll set it up to save key material to the client's private directory
by default... but it will also be possible to instead use ephemeral
hidden services if you really want to do so.

The end goal is that it will be super easy to setup Tahoe-LAFS + Tor
on any olde computer-like device behind a NAT and just make it work
right right now with that onion grid introducer FURL your cryptoparty
friend gave you. hmm this makes me think that it might be useful to
have a PAKE based service to help pass around introducer FURLS... and
for other short bits of secret information in general. If only we had
a magical-pond-wormhole type thing to help us ;-p

If the Tahoe-LAFS storage operator uses an existing tor process via
the control port then does the txtorcon remove existing Tor hidden
services when it adds it's own new hidden service? The old control
port API is terrible and hard to use... does txtorcon use the new
ephemeral hidden service control port API? I believe there was some
discussion on the tor-dev mailing list about that a while back and
someone mentioned sending key material through the control port for a
given onion service. I'm just wondering what sorts of options we have
for Tahoe-LAFS + existing tor process. I'd want to make sure that our
release docs make well known the the various deployment issues and
feature caveats.

> [..]
>> using our own plugin system... we can instantiate endpoint objects
>> however we want; with or without the help of the endpoint parser
>> plugin system.
>
> Perfect, I *believe* the existing hooks (factory methods) for the server
> endpoints will let you choose between a system or launched Tor easily
> (and change its configuration as necessary).

yes I was looking at the API. Looks like we want to use `system_tor`
and `global_tor depending` on what the user specifies in their
tahoe.cfg. I'm thankful for the clear API documentation... because
even though I helped write this API it's been months since I've looked
at it in detail.

https://github.com/meejah/txtorcon/blob/master/txtorcon/endpoints.py#L124-L136


> The client-side of this doesn't exist at all, but I *would* like to add
> similar features as the server-side...

oh yes I see what you mean... and I agree that factory (class) methods
for the client side would be helpful.