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

[Yawning Angel]

On Mon, 16 Feb 2015 19:35:58 +0000
Michael Rogers <michael at briarproject.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> (CCing the hidden-services list.)

(Wonder if my reply will bounce.)

> On 16/02/15 16:11, Leif Ryge wrote:
> >> If someone has a suggestion for an alternative interface that
> >> can handle applications crashing (possibly before they persist
> >> the list of HSes they need to clean up), applications that are
> >> just poorly written (and not cleaning up all the ephemeral HSes),
> >> and (optionally, though lacking this would be a reduction in
> >> features) limiting cross application HS enumeration, I'd be more
> >> inclined to change things.
> > 
> > First, thanks for doing this! I think it's a great feature which
> > will make it much easier to create new hidden service
> > applications.
> 
> Seconded!
> 
> > I like the idea of tying HS lifetime to the control port connection
> > for the reasons you state, namely that cleanup is automatic when
> > applications crash.
> 
> As an app developer this strikes me as the right approach. But having
> said that, I wouldn't actually need this feature because Briar already
> uses __OwningControllerProcess to shut down Tor if the control
> connection is closed. I imagine the same would apply to any app that
> manages its own Tor process - so this feature would only be useful for
> apps that share a Tor process with other apps and communicate directly
> with it via the control port, rather than indirectly via a controller
> such as Orbot.

Yep.  I suspect that well behaved applications won't need this for the
most part, but by defining things this way, it avoids unpleasant
surprises for apps that aren't written well, or those that do try to
share a tor instance.

> Are there any such apps, and is it a good idea to support such apps
> (has the rest of the control protocol been examined for
> cross-controller data leaks, what happens if apps tread on each
> other's configuration changes, etc)?

I haven't looked at other concerns in depth, and AFAIK it's a huge
problem area.  My concerns in this area are more "does my branch make
the current situation any worse", rather than "solve all the control
port problems, and make sure this is totally a safe/fine/recommended
thing to do" (It's none of those things).

If most if not all apps will set _OwningControllerProcess, the current
behavior doesn't hurt either since the tor instance will die anyway,
and on the off chance that someone writes a not-so-great app (heaven
forbid), the right thing happens.

> > 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.
> 
> Dormant processes are essentially free, so does this matter?

I have this mindset too.

-- 
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/84851f5d/attachment-0001.sig>