tor hidden service endpoint designs

David Stainton dstainton415 at gmail.com
Sun May 11 11:15:36 UTC 2014


Dear Meejah,

I'm replying by e-mail because it might be better than a conversation
inside a github pull request.

Excellent idea about not launching tor all the time! We were just
talking about that. My friend Leif Ryge and I were discussing possible
designs for this tor hidden service endpoint... and what we realized
is that the Tahoe-LAFS python process will have many endpoints it will
listen on and many endpoints it will connect to. In this case we
really want these features:

- Each Twisted process (in this case Tahoe-LAFS) would use 1 (one)
instance of Tor for all it's client and server communication. We don't
want txsocksx to have to be dependent on txtorcon... however the
txsocksx client tor endpoint could *optionally* read a txtorcon module
variable specifying the tor socks port. If that fails then the tor
client endpoint would try to find the system tor socks port.

- The first time a python process calls the `listen` method on a
hidden service endpoint, the endpoint object will either use the
system tor control port OR it will launch it's own tor process.
(great... because we can reuse your new code for this...) Which ever
it chooses it will then record this information in txtorcon module
variables... so that if the same python process later creates more
hidden service endpoints they will all use the tor process that was
chosen by the first `listen` method call. This last part about
tracking a single tor proc is not implemented yet... but Leif seemed
close to finishing a patch for that. Once this is done then I will
make the necessary changes to the txsocksx tor client endpoint.

With this design we would not really need to specify the control port.
We should probably still have it as an option.. however it isn't needed because
if we try a few ports where the system control port might be and we
cannot connect to it then in that case we should start tor with it's
control port set to an unused port.

By the way... a bit about design patterns I'm using with twisted endpoints:
In Foolscap and Tahoe-LAFS we cannot special case any usage of
endpoint objects. Foolscap currently treats all endpoint objects in
the exact same way... and in this sense is completely decoupled from
the underlying wire protocol; Foolscap is totally decoupled from Tor.
Tahoe-LAFS will have interesting Tor-friendly features like converting
non-tor endpoint descriptor strings into tor endpoint descriptor
strings... when running in "Tor-only" mode for instance. But
Tahoe-LAFS in this case still should be totally decoupled from
launching Tor AND decoupled from the twisted endpoints api; that is
the job of Foolscap. However... Tahoe-LAFS only knows about endpoint
descriptor strings... and this makes it's job very simple. Each
component in the system has it's own simple responsibilities... this
is why I wrote the parsers and why I cannot use extra additional
public methods calling into an endpoint object.


Sincerely,

David



More information about the tahoe-dev mailing list