- tor-dev - lists.torproject.org

GSoC Submission Deadline is Friday (3/21)
by Damian Johnson 17 Mar '14

17 Mar '14

Hi all. Just a friendly reminder that we're fast approaching the deadline for student applications for Google Summer of Code. If you're procrastinating until the last minute then please don't! It's better to get an application in early so we can iterate on it with you. Cheers! -Damian

1 0

Torbirdy
by mujnabed sol 16 Mar '14

16 Mar '14

Hello everyone, I'm in my final year of B.E in Electronics & Instrumentation Engineer and M.Sc in Mathematics from BITS Pilani, India. I was hoping to get a chance to work with the Tor community through this years GSOC. I was reading the projects list and was interested in contributing to the Torbirdy project as I have some experience in coding in Javascript. I wanted to clarify my understanding of the current status of the project. The project requires resolving two issues related to location anonymity weakening due to local timestamp leakage specifically in the MessageID & Date header fields. >From reading issues #6314, #6315 mentioned and the patch requests submitted for bugs #902573 and #902580 at bugzilla.mozilla.org, It seems that the current hold up by Mozilla to accepting the patch request are: 1. Establishing how well Thunderbird & other mail clients handle the date not being inserted by the sender in the mail header 2. Finding which MTA/MSA's automatically insert date headers on their own and if most/all don't, finding a workaround to that. Gmai, Mail.com, Gmx, Yandex and the now dead Lavabit had been tested successfully for automatic date header insertion 3. And using extension hooks with explicit calls instead of checking user set configurations flags for removing timestamp data from header. This it's suggested will allow better handling of messages received/sent in the background by Thunderbird. If someone can let me know if this is the current status of the project or if there are some details I'm missing or even if I've completely missed the point it would be great. Thanks and sorry for the longish mail D

2 1

TBB for Chromebooks?
by Griffin Boyce 16 Mar '14

16 Mar '14

Hello all, Is there a plan to port TBB for chromebooks?

2 1

Feasibility of using a Tor Browser plugin as a PT component?
by David Fifield 16 Mar '14

16 Mar '14

We're making progress on meek (https://trac.torproject.org/projects/tor/wiki/doc/meek) the transport that hides your traffic in HTTPS requests to an unblockable web site. It's already doing a good job at reliably transfering bits. What we'd like to do next is remove trivial means of blocking it based on network fingerprinting. We're currently using the golang HTTPS library, and at https://trac.torproject.org/projects/tor/wiki/doc/meek#Distinguishability you can see meek's TLS differs from Chromium's in its ciphersuites and extensions. It seems the right thing to do is mimic a browser, and I can think of at least three ways to do that: 1. Try really hard, using NSS or some other library, to look like a particular browser. 2. Run a second browser, apart from Tor Browser, that receives commands from a client PT program and makes the HTTPS requests it is commanded to. 3. Run a browser plugin *inside* Tor Browser, that makes HTTPS requests *directly on the Internet, without going through Tor*. That is, the plugin receives commands from the client PT program, and then bypasses all of Tor Browser's proxy settings in order to send HTTPS requests to the web site fronting the circumvention. It's the third option I want to ask about. The first option puts us on the parrot treadmill. The second has the usability and distribution problems of running two browsers at once. The third is slightly crazy, but more usable and easier to deploy. The third option is definitely what I would do if I were using a browser other than Tor Browser and designing purely for circumvention and not anonymity. Is it even possible to run a plugin that bypasses the proxy settings? (I know a binary plugin like Flash can do it--but does that use the browser's HTTP engine or do they cook up their own HTTP with sockets?) Would Tor Browser's customizations, for example the modified User-Agent string, defeat the purpose of looking like an ordinary browser? Anything else I'm missing? This is just brainstorming; negative answers won't be the end of the project. The first option might not be too bad if we use NSS directly. David Fifield

6 10

inTORface - a potential GSoC idea
by Jacek Wielemborek 15 Mar '14

15 Mar '14

Hi, I know there's not much time to apply, but I figured that it's worth asking anyway. I recently gave Tails a try and I have to admit that I wasn't exactly happy with how it routes the traffic through Tor. I basically wanted a ready-to- use airgapped VM and I realized that torsocks doesn't exactly do what I want in all cases. Then I had this idea - wouldn't it be nice to add another virtual NIC to your system that routes all the traffic via Tor and attach a VM to this traffic only? It'd emulate TCP/IP (and maybe some UDP to catch DNS requests) so that if the VM sends a SYN, it notes this fact and tries to establish a real connection. I'm not sure I could hasten to build a prototype, but I wanted to throw the idea there nonetheless. What do you think about it? Yours, Jacek Wielemborek

