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.)
