- tor-dev - lists.torproject.org

[GSoC] Update - Safe cookie support in Stem
by Ravi Chandra Padmala 28 May '12

28 May '12

Hello I'm reporting my progress over the last week. I have been working on implementing support for the safe cookie authentication method for Stem[1]. It is in a usable state[2] right now, but, it isn't fully tested. In the process, Stem also helped uncover a bug in the AUTHCHALLENGE error responses[3]. Now, I'll be writing the tests for the safe cookie implementation and getting it merged. Next, I'll begin work on the general controller class. Damien has already implemented an the GETINFO response parser. Beck also wants to help implement the controller class. I/We will be working on the deliverables scheduled for week two in my proposal, i.e. Implementing the wrapper functions and response parsing for the following control commands, GETCONF, SETCONF, LOADCONF, RESETCONF, SAVECONF, SIGNAL, TAKEOWNERSHIP, USEFEATURE and QUIT. 1. https://trac.torproject.org/projects/tor/ticket/5262 2. http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/safe-cookie-alt 3. https://trac.torproject.org/projects/tor/ticket/5760 -- Regards, neena

1 0

Sanitized bridge descriptor format 1.0
by Karsten Loesing 24 May '12

24 May '12

Hi Damian, I plan to make a few changes to the bridge descriptor sanitizer to implement changes discussed on this list and in various Trac tickets. The result will be format version 1.0. Here's what will change compared to the current (unversioned) format. Can you take a look whether stem would be happy with these descriptors and if there are other tweaks I should do to make it even happier? - Bridge network statuses contain a "published" line containing the publication timestamp, so that parsers don't have to learn that timestamp from the file name anymore. - Bridge network status entries are ordered by hex-encoded fingerprint, not by base64-encoded fingerprint, which is mostly a cosmetic change. - Server descriptors and extra-info descriptors are stored under the SHA1 hashes of the descriptor identifiers of their non-scrubbed forms. Previously, descriptors were (supposed to be; see #5607) stored under the digests of their scrubbed forms. The reason for hashing digests is to prevent looking up an existing descriptor from the bridge authority by its non-scrubbed descriptor digest. With this change, we don't have to repair references between statuses, server descriptors, and extra-info descriptors anymore which turned out to be error-prone (#5608). Server descriptors and extra-info descriptors contain a new "router-digest" line with the hex-formatted descriptor identifier. These lines are necessary, because we cannot calculate the identifier anymore and because we don't want to rely on the file name. - Bridge nicknames (#5684) in all descriptor types and dirreq-* statistics lines (#5807) in extra-info descriptors are not sanitized anymore. - All sanitized bridge descriptors contain @type annotations (#5651). Please let me know what you think about these changes. I plan to start sanitizing descriptors with the described changes tomorrow or the day after and make them available on May 30 (or later if the sanitizing/compressing/uploading takes much longer than expected). Thanks, Karsten

2 5

GSoC Introduction - Pluggable Transports in Python
by Brandon Wiley 22 May '12

22 May '12

Hello fellow Tor developers! Some information about me: *I worked for EFF/Tor Project last year for **GSoC 2011, my project **was a blocking-resistant transport evaluation framework: https://gitweb.torproject.org/user/blanu/blocking-test.git* I am also the author of a pluggable transport written in python: https://github.com/blanu/Dust/tree/master/py/dust/services/socks2 I've been working on censorship resistance technology since 2001. Here are some of my projects: http://blanu.net/Dust-FOCI.pdf http://blanu.net/BayesianClassification.pdf http://blanu.net/Arcadia.pdf http://blanu.net/Freenet2001.pdf Some information about the project: The overall goal of the project is to make it easy for pluggable transports to be written in python. There has been a lot of interest in doing pluggable transports in python, but currently they are all written from scratch. For C transports, obfsproxy can be used to do a lot of the heavy lifting, making it relatively easy to write a new C-based transport. I've heard there is also a port of obfsproxy to C++. A the author of a python transport, I am of course an advocate of writing transports in python. Fortunately, so are some other Tor folks, so soon it will be easy to write python transports! The deliverables for this project are as follows: *A library for parsing pluggable transport configuration options* This will be a python library that authors of SOCKS proxies can use to integrate their proxies with Tor. *A framework (both server and client-side) for writing pluggable transports in python* The framework will provide a SOCKS proxy server already integrated with the pluggable transport library. All the protocol author will need to do is provide the obfuscation and de-obfuscation functions and a main function to do command line parsing and call the framework. *A python implementation of the obfsproxy command line tool* This will be a command line program using the framework that will accept the same command line options as the existing obfsproxy tool. It will support the selection of an obfuscation function, although not all of the protocols currently supported by obfsproxy will initially be available in python. *A python implementation of the obfs2 protocol implemented as an obfsproxy module* The obfs2 protocol will be implemented as a plugin for the framework and made available to the command line tool. *Conversion of Dust to an obfsproxy module* The Dust protocol will be implemented as a plugin for the framework and made available to the command line tool. *py2exe packaging for obfsproxy* The command line tool will be packaged into a standalone executable for Windows. Optional deliverables if there is sufficient time: obfsproxy modules for other protocols, experiment with other packaging systems Current status: I'm working on a spec of the API for the option parsing library. It should be available soon.

2 1

[GSoC] [APAF] Report of 17-21 May hackathon; current status of APAF.
by Michele Orrù 21 May '12

21 May '12

I'm writing this mail as report for the last four days during which, thanks to the supervision of both naif and hellais, I managed to develop the very first basic structure of the APAF project. One nice thing that came out during this weekend was the collaboration and improvement of other python projects, txtorcon[0] and py2app[1]. Especially, I hope to continue improving txtorcon, which will be the most strict dependency for the apaf project. At the end of this hackaton, I reached a state in which: - the basic structure of the apaf has not been only designed, but also developed; - the most important classes have unittests and partial documentation sphynx-compilant; - the file setup.py bulds succesfully an installer for windows, osx, and linux.[2] The very basic structure has been widely described in the documentation, and I will update http://mmaker.github.com/apaf/ according to last changes in the source. The most difficult task during the whole hackathon has been packaging for both windows and osx; pyInstaller didn't manage it, but py2exe + py2app seems to work pretty well, even though with some hacks[3]. Todos. --------- Apart from the design of the panel itself, there are some cool standalone tasks which you may consider as example for other projects. I learned from hellais that the torproject is going to build a sort of package managed in order to safely handle updates of the shipped executables; the APAF, too, is going to download[4] executables from the web as dependencies (gnupg and tor for example). The APAF needs also some icons and graphics for the system tray / icon bar / standalone executable (note that darwin and windows have their own image format); I'm going to use Vidalia's ones, but any adivice/aid here would be strongly appreciated. :) [0] https://github.com/meejah/txtorcon/pull/4 and https://github.com/meejah/txtorcon/issues/6 [1] https://bitbucket.org/ronaldoussoren/py2app/issue/45/psutil-error-importerr… (note: building on osx 10.7 does not work.) [2] at least, it did so yeasterday. :P http://cl.ly/04232z2G1x2K2g1t3s2E [3] https://github.com/mmaker/APAF/blob/master/apaf/blobber.py [4] https://github.com/mmaker/APAF/blob/master/apaf/build.py -- ù

1 0

unscribe
by torbridges.security 21 May '12

21 May '12

unscribe

1 0

Re: [tor-dev] [tor-assistants] Python metrics-lib
by Damian Johnson 17 May '12

17 May '12

Hi Beck, hi Karsten. First I'd like to make sure that I'm clear on what we're trying to do. The javadocs for VerifyDescriptors [1] says that it... > Verify server descriptors using the contained signing key. Verify that > 1) a contained fingerprint is actually a hash of the signing key and > 2) a router signature was created using the signing key. > > Verify consensuses using the separate certs. Verify that > 1) the fingerprint in a cert is actually a hash of the identity key, > 2) a cert was signed using the identity key, > 3) a consensus was signed using the signing key from the cert. Honestly I'm not yet sure what most of this means. The first #2 is simply checking that the descriptor content can be verified using the router-signature and signing-key, right? If so then this sounds like a good place to start since it's entirely self-contained within the descriptor and just involves implementation and testing of... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/descriptor/server_de… > However, I need some suggestions for the choice of Python cryptography API, since I haven't used any before. Nor have I. At present stem does not have any dependencies outside of python's builtin functions. If we need PyCrypto and it's the best choice then so be it, but be sure to wrap the imports in a try/catch so we only raise an ImportError when executing the function that requires the PyCrypto library. Cheers! -Damian [1] https://gitweb.torproject.org/metrics-tasks.git/blob/HEAD:/task-2768/Verify…

7 20

directory requests
by SiNA Rabbani 16 May '12

16 May '12

I see the same IP sending the same request over and over. Is this normal behaviour? All the best, SiNA XXX.XXX.XXX.XXX - - [16/May/2012:15:15:00 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:01 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:02 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:02 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:02 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:02 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:02 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:02 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:04 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:06 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:08 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:09 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:12 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:13 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:13 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:13 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:16 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:16 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:16 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" XXX.XXX.XXX.XXX - - [16/May/2012:15:15:19 -0400] "GET /tor/status/all.z HTTP/1.0" 200 540655 "-" "-" "-" -- First they ignore you, then they laugh at you, then they fight you, then you win ~ Mahatma Gandhi

1 0

Re: [tor-dev] HFOSS as Wesleyan this summer
by Damian Johnson 16 May '12

16 May '12

Hi Megan, hi Erik, glad to have you working with us this summer! First a bit of a project introduction is probably in order. Stem is a python controller library for tor. Like its predecessor, TorCtl [1], it uses tor's control protocol [2] to help developers program against the tor process, enabling them to build things similar to Vidalia [3] and arm [4]. Most of stem's core bits (process communication with tor, asynchronous message handling, etc) are done, and development is now focused on the wrapper around that which makes for a developer-friendly API. There's still a ton of work to do, and currently three people hacking on the project... * Damian (project author) * Ravi (GSoC student) - Working on a grab bag of stem related tasks including the general controller, some descriptor parsing, and migrating the first client (arm) over to stem. [5] * Beck (volunteer) - Doing a deep dive into the crypto behind descriptor validation. [6][7] Karsten, Ravi, and I just updated stem's development wiki yesterday so it should be reasonably up to date... https://trac.torproject.org/projects/tor/wiki/doc/stem Codebase: https://gitweb.torproject.org/stem.git So my first question is, what are your interests? It seems that most people either lean toward research or application, and we have a lot to do that fit both. To start with please take a look at the wiki's bugs and improvements sections. Those are bite sized tasks that should be reasonably small and start immersing you in the codebase. After that, both the metrics-lib tasks (more research focused) or porting the tor interpretor (more application) would be great projects. Here's a brief overview of the communication channels we use: - #tor and #tor-dev on OFTC: we're most active on irc, so I definitely suggest being in these channels [8] - tor-talk [9] is our user mailing list which is somewhat high volume. - tor-dev [10] is a lower volume development list and a good place for technical discussions. Unless something is private please include this in your email cc. Hope this helps, and again - welcome! -Damian PS. I highly suggest introducing yourself to this list. The more you're involved with the tor community the better, and we'd be thrilled if you stuck around after your project to become core tor developers! [1] https://www.torproject.org/getinvolved/volunteer.html.en#project-torctl [2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt [3] https://www.torproject.org/getinvolved/volunteer.html.en#project-vidalia [4] http://www.atagar.com/arm/ [5] https://www.torproject.org/about/gsocProposal/gsoc12-proposal-stemImproveme… [6] https://trac.torproject.org/5810 [7] https://lists.torproject.org/pipermail/tor-dev/2012-May/003510.html [8] https://www.torproject.org/about/contact.html.en#irc [9] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk/ [10] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev/

1 0

Faravahar Directory + reverse proxy
by SiNA Rabbani 16 May '12

16 May '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Last week I experimented with OpenSSL 1.0.1c and saw a huge increase in traffic. Unfortunately, my hardware was not up to the task and I started seeing timeouts and other errors. I have decided to replace the server with a much beefier one in the very near future. Meanwhile, I installed nginx as a reverse proxy on the Directory Port. nginx config: server { listen 154.35.32.5:80; server_name _; location / { proxy_pass http://154.35.32.5:81; } } Tor: DirPort 80 DirListenAddress 154.35.32.5:81 It was very easy and nice to configure Tor Directory behind a reverse proxy. The DirListenAddress came super handy!! Nice design. Currently the directory port is responding blazing fast: http://faravahar.rabbani.jp/tor/status/all.z Can someone poke at the directory port and let me know if they can find any issue with serving Tor in this fashion? If this works fine, I will try to configure the directory port on a fancy DDoS mitigation gear next. All the best, SiNA - -- First they ignore you, then they laugh at you, then they fight you, then you win ~ Mahatma Gandhi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPs17iAAoJEJPBwXYLR9VtSvgP/3X77PZCF9yv2MGHuWwkyIDM 1Xye/A4Q5Vnm1ZekNpzsXHK0jNsl0FWKS0/zzx9zkokzeHbwN+CG7Y5jYJBdIbvP DL81Q5VDjsR8tS6MOcEHK+DqnHPpKSSNf2FYCeX9KAstumim+PTV7G84I+0sq4ZL 7B/o43XEuGA3518oLM0v1QcHW+gn58vmpgw0Xh74iv+9EKCCrEY3OJImhXp3tuoe xoM3R9mdcI87uafU/ZyToPO/sAO7f/A3yZXjvMY9XKCLEXMpSqDgrKx3Xt+AeJVs 2qtBfamiT76hpH9kv8429iP3LzJJfWUZvOl5dgziMg6GaD07KKHKFqyN9KYR/7RQ k/Gm0yQcECGxzyBRVxYIAIQFWOpK7c1/Sa9Mn4VNlzqAflYTbJrf47YDfX7vlFE0 giILtLvjcOK4fkv0OD1bTo+pFbY62WXAoZ3VwWu9jEBkgYAvdD55WWyg/zYJCKLi aSCy8f1VszPU9dciSN4JjgPU+zXvY/Zzkui2r4Y5IduVjI0h4FhTyVUETrqJj8Rt eyhfyWYONoGurSPH/LUwlfsI8T4ertZCKv9kLOl7AkOoDIrbj0XUf1mhZyjGz5H7 cN3y0q8iy87InH8udIndAUVRwYTysAHiHvZ5ycbB4OcNMK1JlC6RL3hJx64rNbob hpYatE88b/E9vlZENF8q =SepB -----END PGP SIGNATURE-----

1 0

Proposal: Make bridges report statistics on daily v3 network status requests
by Karsten Loesing 15 May '12

15 May '12

Hi Nick, here is the proposal as discussed in #5807 to improve our bridge usage statistics. Thanks, Karsten

2 2