bridges

The Tor Cloud images have been updated to include the latest version of Ubuntu 12.04.2 LTS (Precise Pangolin). An instance created from any of the images will automatically be a normal bridge, an obfs2 bridge, and an obfs3 bridge.

When setting up an instance, please remember to edit the security group with the following rules: SSH (22), HTTPS (443), 40872, and 52176.

The Tor Cloud images for all the eight regions have been updated with a minor fix in the rc.local script. In addition, all private bridge images now include Obfsproxy. You will not need to start a new instance if you are already running a Tor Cloud instance with Ubuntu Precise.

The Tor Cloud images for all the seven regions have been updated to include the latest cloud image for stable Ubuntu release 12.04.1 LTS (Precise Pangolin). These new images are available on the Tor Cloud website. You will not need to start a new instance you are already running a Tor Cloud instance with Ubuntu Precise.

The Tor Cloud images for all the seven regions have been updated to fix a bug found in the unattended-upgrades configuration. The normal bridge images have also been updated to include obfsproxy, which attempts to help users circumvent censorship by transforming the Tor traffic between the client and the bridge.

If you are already running a Tor Cloud bridge, you will need to either manually update your image, or set up a new Tor Cloud bridge and terminate the old one. If you decide not to take action, your image will fail to upgrade Tor correctly and will not be running as a bridge.

If you just want to fix the bug in the unattended-upgrades configuration, do the following; log on with SSH and edit /etc/apt/apt.conf.d/50unattended-upgrades to say precise instead of lucid.

The Tor Cloud images for all the seven regions have been updated to include the latest cloud image for stable Ubuntu release 12.04.1 LTS (Precise Pangolin). These new images are available on the Tor Cloud website.

The new images include Tor's new GPG key, uses apt-get instead of aptitude, and also includes the deb.torproject.org-keyring package (#6776).

If you are already running a Tor Cloud bridge, you will need to either manually update your image, or set up a new Tor Cloud bridge and terminate the old one. If you decide not to take action, your image will fail to upgrade Tor correctly and will not be running as a bridge. To manually update your image; log on with SSH, and follow the instructions to add the new GPG key, upgrade Tor, and install the deb.torproject.org-keyring package.

The Tor Cloud images for all the seven regions have been updated to include the latest cloud image for stable Ubuntu release 10.04 LTS (Lucid Lynx). These new images are available on the Tor Cloud website.

The new images include a fix to allow Tor to upgrade automatically without requiring user intervention (#6511).

If you are already running a Tor Cloud bridge, you will need to either manually update your image, or set up a new Tor Cloud bridge and terminate the old one. If you decide not to take action, your image will fail to upgrade Tor correctly and will not be running as a bridge.

To manually update your image, do the following:

0. Log on with SSH
1. Open /etc/apt/apt.conf.d/50unattended-upgrades
2. Add the line: Dpkg::Options { --force-confold; }
3. Save and exit

Although Tor was originally designed to enhance privacy, the network is increasingly being used to provide access to websites from countries where Internet connectivity is filtered. To better support this goal, Tor introduced the feature of bridge nodes – Tor nodes which route traffic but are not published in the list of available Tor nodes. Consequently bridges are commonly not blocked in countries where access to the public Tor nodes are (with the exception of China and Iran).

For bridge nodes to work well, we need lots of them. This is both to make it hard to block them all, and also to provide enough bandwidth capacity for all their users. To help achieve this goal, the Tor Browser Bundle now makes it as easy as clicking a button to turn a normal Tor client into a bridge. The upcoming version of Tor will even set up port forwarding on home routers (through UPnP and NAT-PMP) to make it easier still.

There are, however, potential risks to Tor users if they turn their client into a bridge. These were summarized in a paper by Jon McLachlan and Nicholas Hopper: "On the risks of serving whenever you surf". I discussed these risks in a previous blog post, along with ways to mitigate them. In this blog post I'll cover some initiatives the Tor project is working on (or considering), which could further reduce the risks.

The attack than McLachlan and Hopper propose involves finding a list of bridges, and then probing them over time. If the bridge responds at all, then we know that the bridge operator could be surfing the web though Tor. So, if the attacker suspects that a blogger is posting through Tor and the blogger's Tor client is also a bridge, then only the bridges which are running at the time a blog post was written could belong to the blogger. There are likely to be quite a few such bridges, but if the attack is repeated, the set of potential bridge IP addresses will be narrowed down.

What is more, the paper also proposes measuring how quickly each bridge responds, which might tell the attacker something about how heavily the bridge operator is using their Tor client. If the attacker probes the rest of the Tor network, and sees a node with performance patterns similar to the bridge being probed, then it is likely that there is a connection going through that node and that bridge. In some circumstances this attack could be used to track connections all the way through the Tor network, and back to a client who is also acting as a bridge.

One way of reducing the risk of these attacks succeeding is to run the bridge on a device which is always on. In this case, just because a bridge is running doesn't mean the operator is using Tor. Therefore less information is leaked to a potential attacker. As laptops become more prevalent, keeping a bridge on 24/7 can be inconvenient so the Tor Project is working on two bits of hardware (known as Torouters) which can be left running a bridge even if the user's computer is off. If someone probes the bridge now, they can't learn much about whether the operator is using Tor as a client, and so it leaks less information about what the user is doing.

Having an always-on bridge helps resist profiling based on when a client is on. However, evaluating the risk of profiling based on bridge performance is more complex. The reason this attack works is that when a node is congested, increasing traffic on one connection (say, due to the bridge operator using Tor) decreases the traffic on another (say, the attacker probing the bridge). If you run a Tor client on your PC, and a Tor bridge on a separate device, this reduces the opportunity for congestion on one leading to congestion on the other. However, there is still the possibility for congestion on the network connection which the bridge and device share, and maybe you do want to use the bridge device as a client too. So the Torouter helps, but doesn't fix the problem.

To fully decouple bridges from clients, they need to run on different hardware and networks. Here the Tor Cloud project is ideal – bridges run on Amazon's (or another cloud provider's) infrastructure so congestion on the bridge can't affect the Tor client running on your PC, or it's network.

