Hi, all!

Since 0.2.3 just entered beta (and will be in release-candidate status soon if I have anything to say about it!) I wanted to put out a summary of the Tor proposals that got merged, to the best of my knowledge, in the Tor 0.2.3.x series.

My next email will summarize still-open proposals.

(Note on credits: I'm copying the listed credits from the proposals, their acknowledgments sections, and my incredibly lossy memory. But in every case, these designs were improved enormously through feedback from the entire Tor community, including some design stalwarts who take the time to give feedback on all nearly all the proposals they see. Thanks to everyone, and apologies to everybody whom I'm forgetting here.)

IMPLEMENTED IN 0.2.3.x

110 Avoiding infinite length circuits

We started this one a while ago back in 0.2.1.3-alpha. It provides a mechanism to try to limit the resource-multiplier that a DOS attacker can get against the Tor network by building very long circuits, by limiting the maximum circuit length. We had clients implement the new behavior in 0.2.1.3-alpha, and fixed some bugs related to it in the 0.2.2.x series. It's only now that all of the older versions that don't support it are obsolete that we can actually turn on the attack prevention.

(Proposal by Roger Dingledine based on ideas by Christian Grothoff.)

158 Clients download consensus + microdescriptors 162 Publish the consensus in multiple flavors

In the "Microdescriptors" design, clients download a summary of router descriptors rather than the entire set of signed router descriptors. This can save a large amount of directory bandwidth -- both because microdescriptors are smaller than router descriptors, and because they're designed to change much less frequently.

