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

[Leif Ryge]

On Sat, Feb 28, 2015 at 02:40:29PM +0100, carlo von lynX wrote:
> Thanks "Angel", appreciate your effort.
> 
> On Thu, Feb 26, 2015 at 09:29:05AM +0100, Andreas Krey wrote:
> > On Wed, 25 Feb 2015 13:51:59 +0000, carlo von lynX wrote:
> > ...
> > > 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.
> > 
> > One way to do that would be to tie the hidden service to the existence
> > of the PID of your app - just exec the app in the script after setting
> > up the HS. (I seem to remember that being an option in some form already.)
> 
> Not exactly the intended behaviour when somebody has to restart the web
> server and doesn't expect Tor to stop servicing it... or when the web
> server is written in $occasionalcoredumpstyle.

I think this is an important point I hadn't considered - at the very least, it
will be necessary to make sure that Tor handles well the case where the same HS
is destroyed and then immediately recreated.

> > Alternatively tor could check whether the listener the HS is accessing
> > is still open, and discard the HS when that is no longer the case.
> > (Possibly new idea.)
> 
> Yes, and then hope not for a racing condition.
> 
> > (And hopefully your application isn't giving extended authority to
> > clients connecting from 127.0.0.1.)
> 
> Depends on the specific constellation.. if noone is web browsing
> on the same system.. if processes are not separated by uid anyway,
> because that actually takes some work, und finally nobody else has
> a login, warning about unsecured control ports or suchlike is crying 
> wolf and educating users to ignore such warnings.
> 
> The current default way to run the Tor router is with the same uid as the 
> user herself, right? Putting an authentication method on the control
> port is pretty pointless - if an attacker manages to break into her
> browser he doesn't have to look very far for her Tor state. So all
> the warnings about localhost being not safe enough yet even though for
> the majority of users it is the factual configuration appears somewhat
> counter-productive to me. We should first introduce a habit of having
> Tor neither launched by TBB nor by vidalia nor as root but using its
> own isolated uid.

FWIW this is already how Debian (and presumably other distros') tor packages
work: tor runs as a dedicated user. Already it is possible to grant other users
access to the control port (from which they can already create and remove
hidden services). The reason why HS applications that create their own HSes
generally run their own instance of tor as their own uid is that the hidden
service data (key and hostname) written by tor is currently only readable by
the tor user. There is another patch to address this issue (in progress or
possibly already merged, sorry I'm not looking up the ticket right now) to
allow this data to be written with permissions for another group to read it,
but this ephemeral HS plan of delivering the information over the control port
is obviously much better/more flexible.

>From Valencia,
~leif

> Then again, whichever way you give the user a way to control the Tor
> router opens up an attack vector for somebody who managed to break into
> a faulty client application. So to me the entire lets-not-trust-localhost
> logic doesn't work out in my head. It either produces bureaucratic
> complications or false positives in the warning log.
> 
> Maybe I overlooked something.
> 
> 
> -- 
>   E-mail is public! Talk to me in private using Tor.
>   torify telnet loupsycedyglgamf.onion		DON'T SEND ME
>           irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
>          http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE