February 2008 Progress Report

by phobos | March 12, 2008

Tor 0.2.0.20-rc (released Feb 24) is the first release candidate for the 0.2.0 series. It makes more progress towards normalizing Tor's TLS handshake, makes hidden services work better again, helps relays bootstrap if they don't know their IP address, adds optional support for linking in openbsd's allocator or tcmalloc, allows really fast relays to scale past 15000 sockets, and fixes a bunch of minor bugs reported by Veracode.
http://archives.seul.org/or/talk/Feb-2008/msg00279.html

Tor 0.2.0.19-alpha (released Feb 9) makes more progress towards normalizing Tor's TLS handshake, makes path selection for relays more secure and IP address guessing more robust, and generally fixes a lot of bugs in preparation for calling the 0.2.0 branch stable.
http://archives.seul.org/or/talk/Feb-2008/msg00134.html

Torbutton 1.1.13 (released Feb 1), 1.1.14 (released Feb 24), and 1.1.15 (released Feb 26) fix many more potential privacy and identity leaks, mostly based on exploits found by Greg Fleischer. They also add support for automatic updates via the usual Firefox extension upgrade approach.
https://torbutton.torproject.org/dev/CHANGELOG

Work continued toward the upcoming Vidalia 0.1.0 release (which came out March 1): support for launching Firefox and Polipo as supporting applications; support for learning from Tor when the first circuit is ready so it can inform the user; and many other bugfixes including a few security fixes.
http://trac.vidalia-project.net/browser/vidalia/releases/vidalia-0.1.0/…

The Tor 0.2.0.19-alpha release contained many security-related cleanups based on an anonymously submitted code review from a static analysis tool. The Tor 0.2.0.20-rc release contained even more security-related cleanups, based on an external security analysis and audit by Veracode. Hopefully cleanups at this stage will reduce the number of times we need to push out an urgent new stable "0.2.0" release for security reasons.

From the Tor 0.2.0.19-alpha ChangeLog:
“When connecting to a bridge without specifying its key, insert the connection into the identity-to-connection map as soon as a key is learned. This prevents the Tor user's log from showing a confusing complaint periodically.”
“When our consensus networkstatus has been expired for a while, stop being willing to build circuits using it. Now clients won't give themselves away by behaving uniquely if they start up with an old networkstatus view.”

From the Tor 0.2.0.20-rc ChangeLog:
“Choose which bridge to use proportional to its advertised bandwidth, rather than uniformly at random. This should speed up Tor for bridge users. Also do this for people who set StrictEntryNodes.”

From the Tor 0.2.0.19-alpha ChangeLog:
“If we're a relay, avoid picking ourselves as an introduction point, a rendezvous point, or as the final hop for internal circuits.”
“Directory caches now fetch certificates from all authorities listed in a networkstatus consensus, even when they do not recognize them. This bugfix is particularly important for bridge users, since the bridges are their only contact point for fetching new directory information.”

From the Tor 0.2.0.20-rc ChangeLog:
“Servers that don't know their own IP address should go to the authorities for their first directory fetch, even if their DirPort is off or if they don't know they're reachable yet. This will help them bootstrap better.”

From the Tor 0.2.0.20-rc ChangeLog:
“We were comparing the raw BridgePassword entry with a base64'ed version of it, when handling a "/tor/networkstatus-bridges" directory request. Now compare correctly. This bugfix should allow bridge communities (formerly known as bridge families) to work better. Noticed by Veracode.”

From the Tor 0.2.0.19-alpha ChangeLog:
“Do not include recognizeable strings in the commonname part of Tor's x509 certificates.”

From the Tor 0.2.0.20-rc ChangeLog:
“Enable the revised TLS handshake based on the one designed by Steven Murdoch in proposal 124, as revised in proposal 130. It includes version negotiation for OR connections as described in proposal 105. The new handshake is meant to be harder for censors to fingerprint, and it adds the ability to detect certain kinds of man-in-the-middle traffic analysis attacks. The version negotiation feature will allow us to improve Tor's link protocol more safely in the future.”

From the Tor 0.2.0.20-rc ChangeLog:
“Tune parameters for cell pool allocation to minimize amount of RAM overhead used.”
“Add OpenBSD malloc code from phk as an optional malloc replacement on Linux: some glibc libraries do very poorly with Tor's memory allocation patterns. Pass --enable-openbsd-malloc to get the replacement malloc code.”
“Stop imposing an arbitrary maximum on the number of file descriptors used for extremely high-throughput servers. Bug reported by Olaf Selke; patch from Sebastian Hahn.”

