February 2014 - tor-dev - lists.torproject.org

Weather Rewrite Update
by Abhiram Chintangal 08 Feb '14

08 Feb '14

Hello Guys, I have made some small changes to the existing dajngo app, It would be great if you guys can provide some feedback. Since we might have different settings for testing and production and so on , I made a separate module for it [1]. For now, I check for the debug flag in the updaters module and disable email sending. Here is a link to the new commit [2] Thanks! [1] http://www.rdegges.com/the-perfect-django-settings-file/ [2] https://github.com/achintangal/weather/commit/68035eeea9d26c7f64efd9dbe5484… -- Abhiram Chintangal

1 0

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))
by Karsten Loesing 08 Feb '14

08 Feb '14

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 @@ > > Project Ideas: > <a href="#txtorcon-stemIntegration">Txtorcon/Stem Integration</a> > + <a href="#relayWebPanel">Relay Web Status Panel </a> > > > <a id="project-txtorcon"></a> > @@ -917,6 +918,53 @@ > bonus points if it's Twisted. > </li> > > + <a id="relayWebPanel"></a> > + <li> > + Relay Web Status Panel > + > + Effort Level: Medium > + > + Skill Level: Medium > + > + Likely Mentors: Damian (atagar) > + > + 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">Vidalia</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. > + > + > + The interface will likely <a > + href="https://www.atagar.com/arm/screenshots.php">borrow 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). > + > + > + This project will likely include two parts: an AJAX site and a localhost > + daemon to fulfill those requests. <a > + href="https://stem.torproject.org/">Stem</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. > + > + > + Applicants should be familiar with Python, JavaScript, and learn about > + <a href="https://stem.torproject.org/">Stem</a>. 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">Involvement > + with Stem development</a> during the application process is also a big > + plus. > + > + </li> > + > <a id="httpsImpersonation"></a> > <li> > HTTPS Server Impersonation > > _______________________________________________ > tor-commits mailing list > tor-commits(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits >

3 2

[PATCH] Remove the trailing slash.
by Nikita Karetnikov 07 Feb '14

07 Feb '14

If you apply the attached patch atop of this one [1], you should be able to see the following. $ dist/build/runtests/runtests Cases: 21 Tried: 21 Errors: 0 Failures: 0 (The tests only check encoders/decoders, so you don’t need to have networking enabled.) Is there anything else I can do? [1] https://trac.torproject.org/projects/tor/attachment/ticket/9419/tordnsel.ca…

1 0

Re: [tor-dev] Help hacking Mumble
by Matt 07 Feb '14

07 Feb '14

On Thu, 30 Jan 2014 22:01:18 +0000 Matt <matt(a)pagan.io> wrote: Here is one of the Mumble developers' take on the issue: > I don't know where @zanethomas's post went, but I just want to clarify > what needs to be done here, and what's wrong. > > By default, Qt's proxy support can route hostname resolution through > the proxy if a hostname is used when creating the socket. > > However, in Mumble, we use QHostAddress to resolve addresses ahead of > time in a lot of places (for example, the server list), which causes > the DNS requests to not go through the proxy. > > We need some kind of abstraction on top of QHostAddress that allows us > to route the hostname lookups via the user's selected proxy. That, or > we need to upstream a Qt patch that allows QHostAddress to resolve > through the application's QNetworkProxy. > > ...Something along those lines. Source: https://github.com/mumble-voip/mumble/issues/1033

2 1

Web Relay Status Dashboard Brainstorming
by Damian Johnson 07 Feb '14

07 Feb '14

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

1 0

Status Report - Torsocks 2.x
by David Goulet 06 Feb '14

06 Feb '14

Greetings everyone! After Fosdem 2014, I had the chance to talk with a lot of people about Torsocks and the current status. It appears it's actually quite used! (more than I thought). I've already received multiple contributions after a quick announcement of the project during my talk. This email is to provide a quick status report on what's going on with this effort [1]. In a nutshell, unfortunately, it has been almost two months since the last commit but free time is coming back to me thus expect *MORE* activity. Nick did a *very* nice review of the code base [2] that I finally answered recently [3] but yet to fix stuff upstream. Feel free to jump in the discussion to help or even contribute. Yawning and I had a discussion on #tor-dev about the use of a bitmap instead of an hash table to store connection pointers indexed by file descriptor. After looking in the BSD and Linux code base, we ended up seeing that both OSes allocate the lowest FD everytime a new socket is created which makes thing much more easier to manage a bitmap. Apart from a performance stand point of view, it appears that there is no compelling reasons to move the connection registry from an HT (current state) to a bitmap. Feel free to speak up here if you see any reasons! Finally, Luke Gallagher will continue to contribute tests to the project so big thanks! [4] After the Tor dev. meeting this month, hopefully things will be close to ready for a full on release, I'll most probably write a blog post about this effort on the why it has been rewritten, the current state/limitation and upcoming features. Cheers! David [1] https://github.com/dgoulet/torsocks [2] https://lists.torproject.org/pipermail/tor-dev/2013-December/005886.html [3] https://lists.torproject.org/pipermail/tor-dev/2014-January/006101.html [4] https://lists.torproject.org/pipermail/tor-dev/2014-January/006136.html

1 0

