bridges

Tor Browser Bundle 1.2.10 Released

phobos — Fri, 20 Nov 2009 20:43:26 -0800

On November 20, we released an updated Tor Browser Bundle, version 1.2.10, which includes:

updated Vidalia to 0.2.6
updated Pidgin to 2.6.3
updated Tor to 0.2.1.20
updated Firefox to 3.0.15
updated OpenSSL to 0.9.8l
updated libevent to 1.4.13

You can download the updated version at https://www.torproject.org/torbrowser/

Installing and using Tor

phobos — Thu, 19 Nov 2009 18:31:30 -0800

Thanks to Rob at Freedom House for putting together some videos about how to get, install, and use Tor, Tor Browser Bundle, and Bridges.

Installing and Using Tor, http://tinyvid.tv/show/3lejztnthk2tm
Installing and Using the Tor Browser Bundle, http://tinyvid.tv/show/b0e2hzylie8r
Installing and Using Bridges with Tor, http://tinyvid.tv/show/3uiwckrlqynqv

Freedom House has put together other videos on various tools to use to stay secure online at, http://www.youtube.com/freedom4internet.

Check them out and leave constructive feedback. I'm sure Rob will appreciate help with translating these videos as well.

Picturing Tor censorship in China

phobos — Tue, 13 Oct 2009 19:56:10 -0700

As reported, Tor was partially blocked by China on September 25th or so in anticipation of the CCP October 1, 2009 60th anniversary.

Here's what one directory mirror recorded for September,

And here's the growth of bridge users in response. Alas, like our graphs of bridge use in Iran in June 2009, we only have relative counts for bridge use, not absolute counts. But with a 70x increase in a week, we are talking about 10000+ bridge users:

Tor partially blocked in China

phobos — Sun, 27 Sep 2009 17:15:55 -0700

On September 25, 2009, the Great Firewall of China blocked the public list of relays and directory authorities by simple IP address blocks. Currently, about 80% of the public relays are blocked by IP address and TCP port combination. Tor users are still connecting to the network through bridges. At the simplest level, bridges are non-public relays that don't exit traffic, but instead send it on to the rest of the Tor network.

If you want to help people in China get access to the uncensored Internet, run a bridge.

Feel free to mirror this post, or the Tor website. We have a list of mirrors at https://www.torproject.org/mirrors.html.en or search for tor mirrors via Google, Yahoo, Baidu, etc.

Links to other helpful sites (not run by us):

We knew this day would come, https://blog.torproject.org/blog/torproject.org-blocked-gfw-china%3A-soo....

Measuring Tor and Iran (Part two)

karsten — Wed, 01 Jul 2009 11:25:51 -0700

Two weeks ago we posted early measurements about the growth of Tor usage in Iran. Since then we have improved our math, and used more data sources. This work is part of our metrics project, where we're learning about the Tor network to improve its availability and performance while keeping our users safe.

The first graph shows the estimated number of new and returning Tor clients per day coming from China and Iran. So for example, there were around 7800 new and returning Iranian Tor users on June 24. By "returning", we mean Tor clients that were off for at least several days, so they didn't have cached directory information. We added China as a comparison for the Iran numbers: you can see the results of the recent Green Dam fiasco and attempts to block Google services. Many more details and math are here.

The second graph shows the growth in bridge users coming from Iran and China. Bridges are like normal relays except that they are not listed in a public directory and therefore they're harder to block. We show "growth compared to June 1" because we don't yet have a good estimate of the absolute number of bridge users. The number is probably an order of magnitude smaller than the number of "regular" Tor users. But still, we can say that bridge usage from Iran has boosted to 950% as compared to June 1. For more information on these numbers see this report.

While it is great to see that so many people in Iran find the Tor network useful, we should continue our attempts to make Tor even better. Your contribution could be to set up a bridge or relay as many others recently did. You might also consider setting up an exit relay, possibly with the help of these instructions. But middle nodes and bridges are helping as well!

On the Recent Growth of the Tor Network

karsten — Mon, 22 Jun 2009 18:07:03 -0700

In the past few days the Tor network is seeing a lot of new users coming from Iran. At the same time we have heard from many people who want to support the Tor network by setting up more relays and bridges. Now we wanted to know, are these just promises, or did the network really grow? Here are the results:

The number of relays has grown by 359 or 24% to now 1827 relays within only one week to the highest number of relays the network has ever seen. Likewise, the number of bridges has increased by an incredible 69 % from 255 to 432 within one week. Awesome!

So, does this mean everything is taken care of and no more relays or bridges are needed? Not at all! As you may know, Tor has some performance issues that are, among other things, the result of too few bandwidth capacity for too many clients. If you can, go setup more relays and/or bridges and keep them running even when the conflicts in the world do not hit the headlines. Be sure that your support is much appreciated!

August 2008 Progress Report

phobos — Sun, 21 Sep 2008 16:05:39 -0700

Releases

