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

[carlo von lynX]

On Wed, Feb 25, 2015 at 07:41:01AM +0100, Andreas Krey wrote:
> The AF_TOR listener would go away with closing the listener socket
> as well (and thus is bound to the lifetime of the process); so binding
> a hidden service to the control connection is the obvious analogy.

Yes, but as it stands AF_TOR is not the #1 API deployed in network
applications. The majority of hidden services are $whatever configured
to listen on port localhost:something and zero awareness of any tor
router doing the rest of the work. Having to change hundreds of existing
apps so that they can work with tor without having to edit torrc is a
worse tradeoff than having to edit torrc.

What is useful here is if I can use existing $app with existing
tor router and just have a shell script drop the glue instructions
into the tor unix socket. This allows to configure hidden services
without editing neither torrc nor the code of the $app. A bit like
Vidalia does it, but without messing with the torrc and without 
being Vidalia.

> Also, would you entrust your hidden service keys to a system-wide
> tor process? :-)

It's like asking if I trust my bank to keep my money.
If you don't trust your Tor process, try not using a computer.
If you don't trust your cheap server hosting provider, don't
put hidden services on cheap rented servers or virtual machines.
But if you don't trust your OS, there is no place where you can
hide your hidden service keys.