3 2

GSoC - Tor pluggable transports project
by quinn jarrell 15 Mar '14

15 Mar '14

Hi Tor Devs, I'm a computer engineering undergrad at University of Illinois Urbana-Champaign. I am interested in working on a GSoC pluggable transports project. I mainly code in python or common lisp and have worked with asynchronous programming before (albeit it was a java framework not twisted). The two projects I am interested in are the pluggable transports combiner or building the CBR transport plugin. I really like the idea of the transport combiner but I have a few questions about how far along the design/implementation is. I noticed that there is a prototype called obfs-flash proxy and am wondering if I would work on extending that to work with other plugins or if I would work on a separate combiner. Is the design set in stone yet or is the spec for it still shifting? And if the spec is still shifting, how should I address that in my GSoC proposal. I also talked with Yawning in IRC who pointed me to the CBR transport plugin/unix like plugins to change data length/obfuscate data/add noise. I love the idea that with the combiner a CBR transport could be easily added to any existing transport but if the combiner has not been built/the spec is still developing, I wonder how useful it would be. Also the CBR plugin does not seem to be enough work for a GSoC project but I could definitely be underestimating the difficulty. I would like to work on either of these projects but I do not know which one would be the more helpful/necessary so i would love to hear your opinions on which would be better to work on. Thanks, Quinn

2 1

GSOC Proposal - Improving test coverage in tor
by Punit 15 Mar '14

15 Mar '14

Hello, I have uploaded my GSOC Proposal for the project - "Improving test coverage in tor" at the Melange site. An external link to the same is :- http://punitkoura.github.io/GSOC_proposal.html I would like to know your comments on the same. Thanks, Punit PS - I am working on ConnectionEdge.c in making test cases for connection_edge_process_inbuf function. I will update the proposal when done.

1 0

test_memcpy() on Windows
by Gisle Vanem 14 Mar '14

14 Mar '14

The 'test_memcpy()' in tinytest_demo.c assumes there is a NUL in one of the buffers. (the comment says so). That's not the case here on Windows. At least not in MSVC debug-mode where malloc'ed buffers are filled with '0xCD'. A snippet from my output: ../ext/tinytest_demo.c:159: assert(db->buffer1 < db->buffer2): 537472696E67203000CDCDCDCDCDCDCDCDCDCDCDCDCD ... vs 537472696E67203000CDCDCDCDCDCDCDCDCDCDCDCD ... [memcpy FAILED] I assume this test works on Linux where AFAICS malloc() returns a buffer with zeros. If so, shouldn't calloc() be used in 'setup_data_buffer()' instead? --gv

2 2

[Patch] tinytest_demo.c
by Gisle Vanem 14 Mar '14

14 Mar '14

Since tinytest_demo.c now calls Sleep(), we must include <windows.h>. Patch: --- Git-latest/src/ext/tinytest_demo.c 2014-03-13 20:44:56 +0000 +++ src/ext/tinytest_demo.c 2014-03-14 11:21:56 +0000 @@ -36,7 +36,10 @@ #include <string.h> #include <errno.h> #include <time.h> -#ifndef _WIN32 + +#ifdef _WIN32 +#include <windows.h> +#else #include <unistd.h> #endif -------------- Ref. Nicks commit here: https://gitweb.torproject.org/tor.git/commitdiff/1365ff5b9a04a7da2acc2e52df… --gv

2 1

No IRC meeting to discuss Tor Instant Messaging Bundle today
by Karsten Loesing 14 Mar '14

14 Mar '14

Hi devs, we had an IRC meeting last week, on March 7, to discuss next steps for the Tor Instant Messaging Bundle (TIMB). At the end of that meeting we decided to have another meeting 1 week later, so today. However, there will be no such meeting today! The main reason for today's meeting was to make a decision on an instant messaging client to use in the new bundle. But we already made this decision in internal discussions with the main developers Arlo and Sukhbir. The final decision is that we're going to use Instantbird. The wiki page states some reasons for this decision: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorO/TIMB If you had planned to attend today's meeting to find out how to best help out with the project, please be patient. The project is still in an early state, and we don't have a good list of things that we need help with. Maybe take a look at the Trac tickets in the TIMB component and at the wiki page linked above. There will be IRC meetings in the future to discuss progress on this project, I just can't say when that will be. Thanks for your patience, and thanks for wanting to help out! All the best, Karsten

1 0

A few questions about defenses against particular attacks
by Yuhao Dong 14 Mar '14

14 Mar '14

Hi, I am currently working on a personal project implementing an onion-router, vaguely similar to Tor (let's just call it Oor, other onion router, for the moment), and I have a few questions about attacks, which I think are not really protected by Tor, and whether my solution could possibly work. Of course, if Tor defends against such attacks, then please enlighten me. - Traffic volume correlation. Tor's FAQ says that it doesn't plan on defending against an adversary monitoring traffic volumes flowing through the Tor network. Oor tries to protect against this attack by: - Obfuscating every single link with a protocol derived by Tor's obfs3 protocol - No public list of all node addresses; this makes determining whether certain traffic is Oor traffic much harder. More at the next bulletpoint - Splitting each circuit (termed "onion stew") into many subcircuits, all terminating at the same exit node. à la multipath TCP. Cells going through the subcircuits have a randomly-determined *uneven *distribution of choice of subcircuit, barring attackers from deducing total traffic from observing one subcircuit. - Blanket blacklist attacks by censors. Censors can poll the directory and block all ordinary Tor nodes. (obfsproxy) bridges are a workaround. - Oor's directory maintains a *graph* of all nodes. Each node knows the public keys of all the other nodes, but each node only knows the addresses of *adjacent* nodes. - Note that this allows (sub)circuit-building along any path in the graph. The "extend circuit" command takes the next node's public key as the parameter, rather than the address. - This reduces the bootstrapping problem to distributing (an alias of) the directory server address. Unlike with Tor bridges, this does not create a bandwidth bottleneck, and no nodes need to be reserved for a special pool of bridges, unable to be used by usual users. Bridges often go offline, but this would work until the alias is blocked. However, as with Tor bridges, things like e-mail can be used to distribute many dynamically-generated aliases of the directory server. - Protocol recognition. In "free" countries like the US of A, Tor users see no pressure to use obfuscated bridges. Tor traffic is rather easily distinguished, and could be used to form suspicion on people. Even with obfsproxy, Tor's constant 512-byte cell length may be an issue. The "Stegotorus" paper presents a filter that finds cell lengths typical of Tor. - Every link is obfuscated in oor with obfs3. - obfs3 happens to create various cell lengths. This would be a problem for Tor-like circuits because it doesn't hide data sizes at all, but I think that breaking circuits into subcircuits solves this problem. There is a not-really-working but readable PoC implementation of everything except the "onion stewing" part, i.e. circuits can only work with one subcircuit, athttps://github.com/quantum1423/kirisurf-dev/ Current work is underway to rewrite a more robust version with various repos at https://github.com/KirisurfProject/ (yes, it is currently called Kirisurf, oor is just for short previously, and I want to change the kirisurf name anyways. You may find a "kirisurf" on sourceforge. That is a simple one-hop encrypted proxy I made a long time ago just for breaking censorship without privacy protection; Kirisurf gradually grew onion-routing things until I decided to redesign it; namechange probably needed to prevent misleading version numbers) I would be interested to know what research has been done on these areas in Tor (to avoid reinventing the wheel), and whether any of my ideas are novel. Thanks!

2 1

Fwd: [Twisted-Python] Tor Project has GSoC projects which need Twisted developers!
by isis 14 Mar '14

14 Mar '14

I sent this to the Twisted mailing list at twisted-python(a)twistedmatrix.com -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Pluggable transports meeting tomorrow (Friday 14th of March 2014)
by George Kadianakis 13 Mar '14

13 Mar '14

Greetings humans, this is an email to remind you that the regular biweekly pluggable transports meeting is going to happen tomorrow. Place is the #tor-dev IRC channel in OFTC. Time is 17:00 UTC. Cheers!

1 0

GSoC - Search Engine for Hidden services
by Nurmi, Juha 13 Mar '14

13 Mar '14

Hi All, Ahmia.fi interested in participating in GSoC. Ahmia.fi's back-end is designed by Kordex (Mikko Kortelainen) and I (Juha Nurmi) have built the front-end. In practise, I will apply as a student. Also, kordex might apply. Ahmia.fi is a HS search engine that needs improvements. At the moment, we are using YaCy in the back-end and have developed Django based front-end (Python). Kordex is a Customer Service Architect, CEO of the Fail-Safe IT solutions and software designer. I am a research, postgraduate student and university lecturer. I have a long work experience with web services. At the moment, ahmia.fi has integration to Tor2web and Globaleaks. We have hidden service online cheker, RESTful API for the resources, tested idea how hidden services could publish their information ( https://ahmia.fi/documentation/descriptionProposal/) and a lot of good ideas. Unfortunately, we do not have any funding. We would like to release the source code of ahmia.fi and develop our search engine in GSoC. Greetings Juha Nurmi

3 2

GoSC - Website Fingerprinting project
by Marc Juarez 12 Mar '14

12 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm a PhD student at COSIC (COmputer Security and Industrial Cryptography) in KU Leuven, Belgium. My research topic is related to network traffic analysis and I'm now focused in the more specific problem of website fingerprinting (http://homes.esat.kuleuven.be/~mjuarezm/) I think website fingerprinting is one of the most threatening attacks to Tor because it can be deployed with moderate resources and the information that can be extracted as a result is highly sensitive (e.g., browsing history). It basically defeats one of the main privacy guarantees offered by Tor which is unlinkability between sender and recipient or, in this particular case, between the user and the web server. However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects. That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack. Regarding countermeasures, since Tor is oriented to low-latency applications like web browsing, delaying strategies are unacceptable and, therefore, they must necessarily be based on link-padding. Link-padding normally incurs in high bandwidth overheads, however the increasing broadband bandwidth capacity available makes it a relevant feasible defence. Some capabilities for link-padding have been already specified for Tor by Steven Murdoch (https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.t…, Section 7.2). This functionality is very useful for such a countermeasure but more sophisticated protocols are required for countermeasures that try to adjust the bandwidth overhead. There are several proposed countermeasures based on link-padding that strive for such a trade-off that might be interesting to implement: - Congestion-Sensitive BuFLO (http://arxiv.org/abs/1401.6022) - Adaptive Padding (http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf) Both countermeasures have some building blocks in common (e.g., a control logic to adapt padding under some specific conditions and reduce the overhead). The core of the project would be to implement them in the most general way as possible so they can be useful for other link-padding applications. For example, to implement the basis for a statistical model in the onion proxy and the entry guard that generates the appropriate cover traffic in both directions, where ?appropriate? would be abstracted as it would be defined by each specific countermeasure. I would like to have some feedback from the Tor developers about this project (advices, comments..). I plan to specify it in more detail in the application and to start coding some module that could be shown. But I would like to know if the underlying idea is something that could be of interest for the community. Also, as a PhD student I'm also committed with my research group during the summer so I would like to know if I could work as a part-time student. Best, - -- marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHe+dAAoJEGfJ5xfgazlxYewH/jHv3843o0lQHpHksur86dih u1MtFOpo3RvzdOLNAjdMpnV14Giy8cg0mIcYdCgwCy8jyUgBS5ipX49582Tmf6FT sPYYWOSIBEJVG3DYsD2PwU+XJAiyR9GqdiMiP9MeCJHWP33TBL5hY1TExBejiH+J XsAWo8D2MkzycKITF1leuX4n2eCqncDIy+owU4faYIRj5wPtqwztWDX4ErfdFhws sb/wLF8Wb0tKio/ybkuy5UZeJi0UBF9hAh5UJfZRSllfMFN9g29pJPmTsenMTBS0 XxEEG8gNjHgxpV4rkcTMQBeNp+CAEBsZ7qjxo6IXvLIe0P6zutyQysu9hJCvvY4= =AZG8 -----END PGP SIGNATURE-----

5 4

Weekly Tor dev meeting today, in 90 minutes. (19:00 UTC!)
by Nick Mathewson 12 Mar '14

12 Mar '14

Oh dear. Daylight Savings Time has struck again. The dev meeting this week needs to be at 19:00 UTC, so that I can be done by 4 pm. If you can make it then, great! Else, next week at 19:00 UTC. yrs, -- Nick

1 0

Minutes from Weather rewrite meeting on March 5
by Karsten Loesing 12 Mar '14

12 Mar '14

- only participants today: baumanno and karsten - karsten starts reporting what he did since last meeting - karsten reviewed two tickets - karsten wrote down GSoC idea (u. Rewrite Tor Weather on https://www.torproject.org/getinvolved/volunteer.html.en#Projects) - karsten defined criteria for sending out welcome mails using Onionoo's details documents (#11084) - baumanno starts reporting what he did since last meeting - baumanno closed issue reported by karsten on GitHub repo - baumanno and karsten agreed that there should be unit tests in weather; baumanno is going to create a ticket for this after the meeting; there should be some unit testing framework that plays well with Django - baumanno used most of the existing weather code for scraping emails from relay descriptors - baumanno went on to begin implementation of the welcome script, which leads to #11084 - baumanno notes that we're still missing the script nufuk is working on; baumanno is going to ping him via email and suggest that either feverDream or baumanno takes over - baumanno and karsten wonder how far feverDream is with the vagrant box; this will be very useful to have - baumanno says that utility scripts are ready, so that branching off stable weather would make sense - karsten asked tor's git admins for a user/karsten/weather.git repo that we can use as new stable for now; this is going to be much easier than for feverDream or baumanno to ask for a repo on tor's git - baumanno is going to keep tickets open until we merged them into user/karsten/weather.git - baumanno will create a new branch from atagar's weather repo, add commits, push to a new branch on github, and comment on a trac ticket to pull/review/merge; he's going to cc karsten on the ticket - next meeting is next wednesday at 18:00 utc

1 1

Re: [tor-dev] Volunteering
by Damian Johnson 11 Mar '14

11 Mar '14

> Hi, > > I've been directed to this email address by Matt in regards to volunteering > for the project. Currently I work as a consultant that specialises in > providing hosted services to my clients. I am a keen learner of technology > and have learnt (mostly self taught) various languages (C/C++, python, > Java), where I would like to further improve my knowledge through > volunteering for the Tor project. > > I've browsed through the list of project currently available and have > watched the video, although I cannot decide which project currently > interests me the most. In the past I had used Vidalia when I worked in China > with some limited success, which could be something that I can look to help > upon if possible. > > Thanks, > > Jialu Hi Jialu, glad you want to get involved! Adding tor-dev@ in case the wider community wants to chime in with ideas. The first step of getting involved is to figure out what strikes your fancy and that, obviously, nobody but you can decide. ;) Since you mentioned Vidalia one thing you might want to consider is if you like to work on projects alone or collaborate with others. I include the 'Activity' column on... https://www.torproject.org/getinvolved/volunteer.html.en#Projects ... so you can easily determine for any given project if you would be working with others or adopting a space all your own. Vidalia is firmly in the later camp. Nobody has been actively working on Vidalia for almost a year since chiiph departed. If GUIs strike your fancy then a project you might want to consider is a new stem-based UI. This is an idea we've been batting around for a while now but has yet to get off the ground. Kamran created a python GTK UI a few years back as part of GSoC... http://inspirated.com/2011/07/17/summer-of-code-progress-garm-0-1 This piggybacked on arm, but since his work our controller libraries have greatly improved to a point where we should be able to make a solid, new Tor GUI without that sort of kludge. Like Vidalia, though, nobody else is working in this space so it would involve taking the lead on a new project of your own. If any of the projects on the volunteer table strike your fancy then my best suggestion is to dive in and get involved. Try to fix a minor issue or two then reach out to the maintainer mentioned on the table. Cheers! -Damian

1 0

Mockup for a hidden services publishing tool
by Matt Pagan 10 Mar '14

10 Mar '14

Please see the image file for what I have in mind here. http://oi62.tinypic.com/10x80ok.jpg I hope this tool, when completed, can help reduce the barrier for people seeking to set up hidden services. I anticipate this tool being able to connect to a running tor and write to that tor's torrc file. This tool will be able to connect to the network through a proxy, a standard bridge, or a pluggable transport. It will be able to send a HUP signal to tor. It will be able to read from tor's hidden service directory and tor's log. This mockup was made with wxPython 2.8. This is partially because I'm somewhat familiar with wxWidgets already, and partially because I thought incorporating stem might be a good plan. Here are some pitfalls and shortcomings: * * * By it's current design, this tool has less functionality than Vidalia. As a security property, there's no interface for setting up a relay. This tool's primary focus will be running a hidden service. By it's current design, this tool does not ship with any hosting software. The tool will inform the user that she still needs to run XAMPP or ApacheGUI to host a web page. There's no interface for setting up or designing a blog, only for hosting one that's already designed. I'm still investigating Python's multithreading capabilities so that the Tor log can be continuously read and reported. If I discovered that I didn't need a controller library at all, I'd consider using wxGo instead of wxPython (although writing in Go would be a new experience for me and would take longer). * * * Perhaps some or all of these shortcomings could be overcome given time and community feedback. I'm still not entirely sure where to take this project, if anywhere. Before I get much further with this idea, is this project worth pursuing at all? Does this look like something that could benefit Tor users, given that Vidalia still works for many people? Do you think this tool has potential to function as a point-click-publish hidden services software?

3 2

Re: [tor-dev] [tor-commits] [flashproxy/master] remove failed connections from proxy_pairs as well
by David Fifield 10 Mar '14

10 Mar '14

On Fri, Mar 07, 2014 at 02:39:18PM +0000, infinity0(a)torproject.org wrote: > commit 05b9c101ba9afe4653d1eff6f5414f90f22ef042 > Author: Ximin Luo <infinity0(a)torproject.org> > Date: Fri Mar 7 13:39:31 2014 +0000 > > remove failed connections from proxy_pairs as well > - this is a pretty major fix, as the previous behaviour effectively disabled a proxy after 5 failed connections (= max_num_proxy_pairs / 2) Can you say some more about the circumstances of this fix? What behavior changed for you after making it? I can't reproduce what's described in the commit message. With 9dea0c6c90dedc868dfaa84add2bfa19a2039281, I set up a phony facilitator with ncat -v -lk 7000 --sh-exec "./facilitator.py" where facilitator.py has the contents #!/usr/bin/env python import random import sys port = random.randint(10000,11000) print "HTTP/1.0 200 OK\r" print "Content-Type: application/x-www-form-urlencoded\r" print "Cache-Control: no-cache\r" print "Access-Control-Allow-Origin: *\r" print "\r" sys.stdout.write("check-back-in=10&client=127.0.0.1:"+str(port)+"&relay=173.255.221.44:9901") I then browse to file:///home/david/flashproxy/proxy/embed.html?debug&facilitator=http://127.0.0.1:7000&initial_facilitator_poll_interval=1&unsafe_logging&max_clients=2 All the "client" connections are going to closed ports, but the "Client: error" lines still appear and clients don't accumulate in the request URL. The same happens if I use an open port with a Ncat listener that just closes the connection. The same happens if I change to a non-listening Internet address like 1.1.1.1. 2014-03-10T16:28:48.173Z | Starting; will contact facilitator in 1 seconds. 2014-03-10T16:28:49.179Z | Facilitator: connecting to http://127.0.0.1:7000?r=1&transport=websocket. 2014-03-10T16:28:49.203Z | Next check in 10 seconds. 2014-03-10T16:28:49.204Z | Facilitator: got client:{ host: "127.0.0.1", port: 10782 } relay:{ host: "173.255.221.44", port: 9901 }. 2014-03-10T16:28:49.205Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:49.206Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:49.207Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:49.208Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:49.209Z | Complete. 2014-03-10T16:28:49.209Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:49.209Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:49.210Z | Complete. 2014-03-10T16:28:59.205Z | Facilitator: connecting to http://127.0.0.1:7000?r=1&transport=websocket. 2014-03-10T16:28:59.226Z | Next check in 10 seconds. 2014-03-10T16:28:59.227Z | Facilitator: got client:{ host: "127.0.0.1", port: 10221 } relay:{ host: "173.255.221.44", port: 9901 }. 2014-03-10T16:28:59.227Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:59.227Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:59.229Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:59.229Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:59.230Z | Complete. 2014-03-10T16:28:59.230Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:59.230Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:59.231Z | Complete. 2014-03-10T16:29:09.227Z | Facilitator: connecting to http://127.0.0.1:7000?r=1&transport=websocket. 2014-03-10T16:29:09.249Z | Next check in 10 seconds. 2014-03-10T16:29:09.250Z | Facilitator: got client:{ host: "127.0.0.1", port: 10069 } relay:{ host: "173.255.221.44", port: 9901 }. Now what *does* seem to be happening, and what had me confused for a while, is that Firefox seems to be artificially delaying repeated WebSocket connections to the same port with some kind of exponential delay. I originally had a hardcoded port in facilitator.py, and the delay made it appear that something like what the commit message describes was happening. Since WebSocket connections eventually start waiting a long time to fail, it looks like they are not being closed. https://people.torproject.org/~dcf/graphs/firefox-exponential-delay.png is a screenshot showing what looks like exponential growth in the Network panel. Chromium doesn't appear to have the same issue; the requests are linearly spaced in the network pane. Are you able to confirm any of the above? When you discovered the bug, were you testing with Firefox or Chromium? How did you find the bug, and what did you do (differently from the above) to reproduce it? In any case, what's going on must be different than what's described in the commit message, because even before the fix the proxy continues running for me with max_clients=2. David

2 2

Weekly Tor dev meeting: Wednesday March 12, 20:00 UTC
by Nick Mathewson 10 Mar '14

10 Mar '14

Hi, all! This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday, so it can go right after the TBB meeting. The meeting time will be: Wednesday March 12, 20:00 UTC. (That's 3pm EST and 12:00 noon PST) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. peace, -- Nick

3 2

GSOC Proposal - Improving test coverage for tor
by Punit 10 Mar '14

10 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am Punit Singh, and I have been working on Chutney for the past one week. I have already expressed my interest [1] in participating in GSOC this year for the project - Improving test coverage in tor. I have made some changes to the code base of Chutney, including completing some TODO tasks. The code can be found here. [2] I am currently in the process of completing the proposal for the project. Here are the things I have done - 1. I am now able to understand the code base of Chutney. 2. I have read parts of the Tor specification [3], not the complete document. 3. I have computed the test coverage of tor, and have seen that some parts of the code are totally untested. [4] 4. I know about unit tests and integration tests, how to write them, how to write testable code, and so on. I wanted some pointers as to how should I choose which function to write unit test for (with reference to the application requirement), and how should I go about writing the unit test (I know that I have to script individual clients using Stem, I just needed some guidance how to execute individual functions in the C code from Stem). I am really interested as well as enthusiastic to work on this. I just need a little guidance. Please correct me if I am thinking in the wrong direction. Thanks, Punit References - [1] https://lists.torproject.org/pipermail/tor-dev/2014-February/006317.html [2] https://github.com/punitkoura/chutney Branch : changes [3] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.t… [4] command.c circuitmax.c circuituse.c compat_libevent.c connection.c connection_edge.c -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHMVoAAoJEEBFGwew+1S1b2MH/1X0N+0sBl6tXiZ0w6FyWS2r MIGAN+IwvxTGOdHtk3/8926buSWAtCzhoW8XQX7IWOPDtPMQtQ9PqwhTDFRjl0tz MaHtXSfY6qOu8HToe6rJrVWiJxM+mP/v4VSLQ/tdKb5pl7AVwlli3xQnE0Qnu0UI ibOSROe9yBBtxzG2jdA5xxvlTuyUK2e5OKEjHA+qjCAXrJXqri5Zs0Kx1BYQRb2r K430hSaKAi74zw7abRjmeUXuuvWs1KJTWf7KtPcv6bjwIsO+sR5aiEL/bxQ8mAxC lB4+pKWsbW/X12BlbtY44TjUgX42kXNNq7GxyEqyYFCFuu82tVXVh3TMMH+qSs8= =ZxRG -----END PGP SIGNATURE-----

3 2

Novel distribution mechanisms (was: "s3 alternatives" on libtech)
by Griffin Boyce 10 Mar '14

10 Mar '14

Nathan of Guardian wrote: > Github? Maybe not whole sites, but specific files. I've been working with users who have networks in censored countries to expand access to specific software bundles (not just Tor). My two approaches right now are Google Web Store and torrents attached to a stable offsite seedbox. Both are fairly accessible, but both have pros/cons. With torrents, someone can sit as a seeder and try to tally information on downloaders. Google Web Store downloads are tracked in unknown (legally requestable?) ways by Google and of course it requires downloading/installing Google Chrome to gain access.[1] It's not perfect, but at least for the user groups I talk to, they are realistic solutions to a really tricky problem. ~Griffin [0] cross-posted upon recommendation of David Fifield [1] most users can't figure out how to download extensions manually

3 4

Another fake key for my email address
by Erinn Clark 09 Mar '14

09 Mar '14

Hi everyone, In September last year I discovered a fake key for my torproject.org email address[1]. Today I discovered another one: pub 2048R/C458C590 2014-02-13 [expires: 2018-02-13] Key fingerprint = 106D 9243 7726 CD80 6A14 0F37 B00C 48E2 C458 C590 uid Erinn Clark <erinn(a)torproject.org> sub 2048R/D16B3DB6 2014-02-13 [expires: 2018-02-13] To reiterate what I said last time this happened: 1. That is NOT MY KEY. Do not under any circumstances trust anything that may have ever been signed or encrypted with this key. I looked around and was unable to find anything, but nonetheless, it is out there and that is creepy. 2. If anyone on any of these lists has encountered this key anywhere -- the main fear being that it has been used to fraudulently sign packages of some kind -- can you please let me/us know ASAP? Tor Project official signatures are listed here: https://www.torproject.org/docs/signing-keys.html.en Consider that the canonical source for all signatures! Be suspicious of anything not listed there and let us know if you ever find anything. I want to note here that last year I created a new key which also belongs to me and I just haven't switched to yet. I am not signing any Tor packages whatsoever with this key, but it does belong to me and has several signatures from people I've met in person, some of whom also signed my old/current (63FEE659) key: pub 4096R/91FCD12F 2013-09-21 Key fingerprint = 724B 96C1 997A E999 F0C0 0F8A F8F4 9DD8 91FC D12F uid Erinn Clark <erinn(a)torproject.org> uid Erinn Clark <erinn(a)double-helix.org> uid Erinn Clark <erinn(a)debian.org> sub 4096R/1B749632 2013-09-21 With declining trust in the web of trust, Erinn [1] https://lists.torproject.org/pipermail/tor-talk/2013-September/029752.html

1 0

[draft]: Proposal xxx: Pluggable transport SOCKS5 extensions
by Yawning Angel 08 Mar '14

08 Mar '14

Hello all, To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration. --- Begin proposal body --- Filename: xxx-pt-socks5-extensions.txt Title: Pluggable transport SOCKS5 extensions Author: Yawning Angel Created: 25-Feb-2014 Status: Draft 0. Abstract We propose extending the SOCKS5 protocol when communicating with pluggable transports to allow passing more per-bridge meta-data to the transport and returning more meaningful connection failure response codes back to Tor. 1. Introduction To allow for more sophisticated pluggable transports, it would be useful to support more than 510 bytes of per-connection data, while using the SOCKS5 pluggable transport interface. Additionally as pluggable transports increase in sophistication, it is useful for the pluggable transport to be able to return well defined errors back to Tor if the connection establishment fails. 2. Proposal 2.1. Tor Pluggable Transport Username/Password Authentication We introduce a new authentication method to the SOCKS5 protocol based on the existing RFC 1929 Username/Password Authentication that pluggable SHOULD support. The METHOD number to be returned to indicate support for or select this method is X'80', which belongs to the "RESERVED FOR PRIVATE METHODS" range in RFC 1928. After the authentication method has been negotiated following the standard SOCKS5 protocol, the actual authentication phase begins. Tor will send a Username/Password/Extended Data request: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Username Len | +---------------+---------------+ \ Username \ / ... / \ (Username Len bytes) \ +---------------+---------------+ | Password Len | \ +---------------+ / \ Password \ / ... / \ (Password Len bytes) \ +---------------+---------------+ | Extended Data Len | +---------------+---------------+ \ Extended Data \ / ... / \ (Extended Data Len bytes) \ +---------------+---------------+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Username Len: 8 bits (unsigned integer) This field specifies the length of the Username field in bytes. It MAY be X'00', in which case the Username field is omitted. Username: variable length, optional The Username to use when authenticating. Password Len: 8 bits (unsigned integer) This field specifies the length of the Password field in bytes. It MAY be X'00', in which case the Password field is omitted. Password: variable length, optional The Password to use when authenticating. Extended Data Len: 16 bits (unsigned integer) This field specifies the length of the Extended Data field in bytes. It MAY be X'0000', in which case the Extended Data field is omitted. The Extended Data Len field MUST be transmitted in network byte order. The pluggable transport verifies the supplied Username, Password, and Extended Data and sends the following response: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Status | +---------------+---------------+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Status: 8 bits (unsigned integer) This field specifies the status of the authentication request. A Status of X'00' indicates 'success'. If the pluggable transport returns a 'failure' (Status value other than X'00'), it MUST close the connection. 2.2. Tor Pluggable Transport SOCKS5 Reply Codes We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 reply message. Where: * X'F0' Temporary failure, retry immediately Pluggable transports SHOULD return this status code if the connection attempt failed, but the pluggable transport believes that subsequent connections with the same parameters are likely to succeed. Example: The ScrambleSuit Session Ticket handshake failed, but reconnecting is likely to succeed as it will use the UniformDH handshake. * X'F1' Pluggable transport protocol failure, invalid bridge Pluggable transports MUST return this status code if the connection attempt failed in a manner that indicates that the remote peer is not likely to accept connections at a later time. Example: The obfs3 handshake failed. * X'F2' Pluggable transport internal error Pluggable transports SHOULD return this status code if the connection attempt failed due to an internal error in the pluggable transport implementation. Tor might wish to restart the pluggable transport executable, or retry after a delay. 3. Compatibility SOCKS5 negotiates authentication methods so backward and forward compatibility is obtained for free, assuming a non-broken SOCKS5 implementation in the pluggable transport side that ignores unrecognised authentication methods in the negotiation phase. The extended status codes are informative clarifications of a failure state, so existing Tor binaries will continue existing behavior for a general failure. 4. Security Considerations Identical security considerations to RFC 1929 Username/Password authentication applies. As the Username/Password fields are carried in cleartext, this authentication method MUST NOT be used in scenarios where sniffing is possible. The authors of this proposal note that pluggable transports bind to the loopback address, so in the current model this is believed to be acceptable. 5. Open Questions Is 65535 bytes of per-bridge/per-connection data sufficient? Pluggable transports currently have no notion of authentication due to the Username/Password fields of the RFC 1929 authentication method being hijacked to convey extended data. Is this a feature that will be implemented in the future? 6. References Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Jones L., "SOCKS Protocol Version 5", RFC 1928, March 1996. Leech, M. "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996. Appelbaum, J., Mathewson, N., "Pluggable Transport Specification", June 2012. --- End proposal body --- Questions, comments, feedback appreciated. -- Yawning Angel

5 11