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:
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.)
Comments
Please note that the comment area below has been archived.
Does the meek server itself
Does the meek server itself act as a guard node, in the sense that it is always the first hop, before the Tor protocol is even in play? And does that mean that the provider of the meek server could perform confirmation attacks on users browsing sites hosted by the same provider?
Yes, that is right. It is
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
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.
How can I help the Tor
How can I help the Tor network more at the moment?
By becoming a bridge, or by becoming a middle relay?
That's a good question. The
That's a good question. The FAQ says:
The Tor Metrics site has information about the number of relays and bridges that exist.
If you set up a bridge, be sure to enable a pluggable transport. As you can see from the graph of Bridge users by transport, there are many more users (over 10×) on obfs4 than there are on the unobfuscated Tor protocol ("Default OR Protocol").
Not the OP, but I'm
Not the OP, but I'm wondering what's considered "a lot" or "not a lot" of bandwidth? Do any sites have stats on the average bandwidth of a bridge vs a middle relay?
PS: metrics.torproject.org and similar sites like Atlas and InspecTor might be good Tor at the Heart topics; I would be interested in learning more about them.
I don't know for sure;
I don't know for sure; people on the metrics team may have a good idea.
The graph Advertised bandwidth distribution shows how much bandwidth relays report seeing ("advertised bandwidth"). Looking at just the 50th percentile, we see that the median bandwidth of exits is 30 Mbit/s. Including non-exits, the median bandwidth is 10 Mbit/s. I don't know of a graph that shows only bridges.
Thanks. I guess it is
Thanks. I guess it is difficult to collect data on bridges due to their secretive nature. If I can get in touch with the metrics team, I'll see if it's possible for them to publish anonymous bridge bandwidth statistics. In the meantime, I guess anything under 10Mbits/s should probably be a bridge.
Torproject official site is
Torproject official site is blocked in China. We need to download Tor browser from Github or some mirror sites
Check
Check out
https://blog.torproject.org/blog/gettor-new-ways-download-tor-browser
for many more ways of fetching Tor even when the main website is blocked.
Here is a GitHub download
Here is a GitHub download link:
https://github.com/TheTorProject/gettorbrowser
Here is a guide in Chinese:
https://github.com/TheTorProject/gettorbrowser/issues/1
When you are using meek, it
When you are using meek, it is [...] 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.
The tradeoff with the Meek is understood.
But what if an adversary runs multiple Tor entry and exit nodes in one (or even multiple) CDNs that it has access to? With the existing global CDNs, this would seemingly make it easy for them to learn / de-anonymize / attack globally, defeating the Tor's purpose.
Do you have any tests / protection from the Tor nodes being hosted in the CDNs and such?
What if an adversary runs
What if an adversary runs multiple Tor entry and exit nodes in one (or even multiple) CDNs?
You may be picturing full Tor relays running on cloud servers, but meek doesn't work like that. When you use meek, your bridge (which acts as your guard) is fixed: for meek-azure it is this one and for meek-amazon it is this one. The part that runs on the CDN is not a full Tor relay: the CDN only forwards HTTP requests to the meek bridge and that bridge is hard-coded per CDN. If you set up your own meek service, you can point it at any bridge you want, and it will always use the one you configured.
So an adversary doesn't increase their chances of a successful correlation attack by running their own bridges, exits, or CDN configuration, because 1) bridges and exits don't actually run on the CDN and 2) your tor client will always use one bridge you have configured. There's no way for an adversary to "force" you to use their meek bridge. An adversary can try to run lots of exits to increase their successful attack rate, but they can do that with plain Tor or any other pluggable transport; it's independent of meek.
The additional hazard to anonymity posed by meek is not that an adversary can run lots of bridges and exits and hope to get lucky. That hazard exists regardless. The additional hazard is rather that the CDN itself may be malicious or collude with the adversary. When using a normal bridge, a malicious or colluding bridge can help deanonymize you; the risk is more acute for meek only because CDNs also tend to be popular destinations for web traffic. When you're using a normal bridge, you are not usually using it to eventually connect back to the same network the bridge is hosted on, but when using meek you sometimes do that (depending on what web sites you visit).
Thanks for answering. My
Thanks for answering. My previous question was about the *regular* Tor relays and bridges, and not meek. To rephrase:
If a "nasty" adversary deploys a number of regular Tor nodes in a special way - on some colluding/malicious cloud servers and/or somehow via CDNs, thus reducing the anonymity a lot more (because of the powerful cloud traffic reporting, their Tor entry/exit nodes and destination websites hosted and monitored on CDN's etc):
1) are they able to run bridges and exits on, or routed via, cloud and CDNs?
2) if yes, is there currently anything mitigating that additional risk coming from the cloud-based Tor nodes?
3) should the Tor nodes in general be tested for, and disallowed if deployed from a spying cloud?
If i understand the question
If i understand the question correctly, this is more or less what happened during the "CMU attack". An adversary already discovered a confirmation attack technique (" RELAY_EARLY"), so the next step was to operate enough Tor guard nodes and exit nodes to correlate input and output data. They used Amazon VPSs if I recall correctly, and it worked: they deanonymized quite a large number of users considering the complexity/difficulty of the attack. After the attack was discovered Tor was patched to stricten the criteria on becoming eligible to be a guard node. One of these criteria was that guard nodes could not be hosted in IP space known to belong to large CDNs and hosting providers. Overall they made it harder to become a guard node; see the Tor blog post about the CMU attack.
I am unsure if this affected bridges though. Bridges probably don't normally meet the criteria that regular guard nodes are subject to in the first place (namely throughput), and the chosen bridge must also necessarily be the guard node. So if bridge nodes are not held to the same criteria, then theoretically an attack like you mentioned would be possible, but it would only affect bridge users, not regular Tor users.
Note that meek connects to guard nodes, not bridge nodes, so the attack wouldn't work on meek users either, except if meek was the endpoint as described in the earlier comment thread.
Tor also attempts to select nodes from three different subnets and three different "families" (nodes operated by the same organization are called a "family"), but the collusion problem is really outside the scope of Tor, and is not really a technical problem at all.
What you're describing is
What you're describing is sometimes called a Sybil attack, where an attacker runs a lot of nodes that may appear to be independent, but actually are all colluding. #comment-224934 is correct that the CMU/CERT attack in 2014 was a Sybil attack. They had discovered a flaw in the Tor protocol that enabled traffic confirmation, but they needed to run a large number of guard and HSDir nodes in order to exploit it.
I think I was confused by your reference to cloud servers and CDNs. It doesn't really matter where there Sybil nodes are run. Cloud services may make it cheaper and easier to run a large number of services, but the fundamental attack is the same no matter where the servers are.
There are some mitigations in place against Sybil attacks in Tor. For a detailed study, see the research on Protecting Tor from Sybil attacks by Philipp Winter, Roya Ensafi, Karsten Loesing, and Nick Feamster. They have a program called sybilhunter that looks for similarities among relays that may indicate they have the same operator—being hosted on the same cloud service is one clue, but there are others such as uptime, operating system, and nickname. As I understand it, someone at Tor is running sybilhunter and other tools to discover and block suspicious relays (but I don't know the details).
Bridges would be harder to classify as Sybils than ordinary relays because they don't have public addresses. If you ask Onionoo for a list of bridges, you will get a list, but the
or_addressesfield is randomized and doesn't reflect the true address. A couple of week ago I posted about some obfs4 bridges with similar characteristics, but I don't know what came of that.@ Shari: Many enthusiastic
@ Shari:
Many enthusiastic Tor supporters are wondering why Tor Project has not endorsed the petition to pardon the whistleblower and true American hero Edward Snowden. I hope you will consider doing that without delay, or at least explaining such a curious omission if you feel you cannot join us.
By the time this comment is posted (if it ever is), the event may have ended, but Edward Snowden just tweeted that he will be chatting online around noon EST 14 Dec 2016:
> Tomorrow I'm talking with Twitter CEO @Jack at 12:05 EST. You'll be able to watch live via @PardonSnowden and ask questions via #AskSnowden
major thank you to all tor
major thank you to all tor team and contributors
just an question
as an regular user of tor but an non regular user of the pluggable transports. does this mean or potentially mean i am marked up even so that i am not blocked ?
should i/we mix our browsing with regular tor and or with pluggable whether we are blocked or not ?
just interested if it help us in anyway.
thanks in advance
It is hard to give a short
It is hard to give a short answer to the question "should I use pluggable transports even if I am not blocked from Tor?" because the answer depends on many things.
To answer your first question, yes, your ISP or some other eavesdropper can tell that you are using Tor, even if they cannot tell what you are using Tor for. The eavesdropper could make a list of all Tor users (client IP addresses), even if they don't block Tor users. That is, you may be surveilled even if you are not censored.
An eavesdropper can tell you are using Tor in a number of ways. Ordinary Tor relays (not bridges) are all published in the network status consensus along with their IP addresses. The eavesdropper can simply look for connections to IP addresses that are listed in the consensus. Alternatively, the eavesdropper could look for the particular way that Tor uses TLS in network connections.
Pluggable transports make it harder to identify that you are using Tor, but there are a number of issues to be aware of. For better security, you should use a secret bridge from bridges.torproject.org, rather than a default bridge. (You are using a default bridge if you selected "Connect with a provided bridge" rather than pasting in your own bridge information.) There are only a few dozen default bridges, and their IP addresses are listed in the Tor Browser source code. This is good enough to fool naive censors, but it would be easy for an eavesdropper to make a list of everyone who connects to one of the default bridges. The risk of being detected as a Tor user is less if you are using a secret bridge.
Besides the consideration about default bridges, there is improving research on identifying the use of Tor even when pluggable transports are used. For example, see this paper from 2015: Seeing through Network-Protocol Obfuscation. They had some success in identifying obfs4, fte, and meek, using a classifier trained on a large sample of traffic. It is thought that national censors are not yet using this kind of classifier, but they will get better over time. (We got a report that a commercial firewall can block obfs4 and it seems that some obfs4 bridges are blocked in Kazakhstan, and we don't know exactly how they're doing it yet.)
meek is probably the most covert of the currently deployed pluggable transports, but it too has characteristics that could cause an eavesdropper to suspect that you are using Tor. If you are running meek for yourself, please try to set up your own instance on App Engine—it only takes a Google Account and you can use 1 GB per day without paying.
People are working on pluggable transport designs that may offer better covertness. If you like reading about censorship research, you should take a look at CensorBib, a list of censorship-related research papers.
The china (mandarin
The china (mandarin language) uni-con (nick name East-North part of AT&T) /
China mobile ISP ( nick name mandarin language Verizon ) (
TAi Dong (sky wing (Teng yang) mobile ISP same as T-mobile
own 95% of mandarin speaker yellow skin 1.1bn communication
message / voice call / 9 PB/S (9000 TB /s ) internet speed
those shanghai index , hang-sang index , SZ index stock syllabus
were own and manage / surveillance by CHN communist
party(yellow skin chan -cheung- chun) that they send their son /
daug to USA/UK/AUST/CANADA /
E.U for study and hide their corrupt from (wu nam ) shang- sei -
Sei-chung - Kau chou ,
We hope Tor project can suggest hardware equipment OEM vendor
far more become a software encryption company / We hope
EMEA/ USCAN gov can provide fund for affordable satellites
communication to avoid your internet HTTP traffic being capture /
monitor / analysis and using it target on you and your family , your
friend/ your school , your working corp, your bank your insurance
company your house your car!!!
> The china (mandarin
> The china (mandarin language) uni-con (nick name East-North part of AT&T)
...
> Sei-chung - Kau chou
If that was produced by pasting text in Mandarin into Google translate, I fear something may have gone wrong.
> We hope Tor project can suggest hardware equipment OEM vendor far more become a software encryption company
"We hope TP can encourage OEM vendors to provide strong hardware enforced encryption?"
> We hope EMEA/ USCAN gov
"Europe, Middle East, Asia, Five Eye (US/UK/CA/AU/NZ) governments?"
Wow, not many privacy friendly governments in that rather broad list.
> can provide fund for affordable satellites communication to avoid your internet HTTP traffic being capture / monitor / analysis and using it target on you and your family , your friend/ your school , your working corp, your bank your insurance company your house your car!!!
"We hope they can fund development of affordable satellite communication to circumvent monitoring of http traffic?"
If that's what you meant, if you are using Tor, you should probably visit
https://www.eff.org/nsa-spying/nsadocs
and read some of the Snowden leaked documents describing NSA's very extensive programs for covertly monitoring *all* web/phone/text/fax messages sent via *any* commercial satellite link. These documents make it clear that these easily tapped communication channels are among their most lucrative sources of information.
That said, there are proposals to put thousands of citizen funded micro-satellites in orbit (or millions of high altitude balloons) in order to create a decentralized global communication network which cannot be censored (one hopes) by any government. On a more local level, there are also proposals to distribute tiny WiFi nodes to every house, allowing citizens to create a WiFi mesh which (one hopes) is not controlled by local government. These hopes may or may not be fulfilled.
As a recent example of why
As a recent example of why we need to resist state-sponsored blocking:
https://motherboard.vice.com/read/signal-claims-egypt-is-blocking-acces…
Signal Claims Egypt Is Blocking Access to Encrypted Messaging App
Joseph Cox
19 Dec 2016
> Egypt has been censoring access to encrypted messaging app Signal, according to Open Whisper Systems, the company behind the app. The move highlights that as privacy-focused users move to technologies such as Signal, governments may still try to limit their use.
For anyone who works at a
For anyone who works at a tech company which handles personal user data:
eff.org
Andrew Crocker and Amul Kalia
How Tech Companies Can Fight for Their Users in the Courts
19 Dec 2016
> There are a lot of political uncertainties around the incoming Trump administration, but the threats to civil liberties are potentially greater than ever. President Obama failed to rein in the surveillance state, and Mr. Trump has nominated cabinet members like Mike Pompeo who are big fans of bulk surveillance. Now, given Mr. Trump’s campaign posture of being a “law and order” candidate who has openly criticized Apple for standing up for strong encryption, tech companies need to be even more vigilant in fighting for their users in the courts.
>
> EFF stands ready to support those who will be pioneers in these efforts. Below, we highlight a few ways companies can stand up for their users, along with some prominent examples of from the past. In addition, for the last six years EFF has produced an annual “Who Has Your Back?” report evaluating the practices of technology companies in categories such as insisting on a warrant for user content and issuing transparency reports. Companies can look at these reports to get a sense of best practices in the industry.
The topic of censorship is
The topic of censorship is closely tied to the rapidly expansion of state-sponsored attacks on the free press, coming from almost every government on Earth, so this seems relevant:
https://www.eff.org/deeplinks/2016/12/trump-free-speech-and-freedom-pre…
Trump on Free Speech and Freedom of the Press
Jennifer Lynch
19 Dec 2016
> No one can know for sure what the incoming Trump administration will do, but President-elect Donald Trump has repeatedly criticized and threatened the media in the United States. In lieu of attempting the impossible and predicting the future, we’ve gathered all of Trump’s stated positions on free speech and freedom of the press. If you are aware of any additional statements that we have not included, please email kate@eff.org with a link to your source material, and we will consider it for inclusion.
Readers who are nervous
Readers who are nervous about the prospect of Donald Trump inheriting the enormously oppressive power of the Surveillance State ought to be downright terrified by this revelation:
https://www.salon.com/2016/12/20/donald-trumps-future-nsa-director-met-…
Donald Trump’s future NSA director met with Austrian party founded by Nazis
Yes, there is a worldwide fascist movement, and both Trump and Putin are playing their part in Austria
Matthew Rozsa
20 Dec 2016
> The leader of Austria’s Nazi-founded Freedom Party has signed a cooperation agreement with Russia’s ruling party — only weeks after meeting with Lt. Gen. Michael T. Flynn, who will soon be national security adviser to President-elect Donald Trump. This muddies the waters as to the United States’ place in a geopolitical world that could be dominated by Russia in the near term.
Some months ago, one or posters who appeared to be high level current or former NSA employees showed up here to defend themselves. We tried to warn them, following whistleblower Bill Binney, that their insistence that the Dragnet is well intentioned is seen to be irrelevant as soon as you acknowledge that the next US President might not be a "responsible" or "humane" person, but a fascist. They replied (in my reading), that in that case we might rue the day that someone like former NSA/CIA Director Mike Hayden (the former General who rejected Binney's argument that the expanding NSA dragnet required technological blocks, not mere policies which could be overruled by a mean-spirited or even genocidal C-in-C) departed from NSA headquarters. Perhaps we can now agree that in these respects, both sides had a point.