Your 'Relay Web Status Panel' GSoC idea (was: r26589: {website} Adding 'Relay Web Status Panel' Adding a project I'm interes (website/trunk/getinvolved/en))
Hi Damian,
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.
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?
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?
Looking forward to seeing this happen!
All the best, Karsten
On 05/02/14 18:01, Damian Johnson wrote:
Author: atagar Date: 2014-02-05 17:01:31 +0000 (Wed, 05 Feb 2014) New Revision: 26589
Modified: website/trunk/getinvolved/en/volunteer.wml Log: Adding 'Relay Web Status Panel'
Adding a project I'm interested in mentoring this summer.
Modified: website/trunk/getinvolved/en/volunteer.wml
--- website/trunk/getinvolved/en/volunteer.wml 2014-02-05 03:18:48 UTC (rev 26588) +++ website/trunk/getinvolved/en/volunteer.wml 2014-02-05 17:01:31 UTC (rev 26589) @@ -629,6 +629,7 @@ <p> <b>Project Ideas:</b><br /> <i><a href="#txtorcon-stemIntegration">Txtorcon/Stem Integration</a></i><br />
<i><a href="#relayWebPanel">Relay Web Status Panel </a></i><br />
</p>
<a id="project-txtorcon"></a>
@@ -917,6 +918,53 @@ bonus points if it's Twisted.</p> </li>
- <a id="relayWebPanel"></a>
<li>
- <b>Relay Web Status Panel</b>
<br>
- Effort Level: <i>Medium</i>
<br>
- Skill Level: <i>Medium</i>
<br>
- Likely Mentors: <i>Damian (atagar)</i>
<p>
- Relay operators presently have a couple options for monitoring the status
- of their relay: <a
- href="https://www.torproject.org/getinvolved/volunteer.html.en#project-vidalia%22%...</a>
- which is a gui and <a href="https://www.atagar.com/arm/">arm</a> which uses
- curses. This project would be to make a new kind of monitor specifically
- for relay operators that provides a status dashboard site on localhost.
</p>
<p>
- The interface will likely <a
- href="https://www.atagar.com/arm/screenshots.php%22%3Eborrow heavily from
- arm</a>, except of course in areas where we can improve upon it. Two
- important design constraints is that a localhost controller provides a
- bigger attack surface than guis or curses, so we should be a little more
- wary of what it does. This should be a read-only controller (ie, you can't
- *do* anything to the relay) and by default not surface any sensitive
- information (such as arm's connection panel).
</p>
<p>
- This project will likely include two parts: an AJAX site and a localhost
- daemon to fulfill those requests. <a
- href="https://stem.torproject.org/%22%3EStem</a> is the backend of arm, and can
- be used to get everything you see in arm's interface (making it a natural
- choice for the daemon). That said, this project might entail some Stem
- improvements if we run across any gaps.
</p>
<p>
- Applicants should be familiar with Python, JavaScript, and learn about
- <a href="https://stem.torproject.org/">Stem</a>. <b>As part of your
- application for this project please make both mockups of the interface and
- a proof of concept demo application using JS to surface something with
- Stem. <a
- href="https://trac.torproject.org/projects/tor/wiki/doc/stem/bugs%22%3EInvolvement
- with Stem development</a> during the application process is also a big
- plus.</b>
</p>
</li>
<a id="httpsImpersonation"></a> <li> <b>HTTPS Server Impersonation</b>
tor-commits mailing list tor-commits@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
Karsten Loesing karsten@torproject.org writes:
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.
I had suggested something pretty similar (as a replacement for Vidalia, for example) quite a while ago (on IRC only maybe?) and several people thought it was a completely horrible idea (e.g. "that'll NEVER happen") mostly on the grounds of what Damian pointed out already (cross-protocol attacks, bigger attack surface) plus fears like getting people used to looking at "a web thing" to control Tor means fake "web things" get easier to attack them with, ...
Aren't these concerns valid for the relay cases and for a "client" (tor-router) sort of thing as well?
If not, or if tor-dev thinks this *could* be made to work (securely), I could potentially dig out the proof-of-concept I had for anyone who wanted a starting-point to tackle this (with txtorcon + Twisted of course, plus d3.js for realtime bandwidth graphs plus some comet/ajax thing I forget right now).
I had suggested something pretty similar (as a replacement for Vidalia, for example) quite a while ago (on IRC only maybe?) and several people thought it was a completely horrible idea (e.g. "that'll NEVER happen") mostly on the grounds of what Damian pointed out already (cross-protocol attacks, bigger attack surface) plus fears like getting people used to looking at "a web thing" to control Tor means fake "web things" get easier to attack them with, ...
Aren't these concerns valid for the relay cases and for a "client" (tor-router) sort of thing as well?
Hi Meejah. I wasn't part of those earlier irc discussions so I can't speak to their concerns. If someone has an actual issue they're worried about then I'm happy to discuss it here.
If not, or if tor-dev thinks this *could* be made to work (securely), I could potentially dig out the proof-of-concept I had for anyone who wanted a starting-point to tackle this (with txtorcon + Twisted of course, plus d3.js for realtime bandwidth graphs plus some comet/ajax thing I forget right now).
Neat! A proof of concept would certainly help to bootstrap the project. :P
-
Damian Johnson -
Karsten Loesing -
meejah