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

[carlo von lynX]

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.

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

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