Vidalia 0.1.7 (released August 2) fixes a bug that caused Vidalia to not recognize Tor's version correctly in Tor 0.2.0.x, adds an "nsh2po" tool that helps Pootle translate the Vidalia bundle installer strings, adds "TZ=UTC" to the BrowserExecutable's environment variables when launched via Vidalia, and updates the Czech, French, and German translations.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.7/CHANG...

Incognito 2008.1 (released August 2) is a Gentoo-based Tor LiveCD. This new release adds a "walkthrough" which will launch on startup; adds language support for Arabic, Green, Hebrew, Russian, and Swedish; improves the support for Chinese and Japanese fonts; adds support for VMWare and partial support for VirtualBox; switches to Tor 0.2.0.30 and Torbutton 1.2.0; and adds some new privacy-supporting software and removes some applications that are too likely to leak private information.
https://svn.torproject.org/svn/incognito/trunk/ChangeLog

Tor 0.2.1.3-alpha (released August 3) implements most of the pieces to prevent infinite-length circuit attacks (see proposal 110); fixes a bug that might cause exit relays to corrupt streams they send back; allows address patterns (e.g. 255.128.0.0/16) to appear in ExcludeNodes and ExcludeExitNodes config options; and fixes a big pile of bugs.
http://archives.seul.org/or/talk/Aug-2008/msg00039.html

Tor 0.2.1.4-alpha (released August 4) fixes a pair of crash bugs in 0.2.1.3-alpha.
http://archives.seul.org/or/talk/Aug-2008/msg00039.html

Tor Browser Bundle 1.1.2 (released August 9) updates Vidalia to version 0.1.6, updates Firefox to 2.0.0.16, updates Tor to 0.2.1.4-alpha, updates Torbutton to 1.2.0, and disables the TZ=UTC environment variable trick since Vidalia 0.1.7 now handles that for us.
https://svn.torproject.org/svn/torbrowser/trunk/README

Vidalia 0.1.8 (released August 17) makes the bandwidth graph window look better for languages like Farsi, includes ssleay32.dll in the Windows packages so Vidalia won't crash when it finds an incompatible version of ssleay32.dll in the user's $PATH, makes "escape" and "return" shortcuts for the settings window, and fixes a variety of other bugs.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.8/CHANG...

Tor 0.2.0.30 (released July 15, announced August 21) switches to a more efficient directory distribution design, adds features to make connections to the Tor network harder to block, allows Tor to act as a DNS proxy, adds separate rate limiting for relayed traffic to make it easier for clients to become relays, fixes a variety of potential anonymity problems, and includes the usual huge pile of other features and bug fixes.
http://archives.seul.org/or/announce/Aug-2008/msg00000.html

Tor Browser Bundle 1.1.3 (released August 22) fixes a bug in the 0.1.2 release that messed up translations in the homepage, adds "small=1" to the homepage URL so it doesn't show the huge green onion by default, and updates Vidalia to 0.1.8.
https://svn.torproject.org/svn/torbrowser/trunk/README

Tor 0.2.1.5-alpha (released August 31) moves us closer to handling IPv6 destinations, puts in a lot of the infrastructure for adding authorization to hidden services, lays the groundwork for having clients read their load balancing information out of the networkstatus consensus rather than the individual router descriptors, addresses two potential anonymity issues, and fixes a variety of smaller issues.
http://archives.seul.org/or/talk/Sep-2008/msg00072.html

Blocking resistance
The Tor 0.2.1.3-alpha and 0.2.1.4-alpha releases include more fixes for hidden service performance and robustness, have slightly improved bootstrap status event behavior, and start hunting down a horrible bug that looks like it could leak private information:
https://bugs.torproject.org/flyspray/index.php?do=details&id=779

Now that the Tor 0.2.0.30 release has been declared stable, ordinary users will finally get bridge features, the new harder-to-block network protocol, and other features by default.

Core Development
We're working on a draft for a new "automatic software update" protocol, code-named Glider, that incorporates the previous proposals 153 and 154 but is easier to extend to other packages, and is easier to implement and maintain on the server side. We hope to have this new draft out as an actual proposal document, along with some early prototypes of the server side, in September.
https://svn.torproject.org/svn/updater/trunk/specs/glider-spec.txt
Part of the ongoing development question is how to write the client side of this auto update engine in a convenient and easy language like Python, yet have it still be extremely compact on the client side -- since Windows doesn't include Python by default, shipping a Python interpreter with the auto updater could add 10MB to the package size.

Roger sent the list of "research directions we should look at" to or-dev, so more people could look at it:
http://archives.seul.org/or/dev/Aug-2008/msg00031.html
We are working these items into a more comprehensive research and development roadmap; stay tuned.

Advocacy
We answered a lot of press organizations about Tor and the Olympics this month. Our main goal was to explain to technical people how bridges work, what they're for, and explain that in most countries right now Tor works just fine out of the box, so bridges are the backup plan for later down the arms race. The CCC (and others) succeeded in making some good press articles, e.g.
http://www.rsf.org/article.php3?id_article=27991
http://www.guardian.co.uk/technology/2008/aug/07/censorship.hacking
http://www.guardian.co.uk/commentisfree/2008/aug/05/china.censorship