Rather than being signed by the routers themselves, microdescriptors are listed by their digests in a consensus document signed by a threshold of directory authorities. (This change doesn't change the threat model, since a successful attack against either system requires adversary who can subvert a majority of directory authorities.)

We anticipate that we might want to serve the consensus in more than one format in the future, so proposal 162 introduces a notion of "consensus flavors" such that any every consensus vote produces a signed consensus in all the formats, caches cache all the formats, and clients download only those they need.

(Proposal 158 by Roger Dingledine, revised a bunch by Nick Mathewson. Proposal 162 by Nick Mathewson, influenced by design discussions with Marian on IRC.)

180 Pluggable transports for circumvention

We introduce "Pluggable transports": a specified way for Tor bridges and Tor bridge users to configure external programs to obfuscate or re-route traffic to avoid censorship.

This is a pretty big deal: it's what lets Tor integrate will with Obfsproxy and similar tools. As we've hoped, having a specified way to integrate with Tor has encouraged others to work on obfuscation tools. Having it ready to go has helped us deal with unexpected censorship events over the past year, and we think that having a couple of other obfuscators up our sleeve will help more in the future.

(Proposal by Jacob Appelbaum and Nick Mathewson, with heavy revisions based on George Kadianakis's experience implementing it.)

171 Separate streams across circuits by connection metadata

Here's a big security improvement.

In earlier versions of Tor, there wasn't a good way to force streams onto separate circuits. This could make for trouble, since all streams sent over the same circuit are definitively linkable by the exit node, and probabilistically linkable by the destinations. (For example, if you make a connection to an SSH host and log into a website over the same circuit, the exit node can learn that the same person has accounts both at the SSH host and the website. If the SSH host and website are colluding, then over time, they can become certain which account on the SSH host corresponds with which activities on the website.)

Starting with Tor 0.2.3, we provide a number of ways for users and integrators to tell Tor not to put the two streams on the same circuit. By default, two streams won't go on the same circuit if they arrive at different Tor client ports (one goes to SOCKSPort 9050 and one goes to SOCKSPort 9051); or if they come from different client addresses (one came from 127.0.0.1, the other from 10.0.10.10); or if they provide different username/password information in their SOCKS handshakes. Additionally, you can configure Tor to isolate connections by destination address, destination port, and chosen client protocol. See the manual page for SOCKSPort for more information.

(Proposal by Robert Hogan, Jacob Appelbaum, Damon McCoy, and Nick Mathewson, based on ideas from a whole bunch of people.)

174 Optimistic Data for Tor: Server Side 181 Optimistic Data for Tor: Client Side

This one is a performance hack that hasn't seen its full impact yet. Starting with Tor 0.2.3.x, clients MAY send data to the exit node before finding out whether the exit has been able to successfully connect to the destination server. Previously, it took an extra round trip for clients to wait to see whether the exit said "Yes, I'm connected" before they were allowed to send data for the exit.

This should make connection startup faster in many protocols where the client speaks first (http, https), as more and more client programs gain support for it.

(Proposal by Ian Goldberg.)

176 Proposed version-3 link handshake for Tor 184 Miscellaneous changes for a v3 Tor link protocol 187 Reserve a cell type to allow client authorization

Here's the crypto-heavy one for 0.2.3. In earlier Tors, we used two different link protocol variants to get the TLS authentication we wanted without being too fingerprintable. In Tor before 0.2.0, we used a "v1" link protocol, where both sides swapped pretty stereotyped certificate chains in the initial handshake, and were as fingerprintable as all get-out. From 0.2.0 through 0.2.2, we've been using a "v2" link protocol, where the connection initiator launched a renegotiation immediately upon making a successful connection. But as anybody who's used TLS renegotiations knows, they are a pain to work with. Moreover, their presence on the wire is visible, and provides another fingerprint for Tor connections.

With the new "v3" link protocol, clients perform an initial TLS handshake, and then use that handshake to bootstrap the trust and authentication they wanted in a less fragile, less fingerprintable manner.

Proposal 184 made variable-length cells more pratical, and added a variable-length padding type.

Since proposal 176 introduced a requirement that no extraneous cells be sent during the handshake, proposal 187 reserves an extra cell type for future use in pre-handshake authentication.

(Proposal 176 by Nick Mathewson, based on an earlier idea by Steven Murdoch, with feedback from Gladys Shufflebottom. Proposal 184 by Nick Mathewson. Proposal 187 by Nick Mathewson based on/influenced by discussions with George Kadianakis and Robert Ransom.)

178 Require majority of authorities to vote for consensus parameters

This one makes us more robust against a rogue directory authority. Previously, a misbehaving authority could set an integer parameter unilaterally, so long as it was the first to hear of that parameter, or the only one to have an opinion. With this proposal implemented, a larger number of authorities must want to vote on a consensus parameter for any vote on that parameter to take place.

(Proposal by Sebastian Hahn.)

179 TLS certificate and parameter normalization

This proposal made a bunch of small but important tweaks to try to emit more normal-looking TLS certificates, to help prevent certificate-based fingerprinting. It didn't all get implemented and stable in time for 0.2.3.x; the remainder is now proposal 195.

(Proposal by Jacob Appelbaum and Gladys Shufflebottom.)

183 Refill Intervals

Tor uses a token-bucket implementation for its rate- limiting strategy. Previously, Tor refilled these token buckets once per second. But this approach seems to have led to choppy behavior, where we exhaust our bandwidth early in the second, and spend the rest of the second sitting around. The new default is 100 msec, but now it's configurable.

(Proposal by Florian Tschorsch and Bjorn Scheuermann.)

PARTIALLY IMPLEMENTED IN 0.2.3.x

186 Multiple addresses for one OR or bridge

We've implemented this to the extent of letting a bridge have a single IPv6 address. Supporting this for regular relays will need to wait for 0.2.4.x. We're still deciding on whether it's worthwhile to allow more than one IPv4 and one IPv6 address.

(Proposal by Nick Mathewson, revised based on extensive feeback by Roger Dingledine and Linus Nordberg.)

198 Restore semantics of TLS ClientHello

In an attempt to impersonate Firefox clients under the eyes of watchful censors, earlier versions of Tor would sometimes claim to support TLS ciphersuites that they didn't. This would cause trouble if we ever wanted to negotiate a cipher other than those which we happen to know that all Tor clients support, since we can't count on the TLS ClientHello actually telling which ciphers are supported.

This proposal provides us with a backward compatible way to migrate ciphersuite lists, emulate new browser fingerprints, and actually use ciphersuites that didn't exist in 2005.

The client side of this proposal is implemented in 0.2.3; the server side will have to wait for 0.2.4.

(Proposal by Nick Mathewson.)