Hi Karsten, thanks for the feedback!
Updating the subject so it's clearer to others that this is a brainstorming thread for a web relay status dashboard. For people just jumping in on this thread, we're discussing a possible GSoC project for a new controller interface...
https://www.torproject.org/getinvolved/volunteer.html.en#relayWebPanel
this sounds like a fun project and a great GSoC project idea!
Some quick feedback: Have you considered suggesting this relay web status panel for a possible Torouter? I could imagine making this the primary interface for a little Torouter box, so that people don't have to ssh into it or install a desktop application to connect to it.
Great point. Added a note regarding it...
https://lists.torproject.org/pipermail/tor-commits/2014-February/068398.html
Which brings up two my questions: why not make this a "relay web status and *control* panel"? Are the security risks really that much higher compared to using arm? And if you distrust the web server part of this design, how do you prevent an attacker from breaking into the web server and abusing the controller connection to reconfigure the relay?
Certainly could. I'd like for the daemon that services the AJAX requests to be customizable via a local config. By default it would only allow read-only requests for non-sensitive data (ie, not connections). However, the operator could easily allow those to make the panel more capable.
The reason that I'm more wary of a web panel than a local application like arm is...
* Network facing applications like web browsers and mail clients tend to be a more expose attack surface. To do something malicious with arm an attacker would need local filesystem access for the authentication cookie or control socket (at which point they could just connect to the control port directly - arm isn't adding to the risk). With a web panel, however, all they need to do is trick the web browser into issuing AJAX requests to localhost.
* The daemon that services AJAX requests is essentially providing a method to bypass Tor's control port authentication. The daemon authenticates to Tor, but the daemon's users don't necessarily have access to the filesystem.
And question number two: why not make this a "relay and *client* web status and control panel"? In the Torouter case, people might want to use their tor only as a client to route all their connections through tor. Think of a little box that provides wifi access to nearby strangers but tunnels everything through the local tor client to avoid legal trouble. Or, if strangers need anonymity, the guy running the box could configure it as (private) bridge and mention the address on its local website for strangers to use with their own tor client.
I'm not at all suggesting to include all this in the GSoC project. But maybe these ideas could be mentioned or kept in mind?
Certainly could. If this project really takes off then I'd love to see it expand to cover additional use cases. I'm just starting with relays to give the project an initial scope.
Looking forward to seeing this happen!
Me too! I hope we get great applicants for this and the txtorcon/stem integration projects.
Cheers! -Damian