But maybe you do want to use your bridge as a client for whatever reason. Recall that the first step of the attack proposed by McLachlan and Hopper is to find the bridges' IP addresses. This is becoming increasingly difficult as more bridges are being set up. Also, there is work in progress to make it harder to scan networks for bridges. Originally this was intended to make it harder to find and block bridges, but it applies equally well to preventing probing. These schemes (e.g. BridgeSPA by Smits et. al.) mean that just because you have a bridge's IP address, it doesn't mean that you can route traffic through it (to measure performance) or even check if the bridge is running. To do either, you need to have a secret which is distributed only to authorized users of the bridge.

There is still more work to be done in protecting bridge operators, but the projects discussed above (and in the previous blog post) certainly improve the situation. Work continues both in academia and at the Tor Project to better understand the problem and develop further fixes.

The Tor network relies on volunteers to donate bandwidth. The more people who run Tor as a bridge or a relay, the faster and safer the network becomes. Tactical Tech created a video to encourage you to join the Tor Network. The video, and information about how you can set up a bridge or a relay, can be found on https://www.torproject.org/relays. If you want to help us translate the video into your language, let us know!

The full HD video can be found here: https://media.torproject.org/video/2012-03-04-BuildingBridges-HD.ogv

On Feb 9, Iran started to filter SSL connections on much of their network. Since the Tor protocol uses SSL, that means Tor stopped working too — even Tor with bridges, since bridges use SSL too.

We've been quietly developing Obfsproxy, a new tool to make it easier to change how Tor traffic looks on the network. In late 2011 Iran moved into the #2 position in global Tor user count, and several important political events are scheduled in Iran this month and next. This situation seemed like a good time to test our new tool while also helping improve Internet freedom around the world.

We started with a "Tor Obfsproxy Browser Bundle" with two test obfsproxy bridges in it, to verify that it worked in-country. Then we got over 300 volunteers running more obfsproxy bridges (even with our complex build instructions!), and picked fourteen fast stable trustworthy obfsproxy bridges for an updated bundle which we put out the morning of Feb 11. We spent the weekend fixing usability, stability, and scalability bugs, and put out another bundle on Feb 13 with new versions of Vidalia, Tor, and Obfsproxy.

Thousands of people in Iran successfully used the Obfsproxy Bundle over the weekend:

We did some spot-checking and it seems that the new addresses on Feb 14 are mostly different from the new addresses on Feb 13; but I would guess these are mostly returning users with dynamic IP addresses, rather than actually fresh users. More importantly, these people will be thinking about Obfsproxy next time the filter cracks down — and based on current events, that next time won't be far off. Finally, even though it looks like SSL and Tor are back, I expect Iran will keep throttling SSL traffic as they've been doing for months, so the Obfsproxy bundle will still be more fun to use in Iran than the normal Tor bundles.