Roger attended Black Hat and Defcon. His Defcon talk was:
"Attacks/Vulnerabilities on Tor: past, present, future"
Slides are at http://freehaven.net/~arma/slides-dc08.pdf
He had a packed room of 500+ people. Lucky Green summarized his take-away from the talk as "we would love to work with you if you find any problems with Tor, and we have a good track record of working well with the community." That sounds like what we were aiming for. We're still waiting for the video to come out so we can link to it from the documentation page.

We also talked a lot with the Mozilla people about privacy-impacting bugs in Firefox. We have a list now:
https://www.torproject.org/torbutton/design/#FirefoxBugs
and should start looking for good Firefox developers to fix them and funding to incent them to do so.

We put up our mid-August NLnet reports:
https://www.torproject.org/projects/hidserv#Aug08
https://www.torproject.org/projects/lowbandwidth#Aug08

Jacob spent a long week of hacking in Argentina, for DebConf 8 (the yearly Debian Conference). Lots of Tor advocacy. Another box of Tor stickers applied to many many laptops. Lots of people were interested in Tor and many many people installed Tor on both laptops and servers. This advocacy resulted in at least two new high bandwidth nodes that he helped the administrators configure. The first is in Japan. The second is our first major high bandwidth node in New Zealand.

Coverity (coverity.com) is now scanning Tor. It found a bunch of minor memory leaks, a few false positives, and some other miscellaneous bugs. Nick fixed almost all of the bugs in a quick afternoon, excepting some testing code that has some resource leaks. Jacob is going to work on getting other Tor related projects into Coverity.

Mike Perry has been working lately on publicity for moving more high-profile websites to use SSL correctly. Last year at Defcon he reported a bug in how many sites (including GMail) handle their cookies: he basically described an easy way for anybody in Starbucks to steal your GMail cookie and log into your gmail account, even if you are always very careful to only use "https" when logging in to your gmail account. The attack works because cookies *can* be set with an "only present this cookie on an SSL connection" flag when they're created, but no sites actually set this flag because they are concerned about usability. This attack is easy to perform as a Tor exit relay too. This year, Mike presented an actual tool that performs this attack on a local wireless network in an automated way. Some high-profile sites are slowly moving to use more secure login approaches.

Matt Edman finished running the "Vidalia logo design contest". The contest resulted in 76 entries. There were a lot of questionable submissions (Vidalia ninjas?!), but there were also a few great ones. He is tending towards this entry as his choice for the new Vidalia logo:
http://www.worth1000.com/view.asp?entry=479229

Usability
Incognito 2008.1 (released August 2) is a Gentoo-based Tor LiveCD. This new release adds a "walkthrough" which will launch on startup; adds language support for Arabic, Green, Hebrew, Russian, and Swedish; improves the support for Chinese and Japanese fonts; adds support for VMWare and partial support for VirtualBox; switches to Tor 0.2.0.30 and Torbutton 1.2.0; and adds some new privacy-supporting software and removes some applications that are too likely to leak private information.
https://svn.torproject.org/svn/incognito/trunk/ChangeLog

Incognito now comes with much more thorough documentation about which software packages are included, and how they are configured:
http://www.browseanonymouslyanywhere.com/incognito/uploadfiles/docs.html

Incognito's next step is to work on a "hardened" option that uses a more secure kernel and other applications. The goal is to keep the same usability but be even less vulnerable to application-level and kernel-level attacks that could be used to gain access to the system and then try to unveil the user.

Tor Browser Bundle 1.1.2 (released August 9) updates Vidalia to release 0.1.6, updates Firefox to 2.0.0.16, updates Tor to 0.2.1.4-alpha, updates Torbutton to 1.2.0, and disables the TZ=UTC environment variable trick since Vidalia 0.1.7 now handles that for us.
https://svn.torproject.org/svn/torbrowser/trunk/README

We're working on a new branch of Vidalia that can be used in Tor Browser Bundle, for launching Firefox directly without needing the extra installer scripts called "Firefox Portable". If we get this working, then we can hopefully make progress on running multiple Firefoxes at once (one used for Tor launched by TBB, and one used for non-Tor).
http://trac.vidalia-project.net/browser/vidalia/branches/alt-launcher

The German CCC organization put together a version of the Tor Browser Bundle called the "Freedom Stick" for use in teaching the media about the Chinese firewall and the Olympics:
http://chinesewall.ccc.de/freedomstick-en.html

Scalability
From the Tor 0.2.1.5-alpha ChangeLog:
"More progress toward proposal 141: Network status consensus documents and votes now contain bandwidth information for each router and a summary of that router's exit policy. Eventually this will be used by clients so that they do not have to download every known descriptor before building circuits."

We're worked on getting "Tor Weather" back up and working:
https://weather.torproject.org/
Weather is a service to let relay operators get notified when their relay is unreachable for an extended period of time. It's still in its early experimental stages, but it's already proved useful to its early testers. It's also using SSL as its base URL now.

Jacob has also been working on a Tor network map, to visualize where our relays are. Using all of the known descriptors, it maps each node with some GeoIP code and plot it onto a map. You can interact with the data to see the IP address of each node, the node name and the city/country information if we could find it. Sadly, it *will* lock your browser up for one or two minutes, as there's a lot of data to parse:
http://freehaven.net/~ioerror/maps/v3-tormap.html

July 2008 Progress Report

phobos — Sun, 17 Aug 2008 20:11:31 -0700

Releases:

Torbutton 1.2.0rc5 (released July 6) provides improved addon compatibility, better preservation of Firefox preferences that we touch, fixing issues with Tor toggle breaking for some option combos, and an improved 'Restore Defaults' button. This version also features Firefox 3 cookie jar support, and support for storing cookie jars in memory.
http://archives.seul.org/or/talk/Jul-2008/msg00026.html

Vidalia 0.1.6 (released July 8) fixes a bug introduced in 0.1.3 that could cause excessive CPU usage or crashing on some platforms; continues to prepare Vidalia's strings for easier translation; adds a Romanian GUI and installer translation; and updated the Farsi, Finnish, French, German, and Swedish translations.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.6/CHANG...

Tor 0.2.0.29-rc (released July 8) fixes two big bugs with using bridges, fixes more hidden-service performance bugs, and fixes a bunch of smaller bugs.
http://archives.seul.org/or/talk/Jul-2008/msg00038.html

Torbutton 1.2.0rc6 (released July 12) features fixes for a nasty history loss bug, an exception during Tor toggle, javascript being disabled in some tabs, better pref handling, and more.
http://archives.seul.org/or/talk/Jul-2008/msg00049.html

Tor 0.2.0.30 (released July 15) is the first stable release of the 0.2.0.x branch. The previous stable branch (0.1.2.x) went stable in April of 2007. We are still waiting for Torbutton and Vidalia to stabilize before announcing the Windows and OS X packages on the or-announce announcements
list. We expect to do that in August.

Tor Browser Bundle 1.1.1 (released July 20) updates Vidalia to release 0.1.6, updates Pidgin Portable to 2.4.3, updates Pidgin OTR plugin to 3.2, updates Tor to 0.2.1.2-alpha, updates Torbutton to 1.2.0rc6, and sets TZ=UTC environment variable in RelativeLink (needed by Torbutton).
https://svn.torproject.org/svn/torbrowser/trunk/README

Torbutton 1.2.0 (released July 30) is finally a stable release for the new Torbutton tree that includes application-level privacy protections.
https://svn.torproject.org/svn/torbutton/trunk/src/CHANGELOG

From the Tor 0.2.0.29-rc ChangeLog:
"When a hidden service was trying to establish an introduction point, and Tor had built circuits preemptively for such purposes, we were ignoring all the preemptive circuits and launching a new one instead. Bugfix on 0.2.0.14-alpha."
"When a hidden service was trying to establish an introduction point, and Tor *did* manage to reuse one of the preemptively built circuits, it didn't correctly remember which one it used, so it asked for another one soon after, until there were no more preemptive circuits, at which point it launched one from scratch. Bugfix on 0.0.9.x."

The upcoming Tor 0.2.1.3-alpha and 0.2.1.4-alpha releases include more fixes for hidden service performance and robustness, have slightly improved bootstrap status event behavior, and start hunting down a horrible bug that looks like it could leak private information:
https://bugs.torproject.org/flyspray/index.php?do=details&id=779

Proposals:

Proposal 145 (Separate "suitable as a guard" from "suitable as a new guard") suggests one approach for separating the role of "is still useful as an entry guard" from "should be an option when choosing a new entry guard". This step will help us load balance over the network better.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/145-newguard...

Proposal 146 (Add new flag to reflect long-term stability) discusses how to ship the Tor client with a set of alternate sources for initial bootstrap directory information. We already have this feature in Tor 0.2.0.x, called the "fallback consensus", but we never enabled it because the Tor client would spend too long trying directory mirrors that were long since gone from the network. This proposal moves us closer to being able to distinguish the more long-term reliable mirrors.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/146-long-ter...

Proposal 147 (Eliminate the need for v2 directories in generating v3 directories) helps wean us off of needing the old deprecated v2 directory design. Currently we only use it to give advance warning to the v3 authorities about relays that haven't heard about yet, so they can fetch information about those relays before the time arrives to make an official vote about their state.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/147-prevotin...

Proposal 148 (Stream end reasons from the client side should be uniform) describes a simple fix for a potential anonymity flaw in Tor's core protocol for passing explanations from one end of a Tor circuit to the other when an application stream ends.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/148-uniform-...

Proposal 149 (Using data from NETINFO cells) starts talking about how to make use of the timestamp and IP address listed in Tor's new NETINFO cells. In theory we can use them to decide if our clock is skewed, and to decide if a traffic analysis man-in-the-middle attack is happening against us. In practice it appears more complex than we expected.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/149-using-ne...

