January 2009 Progress Report

New releases, new hires, new funding

Tor (released January 6) fixes two major bugs in bridge
relays (one that would make the bridge relay not so useful if it had
DirPort set to 0, and one that could let an attacker learn a little bit
of information about the bridge's users), and a bug that would cause your
Tor relay to ignore a circuit create request it can't decrypt (rather
than reply with an error). It also fixes a wide variety of other bugs.

Tor (released Jan 20) finishes fixing the "if your Tor is
off for a week it will take a long time to bootstrap again" bug. It also
fixes an important security-related bug reported by Ilja van Sprundel. You
should upgrade. (We'll send out more details about the bug once people
have had some time to upgrade.)

Tor (released Jan 21) fixes a variety of bugs that were making
relays less useful to users. It also finally fixes a bug where a relay or
client that's been off for many days would take a long time to bootstrap.

Tor Browser Bundle 1.1.8 (released Jan 22) updates Tor to
(security update), updates OpenSSL to 0.9.8j (security update), updates
Firefox to 3.0.5, updates Pidgin to 2.5.4, and updates libevent to 1.4.9.

This month we also hired three new people: Martin Peck is working on
Tor VM, a new way of packaging Tor on Windows that will let people use
Youtube safely again; Mike Perry is working on Torbutton maintenance
and development and on Torflow, a set of scripts to do measurements on
the Tor network; and Andrew Lewman is our new executive director.

Major bugfixes in the Tor and releases:
- If the cached networkstatus consensus is more than five days old,
discard it rather than trying to use it. In theory it could be useful
because it lists alternate directory mirrors, but in practice it just
means we spend many minutes trying directory mirrors that are long
gone from the network. Helps bug 887 a bit; bugfix on 0.2.0.x.

Tor contains cleanups that let Tor build on Google's
Android phone:
- Change our header file guard macros to be less likely to conflict
with system headers. Adam Langley noticed that we were conflicting
with log.h on Android.

Major bugfixes in the Tor and releases:
- Discard router descriptors as we load them if they are more than
five days old. Otherwise if Tor is off for a long time and then
starts with cached descriptors, it will try to use the onion
keys in those obsolete descriptors when building circuits. Bugfix
on 0.2.0.x. Fixes bug 887.

Security bugfixes in the Tor and releases:
- Fix a heap-corruption bug that may be remotely triggerable on
some platforms. Reported by Ilja van Sprundel.

Circuit-building speedups in Tor
- When a relay gets a create cell it can't decrypt (e.g. because it's
using the wrong onion key), we were dropping it and letting the
client time out. Now actually answer with a destroy cell. Fixes
bug 904. Bugfix on 0.0.2pre8.

Scalability fixes from the Tor ChangeLog:
- Clip the MaxCircuitDirtiness config option to a minimum of 10 seconds,
and the CircuitBuildTimeout to a minimum of 30 seconds. Warn the user if
lower values are given in the configuration. These fixes prevent a user
from rebuilding circuits too often, which can be a denial-of-service
attack on the network.
- When a stream at an exit relay is in state "resolving" or
"connecting" and it receives an "end" relay cell, the exit relay
would silently ignore the end cell and not close the stream. If
the client never closes the circuit, then the exit relay never
closes the TCP connection. Bug introduced in Tor;
reported by "wood".
- When sending CREATED cells back for a given circuit, use a 64-bit
connection ID to find the right connection, rather than an addr:port
combination. Now that we can have multiple OR connections between
the same ORs, it is no longer possible to use addr:port to uniquely
identify a connection.

Bootstrapping speedups in Tor
- When our circuit fails at the first hop (e.g. we get a destroy
cell back), avoid using that OR connection anymore, and also
tell all the one-hop directory requests waiting for it that they
should fail. Bugfix on

Proposal 158 ("Clients download consensus + microdescriptors") suggests a
new way forward for reducing directory overhead for clients, and replaced
part of proposal 141. Rather than modifying the circuit-building protocol
to fetch a server descriptor inline at each circuit extend, we instead put
all of the information that clients need either into the consensus itself,
or into a new set of data about each relay called a microdescriptor.

From the ChangeLog:
- Never use OpenSSL compression: it wastes RAM and CPU trying to compress
cells, which are basically all encrypted, compressed, or both. It also
made us stand out from other applications on the wire.

Jillian York continued blogging for us about the good uses of Tor:

"Federico Heinz advocates anonymous browsing in Argentina", Jan 8

"Human Rights Organizations in Argentina welcome anonymous browsing", Jan 25

"Watch how you get around", Jan 30

Pre-configured bundles
Tor Browser Bundle 1.1.8 (released Jan 22) updates Tor to
(security update), updates OpenSSL to 0.9.8j (security update), updates
Firefox to 3.0.5, updates Pidgin to 2.5.4, and updates libevent to 1.4.9.

