Different Ways to Use a Bridge

Different Ways to Use a Bridge

When some adversary prevents users from reaching the Tor network, our most popular answer is using bridge relays (or bridges for short). Those are hidden relays, not listed along with all the other relays in the networkstatus documents. Currently, we have about 600 of them, and censors are having different luck learning and blocking them — see the 10 ways to discover Tor bridges blog post for more on how discovery approaches may work. China appears to be the only place able to successfully block most bridges consistently, whereas other places occasionally manage to block Tor's handshake and as a byproduct block all bridges too.

Bridge users can be broadly grouped in three camps:

  • Tor is blocked, and some way — any way — to reach the network has to be found. The adversary is not very dangerous, but very annoying.
  • Tor may or may not be blocked, but the user is trying to hide the fact they're hiding Tor. The adversary may be extremely dangerous.
  • Other bridge users: Testing whether the bridge works (automated or manual), probing, people using bridges without their knowledge because they came pre-configured in their bundle.

Here we examine the first two use cases more closely. Specifically, we want to look at properties of a bridge that must exist for it to be useful to a user.

Bridges — building blocks

First off, it is helpful to understand some basics about bridges and how they are used by normal users.

Bridges are very similar to ordinary relays, in that they are operated by volunteers who made the decision to help people reach the Tor network. The difference to a normal relay is where the information about the bridge is published to — bridges can choose to either publish to the Bridge Authority (a special relay collecting all bridge addresses that it receives), or to not publish their information anywhere. The former are called public bridges, the latter private bridges.

We don't have any information about the number of private bridges, but since the Bridge Authority collects data about the public bridges, we do know that bridges are used in the real world. See the bridge users and networksize graphs for some examples. Not having data about private bridges or their users means some of the analysis below is based on discussions with users of private bridges and our best estimates, and it can't be backed up by statistical data.

The reason we're using a Bridge Authority and collecting information about bridges is that we want to give out bridges to people who aren't in a position to learn about a private bridge themselves.

"Learning about a bridge" generally means learning about the bridge's IP address and port, so that a connection can be made. Optionally, the bridge identity fingerprint is included, too — this helps the client to verify that it is actually talking to the bridge, and not someone that is intercepting the network communication. For a private bridge, the operator has to pass on that information; public bridges wrap up some information about themselves in what is called their bridge descriptor and send that to the bridge authority. The bridge descriptor includes some statistical information, like aggregated user counts and countries of origin of traffic. Our analysis here focuses solely on the data provided by public bridges.

Once a user has learned about some bridges, she configures her Tor client to use them, typically by entering them into the appropriate field in Vidalia. Alternatively, she might use a different controller or put the data into tor's configuration file directly.

Learning from bridge descriptor fetches

We've been collecting bridge descriptor fetch statistics on the bridge authority, and are using this data to pose some questions and propose some changes. The statistics collected are how many bridge descriptors were served in total, and how many unique descriptors were served, as well as the 0, 25, 50, 75 and 100 percentiles of fetches per descriptor. Every 24 hours, the current statistics are written to disk and the counters reset. The current statistics are attached to this post, for closer inspection. We've also prepared two graphs to easily see the data at a glance:

Total bridge downloads

Bridge downloads per descriptor

The first thing to note is that there aren't very many bridge descriptor fetches at all, which isn't a big surprise: The current Tor bundles don't fetch them when they're used in the typical way, that is by adding some bridges via Vidalia's interface after bridges were discovered via one of our bridge distribution channels. Over the past month, there have been between 3900 and 6600 fetches per day, with a median of 8 fetches per bridge. The most fetched descriptor is fetched up to 350 times per day, indicating that it does indeed belong to a bridge that was given out with a fingerprint and being used by Tor clients. We have gotten some reports that a bundle circulated with pre-configured bridges, and this could account for the many fetches.

Secondly, most bridge descriptors are not even fetched from the authority. This is a clear indication that we can improve our odds of updating bridge clients with current bridge info if we can get them to request the information better.

Improving Tor's behaviour for the two user groups

The first group ("Tor is blocked, and some way to reach the network has to be found") is mostly concerned about circumvention, without necessarily hiding that they're using Tor from someone. Typically, access to the Internet is filtered, but circumventing a filter isn't too risky and people are more concerned with access than hiding their tracks from a data-collecting adversary. Speed, bootstrapping performance, and little intervention/maintenance of a setup are the biggest goals.

Adding auto-discovery mechanisms for bridges that changed their IP address will help this group gain a lot more robustness when it comes to maintaining connectivity against an adversary that blocks public relays, but isn't very quick in blocking all bridges. As far as we know, this is currently true for the majority of our bridge userbase.

For the second group ("Tor may or may not be blocked, but the user is trying to hide the fact they're hiding Tor"), precise control over Tor's actions is much more important than constant connectivity, and private bridges might be utilized to that end as well. A user in this group wants to keep the bridges he's using secret, and puts up with frequent updates to the configuration for the added safety of only connecting to a pre-specified IP address:port combination. We can't do very much for a user belonging to this group with regard to bridges, but he will very much benefit from improvements made to our general fingerprintability resistance. Also options like the DisableNetwork option (prevent touching the network in any kind of way until this option is changed) that was recently introduced to Tor help him.

Another interesting point here is that we can indirectly improve the behaviour for the first group by not making it too easy to learn about bridges, because censors can use the same data to more effectively block them. This means that we shouldn't, for example, start giving out significantly more bridges to a single user.

We've written a proposal to implement some changes in Tor, to better facilitate the needs of the first group of bridge users.

New Tor Browser Bundles

The Tor Browser Bundles have been updated to Firefox 8.0.1 along with a new Libevent and some extension updates.

Tor Browser Bundle (2.2.34-3)

  • Update Firefox to 8.0.1
  • Update Libevent to 2.0.16-stable
  • Update NoScript to 2.2
  • Update HTTPS Everywhere to 1.2.1
  • Begin building Tor with --enable-gcc-warnings

Tor is out

Tor fixes some crash and assert bugs, including a
socketpair-related bug that has been bothering Windows users. It adds
support to serve microdescriptors to controllers, so Vidalia's network
map can resume listing relays (once Vidalia implements its side),
and adds better support for hardware AES acceleration. Finally, it
starts the process of adjusting the bandwidth cutoff for getting the
"Fast" flag from 20KB to (currently) 32KB -- preliminary results show
that tiny relays harm performance more than they help network capacity.

Changes in version - 2011-11-22
Major bugfixes:

  • Initialize Libevent with the EVENT_BASE_FLAG_NOLOCK flag enabled, so
    that it doesn't attempt to allocate a socketpair. This could cause
    some problems on Windows systems with overzealous firewalls. Fix for
    bug 4457; workaround for Libevent versions 2.0.1-alpha through
  • Correctly sanity-check that we don't underflow on a memory
    allocation (and then assert) for hidden service introduction
    point decryption. Bug discovered by Dan Rosenberg. Fixes bug 4410;
    bugfix on
  • Remove the artificially low cutoff of 20KB to guarantee the Fast
    flag. In the past few years the average relay speed has picked
    up, and while the "top 7/8 of the network get the Fast flag" and
    "all relays with 20KB or more of capacity get the Fast flag" rules
    used to have the same result, now the top 7/8 of the network has
    a capacity more like 32KB. Bugfix on Fixes bug 4489.
  • Fix a rare assertion failure when checking whether a v0 hidden
    service descriptor has any usable introduction points left, and
    we don't have enough information to build a circuit to the first
    intro point named in the descriptor. The HS client code in
    0.2.3.x no longer uses v0 HS descriptors, but this assertion can
    trigger on (and crash) v0 HS authorities. Fixes bug 4411.
    Bugfix on; diagnosed by frosty_un.
  • Make bridge authorities not crash when they are asked for their own
    descriptor. Bugfix on, reported by Lucky Green.
  • When running as a client, do not print a misleading (and plain
    wrong) log message that we're collecting "directory request"
    statistics: clients don't collect statistics. Also don't create a
    useless (because empty) stats file in the stats/ directory. Fixes
    bug 4353; bugfix on and

Major features:

  • Allow Tor controllers like Vidalia to obtain the microdescriptor
    for a relay by identity digest or nickname. Previously,
    microdescriptors were only available by their own digests, so a
    controller would have to ask for and parse the whole microdescriptor
    consensus in order to look up a single relay's microdesc. Fixes
    bug 3832; bugfix on
  • Use OpenSSL's EVP interface for AES encryption, so that all AES
    operations can use hardware acceleration (if present). Resolves
    ticket 4442.

Minor bugfixes (on 0.2.2.x and earlier):

  • Detect failure to initialize Libevent. This fix provides better
    detection for future instances of bug 4457.
  • Avoid frequent calls to the fairly expensive cull_wedged_cpuworkers
    function. This was eating up hideously large amounts of time on some
    busy servers. Fixes bug 4518; bugfix on
  • Don't warn about unused log_mutex in log.c when building with
    --disable-threads using a recent GCC. Fixes bug 4437; bugfix on which introduced --disable-threads.
  • Allow manual 'authenticate' commands to the controller interface
    from netcat (nc) as well as telnet. We were rejecting them because
    they didn't come with the expected whitespace at the end of the
    command. Bugfix on; fixes bug 2893.
  • Fix some (not actually triggerable) buffer size checks in usage of
    tor_inet_ntop. Fixes bug 4434; bugfix on Tor Patch
    by Anders Sundman.
  • Fix parsing of some corner-cases with tor_inet_pton(). Fixes
    bug 4515; bugfix on; fix by Anders Sundman.
  • When configuring, starting, or stopping an NT service, stop
    immediately after the service configuration attempt has succeeded
    or failed. Fixes bug 3963; bugfix on
  • When sending a NETINFO cell, include the original address
    received for the other side, not its canonical address. Found
    by "troll_un"; fixes bug 4349; bugfix on
  • Rename the bench_{aes,dmap} functions to test_*, so that tinytest
    can pick them up when the tests aren't disabled. Bugfix on which introduced tinytest.
  • Fix a memory leak when we check whether a hidden service
    descriptor has any usable introduction points left. Fixes bug
    4424. Bugfix on
  • Fix a memory leak in launch_direct_bridge_descriptor_fetch() that
    occurred when a client tried to fetch a descriptor for a bridge
    in ExcludeNodes. Fixes bug 4383; bugfix on

Minor bugfixes (on 0.2.3.x):

  • Make util unit tests build correctly with MSVC. Bugfix on Patch by Gisle Vanem.
  • Successfully detect AUTH_CHALLENGE cells with no recognized
    authentication type listed. Fixes bug 4367; bugfix on
    Found by frosty_un.
  • If a relay receives an AUTH_CHALLENGE cell it can't answer,
    it should still send a NETINFO cell to allow the connection to
    become open. Fixes bug 4368; fix on; bug found by
  • Log less loudly when we get an invalid authentication certificate
    from a source other than a directory authority: it's not unusual
    to see invalid certs because of clock skew. Fixes bug 4370; bugfix
    on and

Minor features:

  • Add two new config options for directory authorities:
    AuthDirFastGuarantee sets a bandwidth threshold for guaranteeing the
    Fast flag, and AuthDirGuardBWGuarantee sets a bandwidth threshold
    that is always sufficient to satisfy the bandwidth requirement for
    the Guard flag. Now it will be easier for researchers to simulate
    Tor networks with different values. Resolves ticket 4484.
  • When Tor ignores a hidden service specified in its configuration,
    include the hidden service's directory in the warning message.
    Previously, we would only tell the user that some hidden service
    was ignored. Bugfix on 0.0.6; fixes bug 4426.
  • When we fail to initialize Libevent, retry with IOCP disabled so we
    don't need to turn on multi-threading support in Libevent, which in
    turn requires a working socketpair(). This is a workaround for bug
    4457, which affects Libevent versions from 2.0.1-alpha through
  • Detect when we try to build on a platform that doesn't define
    AF_UNSPEC to 0. We don't work there, so refuse to compile.
  • Update to the November 1 2011 Maxmind GeoLite Country database.

Packaging changes:

  • Make it easier to automate expert package builds on Windows,
    by removing an absolute path from makensis.exe command.

Code simplifications and refactoring:

  • Remove some redundant #include directives throughout the code.
    Patch from Andrea Gelmini.
  • Unconditionally use OpenSSL's AES implementation instead of our
    old built-in one. OpenSSL's AES has been better for a while, and
    relatively few servers should still be on any version of OpenSSL
    that doesn't have good optimized assembly AES.
  • Use the name "CERTS" consistently to refer to the new cell type;
    we were calling it CERT in some places and CERTS in others.


  • Numerous new unit tests for functions in util.c and address.c by
    Anders Sundman.
  • The long-disabled benchmark tests are now split into their own
    ./src/test/bench binary.
  • The benchmark tests can now use more accurate timers than
    gettimeofday() when such timers are available.

Suggest a new name for the Torouter, win an Excito B3

The Torouter is the codename for a hardware project that aims to provide users with a device that can easily be configured to run as a Tor bridge or relay. We are currently working on two devices; the Excito B3 and the DreamPlug.

Having two devices that are both called "the Torouter" can be a bit confusing, so we would like your help in renaming the Excito B3 Torouter!

The best suggestion will not only be the new name for the Excito B3 Torouter, but the winner will also receive an Excito B3, a Tor t-shirt and stickers. Five runners-up will receive Tor t-shirts and stickers.

To suggest new names for the Excito B3 Torouter, send an email to tor-assistants AT with "Torouter naming contest" in the subject. The deadline is December 5, 2011.

UPDATE: We have received a lot of good naming suggestions for the Excito B3 Torouter, thank you to everyone who emailed us! We have decided that the new name for the Excito B3 Torouter is onionbox. An email has gone out to the lucky winner of a B3, a t-shirt and some stickers, as well as five-runners up who will all get t-shirts and stickers.

Run Tor as a bridge in the Amazon Cloud

The Tor Cloud project gives you a user-friendly way of deploying bridges to help users access an uncensored Internet. By setting up a bridge, you donate bandwidth to the Tor network and help improve the safety and speed at which users can access the Internet.

Bridges are Tor relays that aren't listed in the main directory. This means that to use a bridge, you'll need to locate one first. And because there is no complete public list of all the bridges, they are also harder to block. A bridge will act as the first hop in a circuit, and will only forward traffic on to other relays in the Tor network.

Setting up a Tor bridge on Amazon EC2 is simple and will only take you a couple of minutes. The images have been configured with automatic package updates and port forwarding, so you do not have to worry about Tor not working or the server not getting security updates.

You should not have to do anything once the instance is up and running. Tor will start up as a bridge, confirm that it is reachable from the outside, and then tell the bridge authority that it exists. After that, the address for your bridge will be given out to users.

To help new customers get started in the cloud, Amazon is introducing a free usage tier. The Tor Cloud images are all micro instances, and new customers will be able to run a free micro instance for a whole year. The Tor Cloud images have been configured with a bandwidth limit, so customers who don't qualify for the free usage tier should only have to pay an estimated $30 a month.

For more information, see the Tor Cloud website.

UPDATE: Some users have asked about the AWS free usage tier and pointed out that it only includes 15 GB of bandwidth out per month. I have updated the Tor Cloud website (changes should go live soon) with the following:

The Tor Cloud images have been configured to use no more than 40 GB of bandwidth out per month. We have estimated that customers who do not qualify for the free usage tier will pay up to $30 a month. Customers who qualify for the free usage tier, but who run bridges that use more than 15 GB of bandwidth out per month, will pay up to $3 per month.

I hope that this better clarifies the cost of running a bridge in the Amazon cloud, let me know if you have any questions.

Tails 0.9 Released

The latest version of the anonymous operating system Tails is now available.

Notable user-visible changes include:

## Tor
- Upgrade to This fixes CVE-2011-2768 and CVE-2011-2769 which prompted for manual updates for users of Tails 0.8.1.
- Suppress Tor's warning about applications doing their own DNS lookups. Some users have reported concerns about these warnings, but it should be noted that they are completely harmless inside Tails as its system DNS resolver is Torified.

- Linux 3.0.0-6, which fixed a great number of bugs and security issues.

## Iceweasel
- Upgrade to 3.5.16-11 ((fixes CVE-2011-3647, CVE-2011-3648, CVE-2011-3650).
- Torbutton: upgrade to, including support for the in-browser "New identity" feature.
- FireGPG: upgrade to 0.8-1+tails2. Users are notified that the FireGPG Text Editor is the only safe place for performing cryptographic operations, and these operations has been disabled in other places. Performing them outside of the editor opens up several severe attacks through JavaScript (e.g. leaking plaintext when decrypting, signing messages written by the attacker).
- Replace CS Lite with Cookie Monster for cookie management. Cookie Monster has an arguably nicer interface, is being actively maintained and is packaged in Debian.

## Software
- Install MAT, the Metadata Anonymisation Toolkit. Its goal is to remove file metadata which otherwise could leak information about you in the documents and media files you publish. This is the result of a Tails developer's suggestion for GSoC 2011, although it ended up being mentored by The Tor Project.
- Upgrade WhisperBack to 1.5~rc1. Users are guided how to send their bug reports through alternative channels upon errors sending them. This will make bug reporting easier when there's no network connection available.
- Upgrade TrueCrypt to 7.1.

## Miscellaneous
- The date and time setting system was completely reworked. This should prevent time syncing issues that may prevent Tor from working properly, which some users have reported. The new system will not leave a fingerprintable network signature, like the old system did. Previously that signature could be used to identify who is using Tails (but not deanonymize them).
- Erase memory at shutdown: run many instances of the memory wiper. Due to architectural limitations of i386 a process cannot access all memory at the same time, and hence a single memory wipe instance cannot clear all memory.
- Saner keyboard layouts for Arabic and Russian.
- Use Plymouth text-only splash screen at boot time.

Plus the usual bunch of minor bug reports and improvements. The full technical changelog is available.

The full version of this release is available at

Download from here,

New Tor Browser Bundles

The Tor Browser Bundles have been updated to Firefox 8. There was a slight delay as we adjusted to their new add-on management scheme, but everything should be working normally now. Please let us know if you have any issues!

Tor Browser Bundle (2.2.34-2)

  • Update Firefox to 8.0
  • Update Libevent to 2.0.15-stable
  • Update NoScript to 2.1.8
  • Add extensions.autoDisableScopes to allow TBB's Firefox to launch with its extensions enabled

October 2011 Progress Report

The October 2011 Progress report is available in PDF and text formats. It contains details of the six major releases, new censorship events in China, and results of a concerted effort to work on hiding Tor's network signature, amongst other progress.

Syndicate content Syndicate content