How does it work?

Deep Packet Inspection (DPI) algorithms classify Internet traffic by protocol. That is, they look at a given traffic flow and decide whether it's http, ssl, bittorrent, vpn, etc. Governments like Iran, China, and Syria increasingly use these tools (and they often purchase them from Western corporations, but that's a different story) to implement their country-wide censorship, either by looking for a given protocol and outright blocking it, or by more subtle mechanisms like squeezing down the bandwidth available to a given protocol to discourage its use.

Obfsproxy's role is to make it easy for Tor's traffic flows to look like whatever we like. This way Tor can focus on security and anonymity, and Obfsproxy can focus on appearance. The first thing we decided to try looking like was nothing at all: the "obfs2" module adds an encryption wrapper around Tor's traffic, using a handshake that has no recognizable byte patterns.

It won't work perfectly. For example, the traffic flows will still have recognizable timing, volume, and packet size characteristics; a good entropy test would show that the handshake looks way more random than most handshakes; and the censors could always press the "only allow protocols my DPI box recognizes" panic button. Each step in this arms race aims to force the censor to a) put more development time and DPI resources into examining flows, and b) risk more false positives, that is, risk blocking innocent users that they didn't realize they'd be blocking.

This particular new obfuscating layer isn't the most important feature of Obfsproxy. The best part is that makes it easy to design, deploy, and test other obfuscating layers without messing with the rest of Tor. There's a lot of research into trying to make traffic flows look like other protocols, so for example we could rewrite the Tor flows as valid http that the DPI engine considers harmless. That problem is harder than it sounds — and it sounds hard. But by making a separate component that only has to worry about how the traffic looks, other researchers can try out different strategies without needing to learn so much about the rest of Tor. This approach will also let us easily plug in other transports like Telex, and it will also let other circumvention projects reuse Obfsproxy so they don't have to reinvent our wheels.

Moving forward

One of the choices we faced was how widely and loudly to mention the bundle. While we think it would be hard and/or risky for attackers to block the Obfsproxy protocol, the bundle included 14 preconfigured bridge addresses, and censors could just plug those addresses into their blacklists. We started the weekend telling people to only tell their close friends, but on Sunday we opted for a broader publicity push inside the activist community for two reasons. First, the new Vidalia release (0.2.17) lets users configure their own obfsproxy bridge addresses, so if the preconfigured addresses get blocked the user can just put in new ones. Second, it became clearer that the blocking would let up in a few days once the immediate political pressure was over, and we decided it was more important to get the word out about Obfsproxy in general so these users will know about it next time.

I should point out that I don't think they were targeting Tor here. They were targeting popular websites that use SSL, like Gmail and Facebook. Tor was collateral damage because we opted to make Tor traffic look like SSL. That said, we should not forget that we are on their radar: they targeted Tor by DPI in September 2011, and the Diginotar breakin obtained a fake SSL cert for torproject.org.

The next choice we face is: what other communities should we tell? The bundle works great in China too, where their aggressive censorship has been a real hassle for us the past year or so. Some other countries in Asia appear to be newly using DPI to recognize Tor traffic (more on that in an upcoming blog post). We have more development work to do before we can keep up with the China arms race, including teaching obfsproxy bridges to automatically report their addresses to us and teaching our bridgedb service to give them out, and we need to answer research questions around getting more bridges, giving them out in smarter ways, learning when they get blocked, and making it hard for censors to find them. We also need to spread the word carefully, since the arms race is as much about not drawing the attention of the censors as it is about the technology. But the Obfsproxy Bundle works out of the box right now in every censoring country we know of, so we shouldn't be too quiet about it.

And finally, thanks go to George Kadianakis for taking Obfsproxy on as his Google Summer of Code 2011 Project; to Nick Mathewson for mentoring him and getting the Obfsproxy architecture going in the right direction; to Sebastian Hahn for spending all weekend with me fixing bugs and making packages; and to Karsten Loesing, Erinn Clark, Robert Ransom, Runa Sandvik, Nick, George, and the broader Tor community for stepping up over the weekend to help us take it from "early prototype" to "deployed software in use by 5000+ people" in 72 hours.

Tor 0.2.3.9-alpha introduces initial IPv6 support for bridges, adds
a "DisableNetwork" security feature that bundles can use to avoid
touching the network until bridges are configured, moves forward on
the pluggable transport design, fixes a flaw in the hidden service
design that unnecessarily prevented clients with wrong clocks from
reaching hidden services, and fixes a wide variety of other issues.

https://www.torproject.org/download

Changes in version 0.2.3.9-alpha - 2011-12-08
Major features:

• Clients can now connect to private bridges over IPv6. Bridges
  still need at least one IPv4 address in order to connect to
  other relays. Note that we don't yet handle the case where the
  user has two bridge lines for the same bridge (one IPv4, one
  IPv6). Implements parts of proposal 186.
• New "DisableNetwork" config option to prevent Tor from launching any
  connections or accepting any connections except on a control port.
  Bundles and controllers can set this option before letting Tor talk
  to the rest of the network, for example to prevent any connections
  to a non-bridge address. Packages like Orbot can also use this
  option to instruct Tor to save power when the network is off.
• Clients and bridges can now be configured to use a separate
  "transport" proxy. This approach makes the censorship arms race
  easier by allowing bridges to use protocol obfuscation plugins. It
  implements the "managed proxy" part of proposal 180 (ticket 3472).
• When using OpenSSL 1.0.0 or later, use OpenSSL's counter mode
  implementation. It makes AES_CTR about 7% faster than our old one
  (which was about 10% faster than the one OpenSSL used to provide).
  Resolves ticket 4526.
• Add a "tor2web mode" for clients that want to connect to hidden
  services non-anonymously (and possibly more quickly). As a safety
  measure to try to keep users from turning this on without knowing
  what they are doing, tor2web mode must be explicitly enabled at
  compile time, and a copy of Tor compiled to run in tor2web mode
  cannot be used as a normal Tor client. Implements feature 2553.
• Add experimental support for running on Windows with IOCP and no
  kernel-space socket buffers. This feature is controlled by a new
  "UserspaceIOCPBuffers" config option (off by default), which has
  no effect unless Tor has been built with support for bufferevents,
  is running on Windows, and has enabled IOCP. This may, in the long
  run, help solve or mitigate bug 98.
• Use a more secure consensus parameter voting algorithm. Now at
  least three directory authorities or a majority of them must
  vote on a given parameter before it will be included in the
  consensus. Implements proposal 178.

Major bugfixes:

• Hidden services now ignore the timestamps on INTRODUCE2 cells.
  They used to check that the timestamp was within 30 minutes
  of their system clock, so they could cap the size of their
  replay-detection cache, but that approach unnecessarily refused
  service to clients with wrong clocks. Bugfix on 0.2.1.6-alpha, when
  the v3 intro-point protocol (the first one which sent a timestamp
  field in the INTRODUCE2 cell) was introduced; fixes bug 3460.
• Only use the EVP interface when AES acceleration is enabled,
  to avoid a 5-7% performance regression. Resolves issue 4525;
  bugfix on 0.2.3.8-alpha.

Privacy/anonymity features (bridge detection):

• Make bridge SSL certificates a bit more stealthy by using random
  serial numbers, in the same fashion as OpenSSL when generating
  self-signed certificates. Implements ticket 4584.
• Introduce a new config option "DynamicDHGroups", enabled by
  default, which provides each bridge with a unique prime DH modulus
  to be used during SSL handshakes. This option attempts to help
  against censors who might use the Apache DH modulus as a static
  identifier for bridges. Addresses ticket 4548.

Minor features (new/different config options):

• New configuration option "DisableDebuggerAttachment" (on by default)
  to prevent basic debugging attachment attempts by other processes.
  Supports Mac OS X and Gnu/Linux. Resolves ticket 3313.
• Allow MapAddress directives to specify matches against super-domains,
  as in "MapAddress *.torproject.org *.torproject.org.torserver.exit".
  Implements issue 933.
• Slightly change behavior of "list" options (that is, config
  options that can appear more than once) when they appear both in
  torrc and on the command line. Previously, the command-line options
  would be appended to the ones from torrc. Now, the command-line
  options override the torrc options entirely. This new behavior
  allows the user to override list options (like exit policies and
  ports to listen on) from the command line, rather than simply
  appending to the list.
• You can get the old (appending) command-line behavior for "list"
  options by prefixing the option name with a "+".
• You can remove all the values for a "list" option from the command
  line without adding any new ones by prefixing the option name
  with a "/".
• Add experimental support for a "defaults" torrc file to be parsed
  before the regular torrc. Torrc options override the defaults file's
  options in the same way that the command line overrides the torrc.
  The SAVECONF controller command saves only those options which
  differ between the current configuration and the defaults file. HUP
  reloads both files. (Note: This is an experimental feature; its
  behavior will probably be refined in future 0.2.3.x-alpha versions
  to better meet packagers' needs.)

Minor features:

• Try to make the introductory warning message that Tor prints on
  startup more useful for actually finding help and information.
  Resolves ticket 2474.
• Running "make version" now displays the version of Tor that
  we're about to build. Idea from katmagic; resolves issue 4400.
• Expire old or over-used hidden service introduction points.
  Required by fix for bug 3460.
• Move the replay-detection cache for the RSA-encrypted parts of
  INTRODUCE2 cells to the introduction point data structures.
  Previously, we would use one replay-detection cache per hidden
  service. Required by fix for bug 3460.
• Reduce the lifetime of elements of hidden services' Diffie-Hellman
  public key replay-detection cache from 60 minutes to 5 minutes. This
  replay-detection cache is now used only to detect multiple
  INTRODUCE2 cells specifying the same rendezvous point, so we can
  avoid launching multiple simultaneous attempts to connect to it.

Minor bugfixes (on Tor 0.2.2.x and earlier):

• Resolve an integer overflow bug in smartlist_ensure_capacity().
  Fixes bug 4230; bugfix on Tor 0.1.0.1-rc. Based on a patch by
  Mansour Moufid.
• Fix a minor formatting issue in one of tor-gencert's error messages.
  Fixes bug 4574.
• Prevent a false positive from the check-spaces script, by disabling
  the "whitespace between function name and (" check for functions
  named 'op()'.
• Fix a log message suggesting that people contact a non-existent
  email address. Fixes bug 3448.
• Fix null-pointer access that could occur if TLS allocation failed.
  Fixes bug 4531; bugfix on 0.2.0.20-rc. Found by "troll_un".
• Report a real bootstrap problem to the controller on router
  identity mismatch. Previously we just said "foo", which probably
  made a lot of sense at the time. Fixes bug 4169; bugfix on
  0.2.1.1-alpha.
• If we had ever tried to call tor_addr_to_str() on an address of
  unknown type, we would have done a strdup() on an uninitialized
  buffer. Now we won't. Fixes bug 4529; bugfix on 0.2.1.3-alpha.
  Reported by "troll_un".
• Correctly detect and handle transient lookup failures from
  tor_addr_lookup(). Fixes bug 4530; bugfix on 0.2.1.5-alpha.
  Reported by "troll_un".
• Use tor_socket_t type for listener argument to accept(). Fixes bug
  4535; bugfix on 0.2.2.28-beta. Found by "troll_un".
• Initialize conn->addr to a valid state in spawn_cpuworker(). Fixes
  bug 4532; found by "troll_un".

Minor bugfixes (on Tor 0.2.3.x):

• Fix a compile warning in tor_inet_pton(). Bugfix on 0.2.3.8-alpha;
  fixes bug 4554.
• Don't send two ESTABLISH_RENDEZVOUS cells when opening a new
  circuit for use as a hidden service client's rendezvous point.
  Fixes bugs 4641 and 4171; bugfix on 0.2.3.3-alpha. Diagnosed
  with help from wanoskarnet.
• Restore behavior of overriding SocksPort, ORPort, and similar
  options from the command line. Bugfix on 0.2.3.3-alpha.

Build fixes:

• Properly handle the case where the build-tree is not the same
  as the source tree when generating src/common/common_sha1.i,
  src/or/micro-revision.i, and src/or/or_sha1.i. Fixes bug 3953;
  bugfix on 0.2.0.1-alpha.

Code simplifications, cleanups, and refactorings:

• Remove the pure attribute from all functions that used it
  previously. In many cases we assigned it incorrectly, because the
  functions might assert or call impure functions, and we don't have
  evidence that keeping the pure attribute is worthwhile. Implements
  changes suggested in ticket 4421.
• Remove some dead code spotted by coverity. Fixes cid 432.
  Bugfix on 0.2.3.1-alpha, closes bug 4637.