bridges

Tor at the Heart: Bridges and Pluggable Transports

During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom.
Donate today

Technology against censorship: bridges and pluggable transports

You can use Tor to view websites that are censored or blocked. But what do you do when Tor itself is blocked? When it happens, you can use bridges and pluggable transports to get around the censors. Here is how to do it in Tor Browser:

Animated graphic showing 6 steps to configuring pluggable transports.

How does it work?

Censors block Tor in two ways: they can block connections to the IP addresses of known Tor relays, and they can analyze network traffic to find use of the Tor protocol. Bridges are secret Tor relays—they don't appear in any public list, so the censor doesn't know which addresses to block. Pluggable transports disguise the Tor protocol by making it look like something else—for example like HTTP or completely random.

There are several pluggable transports, and it can be hard to know which one to use. If it is your first time, try obfs4: it is a randomizing transport that works for most people. If obfs4 doesn't work, try fte. If that doesn't work, it may mean that the default bridges are blocked, and you should get a custom bridge from bridges.torproject.org. If the custom bridge doesn't work, try meek-azure or meek-amazon.

  • obfs4 is a randomizing transport: it adds an extra layer of specialized encryption between you and your bridge that makes Tor traffic look like random bytes. It also resists active-probing attacks, where the censor discovers bridges by trying to connect to them. obfs3 and scramblesuit are similar in nature to obfs4.
  • fte makes Tor traffic resemble plain HTTP. The name stands for "Format-Transforming Encryption."
  • meek makes Tor traffic look like a connection to an HTTPS website. Unlike the other transports, it doesn't connect directly to a bridge. meek first connects to a real HTTPS web server (in the Amazon cloud or the Microsoft Azure cloud) and from there connects to the actual bridge. Censors cannot easily block meek connections because the HTTPS servers also provide many other useful services.

There are a number of built-in, default bridges, which you can use just by choosing a pluggable transport name. For better secrecy, you should get custom bridges from bridges.torproject.org. meek doesn't need custom bridges; however it is slower and more expensive to operate than the other pluggable transports, so you should use obfs4 or fte if they work for you.

Tor is not the only project to use pluggable transports. We work often with researchers and developers to study Internet censorship, improve pluggable transports, and develop new ones. Psiphon and Lantern are two other projects that use pluggable transports. (Unlike Tor, they focus only on access and not on anonymity.)

If you are not censored yourself, you can help censored people by running a bridge with a pluggable transport. Running a bridge is the same as running a relay, just with a little extra configuration. See this guide: Become a PT bridge operator! Once your bridge is running, it will automatically become available to users at bridges.torproject.org.

The world of censorship is changing all the time. It's a good idea to learn how to use bridges and pluggable transports before you actually need them. Just last week, ISPs in Belarus began blocking public Tor relays—but bridges and pluggable transports are so far working to defeat the blocks. We are tracking other censorship events, such as those in Saudi Arabia, Kazakhstan, and elsewhere. If you know details of these or any other Tor blocks, please tell us. The best way to do that is to leave a comment on our bug tracker. (You can create an account first.)

A New Bridge Authority

After ten years of volunteer maintenance of Tonga, Tor's bridge Authority—a piece of critical infrastructure within the Tor network—our colleague and friend, Lucky Green, a long time cypherpunk, and free speech and privacy advocate, has decided to step down from this role. Tonga's cryptographic keys will be destroyed this week. We are incredibly thankful to Lucky for all his support and selfless labour in maintaining a key component of our censorship circumvention efforts, grateful for the years we have spent working with him, and very sorry to see him go.

The Bridge Authority is a simple but essential piece of the Tor Network. Unlike the other directory authorities, the Bridge Authority does not get a vote in Tor's consensus protocol. Instead, it serves to aggregate relay descriptors which Tor Bridges send to it, checking their cryptographic validity and testing that the Bridges' ORPorts within these descriptors are reachable. It then sends these descriptors to BridgeDB, which does all the deduplication, cryptographic signature verification (again), stability calculations, pluggable transport argument validation, assignment into the hashring of each Bridge distribution mechanism, and finally distributing the Bridges to Tor clients.



Number of bridges reported by both Tonga and Bifröst during the bridge authority transition period. Graph by Karsten Loesing.

