[tor-dev] Web Relay Status Dashboard Brainstorming

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev