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

[Yawning Angel]

On Mon, 16 Feb 2015 16:11:55 +0000
Leif Ryge <leif at synthesize.us> wrote:
[snippity]
> However, it seems like in the case of applications which are not
> HS-specific this will necessitate keeping another process running
> just to keep the HS alive. I'd rather see two modes: one as you
> describe, and another in which the ephemeral HS stays running until a
> new control port connection requests that it be stopped. To avoid
> allowing enumeration of running services, the "stop" command could
> require that the requestor already knows some details of the HS -
> either a cookie generated at creation time, or perhaps just the
> private key that was provided when it was started.

dgoulet suggested "Detach=true" as an optional argument, which is what
the add side interface would look like if I did this.

> This of course wouldn't result in crashed applications' HSes being
> cleaned up automatically, but having a few stale HSes sitting around
> isn't the end of the world. One approach for cleaning them up could
> be that tor could remove them automatically after it sees connection
> refused a few times.

I'm not quite sure how I feel about this yet.  The code for doing all
of this isn't that difficult, but I'd want to hear from a few more
people about what the right thing to do here would be.

Most importantly since the `ADD_EPH_HS` interface uses key/value pairs
for the port/target now, this would be easy to add on at a later date
even if it doesn't get included in the first iteration.

Something to discuss at the dev-meeting if consensus hasn't been
reached by then.

Regards,

-- 
Yawning Angel
-------------- 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/20150216/16cf1447/attachment.sig>