Proposal 150 (Exclude Exit Nodes from a circuit) allows users to specify which relays should never be used as the last (exit) hop in a circuit. We took the proposal one step further and allowed users to also specify IP addresses and netmasks for which relays to avoid in the exit position.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/150-exclude-...

Proposal 151 (Improving Tor Path Selection) is a draft proposal to implement the results of Fallon Chen's Google Summer of Code project. Her plan is to measure the expected time it takes to establish a circuit, and then abandon circuits that take significantly longer than that to form. The assumption is that circuits that take a long time to set up will generally have unacceptably high latency as well.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/151-path-sel...

Proposal 154 (Automatic Software Update Protocol) starts the discussion of how to let Vidalia automatically manage updates for Tor, Polipo, Vidalia, etc. This is very important for keeping users up to date with respect to security and stability fixes. We will especially aim to do the updates over Tor, a) for privacy, and b) so users who are blocked from the Tor website will still be able to upgrade seamlessly.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/154-automati...

Research:

Karsten Loesing's report on 7 ways to improve the performance and robustness of Tor hidden services:
http://freehaven.net/~karsten/hidserv/discussion-2008-07-15.pdf

Four new research papers on Tor came out in July:
http://freehaven.net/anonbib/#loesing2008performance
http://freehaven.net/anonbib/#improved-clockskew
http://freehaven.net/anonbib/#mccoy-pet2008
http://freehaven.net/anonbib/#danezis-pet2008

We continued evaluating the TBB footprints here:
https://svn.torproject.org/svn/torbrowser/trunk/docs/traces.txt

In particular, we added a new "Registry modifications" section to that file, describing some new traces that appear to be left behind after operating Tor Browser Bundle, even from the USB key. One of the most worrying is the "user assist" registry key that gets set, and (incredible as it sounds) is obfuscated by rot-13 before being set.

Ease of Use:

The first Incognito (Gentoo-based Tor LiveCD) release of 2008 is also nearing completion, and we expect to see it released in August.

Finally, we contracted to start work on the Tor VM project. The idea is to run a Linux kernel and a Tor client inside a thin VM (like QEMU) on Windows, and then transparently intercept outgoing connections and redirect them into Tor. This approach will a) make proxy-avoiding side-channel and sidejacking attacks less devastating, and b) isolate the Tor client from the rest of the OS to provide a more robust security approach. Current design document is under development at
https://svn.torproject.org/svn/torvm/trunk/doc/design.html

Getting Tor:

We have established our "gettor" email auto-responder script that lets people mail gettor@torproject.org and retrieve a copy of Tor from their mailbox. We still need to ponder more usability issues, such as translation.
https://www.torproject.org/finding-tor

We have also automated the process of checking Tor website mirrors: there's a new update-mirrors.pl script in the website directory that generates a list of mirrors ordered by when they last synced with the main website.
https://www.torproject.org/mirrors

Translations:

We have our translation server up and online:
https://translation.torproject.org/

We revised our translation tutorial here:
https://www.torproject.org/translation-portal

Users continued to submit updated translations for many different languages.

We continued enhancements to the Chinese and Russian Tor website
translations. We added Vidalia, Torbutton, and website translations
into Farsi.

We also added the strings for Vidalia's installer; this required writing several scripts to convert from the "nsh" (nullscript installer language) format to the "po" (preferred by Pootle) format and back.

June 2008 Progress Report

phobos — Tue, 22 Jul 2008 20:25:34 -0700

Torbutton 1.2.0rc1 (released June 1), the first release candidate for the next stable series of the security-enhanced Torbutton Firefox extension, features functional support for Firefox 3. However, this support has not been extensively tested. In particular, timezone masking does not work at all. The workaround is to manually set the environment variable 'TZ' to 'UTC' before starting Firefox. This works on both Linux and Windows:
http://archives.seul.org/or/talk/Jun-2008/msg00044.html

Tor 0.2.0.27-rc (released June 3) adds a few features we left out of the earlier release candidates. In particular, we now include an IP-to-country GeoIP database, so controllers can easily look up what country a given relay is in, and so bridge relays can give us some sanitized summaries about which countries are making use of bridges. (See proposal 126-geoip-fetching.txt for details.)
http://archives.seul.org/or/talk/Jun-2008/msg00055.html

Torbutton 1.2.0rc2 (released June 8) features a fix for an annoying bug on MacOS, and adds much clamored for options to start Firefox in a specific Tor state:
http://archives.seul.org/or/talk/Jun-2008/msg00103.html

Tor 0.2.0.28-rc (released June 13) fixes an anonymity-related bug, fixes a hidden-service performance bug, and fixes a bunch of smaller bugs.
http://archives.seul.org/or/talk/Jun-2008/msg00165.html

Tor 0.2.1.1-alpha (released June 13) fixes a lot of memory fragmentation problems that were making the Tor process bloat especially on Linux; makes our TLS handshake blend in better; sends "bootstrap phase" status events to the controller, so it can keep the user informed of progress (and problems) fetching directory information and establishing circuits; and adds a variety of smaller features. http://archives.seul.org/or/talk/Jun-2008/msg00185.html

Vidalia 0.1.4 (released June 13) adds a bootstrap progress bar, UPnP support, a new set of freely licensed GUI icons, and fixes a few bugs.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.4/CHANG...

The Tor Browser Bundle 1.1.0 (released June 13) replaces startup batch script with application (RelativeLink) so there is a helpful icon, optionally installs Pidgin (for Tor IM Browser Bundle), optionally uses WinRAR to produce a self-extracting split bundle, and includes upgraded versions of Tor, Vidalia, and Torbutton.
https://svn.torproject.org/svn/torbrowser/trunk/README

Tor 0.2.1.2-alpha (released June 20) includes a new "TestingTorNetwork" config option to make it easier to set up your own private Tor network; fixes several big bugs with using more than one bridge relay; fixes a big bug with offering hidden services quickly after Tor starts; and uses a better API for reporting potential bootstrapping problems to the controller.
http://archives.seul.org/or/talk/Jun-2008/msg00247.html

Vidalia 0.1.5 (released June 21) switches Vidalia's internal string representation so it can use the new Pootle-based translation system.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.5/CHANG...

Torbutton 1.2.0rc3 and 1.2.0rc4 (both released June 27) provide improved addon compatibility, better preservation of Firefox preferences that we touch, fixing issues with Tor toggle breaking for some option combos, and an improved 'Restore Defaults' button.
https://torbutton.torproject.org/dev/CHANGELOG

We finally got around to writing down the details of many of our architecture and technical design changes:

Proposal 137 ("Keep controllers informed as Tor bootstraps") modifies Tor so it keeps Vidalia informed of each "bootstrap phase" -- that is, progress Tor makes at learning directory information, making connections to the network, etc. Now Vidalia has a progress bar on Tor startup that explains what's going on. Further, Tor reports "bootstrap problems" when it believes it's having troubles starting up correctly, and Vidalia can now tell the user. All of this is in as of the Tor 0.2.1.2-alpha release (June 20).
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/137-bootstra...

Proposal 138 ("Remove routers that are not Running from consensus documents") modifies the directory "networkstatus consensus" documents so they no longer list relays that are believed to be unusable. They used to list these relays so clients could decide for themselves, but in practice clients just ignored them. This change saves 30% to 40% in download bandwidth for consensus documents. It is included in the 0.2.1.2-alpha release (June 20).
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-d...

Proposal 139 ("Download consensus documents only when it will be trusted") tries to make Tor clients better handle the case when new directory authorities have been added to the system, or when directory authorities have changed (for example, this could happen if we have another bug like the one in May that caused us to change keys for half the directory authorities). Now clients specify which directory authorities they trust, so the directory mirrors can give them a consensus document they'll be willing to use. This change is included in Tor 0.2.1.1-alpha, and a bugfix on it was included in Tor 0.2.1.2-alpha.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/139-conditio...

Proposal 140 ("Provide diffs between consensuses") is still under development, but is scheduled to be included in the Tor 0.2.1.x tree. The idea is that most parts of the consensus document don't change from one hour to the next, so we can give clients a diff on the previous one rather than a whole new document, changing the size of the document every client must download every few hours from 92KB on average to 13KB on average.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensu...

Proposal 141 ("Download server descriptors on demand") is still under discussion, and may not be ready until for inclusion until Tor 0.2.2.x. This is the more detailed version of our "grand scaling plan" first mentioned in April. The idea is to have clients download networkstatus consensus documents as they do now, but rather than preemptively fetching every relay descriptor just in case, they fetch descriptors "just in time" only when they need them. The trick is to keep the bandwidth overhead low while not introducing too many new anonymity attacks e.g. due to leaking which relays you're picking.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-d...

We've instrumented a Tor client to collect stats on how much bandwidth we use now for directory overhead and how much we'd save with this new approach:
http://archives.seul.org/or/dev/Jun-2008/msg00024.html

Proposals 142 ("Combine Introduction and Rendezvous Points") and 143 ("Improvements of Distributed Storage for Tor Hidden Service Descriptors") are still in the discussion phase. Their goal is to improve the experience for clients accessing Tor hidden services, both by making the handshake faster and by making hidden service reachability more reliable and more robust.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/142-combine-...
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/143-distribu...

The "spoofing Firefox cipher suites and extensions" features are now in the Tor 0.2.1.1-alpha release, meaning they're in the Tor Browser Bundle 1.1.0 release also. From the 0.2.1.1-alpha ChangeLog:
"More work on making our TLS handshake blend in: modify the list of ciphers advertised by OpenSSL in client mode to even more closely resemble a common web browser. We cheat a little so that we can advertise ciphers that the locally installed OpenSSL doesn't know about."

We've done some initial security auditing (though there's always room for more, and we plan to do some more concrete auditing in July).

Nick also wrote some early thoughts on doing pass-through to an Apache server to improve scanning resistance:
http://archives.seul.org/or/dev/Jun-2008/msg00014.html

We also looked into running two Firefoxes in parallel:
https://svn.torproject.org/svn/torbrowser/trunk/docs/two-firefox.txt
and we even hacked in some Torbutton fixes that will come out in version 1.2.0rc3 that should get us closer:
http://archives.seul.org/or/cvs/Jun-2008/msg00213.html

Speaking of which, we also hacked in another feature in Torbutton 0.1.2rc2, to add a "locked" mode so Tor Browser Bundle can start Torbutton and not fear that the user will click and disable Tor. I believe TBB 1.1.0 doesn't use this feature yet though.
http://archives.seul.org/or/cvs/Jun-2008/msg00186.html

From the Tor 0.2.1.2-alpha ChangeLog:
"If you have more than one bridge but don't know their digests, you would only learn a request for the descriptor of the first one on your list. (Tor considered launching requests for the others, but found that it already had a connection on the way for $0000...0000 so it didn't open another.) Bugfix on 0.2.0.x."
"If you have more than one bridge but don't know their digests, and the connection to one of the bridges failed, you would cancel all pending bridge connections. (After all, they all have the same digest.) Bugfix on 0.2.0.x."
"If you're using bridges, generate "bootstrap problem" warnings as soon as you run out of working bridges, rather than waiting for ten failures -- which will never happen if you have less than ten bridges."

We put up a new webpage to describe bridges, how to fetch bridge relay addresses, etc:
https://www.torproject.org/bridges

