[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Mon, 16 Feb 2015 16:11:55 +0000
Leif Ryge <leif@xxxxxxxxxxxxx> 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

Attachment: pgpUDV1fv6jLC.pgp
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev