[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[Yawning Angel]

On Tue, 17 Feb 2015 02:22:54 +0400
meejah <meejah at meejah.ca> wrote:

> From my perspective, the entire point of this feature is to allow
> applications to use "the system Tor" (or, at least "some
> already-running tor") to put their hidden services on.

The design the way it is with more isolation than usual also allows for
people that use the tails/whonix/or my control port tinfoil hat filter
to potentially whitelist the commands as well, since there isn't any
information disclosure (unless I screwed up the implementation).

Modifying the filters is left up to the implementors (and I probably
won't change or-ctl-filter to allow them since I don't use HSes[0]),
but I view it as a step forward for including/using applications that
use HSes into such environments.

> (Or, looking at it another way, if you don't want to share a tor
> instance with other applications, you can do that easily today -- you
> start up a tor, and can use __OwningControllerProcess as you see fit).
> 
> The *only* reason that txtorcon by default launches a new tor process
> for the "onion:" endpoints is because nothing else will work reliably.
> 
> I'd very much like the default to be that it adds a new onion using
> Yawning's API. This will still fall back to "launch a new tor
> process", but if you know what you're doing you can have a system (or
> personal) Tor instance running (with cookie authentication) that can
> have hidden services added and removed from it.
> 
> Obviously, this will be a lot faster than launching a new Tor (and
> less load or DirAuths). As a bonus, Yawning's API is nice and simple
> (versus SETCONF, which makes it super easy to nuke all the *other*
> hidden services you configured).
> 
> What I would expect of people using this feature is that the process
> that's "adding the hidden service" is the very same one that's
> "providing the service"...
> 
> (If you're doing something with a separate nginx or whatever process
> running your hidden-service, than you should know enough to be able to
> add a couple lines to your torrc and make a normal, "permanent"
> hidden-service).

Or write a trivial script that prompts for a password, decrypts a HS
key, and loads it into a tor instance over the control port.  I assume
if/when my branch gets merged into mainline tor that the controler APIs
will support it in a easy to use manner.

> So, in that context, if your application code isn't perfect and might
> sometimes crash, definitely the right thing is to nuke the hidden
> service. If the app didn't even save its private keys before that
> happened, well, too bad.
> 
> I guess to put another way: I can't see a use-case to keep the hidden-
> service around if the application that added it went away.

It seems a lose consensus is reached here that this is ok, so I'm going
to leave the design as is and write the control-spec.txt patch.

-- 
Yawning Angel

[0]: The first HS I ever set up was when I finished my first pass
implementation, and got the code to a working state.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150217/6e65648f/attachment.sig>