pluggable transports

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 use the “meek” pluggable transport

The recently released 4.0-alpha-1 version of Tor Browser includes meek, a new pluggable transport for censorship circumvention. meek tunnels your Tor traffic through HTTPS, and uses a technique called “domain fronting” to hide the fact that you are communicating with a Tor bridge—to the censor it looks like you are talking to some other web site. For more details, see the overview and the Child’s Garden of Pluggable Transports.

You only need meek if your Internet connection is censored so that you can’t use ordinary Tor. Even then, you should try other pluggable transports first, because they have less overhead. My recommended order for trying transports is:

  1. obfs3
  2. fte
  3. scramblesuit
  4. meek
  5. flashproxy

Use meek if other transports don’t work for you, or if you want to help development by testing it. I have been using meek for my day-to-day browsing for a few months now.

All pluggable transports have some overhead. You might find that meek feels slower than ordinary Tor. We’re working on some tickets that will make it faster in the future: #12428, #12778, #12857.

At this point, there are two different backends supported. meek-amazon makes it look like you are talking to an Amazon Web Services server (when you are actually talking to a Tor bridge), and meek-google makes it look like you are talking to the Google search page (when you are actually talking to a Tor bridge). It is likely that both will work for you. If one of them doesn’t work, try the other.

These instructions and screenshots are for the 4.0-alpha-1 release. If they change in future releases, they will be updated at https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart.

How to use meek

First, download a meek-capable version of Tor Browser for your platform and language.

Verify the signature and run the bundle according to the instructions for Windows, OS X, or GNU/Linux.

On the first screen, where it says Which of the following best describes your situation?, click the Configure button.

Tor Network Settings “Which of the following best describes your situation?” screen with the “Configure” button highlighted.

On the screen that says Does this computer need to use a proxy to access the Internet?, say No unless you know you need to use a proxy. meek supports using an upstream proxy, but most users don’t need it.

Tor Network Settings “Does this computer need to use a proxy to access the Internet?” screen with “No” selected.

On the screen that says Does this computer's Internet connection go through a firewall that only allows connections to certain ports?, say No. As an HTTPS transport, meek only uses web ports, which are allowed by most firewalls.

Tor Network Settings “Does this computer's Internet connection go through a firewall that only allows connections to certain ports?” screen with “No” selected.

On the screen that says Does your Internet Service Provider (ISP) block or otherwise censor connections to the Tor Network?, say Yes. Saying Yes will lead you to the screen for configuring pluggable transports.

Tor Network Settings “Does your Internet Service Provider (ISP) block or otherwise censor connections to the Tor Network?” screen with “Yes” selected.

On the pluggable transport screen, select Connect with provided bridges and choose either meek-amazon or meek-google from the list. Probably both of them will work for you, so choose whichever feels faster. If one of them doesn’t work, try the other. Then click the Connect button.

Tor Network Settings “You may use the provided set of bridges or you may obtain and enter a custom set of bridges.” screen with “meek-google” selected.

If it doesn’t work, you can write to the tor-dev mailing list, or to me personally at dcf@torproject.org, or file a new ticket.

On recent and upcoming developments in Pluggable Transports

Hello friends,

this is a brief post on recent and upcoming developments of the Pluggable Transport world:

What has happened

Here is what has been keeping us busy during the past few months:

TBB 3.6

As many of you know, the TBB team recently released the Tor Browser Bundle 3.6 that features built-in PT support. This is great and has taken PT usage to new levels. Maaad props to the TBB team for all their work.

TBB-3.6 includes obfs3 and FTE by default. If the built-in bridges are blocked for you (this is the case at least in China), try getting some more bridges from BridgeDB (which also got renovated recently).

obfs2 deprecation

We are in the process of deprecating the obfs2 pluggable transport.

This is because China blocks it using active probing, and because obfs3 is stictly better than obfs2. obfs3 can also be blocked using active probing, but China hasn't implemented this yet (at least as far as we know). The new upcoming line of PTs (like scramblesuit and obfs4) should be able to defend more effectively against active probing.

Outgoing proxies and Pluggable Transports

Yawning Angel et al. recently implemented outgoing proxy support for PTs. This means that soon our PTs will be able to connect to an outgoing proxy using the Socks5Proxy torrc option (or the corresponding proxy field in TBB).

A Childs Garden Of Pluggable Transports

David Fifield created refreshing visualizations of Pluggable Transports. Take a look; it might help you understand what these damned things are doing.

What will happen

Now let's take a look into the short-term future (a few months ahead) of Pluggable Transports:

obfs4 and ScrambleSuit

Remember ScrambleSuit? Guess what; we are thinking of not deploying it after all...

Don't get me wrong, ScrambleSuit is great, but during the past two months Yawning has been developing a new transport called 'obfs4'. obfs4 is like ScrambleSuit (with regards to features and threat model), but it's faster and autofixes some of the open issues with scramblesuit (#10887, #11271, ...).

Since scramblesuit has not been entirely deployed yet, we thought that it would be a good idea to deploy obfs4 instead, and keep scramblesuit around as an emergency PT.

Meek

Meek is an exciting new transport by David Fifield. You can read all about it here: https://trac.torproject.org/projects/tor/wiki/doc/meek

It's basically a transport that (ab)uses Firefox to do SSL in a way that makes it look like Firefox but underneath it's actually Tor. Very sneaky, and because it uses third-party services (like Google Appspot, Akamai, etc.) as proxies, the user does not need to input a bridge. Meek just works bridgeless and automagically.

Help us by testing the latest bundles that David made: https://lists.torproject.org/pipermail/tor-qa/2014-June/000422.html

Also, since the recent Google block in China, Meek will not work with Google Appspot. However, other third-party services can be used instead of Appspot, so Meek does not lose its effectiveness.

PTs and IPv6

PTs are not very good at IPv6 yet. We identified some of the open issues and hopefully we will fix them too.



And that's that for now.

Till next time, enjoy life and give thanks and praises :)

(For what it's worth, this was originally a post in the [tor-talk] mailing list:
https://lists.torproject.org/pipermail/tor-talk/2014-June/033296.html)

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.

Pluggable transports bundles 2.4.18-rc-1-pt1 and 2.4.18-rc-2-pt1 with Firefox 17.0.11esr

There are new Pluggable Transports Tor Browser Bundles with Firefox 17.0.11esr. They are made from the Tor Browser Bundle 2.4.18-rc-1 release of November 19, except for the 64-bit GNU/Linux bundle, which is made from the 2.4.18-rc-2 release of November 20.

Pluggable Transports bundle download

Pluggable transports bundles 2.4.17-rc-1-pt2 with Firefox 17.0.10esr

There are new Pluggable Transports Tor Browser Bundles with Firefox 17.0.10esr. They are made from the Tor Browser Bundle release of November 1.

These are mostly the same as 2.4.17-rc-1-pt1 released a few days ago, the only change being a workaround that allows them to run on OS X Mavericks.

Pluggable transports bundles 2.4.17-rc-1-pt1 with Firefox 17.0.10esr

There are new Pluggable Transports Tor Browser Bundles with Firefox 17.0.10esr. They are made from the Tor Browser Bundle release of November 1.

The OS X bundle won't work in the new OS X Mavericks by default. It is caused by some changes in the new operating system release. We know about this problem and are working on fixing it. If you are an affected user, you can try this workaround of placing absolute paths in the torrc file.

The bundles contain flash proxy and obfsproxy configured to run by default. If you want to use flash proxy, you will have to take the extra steps listed in the flash proxy howto.

These bundles contain the same hardcoded obfs2 bridge addresses as the previous bundles which may work for some jurisdictions but you are strongly advised to get new bridge addresses from BridgeDB.

Pluggable transports bundles 2.4.17-beta-2-pt3 with Firefox 17.0.9esr

There are new Pluggable Transports Tor Browser Bundles with Firefox 17.0.9esr. They are made from the Tor Browser Bundle release of September 20 and contain important security fixes.

The bundles contain flash proxy and obfsproxy configured to run by default. If you want to use flash proxy, you will have to take the extra steps listed in the flash proxy howto.

These bundles contain the same hardcoded obfs2 bridge addresses as the previous bundles which may work for some jurisdictions but you are strongly advised to get new bridge addresses from BridgeDB.

Pluggable transports bundles 2.4.15-beta-2-pt1 with Firefox 17.0.8esr

We've updated the Pluggable Transports Tor Browser Bundles with Firefox 17.0.8esr and Tor 0.2.4.15-beta-2. These correspond to the Tor Browser Bundle release of August 9 and contain important security fixes.

These bundles contain flash proxy and obfsproxy configured to run by default. If you want to use flash proxy, you will have to take the extra steps listed in the flash proxy howto.

These bundles contain the same hardcoded obfs2 bridge addresses as the previous bundles which may work for some jurisdictions but you are strongly advised to get new bridge addresses from BridgeDB.

These bundles are signed by David Fifield (0x5CD388E5) with this fingerprint.

Pluggable transports bundles 2.4.12-alpha-2-pt1 with Firefox 17.0.6esr

We've updated the Pluggable Transports Tor Browser Bundles with Firefox 17.0.6esr and Tor 0.2.4.11-alpha. These correspond to the Tor Browser Bundle release of May 14.

These bundles contain contain flash proxy and obfsproxy configured to run by default. Flash proxy has a new faster registration method, flashproxy-reg-appspot. The existing flashproxy-reg-email and flashproxy-reg-http will be tried if flashproxy-reg-appspot doesn't work.

If you want to use flash proxy, you will have to take the extra steps listed in the flash proxy howto.

These bundles contain the same hardcoded obfs2 bridge addresses as the previous bundles which may work for some jurisdictions but you are strongly advised to get new bridge addresses from BridgeDB: https://bridges.torproject.org/?transport=obfs2 https://bridges.torproject.org/?transport=obfs3.

These bundles are signed by David Fifield (0x5CD388E5) with this fingerprint.

Syndicate content Syndicate content