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

[David Stainton]

> 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.

This feature is going to change how tor controllers operate... and
whether the tor controller is a separate process or an API that the
application uses seems to have been overlooked in this last statement
of yours. Here's an example of what I mean; In the case of Twisted
Python applications... olde apps written a decade ago are made to work
with Tor hidden services without a single line of code changing...
because the endpoint is dynamically loaded and the controlling of tor
is abstracted by this Twisted endpoint.

pip install txtorcon && twistd -n web --port "onion:80" --path ~/public_html

In this case... can twistd be said to manage it's own tor process? It
certainly does not contain any Tor specific code whatsoever. It is
managed in the same process but the details are abstracted away by the
txtorcon controller API.

Furthermore it is not limited to apps that share a tor process with
other applications... Perhaps the computer has multiple instances of
tor running; the Tor controller could be setup to connect to any of
these control ports. This is an observation about a deployment issue
more so than an API issue.

>> 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.

responding to Leif's comment above:

This seems like a false statement in the context of using txtorcon
with this feature.
The above txtorcon twistd example could be made to work with the tor
control port and it would not imply "keeping another process running".
Furthermore, the above example currently relies on txtorcon launching
it's own Tor process which I think is convenient but not so good for
"security isolation"... and implies ambient authority, that is, why
should the python process have that much control over the tor process?
The python app only needs the privilege to create and remove it's Tor
hidden service (principal of least privilege ftw).

> Dormant processes are essentially free, so does this matter?

Yes, it seems like it doesn't matter much.. The local connection from
the tor process would fail to connect to the local service.
I'm not sure if there are other implications that are more important than this.