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.