From the Tor 0.2.0.19-alpha ChangeLog:
“Patch from "Andrew S. Lists" to catch when we contact a directory mirror at IP address X and he says we look like we're coming from IP address X. This was causing some Tor relays to test their reachability by testing the wrong address, and never actually publish to the main list.”

We cleaned up the Tor Browser Bundle's webpage and instructions based on feedback from users who were visiting Iran and Burma. Also started preparations to make it easy for our translators to provide an alternate languages. As of March 10, we have English, German, Italian, Polish, and Russian translations. We are working to coordinate an Arabic translation too.
https://torbrowser.torproject.org/

The new Tor Browser Bundle 0.0.7 (released Feb 8) and 0.0.8 (released Feb 15) include security updates for Firefox (2.0.12), security updates for Torbutton (1.1.13), automate generation of internationalized bundles, allow optional extensions to be placed in build-scripts/extensions, build Polipo with regular expression support (activating the forbiddenFile option), and update Polipo configuration based on suggestions from Incognito's Polipo configuration:
https://tor-svn.freehaven.net/svn/torbrowser/branches/stable/README

Comments

Please note that the comment area below has been archived.

keelort (not verified) said:

March 16, 2008

Permalink

torbutton 1.1.14 alpha 及以后版本(目前1.1.14-1.1.17)存在Locale switch问题
我使用的是英文版本的Firefox 2.0.0.12(en_US)+Locale switch，安装了zh_CN的locale，使用简体中文语言(zh_CN)的locale，但是安装了torbutton 1.1.14 alpha及以后版本，激活torbutton就会变成英文(en_US)的locale
1.1.13没问题

hank (not verified) said:

April 08, 2008

Permalink

OSX 10.4.11, via a Linksys router, static DSL.
It appears I can use Vidalia with Firefox (torbutton works, passes tests)
I can invoke Vidalia from the Dock; it runs a while then quits on its own.
It says I don't have the ORport and DIRport set -- true that.

All I'd want to do -- I think -- is set the thing to relay but without offering any of the checkbox services, just to serve as a router within the system - the Help says that's useful.

Is it safe, at this level of inexpertise? OR should I just wait?

Closest advice I've found online is for Linux, says:

[open the web page for the router]
Go to the advanced tab -> forwarding
set up two applications, ORport, DIRport
select TCP, select 9001 and 9030, and
point them to whatever IP you have on your linux box.
Make sure you tell TOR to advertise your external IP address via torc.

Well, "whatever IP" and "torc" are mysteries.
--------------------

Doesn't quite fit the Linksys. Maybe this should be done in the "Port Range Forwarding" section? I have the help info. But I wonder if I'm not smart enough to be opening the machine up like this, til it's got more assurance of security.

Got a "don't bother me yet trying to be helpful, we'll call you when ready" flag you can set somewhere for folks like me to know when to try to make our machines useful?

I THINK this is right -- not using the internal firewall, using the router.
The FAQ for that seems to be, in full:

-----------begin-----

* If you just use an external NAT router as your firewall, you only need to do the port forwarding through that.

Volunteers: please add advice for other platforms if you know how they work.

----------end--------

COMMENT:

I usually have just the specific IP addresses of the machines attached to the router authorized. So I gather I'd have to add two IP addresses, and in the setup, give a 'range' of only one port number each for ORport and DIRport?

Here's what the Linksys BEFSR says about port forwarding. I am open to advice whether this is what ought to be done:

------LINKSYS_HELP---------

Port Range Forwarding

Port Range Forwarding can be used to set up public services on your network. When users from the Internet make certain requests on your network, the Router can forward those requests to computers equipped to handle the requests. If, for example, you set the port number 80 (HTTP) to be forwarded to IP Address 192.168.1.2, then all HTTP requests from outside users will be forwarded to 192.168.1.2. It is recommended that the computer use static IP address.

You may use this function to establish a web server or FTP server via an IP Gateway. Be sure that you enter a valid IP address. (You may need to establish a static IP address with your ISP in order to properly run an Internet server.) For added security, Internet users will be able to communicate with the server, but they will not actually be connected. The packets will simply be forwarded through the Router.

To add a server using forwarding:

1. Enter an Application name of the service you want to forward.
2. Enter the Port Range Start and End of the service you want to forward.
3. Select the protocol used by the services.
4. Enter the IP Address of the server that you want the Internet users to access.
5. Select Enabled for that entry.
6. Click the Save Settings button to save the settings.

To delete a service entry:

1. Enter a zero number in the Port Range number and IP Address fields.
2. Uncheck the TCP and/or UDP check box and the Enable check box.
3. Clear the Application field.