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.
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:
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.)
Yes, that is right. It is good to know the risks, because there are sometimes tradeoffs between censorship resistance and anonymity. When you are using meek, it is like having four hops between you and the destination: you→CDN→guard→middle→exit→destination. If the destination web site is also hosted on the CDN, then the CDN gets to see both entry and exit traffic and has a better chance of doing a confirmation attack.
You can read more about it in Yawning's evaluation of meek: "...the third party gets to observe the user's traffic to the Bridge and the application traffic to and from the exit..." (You can find similar evaluations of other pluggable transports here.) There's a note about the issue in the 2015 research paper that covers meek and other systems: "The intermediate web service has a privileged network position..."
Thanks! This kind of information is very helpful in enabling Tor users to make informed decisions about what kind of bridges to use, and how to use them.