[tor-dev] Tor proposals implemented in Tor 0.2.3.x

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

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.)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev