In January I did Tor talks for the Dutch regional police, the Dutch national police, and the Belgian national police. Jake and I also did a brief inspirational talk at Bits of Freedom, as well as the closing keynote for the Dutch National Cyber Security Centre's yearly conference.
You may recall that one of my side hobbies lately has been teaching law enforcement about Tor — see my previous entries about teaching the FBI about Tor in 2012 and visiting the Stuttgart detectives in 2008 back when we were discussing data retention in Germany. Before this blog started I also did several Tor talks for the US DoJ, and even one for the Norwegian Kripos.
Now is a good time to talk to the Dutch police, first because they're still smarting from the DigiNotar disaster in 2011, but second because of their 2012 ambitions to legalize breaking into foreign computers when they aren't sure what country they're in. (I say legalize because they already did it!)
Below are some discussion points that made an impression on me.
- I started the trip with a talk to about 80 people from the Dutch regional police. Apparently each regional police group has basically one cybercrime person, and pretty much all of them came to learn about Tor. These are the people who advise their police groups about how to handle Tor cases, so they're exactly the ones who need to know about services like ExoneraTor. (Afterwards, one of the national police thanked me heartily for teaching the regional police about Tor, since it makes *his* job easier.)
- One issue that came up repeatedly during the talks: what if a bad guy runs a Tor exit relay to provide plausible deniability when somebody shows up as his door? My first thought is that anybody who runs a Tor exit relay in order to attract *less* attention from the police is crazy: if you want to be ignored, you should use a botnet or whatever to do your bad things, nobody will learn that it's you, end of story. Until we educate every law enforcement person on the planet about Tor, there will always be people who raid every IP address on their suspect list without ever knowing what Tor is. The second point they found interesting was that Tor relays never write any traffic to disk; so if your suspect has bad stuff on his hard drive and says it was because of the Tor relay, he's lying. Of course, disk encryption complicates the situation (which is why, counterintuitively, we recommend *not* using disk encryption on your exit).
- Did you know that the Dutch police have their own internal anonymity network? They started out using a secret subnet ("nobody knows that it's the Dutch police, until somebody figures out that it is"). Apparently now they do smarter things like grabbing addresses from Dutch ISPs so they can blend in better. But that's still not perfect: if they borrow an IP address for 36 hours, then that's a 36-hour window where if you can recognize any of the traffic as Dutch police, you can link the rest of the traffic to them too. I hear their new generation of client-side software has an option for using Tor; I wonder if that means the Tor Browser Bundle, or just tunnelling the traffic through Tor naked? More details here and here. (Two points for transparency and open standards!)
- When we met with the US DEA earlier in January, many people there said they use Tor for their job. Most people in the Dutch national police meeting said they used it often. On the other hand, most people in the Dutch regional police meeting said they certainly did not use it, "because that would be inappropriate." We have some more educating left to do.
- One regional Dutch police woman told us that they know how to check if it's a Tor exit IP, but sometimes they do the raid anyway "to discourage people from helping Tor." I later told that statement to one of the national police, and he was shocked, said that was illegal, and said he'd look into it. Alas, I'm not optimistic that anything will come of it: giving investigators discretion about how to act can be both good and bad.
- It took me a few hours to get the regional police comfortable enough to discuss, but by the end they were answering each other's questions — which is one of my main goals, since I won't be there later to answer them. The best example was one detective who stood up and explained that in his opinion they are focusing way too much on Tor ("because we can't break it"), while at the same time there are many other crimes they *can* fight, like criminals using file sharing networks, and they're ignoring those. Certainly Tor gets a lot of publicity (last year a Dutch TV show stirred up a media fear frenzy about Tor that resulted in a Dutch Parliament member calling to ban it), but according to this detective there's a lot more crime elsewhere. My response: "Did everybody hear that?" It works best when police hear statements like this from their peers rather than from me.
- Here's an argument based on discussions with Karen Reilly for responding about child porn and banning Tor. A lot of people think that it's about trading off the good for the bad. On the one hand, you have a girl in Syria who is alive right now because of Tor. On the other hand, you have a girl in America who is harmed by some jerk and the jerk uses Tor. So, how do you balance these two? How do you decide which one is more important, or more 'valuable' to the world? The answer is that it's the wrong question to ask: you aren't actually going to save the girl in America by getting rid of Tor. Whereas getting rid of Tor *would* harm the girl in Syria (along with a wide variety of people and groups around the world).
- The day after I did the talk to the regional police, I did a short talk at Bits of Freedom, an EFF-like digital rights nonprofit in Amsterdam. They held a "Boffel" for many of their supporters to show up and socialize. It was a really great crowd — these are smart people who care. It was like a tiny CCC congress. And now that I've been clearly complimentary to them, you'll be able to properly interpret my next statement: many of the Dutch police would have fit in just fine at the Boffel. People came up to me at the NCSC conference days later and said "I liked your talk!" and I genuinely couldn't tell if they meant my talk at the regional police or my talk at Bits of Freedom. There were some exceptions, sure, but most of the Dutch police I talked to have somehow managed to not get ground down by their job and lose track of the civil liberties angle. I wonder what their trick is.
- Rejo Zenger (from BoF) and two others are working to create a Dutch organization to run fast Tor exit relays, to gather donations and centrally handle abuse complaints — like Zwiebelfreunde in Germany, Nos Oignons in France, DFRI in Sweden, and NoiseTor in the US. That's great! Please help them out however you can.
- At the NCSC conference, Jake and I did an open Q&A session on the first day, and did the closing keynote (slides) on the second day. Both talks went very well (imagine what would happen if Jake and I practiced any of our talks together before giving them! :). We now have invites to come to all sorts of CERTs around the world; the woman managing the conference is moving to Europol shortly and wants us to come talk there; and one of the heads of NCSC wants us to come back and help the Netherlands with their general direction and strategy. We should try to connect them to local Dutch Tor advocates as much as we can, since after all we have software to write.
- I'm afraid I missed most of the other talks at the conference (and I missed the alternate conference entirely), but I did see Peter Zinn's well-choreographed talk about what the Dutch national police should be focusing on. His conclusion was that the Netherlands should focus on being the "safest country in the world wrt cybercrime by 2017". I had to restrain myself from yelling out the word externalities! during his talk: if their plan is to convince cybercriminals to go elsewhere, and then the neighboring countries like Belgium become cyber-hives-of-scum-and-villainy, that's not going to end well for anybody.
- One person in the Belgian FCCU (Federal Computer Crime Unit) suggested during a break in the discussion that maybe Belgium should block all connections from the Tor network *to* any Belgian IP space. By now there's almost no such thing as a new question for me during these talks, but I have to admit that this one took me by surprise. Eventually I produced the right answer: "The Internet community would destroy you. 'Great Firewall of Belgium'? 'Adopt a Belgian dissident'? Nobody would take you seriously again as an alleged democracy." In any case, my friend at RIPE tells me that technically, it's harder than it sounds for Belgium to do this scale of blocking.
- I got into a discussion with the Belgian police about how they don't regard their Internet filtering as "censorship". In my experience, the way it starts is some legislators decide there's something so horrible on the Internet that it justifies filtering. From there, they delegate to some quasi-governmental organization which comes up with a list (in some totally non-transparent fashion) of verboten URLs. Inevitably, the list contains more types of content than the original reason for setting up the filtering; and inevitably, there's no redress mechanism to get off the list if you shouldn't be on it. The Belgian police assured me that they only filter a small set of URLs, and that each of them is discussed and transparently decided about in a democratic fashion. And then they wouldn't tell me what's on their list.
- I met a US FBI agent and a US Secret Service agent who are "permanently" stationed with the Dutch national police. They acted just like normal Dutch police, except I guess they're paid by the United States to be Dutch police. Weird world we live in.
- In each of the three police meetings, somebody suggested an alternate model for Tor where a judge should get to decide whether a given Tor user should be deanonymized. (While in America we don't trust our judges, in Europe they really do.) Putting aside for a moment the technical fact that building in a backdoor would mean that criminals can exploit it too (this argument doesn't work on them), I tried to press on the multi-jurisdictional aspect: we have governments, militaries, and law enforcement from around the world relying on Tor. When I asked the embedded Secret Service guy if he would be ok with the Dutch police having a backdoor to Tor, he said "We like our Dutch colleagues." When I rephrased it to whether he would be ok with the Dutch police knowing what the US police are using Tor for, he paused, smiled, and tactfully said "No comment."
- Several people at the Dutch cybercrime unit quietly told me they regretted their "break into a Tor hidden service and zero it out" action: it got people upset at them, but more importantly, it *didn't work*. That is, it didn't stop any bad people from doing bad things. Apparently playing whack-a-mole like this doesn't make the criminals go away. And worse, it disrupts the police's other monitoring and infiltration operations.
- If I wanted to run a hidden service website that had a nation-state adversary, I would a) run a good solid webserver like nginx; b) run it in a VM, in a way that the VM couldn't learn its location — "no looking up its IP", but also more subtle things like "no looking up nameservers", "no looking up reachable wireless access points", etc; and then c) put that VM in a VPS running in a country that hates my adversary. That way even if somebody breaks into the webserver and breaks out of the VM, they're still faced with a frustratingly long bureaucratic step.
- I took Aaron Gibson and Pepijn Le Heux with me to the Brussels meeting, and took Pepijn again to the Dutch national police meeting. Pepijn is a great guy; I'm hoping to turn him into a Roger replica so he can act as a Dutch Tor resource and so he can help organizations like Bits of Freedom save their country.
In December I attended the award ceremony for the 2012 Access Innovation Awards. Their finalists included three projects that Tor maintains or co-maintains: OONI (a framework for writing open network censorship measurement tests, and for making the results available in an open way; see its git repo), Flash Proxy (a creative way to let people run Tor bridges in their browser just by visiting a website; see its git repo), and HTTPS Everywhere (a Firefox extension to force https connections for websites that support https but don't use it by default; see its git repo). Of these, OONI and Flash Proxy ended up being winners in their respective categories.
(The Access Innovation Prize gave $100,000 across 5 categories to individuals, organizations and networks who submitted "the best actionable ideas on how to use information technology to promote and enable human rights and deliver social good.")
I'm happy that people are recognizing some of the cool projects that Tor works on. But more than that, it's interesting to watch how our projects are integrating into the broader community. The HTTPS Everywhere website is hosted by EFF, and the tool is co-developed by EFF and The Tor Project. The Flash Proxy submission was actually submitted by the New America Foundation's OTI group, where they plan to work on integrating the Flash Proxy badge into a Facebook app (don't worry, they're splitting the prize money with David Fifield, the main Flash Proxy developer). We (Tor) wouldn't be able to have this reach if we didn't have these other organizations working on our topics too.
More generally, the line around what counts as a Tor project has been getting blurrier over the years. We're a community based around free software and transparent design and development, and when we encounter somebody else who is "doing it right", we embrace them and offer whatever resources we can to help them succeed. One nice example is Nathan Freitas of Guardian — he started maintaining an Android version of Tor, and we liked how he was doing it, so we called him a Tor developer. When Nathan uses his Tor affiliation to get funders to listen to him about mobile security issues, everybody wins. Similarly, while David Fifield spends most of his time being a Stanford grad student, he's made such progress on Flash Proxy that we're paying a second Flash Proxy developer to help him with Windows deployment. It's great that OTI is working in this pluggable transport space too. There's no shortage of hard problems and development tasks to go around.
I'm glad I attended the awards evening. I confess that I was worried it would be full of media hype, with journalists lined up to write hasty and shallow articles. (I suppose I'm jaded by being followed around at hacker conferences by journalists with quotas and deadlines. But I was particularly worried this time because both OONI and Flash Proxy are young projects, and we'd be wisest to make some real progress before drawing mainstream media attention to them.) Instead, the attendees were a variety of enthusiastic, not-very-technical New York City residents. Most of them hadn't heard of Tor and had only a very general understanding of Internet privacy and censorship issues; so I had my work cut out for me in terms of advocacy and awareness-building. Highlights included conversations with people from Committee to Protect Journalists, Human Rights Watch, and several similar organizations — these are exactly the sort of orgs that needs the neutral censorship measurement results that OONI aims to provide.
In September, Karen and I attended a conference at the German Foreign Office to help
them decide what role Germany and the EU should have at regulating the sale of censorship and surveillance tools to dictators:
- I liked Eric King (from Privacy International)'s suggestion that when companies are submitting their tools for export evaluation, they should be required to submit their brochures too. Some of these companies are just shameless in terms of how they pitch their tool in terms of number of bloggers you can round up per unit time. He convinced me that controlling "the worst of the worst" in terms of how they can present their product will influence how these products spread.
- That said, these were all (foreign) policy experts, not technologists. They all seemed to take it for granted that you could draw a line between "bad" products and acceptable / dual-use products. I tried to hold back from saying "every time you people try to come up with legal phrasings about what technologies are ok, you end up putting tools like mine on the wrong side of the line." In retrospect, I should have said it more loudly.
- They were really proud to have Tor representatives there. Having us there let them show the world that they had "real technologists" at their meeting. There were several cases where the whole breakout session turned to me and wanted to know what Tor thought about the given question.
- I met a nice man who worked for a telco/DPI company that deploys its products in the Middle East. He raised a compelling argument: "Look, you folks are the ones that mandated backdoors in the telco equipment we produce, using the term 'lawful intercept'. And now you're surprised and upset when bad people use these same backdoors? You made us build it that way!" It certainly is easier for officials in countries like Germany to think of the world as divided between "good" places and "bad" places, but it sure isn't that simple.
- "Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor". Basically Tariq has written a suite of tools for analyzing how likely an adversary is to be able to see a Tor user's circuits given various values for guard selection and guard rotation. Early results include "three guards is probably the wrong number" and "we probably shouldn't rotate guards so often". Later results I hope will include "here's an algorithm for assigning the Guard flag to relays that makes users safer".
- "Torchestra: Reducing interactive traffic delays over Tor". This paper suggests having two parallel TLS connections between each pair of relays — one for the loud circuits and one for the quiet ones. I've had a series of debates with Rob Jansen over whether this should really help, or if it's just shifting the round-robining to a deeper level (e.g. kernel-level buffers). My current opinion is that it should really help, not because it writes important bytes out faster, but because the other side can *read* important bytes faster — in the current state a relay can't predict which incoming bytes are going to be high-priority, but when high-priority bytes come on a separate TCP connection, it's easy to tell.
- "Enhancing Tor's Performance using Real-time Traffic Classification". I haven't read it in detail yet, but it looks at using machine learning to classify circuits depending on what sort of traffic they're carrying. This direction is worthwhile, but it skips over the question that Rob and I are currently wrestling with, which is "ok, so you've decided to give lower priority to a circuit. What should you actually do to make that circuit put less load on the network?" See also Rob's Usenix Security paper: http://freehaven.net/anonbib/#throttling-sec12
- "SkypeMorph: Protocol Obfuscation for Tor Bridges". The idea is to use the actual Skype program to make a (TCP) video call between user and bridge, and then drop the call and start up your own UDP traffic flows that mimic Skype's UDP flows in terms of size and timing. I'm not clear that trying to look like Skype is a game we can win (especially with DPI-level adversaries already playing the arms race to detect and block 'real' Skype, and with the wasted bandwidth that comes with pretending to be a Skype video call), but I think we can get a lot of mileage out of a Tor pluggable transport that carries Tor traffic over a UDP flow — especially with recent rumors of a Syrian ISP throttling all TCP flows.
- "StegoTorus: A Camouflage Proxy for the Tor Anonymity System". Stegotorus is an obfsproxy fork with two goals: first, chop up Tor traffic flows so you can't recognize Tor traffic just by looking for more 586-byte TCP packets than usual; and second, transport those chopped-up flows over a variety of steg modules, to hide the traffic in protocols that the adversary is unwilling to block (as opposed to obfsproxy's goal, which is to make a flow that's hard enough to DPI for that the adversary has to choose between blocking all unrecognized protocols or letting the flows through). Unfortunately, there aren't any great steg modules yet; rather, it aims to be a framework where if you *did* have a great steg module, you could just pop it in.
- "CensorSpoofer: Asymmetric Communication using IP Spoofing for Censorship-Resistant Web Browsing". It's designed for censored users who mostly consume bytes rather than produce them. This design also uses a UDP stream to deliver the bytes, but they spoof the stream as coming from a plausible-looking voip client rather than from the real source. Then they need some low-latency low-bandwidth way (e.g. instant messaging) to get the upstream packets to the server.
- There's also "Touching from a Distance: Website Fingerprinting Attacks and Defenses". But I confess I haven't looked at it yet. Website fingerprinting remains a huge and open issue that needs more attention.
This recent variety of pluggable-transport designs and research papers is fantastic. It also makes me realize that somebody should put some effort into identifying the various components that a Tor transport system needs, and which papers provide which components. For example, it sounds like SkypeMorph and CensorSpoofer could share the same details for the link encryption and flow control for their UDP stream, rather than inventing two separately. Similarly, the "small upstream channel" requirement from CensorSpoofer reminds me of the similar goal that David's Flashproxy design faces. I see that Tariq and Ian have a new tech report out that gives that a start.
A few days ago, we published a blog post exposing the use of Deep Packet Inspection (DPI) to filter all Internet traffic in Ethiopia, including connections to the Tor network. We concluded that they are doing some sort of TLS fingerprinting, but had not been able to figure out exactly what they are fingerprinting on. Since then, we have managed to determine exactly how Ethiopia blocks Tor and we have developed a workaround. We will publish a full technical analysis very soon.
The long-term solution for Tor users in Ethiopia is to use the Obfsproxy Tor Browser Bundle. The bundles are, unfortunately, not up to date at the moment, but this is something we are working on (see #5937 for details). In the meantime, try using one of the following three bridges:
If the bridges are not working, or you have questions, send an email to firstname.lastname@example.org.
The Ethiopian Telecommunication Corporation, which happens to be the sole telecommunication service provider in Ethiopia, has deployed or begun testing Deep Packet Inspection (DPI) of all Internet traffic. We have previously analyzed the same kind of censorship in China, Iran, and Kazakhstan.
Reports show that Tor stopped working a week ago -- even with bridges configured. Websites such as https://gmail.com/, https://facebook.com/, https://twitter.com/, and even https://torproject.org/ continue to work. The graphs below show the effects of this deployment of censorship based on Deep Packet Inspection:
An analysis of data collected by a volunteer shows that they are doing some sort of TLS fingerprinting. The TLS server hello, which is sent by the Tor bridge after the TLS client hello, never reaches the client. We don't know exactly what they are fingerprinting on, but our guess is that it is either the client hello or the server hello. An illustration can be found in this network flow diagram.
Thanks to Philipp Winter and George Kadianakis for helping me analyze the data. If you have more information about the censorship in Ethiopia, please email email@example.com.
The 2nd USENIX Workshop on Free and Open Communications on the Internet (FOCI '12) seeks to bring together researchers and practitioners from technology, law, and policy who are working on means to study, detect, or circumvent practices that inhibit free and open communications on the Internet.
The Internet offers great promise for improving the communication capabilities of citizens, but our increasing dependence on networked communications also makes it easier for organizations to control, monitor, and block communications. ISPs and governments routinely restrict access to Internet content and services, either by censoring access to information or by degrading the performance of services or blocking them entirely. Similarly, ISPs can degrade network performance for certain sets of users for some or all services, for arbitrary purposes. ISPs have been found to block or throttle certain application traffic routinely. This growing trend toward blocking, tampering, or otherwise restricting communications on the Internet calls for improved techniques both for monitoring the state of restrictions on Internet content and communications, in order to inform users, and for circumventing attempts to censor, degrade, or otherwise tamper with Internet communications.
The broadening scope of attacks on Internet freedom is forcing more disciplines to address the issue. Last year's workshop brought together four research communities:
- Those studying network neutrality and performance degradation
- Those measuring content censorship and blocking of resources and services
- Those designing and evaluating censorship circumvention tools
- Those who work on the wider implications of censorship, bringing perspectives from the worlds of policy, law, ethics, and political and social sciences
This second workshop aims to repeat and promote this critical interdisciplinary approach.
Six-page short-paper submissions are due April 26 (edit: May 3), and the workshop is August 6 near Seattle. See the full Call for Papers for details.
Two weeks ago we announced the use of deep packet inspection to censor the Internet in Kazakhstan. Over those two weeks we've continued working on how they are blocking native tor connections. The good news is that our obfsproxy bundle continues to work well in country. Thanks to wanoskarnet, ann, and others for their help.
We have some network-level data captures at both ends to help us assess what is occuring. It seems the Kazakhstan firewall finds something unique in the TLS "Server Hello" message as sent by the Tor relay or bridge and therefore blocks subsequent communications. IP address and TCP port are irrelevant to the censorship. Research continues. Anonymized network flows are available here:
.kz client to relay: https://media.torproject.org/misc/2012-02-28-tor-kz-client-flow.txt
the relay view of that same conversation: https://media.torproject.org/misc/2012-02-28-tor-kz-bridge-relay-flow.tx...
Here's a graph of what this censorship looks like nationwide. The red dots are probable censorship events.
In December 2011 we were aware of Kazakhstan increasing Internet censorship in response to some unrest and protests in Zhanaozen in the west. The censorship was then deployed around the country, in many cases with the full support of the populace. The initial invesitgation showed simple IP address blocking coupled with basic dns censorship. Tor continued to work without incident until this week.
JSC KazTransCom, AS35104, has deployed or begun testing deep packet inspection (dpi) of all Internet traffic. They specifically target SSL-based protocols for blocking. This includes Tor, IPsec, and PPTP-based technologies, as well as some SSL-based VPNs. Business and private users of these technologies are equally affected.
An example of the censorship, as recorded by volunteers in country, can be found in this network flow diagram. Kazakhstan is identifying and blocking the SSL client key exchange during the setup of an SSL connection. This graph shows the effects of this deployment of censorship based on dpi.
Luckily, due to our recent experience with Iran we have an answer for people: use obfsproxy. Obfsproxy continues to work in Kazakhstan, as well as Iran. In fact, it works in any country where dpi is used to censor citizens' access to the Internet.
Thank you to the volunteers for spending their Valentine's Day collecting and analyzing data.
On Feb 9, Iran started to filter SSL connections on much of their network. Since the Tor protocol uses SSL, that means Tor stopped working too — even Tor with bridges, since bridges use SSL too.
We've been quietly developing Obfsproxy, a new tool to make it easier to change how Tor traffic looks on the network. In late 2011 Iran moved into the #2 position in global Tor user count, and several important political events are scheduled in Iran this month and next. This situation seemed like a good time to test our new tool while also helping improve Internet freedom around the world.
We started with a "Tor Obfsproxy Browser Bundle" with two test obfsproxy bridges in it, to verify that it worked in-country. Then we got over 300 volunteers running more obfsproxy bridges (even with our complex build instructions!), and picked fourteen fast stable trustworthy obfsproxy bridges for an updated bundle which we put out the morning of Feb 11. We spent the weekend fixing usability, stability, and scalability bugs, and put out another bundle on Feb 13 with new versions of Vidalia, Tor, and Obfsproxy.
Thousands of people in Iran successfully used the Obfsproxy Bundle over the weekend:
We did some spot-checking and it seems that the new addresses on Feb 14 are mostly different from the new addresses on Feb 13; but I would guess these are mostly returning users with dynamic IP addresses, rather than actually fresh users. More importantly, these people will be thinking about Obfsproxy next time the filter cracks down — and based on current events, that next time won't be far off. Finally, even though it looks like SSL and Tor are back, I expect Iran will keep throttling SSL traffic as they've been doing for months, so the Obfsproxy bundle will still be more fun to use in Iran than the normal Tor bundles.
How does it work?
Deep Packet Inspection (DPI) algorithms classify Internet traffic by protocol. That is, they look at a given traffic flow and decide whether it's http, ssl, bittorrent, vpn, etc. Governments like Iran, China, and Syria increasingly use these tools (and they often purchase them from Western corporations, but that's a different story) to implement their country-wide censorship, either by looking for a given protocol and outright blocking it, or by more subtle mechanisms like squeezing down the bandwidth available to a given protocol to discourage its use.
Obfsproxy's role is to make it easy for Tor's traffic flows to look like whatever we like. This way Tor can focus on security and anonymity, and Obfsproxy can focus on appearance. The first thing we decided to try looking like was nothing at all: the "obfs2" module adds an encryption wrapper around Tor's traffic, using a handshake that has no recognizable byte patterns.
It won't work perfectly. For example, the traffic flows will still have recognizable timing, volume, and packet size characteristics; a good entropy test would show that the handshake looks way more random than most handshakes; and the censors could always press the "only allow protocols my DPI box recognizes" panic button. Each step in this arms race aims to force the censor to a) put more development time and DPI resources into examining flows, and b) risk more false positives, that is, risk blocking innocent users that they didn't realize they'd be blocking.
This particular new obfuscating layer isn't the most important feature of Obfsproxy. The best part is that makes it easy to design, deploy, and test other obfuscating layers without messing with the rest of Tor. There's a lot of research into trying to make traffic flows look like other protocols, so for example we could rewrite the Tor flows as valid http that the DPI engine considers harmless. That problem is harder than it sounds — and it sounds hard. But by making a separate component that only has to worry about how the traffic looks, other researchers can try out different strategies without needing to learn so much about the rest of Tor. This approach will also let us easily plug in other transports like Telex, and it will also let other circumvention projects reuse Obfsproxy so they don't have to reinvent our wheels.
One of the choices we faced was how widely and loudly to mention the bundle. While we think it would be hard and/or risky for attackers to block the Obfsproxy protocol, the bundle included 14 preconfigured bridge addresses, and censors could just plug those addresses into their blacklists. We started the weekend telling people to only tell their close friends, but on Sunday we opted for a broader publicity push inside the activist community for two reasons. First, the new Vidalia release (0.2.17) lets users configure their own obfsproxy bridge addresses, so if the preconfigured addresses get blocked the user can just put in new ones. Second, it became clearer that the blocking would let up in a few days once the immediate political pressure was over, and we decided it was more important to get the word out about Obfsproxy in general so these users will know about it next time.
I should point out that I don't think they were targeting Tor here. They were targeting popular websites that use SSL, like Gmail and Facebook. Tor was collateral damage because we opted to make Tor traffic look like SSL. That said, we should not forget that we are on their radar: they targeted Tor by DPI in September 2011, and the Diginotar breakin obtained a fake SSL cert for torproject.org.
The next choice we face is: what other communities should we tell? The bundle works great in China too, where their aggressive censorship has been a real hassle for us the past year or so. Some other countries in Asia appear to be newly using DPI to recognize Tor traffic (more on that in an upcoming blog post). We have more development work to do before we can keep up with the China arms race, including teaching obfsproxy bridges to automatically report their addresses to us and teaching our bridgedb service to give them out, and we need to answer research questions around getting more bridges, giving them out in smarter ways, learning when they get blocked, and making it hard for censors to find them. We also need to spread the word carefully, since the arms race is as much about not drawing the attention of the censors as it is about the technology. But the Obfsproxy Bundle works out of the box right now in every censoring country we know of, so we shouldn't be too quiet about it.
And finally, thanks go to George Kadianakis for taking Obfsproxy on as his Google Summer of Code 2011 Project; to Nick Mathewson for mentoring him and getting the Obfsproxy architecture going in the right direction; to Sebastian Hahn for spending all weekend with me fixing bugs and making packages; and to Karsten Loesing, Erinn Clark, Robert Ransom, Runa Sandvik, Nick, George, and the broader Tor community for stepping up over the weekend to help us take it from "early prototype" to "deployed software in use by 5000+ people" in 72 hours.