This transition does not affect Tor users, regardless of whether or not Bridges are used to connect to the Tor network. However, it is extremely important that relay operators running Bridges upgrade to tor-0.2.8.7 or tor-0.2.9.2.-alpha, which contains a patch to replace Tonga with the new Bridge Authority. Bridges which do not upgrade will cease to be distributed to new clients; however, clients which have connected to your Bridge previously will still be able to connect (at least until your Bridge's IP address, port, or fingerprint changes).


"The same thing, but made of rainbows and on fire."

As a replacement for Tonga, I am happy to announce that Greenhost has donated hardware and hosting for the new Bridge Authority, Bifröst. Bifröst is a Norse mythological bridge that connects Midgard, the mortal realm, and Asgard, the realm of the gods, and is described in the poem Grímnismál within the Poetic Edda as a burning bridge, constructed out of a rainbow whose end lies upon Himinbjorg, or "Heaven's cliffs." The name was suggested by both our colleagues Alison Macrina of the Library Freedom Project and Moritz Bartl of Torservers.net. Despite the personal temptation to follow Nick Mathewson's suggestion to christen it after that iconic symbol of my home, I could not help but name it Bifröst, because why go with some boring normal thing, when you could have the same thing, but made of rainbows and on fire. RAINBOWS. FIRE. Clear choice.

The Tor Project is incredibly thankful to Greenhost for their generous donation of hardware, hosting, and bandwidth. In particular, I am thankful to my colleagues at Greenhost, Sacha von Geffen and Jurre van Bergen, for all the work they put into the organisation, collaboration, and technical efforts in setting the server up quickly. Working with Greenhost, as always, is a pleasure, and I would give my highest recommendations for Greenhost to those seeking an ethical, friendly, and experienced hosting provider.


Future Research and Hacking

Moving forward, there are several improvements to these systems which could be made, some requiring further research.

  1. We currently don't have any mechanism for testing the bandwidth capacity of bridge relays. Additional design complications may arise when Bridges have their own Guard relays (#7144), e.g. causing fast Bridges which select slower Guards to not utilize their full capacity. This might be navigated by adding support for bridges to do a self-bandwidth test before selecting a guard node.

  2. We also don't currently have anything that tests the reachability of the address/port for any of a Bridge's pluggable transports. Our previous attempts at a distributed/automated Bridge reachability testing system lead me to believe that there is no way to both reliably and securely, i.e., without literally burning the Bridge by attracting a censor's attention to it, test reachability in a distributed manner. Add on top a game of Russian roulette by mixing in N different pluggable transports with varying indistinguishability, authentication, and security properties merely compounds the issue, adding to the likelihood that the secrecy of the best transport a Bridge provides is reduced to that of its worst. That said, thorough analysis of the risks of a centralised system should be made, and there are likely other alternatives. For example, one might attempt to build a system which heuristically crowdsources this information from clients.

  3. There's no legitimate reason to have the Bridge Authority and BridgeDB be separate systems. It would make more sense to break apart the components into those which
    • receive descriptors
    • conduct reachability tests
    • archive all descriptors
    • access archived descriptors for which Bridges may currently be distributed to clients
    • distribute Bridges to clients in some manner.

  4. Decentralise the Bridge Authority/BridgeDB systems without simply turning a single point-of-failure into multiple points-of-failure.


Researchers and hackers interested in these problems are welcome and encouraged to contribute. If these problems interest you (or your sufficiently bright, self-directed, and motivated students!), please feel encouraged to contact me and/or our Research Director, Roger Dingledine to discuss ideas and projects moving forward.

OONI Bridge reachability study and hackfest

Has a Tor bridge already been blocked in a given country? Being able to answer that question would allow Tor to provide more efficient circumvention methods to those who need them. OONI, the Open Observatory of Network Interference is now actively collecting data on bridge reachability. We are also interested in having a better understanding of how reactive censors are in blocking new bridges distributed via Tor Browser and how effective they are at inhibiting usage of particular pluggable transport.

The countries we are focusing on in this survey are China, Iran, Russia and Ukraine. We call these our test vantage points.

From every test vantage point we perform two types of measurements:

To establish a baseline to eliminate the cases in which the bridge is marked as blocked, while it is in fact just offline, we measure also from a vantage point located in the Netherlands.

So far we have collected about a month worth of data and it is as always publicly available for download by anybody interested in looking at it.

To advance this study at the end of October we did a OONI hackfest in Berlin. Helped by the ubiquitous sticky notes we were able to come up with a plan for those days of work and for continuing the project.

The first visualisation we produced is that of the reachability of bridges categorised by country and pluggable transport over time. This simple visualisation already conveys a lot of information and has proven itself a useful tool also in debugging issues with ooniprobe and the tools we use.



You can visit the actual page by clicking on the picture above.
Please note that because the tests are new and experimental you might find inaccuracies or bugs, so don't seriously rely on it for research just yet.

We also developed a data pipeline that places all of the collected OONI reports into a database. This makes it much easier to search/aggregate and visualise the data of the reports.

To read more about this project check out the ooni-dev mailing list thread on this topic.

This project is still in it's very early stages of development, but we would love to hear feedback on it or your cool visualization ideas, as well as any questions regarding Tor bridge reachability (or more in general on Internet censorship) that you would like us to answer!

How to read our China usage graphs

Recently somebody asked me why our usage numbers in China are so low. More precisely, his question was "How do I read this graph in any way other than 'Tor is effectively blocked in China'?" After writing up an answer for him, I realized I should share it with the rest of the Tor community too.

The correct interpretation of the graph is "obfs3 bridges have not been deployed enough to keep up with the demand in China". So it isn't that Tor is blocked — it's that we haven't done much of a deployment for obfs3 bridges or ScrambleSuit bridges, which are the latest steps in the arms race.

The short explanation is that the old vanilla SSL Tor transport doesn't work in China anymore due to their active probing infrastructure. The obfs2 transport doesn't work anymore either, for the same reason. The obfs3 transport works great for now, and thousands of people are happily using it — and some of those people aren't reflected in the graphs you see (I'll explain that more below).

