Archive

New Tor Browser Bundles for Linux

The Tor Browser Bundles for Linux have all been updated to really include the latest Firefox, 10.0.2.

https://www.torproject.org/download

Tor Browser Bundle for Linux (2.2.35-7.2)

  • Really update Firefox to 10.0.2
  • Update libpng to 1.5.9

Please note that this time around, I made and signed the bundles as Erinn is travelling. I hope all the previous issues have been fixed, and would like to apologize for taking so long to get updated Linux bundles out. Please report any issues you find on our bugtracker.

You can find my gpg key's fingerprint on the signing keys page.

New Tor Browser Bundles

The Tor Browser Bundles have all been updated to the latest Firefox 10.0.2.

https://www.torproject.org/download

Tor Browser Bundle (2.2.35-7)

  • Update Firefox to 10.0.2

Linux updates

  • Update libpng to 1.5.8 (closes: #5144)

UPDATE: The wrong version of Firefox got into the OS X 64-bit and Windows bundles. These have now been updated properly and are online with version number 2.2.35-7.1.

University of Washington Open Hackfest

We're having an open hackfest at the University of Washington on Feb 22nd and 23rd; we may hold an additional open hackfest day on Friday, Feb 24th if we feel the demand. This meeting is largely possible due to the support of the UW Security and Privacy Research Lab.

This hackfest coincides with our Winter Developer summit and many Tor developers will be in attendance. As I write Tor developers have already started their travel to Seattle and many will stick around for the following week.

We'd love to welcome everyone interested in attending. We'd especially like people to feel welcome to discuss ideas or proposals, who want to know what's happening in the world of censorship resistance, anonymity, privacy and related topics. Most of all if you're prepared to write software, we're planning to do quite a lot of that next week as well.

So please, come join us on the UW campus for our winter open hack fest! Times and locations are available on our wiki page about the open hack fest.

Kazakhstan upgrades censorship to deep packet inspection

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.

Obfsproxy: the next step in the censorship arms race

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:

Obfsproxy users in Iran

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.

Moving forward

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.

New Tor Browser Bundles

The Tor Browser Bundles have all been updated to the latest Firefox (10.0.1) as well as a number of other software version updates, such as the latest Vidalia.

https://www.torproject.org/download

Tor Browser Bundle (2.2.35-6)

  • Update Firefox to 10.0.1
  • Update Vidalia to 0.2.17
  • Update Libevent to 2.0.17-stable
  • Update NoScript to 2.3

Vidalia 0.2.17 is out!

Hello everyone, it's been a while since we had a Vidalia release, so we thought "why not make two?".

On a more serious comment, the only difference between 0.2.16 and 0.2.17 is what translations are in. Since we changed our translations workflow, we needed to update the availability policy. Basically, every new translation that has more than 90% done gets enabled. If any of the enabled translations drop bellow the 75% done, we take them out.

Remember that if you find any bugs, you can report them at https://trac.torproject.org/.

Here's what changed since 0.2.15:

0.2.17 11-Feb-2012

  • Improve the translation policy: do not remove translations that
    are not under 75% done. This re enables Polish and Catalan.

0.2.16 11-Feb-2012

  • Make the default data directory in windows be located in the Local
    AppData instead of the Roaming one. Fixes bug 2319.
  • Do not launch Firefox with every CIRCUIT_ESTABLISHED signal, do it
    only if Firefox isn't open yet. Fixes bug 2943.
  • Uses TAKEOWNERSHIP and __OwningControllerProcess to avoid leaving
    tor running in background if Vidalia exits unexpectedly. Fixes bug
    3463.
  • Attempt to remove port.conf file before using it to avoid a race
    condition between tor and Vidalia. Fixes bug 4048.
  • Do not allow users to check the "My ISP blocks..." checkbox
    without entering any bridges. Also updates the
    documentation. Fixes bug 4290.
  • Check that the authentication-cookie file length is exactly 32
    bytes long. Fixes bug 4304.
  • Explicitly disable ControlPort auto. Fixes bug 4379.
  • Make the non exit relay option backward compatible with Vidalia <
    0.2.14 so that it doesn't confuse users. Fixes bug 4642.
  • Sets the preferred size for the GUI layout so it doesn't squeeze
    widges when the size isn't big enough. Fixes bug 4656.
  • Removes the option to have only HTTPProxy since it does not work
    any more as it used to do with older tor versions. Users should
    use HTTP/HTTPSProxy instead. Fixes bug 4724.
  • Add a hidden configuration option called SkipVersionCheck so
    systems like Tails can force Vidalia to skip checking tor's
    version. Resolves ticket 4736.
  • When Tor has cached enough information it bootstraps faster than
    what takes Vidalia connect to it, so Vidalia does not see the
    event to update the progress bar. Now Vidalia explicitly asks for
    bootstrap-phase when it connects to Tor, and updates the progress
    to what is actually happening instead of hanging in
    "Authenticating to Tor". Fixes bug 4827.
  • Fix size hints in the main window layout so that tilling window
    managers display the window properly. Thanks to Mike Warren for
    the fix. Fixes bug 4907.
  • Vidalia only validates IPv4 bridge lines. IPv6 bridges are now
    available, and there will be pluggable transport bridge lines. So
    the validation is now delegated to Tor through SETCONF.
  • Explicitly disable SocksPort auto by setting it to its default
    (9050). Fixes bug 4598.
  • Sets __ReloadTorrcOnSIGHUP to 0 if SAVECONF failed, which means
    the user can't write the torrc file. Fixes bug 4833.
  • Enable new translations that are >90% done. The new languages are:
    Bulgarian, Czech, Hebrew, Greek, Indonesian, Korean,
    Dutch. Resolves ticket 5051.
  • Remove translations that aren't ready enough: Japanese, Thai,
    Albanian, Vietnamese, Chinese (Taiwan), Polish, Catalan and
    Burmese.

January 2012 Progress Report

Our progress report for January 2012 is available now. Highlights include two Tails releases, a summary of support calls for the past six months with actual user stories, a trip to Egypt for the 'Change your world' summit, updated metrics codebase, discussion of a new voting method, and lots of translation updates.

Available as a pdf with full color graphs, https://archive.torproject.org/monthly-report-archive/2012-January-Month...

or as a plain text file for portability and readability, https://archive.torproject.org/monthly-report-archive/2012-January-Month...

Syndicate content