Exitmap Patches
by Damian Johnson 03 Feb '14

03 Feb '14

Hi Philipp. For kicks and giggles I decided to dig into Exitmap a bit this weekend. Patches are available from... https://git.torproject.org/user/atagar/exitmap.git The commits give a pretty good description of the changes but here's a quick summary... * Changes the codebase to be PEP8 compliant. This was the largest (and most time consuming) change. [1] * Adds a run_tests.py executable that runs pyflakes and pep8 checks. [2] * Uses cookie auth for the tor instance we spawn. * Rewrites the get_exits() function. * Swaps some of the threads we use to be daemons. All in all nothing terribly impactful. Cheers! -Damian [1] https://gitweb.torproject.org/user/atagar/exitmap.git/commitdiff/57e0be3?hp… [2] https://gitweb.torproject.org/user/atagar/exitmap.git/blob/HEAD:/run_tests.…

2 1

Help hacking Mumble
by Matt 03 Feb '14

03 Feb '14

If you're into C++ or Qt, we could use some help. Mumble[0] is a free software VoIP application that various people have had success using with Tor. One problem using Mumble with Tor is that Mumble doesn't abide by the native proxy settings when looking up Mumble servers[1]. When using a Tor router device or Torsocks, the DNS requests are just dropped. When using the native proxy settings, the DNS requests still get sent out to the local ISP, not through the proxy. The desired outcome is that if a SOCKS5 proxy is set, DNS requests get sent through the SOCKS5 proxy. The proxy is set as g.s.ptProxyType, and gets set when main.cpp calls NetworkConfig::SetupProxy(), which in turn uses QNetworkProxy::setApplicationProxy. The window that makes these DNS requests is ConnectDialog.cpp, but you'll want to look at Cert.cpp as well. I submitted a pull request[2] that allows users to completely turn off automatic UDP and DNS traffic sent out to the big list of public Mumble Servers. This does not stop the automatic DNS traffic that gets sent to servers on the Favorite servers list though, which is where any private servers you might want to connect to would be. Getting this fixed would be great for Tor because it would make VoIP over Tor easier and safer for people on all platforms. Please help! [0]: http://mumble.info [1]: https://github.com/mumble-voip/mumble/issues/1033 [2]: https://github.com/mumble-voip/mumble/pull/1128

3 2

Re: [tor-dev] Help hacking Mumble
by Matt 03 Feb '14

03 Feb '14

On Fri, 31 Jan 2014 22:17:54 +0000 Andrew F <andrewfriedman101(a)gmail.com> wrote: > Matt, have you gotten any response? > On IRC, Yawning provided me some useful recommendations for further investigation. Any progress I make on this issue will be slow-going though, and getting a fresh set of eyes on this issue would helpful indeed.

1 0

New GPG key for Runa A. Sandvik
by Runa A. Sandvik 03 Feb '14

03 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, Tomorrow is my first day as a staff technologist at the Center for Democracy and Technology in Washington, D.C. I will continue to contribute to the Tor Project in one way or another. This new key will be used to sign email from me going forward. The new key is attached and is also available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu/pks/lookup?op=get&search=0x094D46E2898DB6D5 Here's the fingerprint and current subkey information for reference: pub 4096R/898DB6D5 2014-02-02 Key fingerprint = BEBA DB46 6778 5EF9 B00E D141 094D 46E2 898D B6D5 uid Runa A. Sandvik (offline long term identity key) <runa.sandvik(a)gmail.com> uid Runa A. Sandvik (offline long term identity key) <runa(a)cdt.org> uid Runa A. Sandvik (offline long term identity key) <runa(a)torproject.org> sub 3072R/AC8C6CF6 2014-02-02 [expires: 2015-02-02] sub 3072R/FC71640D 2014-02-02 [expires: 2015-02-02] - -- Runa A. Sandvik -----BEGIN PGP SIGNATURE----- iQGcBAEBCgAGBQJS7qvsAAoJECgKOvb8cWQNT1UL/joI4P1++EIUPmudw179o+j3 4FxEV32snfYNwW9NTaQNwGODglu7EMZRQ4V1UhytXUb9P7taT0eDgiJxPIvC8Okw xZ7jmk5UnV+R37rMLuhcX1Ifwg3Z+tG0qAwJAbFhO/zZX3yTx+ZJoQBjZ4pX5SFQ qE5G7IeLUrWEAIZfm6mLp3M/kh/+8+e5MPsxrdywo9iLi3Y2IB9mO5VVb94qA5Ul l0ETWilusa9PNRD70jtWhQL6EjPS1tkKVbMFk04naDLr+74gwFAta38tJcnZtPId jZXhqpfqcxD0muaEwyvGtV2qfAxbDuDPDxVJofMeK5S5GESOe4AqLyrkMf4MPz4Z ifKFguKpYAiA4Hz9+v4AoZPhX1Zu33AV/4gfE/Q4ZHq3DtqzEkcyzvvEw9kL0pk+ lJC7+R58dJiJ7pGedG9ZCyJugyp6pujiD34RppPL90JxnP5s3V11VkBiv5ZEnB+k kvBq94TkyFD8bUncFhmh4ilkloPDOrqMcfYGl1VjGg== =KZvl -----END PGP SIGNATURE-----

1 0