dpi

Last week, a user in Jordan reported seeing a fake certificate for torproject.org. The user did not report any errors when browsing to sites such as Gmail, Facebook, and Twitter, which suggests that this was a targeted attack. The certificate was issued by a company called Cyberoam. We first believed that this incident was similar to that of Comodo and DigiNotar, and that Cyberoam had been tricked to issue a fake certificate for our website.

After a bit of research, we learned that Cyberoam make a range of devices used for Deep Packet Inspection (DPI). The user was not just seeing a fake certificate for torproject.org, his connection was actually being intercepted by one of their devices. While investigating this further, Ben Laurie and I found a security vulnerability affecting all Cyberoam DPI devices.

Examination of a certificate chain generated by a Cyberoam DPI device shows that all such devices share the same CA certificate and hence the same private key. It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or to extract the key from the device and import it into other DPI devices, and use those for interception.

Ben and I wrote a security advisory and notified Cyberoam of this vulnerability at 17:00 UTC on Saturday, June 30. We made it clear that we intended to publish this blog post and the security advisory on Tuesday, July 3, and encouraged them to respond promptly if they had any comments. At the same time, we notified browser vendors and asked that they blacklist the Cyberoam CA certificate in their browsers.

Cyberoam have not yet commented on this issue, apart from acknowledging our first email and saying that they are looking into it. The Cyberoam CA certificate is not trusted, and so browsers will show users a warning (unless someone has already installed the certificate). Users with the Tor Browser Bundle are not affected.

To check if this CA is installed in your browser, see the following instructions for Internet Explorer, Firefox, Chrome, and Safari. The instructions mention DigiNotar, but they are still valid. If you have more information about this issue, please email help@rt.torproject.org.

A few days ago, we published a blog post exposing the use of Deep Packet Inspection (DPI) to filter all Internet traffic in Ethiopia, including connections to the Tor network. We concluded that they are doing some sort of TLS fingerprinting, but had not been able to figure out exactly what they are fingerprinting on. Since then, we have managed to determine exactly how Ethiopia blocks Tor and we have developed a workaround. We will publish a full technical analysis very soon.

The long-term solution for Tor users in Ethiopia is to use the Obfsproxy Tor Browser Bundle. The bundles are, unfortunately, not up to date at the moment, but this is something we are working on (see #5937 for details). In the meantime, try using one of the following three bridges:

213.138.103.17:443
107.21.149.216:443
46.137.226.203:55440

If the bridges are not working, or you have questions, send an email to help@rt.torproject.org.

The Ethiopian Telecommunication Corporation, which happens to be the sole telecommunication service provider in Ethiopia, has deployed or begun testing Deep Packet Inspection (DPI) of all Internet traffic. We have previously analyzed the same kind of censorship in China, Iran, and Kazakhstan.

Reports show that Tor stopped working a week ago -- even with bridges configured. Websites such as https://gmail.com/, https://facebook.com/, https://twitter.com/, and even https://torproject.org/ continue to work. The graphs below show the effects of this deployment of censorship based on Deep Packet Inspection:

An analysis of data collected by a volunteer shows that they are doing some sort of TLS fingerprinting. The TLS server hello, which is sent by the Tor bridge after the TLS client hello, never reaches the client. We don't know exactly what they are fingerprinting on, but our guess is that it is either the client hello or the server hello. An illustration can be found in this network flow diagram.

Thanks to Philipp Winter and George Kadianakis for helping me analyze the data. If you have more information about the censorship in Ethiopia, please email help@rt.torproject.org.

Two weeks ago we announced the use of deep packet inspection to censor the Internet in Kazakhstan. Over those two weeks we've continued working on how they are blocking native tor connections. The good news is that our obfsproxy bundle continues to work well in country. Thanks to wanoskarnet, ann, and others for their help.

We have some network-level data captures at both ends to help us assess what is occuring. It seems the Kazakhstan firewall finds something unique in the TLS "Server Hello" message as sent by the Tor relay or bridge and therefore blocks subsequent communications. IP address and TCP port are irrelevant to the censorship. Research continues. Anonymized network flows are available here:

.kz client to relay: https://media.torproject.org/misc/2012-02-28-tor-kz-client-flow.txt

and

the relay view of that same conversation: https://media.torproject.org/misc/2012-02-28-tor-kz-bridge-relay-flow.tx...

Here's a graph of what this censorship looks like nationwide. The red dots are probable censorship events.

In December 2011 we were aware of Kazakhstan increasing Internet censorship in response to some unrest and protests in Zhanaozen in the west. The censorship was then deployed around the country, in many cases with the full support of the populace. The initial invesitgation showed simple IP address blocking coupled with basic dns censorship. Tor continued to work without incident until this week.

JSC KazTransCom, AS35104, has deployed or begun testing deep packet inspection (dpi) of all Internet traffic. They specifically target SSL-based protocols for blocking. This includes Tor, IPsec, and PPTP-based technologies, as well as some SSL-based VPNs. Business and private users of these technologies are equally affected.

An example of the censorship, as recorded by volunteers in country, can be found in this network flow diagram. Kazakhstan is identifying and blocking the SSL client key exchange during the setup of an SSL connection. This graph shows the effects of this deployment of censorship based on dpi.

Luckily, due to our recent experience with Iran we have an answer for people: use obfsproxy. Obfsproxy continues to work in Kazakhstan, as well as Iran. In fact, it works in any country where dpi is used to censor citizens' access to the Internet.

Thank you to the volunteers for spending their Valentine's Day collecting and analyzing data.

Over the past two days we've been hearing from, and working with, a number of Iranians having difficulty using Tor from inside Iran. It seems the Iranian government has ramped up censorship in three ways: deep packet inspection (dpi) of SSL traffic, selective blocking of IP Address and TCP port combinations, and some keyword filtering. For instance, they have partially blocked access to Tor's website, torproject.org, via IP address (such as 86.59.30.36) and port 443 (which is the HTTPS port). The third level of blocking is by keywords, such as searching for the word 'tor' via regular, non-encrypted search engine websites.

The blocks on SSL are not complete and not nationwide. Where blocking is in place, initial investigations show they are identifying the beginning of the SSL handshake and simply interrupting the handshake. We continue to research and investigate solutions with the assumption that SSL will eventually be blocked nationwide inside Iran. Our goal is to defeat their dpi signatures and allow tor to work by default.

The Iran Media Program has posted their thoughts on what is happening from a journalist's perspective.

So far, it seems the majority of Tor users are not affected by these blocks. Iran is still the #2 country based on direct usage, https://metrics.torproject.org/users.html?graph=direct-users&country=ir#.... This number is on the decline, however.

More details to follow as we have them.

Update 2011-02-10 18:05 UTC: We are working on making our obfuscating proxy more stable and easier to deploy. If you can compile code, following these directions will help. We're also working on Amazon EC2 instances of obfsproxy for point and click deployment.