china

This blog post is also available in Chinese, translated by our friends from GreatFire.org.

Roya, David, Nick, nweaver, Vern, and I just finished a research project in which we revisited the Great Firewall of China's (GFW) active probing system. This system was brought to life several years ago to reactively probe and block circumvention proxies, including Tor. You might remember an earlier blog post that gave us some first insight into how the active probing system works. Several questions, however, remained. For example, we were left wondering what the system's physical infrastructure looked like. Is the GFW using dedicated machines behind their thousands of probing IP addresses? Does the GFW even "own" all these IP addresses? Rumour had it that the GFW was hijacking IP addresses for a short period of time, but there was no conclusive proof. As a result, we teamed up and set out to answer these, and other questions.

Because this was a network measurement project, we started by compiling datasets. We created three datasets, comprising hours (a Sybil-like experiment to attract many probes), months (an experiment to measure reachability for clients in China), and even years (log files of a long-established server) worth of active probing data. Together, these datasets allow us to look at the GFW's active probing system from different angles, illuminating aspects we wouldn't be able to observe with just a single dataset. We are able to share two of our datasets, so you are very welcome to reproduce our work, or do your own analysis.

We now want to give you an overview of our most interesting findings.

• Generally, once a bridge is detected and blocked by the GFW, it remains blocked. But does this mean that the bridge is entirely unreachable? We measured the blocking effectiveness by continuously making a set of virtual private systems in China connect to a set of bridges under our control. We found that every 25 hours, for a short period of time, our Tor clients in China were able to connect to our bridges. This is illustrated in the diagram shown below. Every point represents one connection attempt, meaning that our client in China was trying to connect to our bridge outside of China. Note the curious periodic availability pattern for both Unicom and CERNET (the two ISPs in China we measured from). Sometimes, network security equipment goes into "fail open" mode while it updates its rule set, but it is not clear if this is happening here.

• We were able to find patterns in the TCP headers of active probes that suggest that all these thousands of IP addresses are, in fact, controlled by a single source. Check out the initial sequence number (ISN) pattern in the diagram below. It shows the value of ISNs (y-axis) over time (x-axis). Every point in the graph represents the SYN segment of one active probing connection. If all probing connections would have come from independent computers, we would have expected a random distribution of points. That's because ISNs are typically chosen randomly to protect against off-path attackers. Instead, we see a clear linear pattern across IP addresses. We believe that active probes derive their ISN from the current time.

• We discovered that Tor is not the only victim of active probing attacks; the GFW is targeting other circumvention systems, namely SoftEther and GoAgent. This highlights the modular nature of the active probing system. It appears to be easy for GFW engineers to add new probing modules to react to emerging, proxy-based circumvention tools.
• The GFW is able to (partially) speak the vanilla Tor protocol, obfs2, and obfs3 to probe bridges. Interestingly, node-Tor—a JavaScript implementation of the Tor protocol—is immune to active probing because it implements the Tor protocol differently, which seems to confuse active probes. We were also able to resist active probes by modifying a bridge of ours to ignore old VERSIONS Tor cells. This is unlikely to be a sustainable circumvention technique, though.
• Back in 2012, the system worked in 15-minute-queues. These days, it seems to be able to scan bridges in real-time. On average, it takes only half a second after a bridge connection for an active probe to show up.
• Using a number of traceroute experiments, we could show that the GFW's sensor is stateful and seems unable to reassemble TCP streams.

Luckily, we now have several pluggable transports that can defend against active probing. ScrambleSuit and its successor, obfs4, defend against probing attacks by relying on a shared secret that is distributed out of band. Meek tunnels traffic over cloud infrastructure, which does not prevent active probing, but greatly increases collateral damage when blocked. While we keep developing and maintaining circumvention tools, we need to focus more on usability. A powerful and carefully-engineered circumvention tool is of little use if folks find it too hard to use. That's why projects like the UX sprint are so important.

Finally, you can find our research paper as well as our datasets and code on our project page. And don't hesitate to get in touch with us if you have any questions or feedback!

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.

• The ramped up censorship of the Internet by China continues while the world is distracted by the Middle East and Japan. http://advocacy.globalvoicesonline.org/2011/03/20/china-pptp-and-l2tp-vp...
• GMail blockage in China, or not. http://techcrunch.com/2011/03/21/google-and-china-at-it-again-with-gover...
• On Mandated Content Blocking in the Domain Name System, http://www.circleid.com/posts/20110318_on_mandated_content_blocking_in_t...
• The always excellent EDRi-gram is out for March 2011, http://www.edri.org/edrigram/number9.5

Experts in China tell us Tor is not being singled out, that all "circumvention" tools are being subjected to the censorship regime of the Great Firewall of China as politically sensitive anniversaries come about. We also hear people in China need their privacy too, even if they never leave the Chinese Internet.

However, it appears China is getting better at blocking Tor. Here's a graph of returning users to the Tor Network from China:

However, most Tor users in China switched to non-public relays, called bridges, over the past few months. Interestingly, the GFW has also started blocking some of the more popular bridges: read more »

As reported, Tor was partially blocked by China on September 25th or so in anticipation of the CCP October 1, 2009 60th anniversary.

Here's what one directory mirror recorded for September,

And here's the growth of bridge users in response. Alas, like our graphs of bridge use in Iran in June 2009, we only have relative counts for bridge use, not absolute counts. But with a 70x increase in a week, we are talking about 10000+ bridge users:

Here's what the Tor Project accomplished in September 2009.

New Hires read more »

• Carolyn Anhalt is our new Translation and Community Manager. Carolyn has years of experience managing and growing content translation, as well as wrangling online communities and developing volunteer moderators and support roles from the community. She’s fluent or conversant in a number of languages, such as: Russian, French, English, German, Italian, and Welsh. Carolyn’s initial goals are to grow the translator community to keep everything Tor translated, work out better translation tools for translators, and to generally assist translators.
• Karen Reilly joins us as our Development Director. Karen has years of experience in growing both community-based and foundation-based funding, as well as helping to fulfill the mission of organizations through outreach and community-building. Karen’s initial goals are to further develop community funding, work with our current donors, help create an annual report, and expand Tor’s outreach efforts.

On September 25, 2009, the Great Firewall of China blocked the public list of relays and directory authorities by simple IP address blocks. Currently, about 80% of the public relays are blocked by IP address and TCP port combination. Tor users are still connecting to the network through bridges. At the simplest level, bridges are non-public relays that don't exit traffic, but instead send it on to the rest of the Tor network.

If you want to help people in China get access to the uncensored Internet, run a bridge.

Feel free to mirror this post, or the Tor website. We have a list of mirrors at https://www.torproject.org/mirrors.html.en or search for tor mirrors via Google, Yahoo, Baidu, etc.

Links to other helpful sites (not run by us): read more »

• http://www.reddit.com/r/technology/comments/9ofr7/we_need_more_tor_bridg...

Design
We continued enhancements to the Chinese and Russian Tor website translations. We also have a second Chinese translator for the website now, so hopefully we will get more prompt translations there. Our Farsi translation from this summer is slowly becoming obsolete; we should solve that at some point.

We added a new "30 second summary" web page for Tor:
https://www.torproject.org/30seconds
and a new "easy download" page since the original is so complex:
https://www.torproject.org/easy-download

In the upcoming Vidalia 0.2.0 development release:
- Support changing UI languages without having to restart Vidalia.
- Updated Czech, Polish, Romanian and Turkish translations.

In the upcoming Vidalia 0.1.10 stable release:
- Add a prettier dialog for prompting people for their control port password that also includes a checkbox for whether the user wants Vidalia to remember the entered password, a Help button, and a Reset button (Windows only).
- Fix a crash bug that occurred when the user clicks 'Clear' in the message log toolbar followed by 'Save All'.
- Uncheck the Torbutton options by default in the Windows bundle installer if Firefox is not installed.
- Add an Windows bundle installer page that warns the user that they should install Firefox, if it looks like they haven't already done so.

It looks like Australia is soon to be joining the ranks of countries with a nationwide filtering regime:
http://arstechnica.com/news.ars/post/20081016-net-filters-required-for-a...

Proposals
We finished the first iteration of our auto-updater spec:
https://svn.torproject.org/svn/updater/trunk/specs/thandy-spec.txt
We detail our current auto-updater progress below. read more »

We didn't expect Tor wouldn't be blocked in China for a long time before it became true days ago.  We've got a lot of users' reports on that from different regions in China about torproject.org was blocked by Great Firewall system in China.  
McFred's Blog said:

torproject.org is the official Tor(The Onion Router) web site, found recently been blocked by China's national firewall, also known as Great Firewall.
Trace route from Beijing, China shows the destination is unreachable, seems they changed the route table on the router at IP 202.97.66.37, refuse connection to Tor web site.

Jacky talked on his Chinese blog: read more »

In Tor's annual board meeting in January, we added Isaac Mao to our board of directors. Isaac is a well-known blogger, especially among the Chinese blogging community, and adding him is the first part of our push to make the Tor board (and The Tor Project in general) more international in scope and awareness.

Isaac will take over Rebecca McKinnon's spot on the board, though Rebecca is planning to stick around and continue helping with advice about how to interact with the media and Tor's role in society, especially in Asia. Isaac has a lot of ideas about how to make Tor easier to use and how to get the word out to all the different groups that need it. We're looking forward to working with him!