We continued work on Vidalia features to support where we want Tor
Browser Bundle to go. In particular, we're changing it to be able to
launch Firefox natively, rather than use the "PortableFirefox" pile of
complex scripts. We hope this change will also let users run a normal
Firefox alongside TBB. More on that in February.

We also continued work on Tor VM, a new way of packaging Tor on
Windows that will (among other things) let people use Youtube safely
again. Hopefully we'll have some simple instructions up about that in
February too.

Major bugfixes in the Tor and releases:
- Bridge relays that had DirPort set to 0 would stop fetching
descriptors shortly after startup, and then briefly resume
after a new bandwidth test and/or after publishing a new bridge
descriptor. Bridge users that try to bootstrap from them would
get a recent networkstatus but would get descriptors from up to
18 hours earlier, meaning most of the descriptors were obsolete
already. Reported by Tas; bugfix on
- Prevent bridge relays from serving their 'extrainfo' document
to anybody who asks, now that extrainfo docs include potentially
sensitive aggregated client geoip summaries. Bugfix on

Bugfixes in the Tor release:
- When we made bridge authorities stop serving bridge descriptors over
unencrypted links, we also broke DirPort reachability testing for
bridges. So bridges with a non-zero DirPort were printing spurious
warns to their logs. Bugfix on Fixes bug 709.

New feature in Tor
- New controller event "clients_seen" to report a geoip-based summary
of which countries we've seen clients from recently. Now controllers
like Vidalia can show bridge operators that they're actually making
a difference.
Vidalia will add support for this feature in February.

Alternate download methods
Our "gettor" email auto-responder is up and working:

Thandy itself is working smoothly at this point too -- it can contact
the central repository, check all the keys, look in the registry and
compare the currently installed version to the new choices, fetch the
right packages, check all the signatures, and launch the install.

As of December we only had a new MSI-based installer for Tor, but not for
Vidalia, Torbutton, or Polipo. Now we do, though it's still in testing:

Our translation server is up and online:

We continued enhancements to the Chinese and Russian Tor website
translations. Our Farsi translation from this summer is slowly becoming
obsolete; we should solve that at some point.


February 23, 2009


Nodoubt TOR is the best. But i would have liked it better if the TOR proxy rotations can be disabled. They change too frequently. Also it would have been better if we can select the end nodes of the proxy when connecting.

Is there a way to do it??

Let me know if there is way to tweak TOR because i didn't find it yet anywhere written.



February 25, 2009

In reply to by An (not verified)


Tor rocks so much, that it is tweaked by default.

Why should someone give away software, which isn't configured/tweaked as good as possible?!

BTW: It's Tor not TOR. See the logos..

TOR or Tor or T-O-R, search engines take it the same way.

And anyway, In Tor i don't like that automatic tweak feature which changes the ip address randomly all the time. If i want to use a usa ip for some time, there is no way to have it fixed and working because the next moment it uses germany ip. And i get blocked again on the websites.

This is the only reason why i have limited my use of Tor.

1) Use TrackHostExits, so that your IP doesn't change every so many minutes. See more details at https://www.torproject.org/tor-manual.html.en

2) # Use exit nodes in GB.
ExitNodes {gb}

# Use exit nodes in countries that have won the World Cup
# recently. Also use any exit node at MIT.
ExitNodes {it}, {br}, {fr},

# Don't use an exit node in any country that is sinking under
# water.
ExcludeExitNodes {mv}


February 23, 2009


Dear Tor Project,
First let me sincerely thank you for your continuous and tireless efforts to provide us with security and freedom of information on the Internet. I just love Tor, especially Tor VM that works great!
I am an English teacher living in Iran. I have a BA in Farsi language and Literature from Yazd University. If you need any help with your Farsi translation, please do not hesitate to let me know. I would be glad to be of any assistance and play a small role in Tor success.
Kind regards


February 25, 2009


Would it be non-trivial to have the MapAddress option behave like TrackHostExits?
That is, if an entry is like
MapAddress .rapidshare.com .rapidshare.com.exitpoint.exit
have it applied to rs1xx.rapidshare.com, rs223dt.rapidshare.com, rs28tl2.rapidshare.com...

I already have such a line in my TORRC file; on start TOR doesn't complain, but apparently it doesn't have any effect. The alternative would be to add 5000-odd MapAddress lines specifying every possible hostname given Rapidshare's current naming convention, but I don't know how TOR would handle it; my connections drop (flaky company proxy) often enough already...

I already have the TrackHostExits enabled for both rapidshare.com and .rapidshare.com, so when rapidshare.com redirects me to whatever.rapidshare.com TOR will reuse the existing circuit; however, if the connection drops and it takes longer than TrackHostExitsExpire to reestablish, TOR will open a new circuit with a different exit point (and Rapidshare will claim I've shared my account and lock it... T_T ).