The medium-length explanation is that we've been leading and coordinating the international research effort at understanding how to design and analyze transports that resist both DPI and active probing, and approximately none of these approaches have been deployed at a large scale yet. So it doesn't make sense to say that Tor is blocked in China, because it mischaracterizes Tor as a static protocol. "Tor" when it comes to censorship circumvention is a toolbox of options — some of them work in China, some don't. The ones that work (i.e. that should resist both DPI and active probing) haven't been rolled out very widely, in large part because we have funders who care about the research side but we have nobody who funds the operations, deployment, or scale-up side.

The long explanation is that it comes down to three issues:

First, there are some technical steps we haven't finished deploying in terms of collecting statistics about users of bridges + pluggable transports. The reason is that the server side of the pluggable transport needs to inform the Tor bridge what country the user was from, so the Tor bridge can include that in its (aggregated, anonymized) stats that it publishes to the metrics portal. We've now built most of the pieces, but most of the deployed bridges aren't running the new code yet. So the older bridges that are reporting their user statistics aren't seeing very many users from China, while the bridges that *aren't* reporting their user statistics, which are the ones that offer the newer pluggable transports, aren't well-represented in the graph. We have some nice volunteers looking into what fraction of deployed obfs3 bridges don't have this new 'extended ORPort' feature. But (and you might notice the trend here) we don't have any funders currently who care about counting bridge users in China.

Second, we need to get more addresses. One approach is to get them from volunteers who sign up their computer as a bridge. That provides great sustainability in terms of community involvement (we did a similar push for obfs2 bridges back when Iran was messing with SSL, and got enough to make a real difference at the time), but one address per volunteer doesn't scale very well. The intuition is that the primary resource that relays volunteer is bandwidth, whereas the primary resource that bridges volunteer is their address — and while bandwidth is an ongoing contribution, once your IP address gets blocked then your contribution has ended, at least for the country that blocked it, or until you get another address via DHCP, etc. The more scalable approaches to getting bridge addresses involve coordinating with ISPs and network operators, and/or designs like Flashproxy to make it really easy for users to sign up their address. I describe these ideas more in "approach four" and "approach five" of the Strategies for getting more bridge addresses blog post. But broad deployment of those approaches is again an operational thing, and we don't have any funded projects currently for doing it.

Third, we need ways of letting people learn about bridges and use them without getting them noticed. We used to think the arms race here was "how do you give out addresses such that the good guys can learn a few while the bad guys can't learn all of them", a la the bridges.torproject.org question. But it's increasingly clear that scanning resistance will be the name of the game in China: your transport has to not only blend in with many other flows (to drive up the number of scans they have to launch), but also when they connect to that endpoint and speak your protocol, your service needs to look unobjectionable there as well. Some combination of ScrambleSuit and FTE are great starts here, but it sure is a good thing that the research world has been working on so many prototype designs lately.

So where does that leave us? It would be neat to think about a broad deployment and operations plan here. I would want to do it in conjunction with some other groups, like Team Cymru on the technical platform side and some on-the-ground partner groups for distributing bridge addresses more effectively among social networks. We've made some good progress on the underlying technologies that would increase the success chances of such a deployment — though we've mostly been doing it using volunteers in our spare time on the side, so it's slower going than it could be. And several other groups (e.g. torservers.net) have recently gotten funding for deploying Tor bridges, so maybe we could combine well with them.

In any case it won't be a quick and simple job, since all these pieces have to come together. It's increasingly clear that just getting addresses should be the easy part of this. It's how you give them out, and what you run on the server side to defeat China's scanning, that still look like the two tough challenges for somebody trying to scale up their circumvention tool design.

New Tor Cloud images with obfs3

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.

Updated Tor Cloud images

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.

Updated Tor Cloud images

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.

Obfsproxy Bridges in the Amazon Cloud

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.

New Tor Cloud images

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.

Updated Tor Cloud images with fix for Tor upgrades

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

Syndicate content Syndicate content