We also modified the BridgeDB database (that is, the server that runs https://bridges.torproject.org/ and answers mail to bridges@torproject.org) to autodetect if the address hitting https://bridges.torproject.org/ is currently a Tor exit relay, and if so to treat it specially -- that is, we reserve a set of bridge addresses and give those out only to folks coming in over Tor.

The updated BridgeDB version now makes sure to give out at least one bridge that's listed as Stable in the bridge authority's networkstatus document, and at least one bridge that listens on port 443. The goal here is to increase the odds that at least one of the bridges we give the user will be usable even if he's in a tightly firewalled situation.

From the Tor 0.2.0.27-rc ChangeLog:
"Include an IP-to-country GeoIP file in the tarball, so bridge relays can report sanitized summaries of the usage they're seeing."

We finished work on a patch for OpenSSL that will make it keep less buffer space around. Currently fast Tor relays use (waste) as much as 100M of memory in OpenSSL's buffers. This patch was accepted and included in the main OpenSSL tree in June:
http://marc.info/?l=openssl-cvs&m=121246471627426&w=2

The Vidalia 0.1.4 release has folded the UPnP library and GUI changes into the main Vidalia tree, along with a "test" button to try speaking UPnP at the local router and tell the user whether it worked; these features will be available by default in the 0.2.0.x stable release.

We've put a lot of effort into reducing Tor's memory footprint again. The main issue was a "memory fragmentation" problem in Linux's memory allocator, which was causing Tor servers on Linux to slowly grow without bound. As of Tor 0.2.1.2-alpha, the issue appears to be substantially better. Many more details are here:
http://archives.seul.org/or/dev/Jun-2008/msg00001.html

From the Tor 0.2.1.2-alpha ChangeLog:
"New TestingTorNetwork config option to allow adjustment of previously constant values that, while reasonable, could slow bootstrapping. Implements proposal 135. Patch from Karsten Loesing."
"When building a consensus, do not include routers that are down. This will cut down 30% to 40% on consensus size. Implements proposal 138."

We've added clear user-oriented instructions for the Tor Browser Bundle split-download page:
https://www.torproject.org/torbrowser/split.html.en

We're starting work on a "gettor" email auto-responder script that will let people mail gettor@torproject.org and retrieve a copy of Tor from their mailbox. More info forthcoming in July.

More generally, we have a new https://www.torproject.org/finding-tor page that describes various mechanisms such as mirrors.

In July we plan to deploy a more automated mechanism for tracking which Tor mirrors are up-to-date.

We have our translation server up and online:
https://translation.torproject.org/

We have imported the strings from Vidalia, Torbutton, and Torcheck, and we currently have active translations for Spanish, French, German, Italian, Polish, Romanian, Swedish, Turkish, Finnish, Russian, Chinese, and Arabic.

We have a more useful overall translation tutorial here:
https://www.torproject.org/translation-portal

And we have internal documentation here for how to deal with the translation stuff behind the scenes:
https://svn.torproject.org/svn/tor/trunk/doc/translations.txt

In July we plan to add the strings for Vidalia's installer; the challenge is that we need to write a script to convert from the "nsh" (nullscript installer language) format to the "po" (preferred by Pootle) format and back.

In July we also expect to see the first version of our "wml to po and back" conversion tool, that will allow us to start putting our website pages into the translation server.

May 2008 Progress Report

phobos — Tue, 24 Jun 2008 20:39:17 -0700

Tor 0.2.0.26-rc (released May 13) fixes a major security vulnerability caused by a bug in Debian's OpenSSL packages. All users running any 0.2.0.x version should upgrade, whether they're running Debian or not.
http://archives.seul.org/or/talk/May-2008/msg00048.html

Vidalia 0.1.3 (released May 25) adds a hidden service configuration UI designed and implemented by Domenik Bork, as well as a few other bugfixes.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.3/CHANG...

The Tor Browser Bundle 1.0.2 (released May 3) and 1.0.3 (released May 16) include upgraded versions of Tor, Vidalia, Torbutton, and Firefox.

We added three new part-time developers in May. We hired Matt Edman as a part-time employee at the beginning of May, to work on Vidalia maintenance, bugfixes, and new features. We also are funding Karsten Loesing to work on making hidden service rendezvous and interaction faster, and Peter Palfrader to work on lowering the overhead of directory requests, especially during bootstrap, which should directly improve the experience for Tor users on modems or cell phones.

Google has agreed to give us some funding to work on auto-update for Windows. Our plan is for Vidalia to look at the majority-signed network status consensus to decide when to update and to what version (Tor already lists what versions are considered safe, in each network status document). We should actually do the update via Tor if possible, for additional privacy, and we need to make sure to check package signatures to ensure package validity. Last, we need to give the user an interface for these updates, including letting her opt to migrate from one major Tor version to the next.

We continued enhancements to the Chinese and Russian Tor website translations. Vidalia also added a Turkish translation.

From the Vidalia 0.1.3 ChangeLog:
"If we're running Tor >= 0.2.0.13-alpha, then check the descriptor annotations for each descriptor before deciding to do a geoip lookup on its IP address. If the annotations indicate it is a special purpose descriptor (e.g., bridges), then don't do the lookup at all."

"Remove the 'Run Tor as a Service' checkbox. Lots of people seem to be clicking it even though they don't really need to, and we end up leaving them in a broken state after a reboot."

"Only display the running relays in the big list of relays to the left of the network map. Listing a big pile of unavailable relays is not particularly useful, and just clutters up the list."

We worked toward a Torbutton 1.2.0rc1 release candidate, which will include support for Firefox 3 along with a huge pile of privacy-related bugfixes.

We spent much of the first half of May dealing with a surprise massive security vulnerability in a crypto library that comes with Debian:
http://archives.seul.org/or/announce/May-2008/msg00000.html

You can read a more detailed explanation of the effects of the flaw here:
https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mea...

Part of dealing with the flaw meant doing some quick design work so we could let new Tor users be safe without making it so old Tor users were cut off from the network:
https://www.torproject.org/svn/trunk/doc/spec/proposals/136-legacy-keys....

Sometime in late June or early July we will disable this workaround, meaning all the 0.2.0.x users who haven't upgraded yet will be cut off.

We are preparing for the Tor gathering at the Privacy Enhancing Technologies Symposium in Leuven in July. This is looking like it will be the largest physical gathering of Tor developers ever -- main developers attending include Roger Dingledine, Nick Mathewson, Jacob Appelbaum, Mike Perry, Matt Edman, Steven Murdoch, and Karsten Loesing; Tor researchers include Paul Syverson and Ian Goldberg; and we'll have 5 of our 7 Google Summer of Code students there as well.
https://blog.torproject.org/events/roger%2C-nick%2C-steven%2C-matt%2C-ka...
http://petsymposium.org/2008/program.php

The upcoming TBB release in June will include optional instant messaging support via Pidgin + Off-The-Record Messaging; replace the startup batch script with an actual application (named RelativeLink), so TBB now has a helpful Tor icon rather than an ugly batch file icon; and optionally support using WinRAR to produce a self-extracting split bundle.

We now have a more thorough set of TBB build instructions:
https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL

We also documented the build and deploy process for a new TBB version:
https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/DEPLOYMENT

We finished integrating a UPnP library into Vidalia. This feature allows users who want to set up a Tor relay but don't want to muck with manual port forwarding on their router/firewall to just click a button and have Vidalia interact with their router/firewall automatically. This approach won't work in all cases, but it should work in at least some. The upcoming Vidalia 0.1.4 (scheduled for June) release has folded the UPnP library and GUI changes into the main Vidalia tree, along with a "test" button to try speaking UPnP at the local router and tell the user whether it worked; these features will be available by default in the 0.2.0.x stable release.

We spent May hunting for a better online translation option, since Launchpad (intended to be used for Vidalia translation) has an ugly interface and can't handle our file formats well, and Babelzilla (intended to be used for Torbutton translation) artificially limited the number of concurrent translators we could have.

In early June we hit upon Pootle, which is a translation server that we host, as opposed to a shared web service that other organizations host. We've set up a test server at http://translation.torproject.org/ and imported strings for Vidalia, Torbutton, and Torcheck. We hope to have a lot more to show here in June.