Censorship is on the rise worldwide. This page describes some of the more common ways that websites and apps are blocked, and how both service providers and users can get around them.


DNS Blocking

DNS blocking is one of the easiest and fastest ways to block a website. It is achieved by forcing ISPs to essentially misdirect users looking for the blocked website to a blank page or a page explaining why a site is blocked. This uses DNS, the Domain Name System, which is a decentralized “phone book” for the internet that translates domain names to internet addresses.

A famous example of this is Turkey’s March 2014 blocking of social media - notably Twitter.

What the host can do

The only real options for the host against this censorship is to provide alternative addresses – and somehow communicate them to users.

What users can do

In the case of Turkey, users were able to override their ISP’s misinformation by switching to using Google’s public DNS servers at 8.8.8.8 and 8.8.4.4.

DNS Graffitti in Turkey

How this escalates

There are a limited number of public DNS servers, which can be blocked with IP blocking and DNS traffic outside of a network itself can be blocked at the protocol level, forcing users to accept the “wrong” information.

IP blocking

IP blocking requires more effort from the censor, and can have unintended consequences. Instead of blocking the “name” of a location on the internet, IP blocking targets its specific address. Alone this and the DNS blocking technique are easily circumvented, but become challenging in combination.

What the host can do

The host of any blocked service can easily swap in a new IP and push out an update, but the new IP will likely get blocked too.

Depending on the nature of the blockage, a host can also use a content delivery network or other cloud service provider, where one IP (and in many cases, one DNS name) may “answer” for thousands of different services. Blocking that would cause “collateral damage” – those thousands of other resources would also be blocked. This is a core concept being used by Greatfire’s Collateral Freedom campaign, where they host censored content in the Amazon cloud and on github.

What users can do

One quick trick that users might try is to use a VPN to get around the blockage – so let’s take an example of an OpenVPN connection that uses the default configuration.

OpenVPN’s default port is 1194 and it uses SSL/TLS as a carrier for the encryption. A basic firewall – like the one which is already blocking your app – can easily classify a connection based on those elements then block the IP address or the domain of the OpenVPN server, this will prevent users from using the an OpenVPN default setup.

A wireshark capture for OpenVPN packets

A wireshark capture for OpenVPN packets

How this escalates

The collateral freedom approach is not without its own risks. In the Greatfire example, while github and the Amazon Cloud were not blocked outright due to the socio-economic impacts, they both paid a steep price for hosting censored content in the form of a crippling denial of service attack

Less advanced adversaries can also take a further step on even the most basic firewalls, which is Protocol and Port Blocking.

Port Blocking

Even basic firewalls can block traffic for a specific protocol. This is commonly seen on public/guest/conference wifi networks which only allow “web browsing” (e.g. port 80 ans 443 - http and https ports). Censors can easily target traffic and simply not allow it to pass on its default ports. In the OpenVPN example, blocking port 1194 will prevent a client from establishing a connection to any OpenVPN server.

What the host can do

In order to go around this kind of censorship, The VPN provider will change the port of the OpenVPN server to use the port 443, and the client’s VPN connection will establish the connection to the port 443 which will make it hard to block the service by port number and it’s hard to filter real https traffic and differentiate it from the OpenVPN, as both are encrypted.

As port 443 is the default port for secure web browsing (https), it is rarely blocked.

What users can do

As the sophistication of the censor increases, the options for users to circumvent the censorship from only their side narrows. Here, users must seek out services which allow them to proxy their traffic through unblocked ports, which generally will require setup in advance.

How this escalates

Taken individually, this and the above techniques are not impossible for a dedicated user to circumvent, with some support from a host service. However, they are easily combined to become more challenging – a host may not only block the OpenVPN port, but also block access to know VPN websites via DNS, and known VPN hosts via IP blocking.

Some adversaries may be willing to accept some of the downsides, including steep economic costs, and accept blocking large portions of the internet or shutting external communications down completely for limited periods of time.

More advanced adversaries can move on from these to using a more active approach to censorship (and surveillance) - Deep Packet Inspections, or DPI.

DPI Blocking

Deep Packet Inspections, or DPI inspects each packet based on the header of its request and the data it carries, it can identify the type of protocol or the connection is using even if it was encrypted. DPI is not a mechanism to decrypt what’s inside packets but to identify the ‘protocol’ or the application it represents.

With DPI, a censor can targeting VPN, Tor and other services by filtering the packets at the Application Layer of the OSI reference model, analyze them, and then block the IP addresses that the clients are trying to connect to.

Even if you are using OpenVPN on the https port, and not using a well-known VPN host (which could be blocked by IP and/or DNS), DPI can inspect the traffic and identify it as OpenVPN, and block it based on that inspection.

A Short History of DPI Blocking
In 2012, both Iran and China began filtering encrypted internet traffic, specifically targeting The Tor Project’s anti-censorship, pro-privacy network; triggering The Tor Project to release their first public obfuscation work.
Other countries soon applied the same strategy – Ethiopia later in 2012, Syria in 2014, among many others – Privacy International tracks surveillance systems in their Transparency Toolkit; and Freedom House’s Freedom on the Net tracks both censorship and other limitations on net freedom.

What the host can do

At this stage, obfuscation of traffic becomes a requirement - to evade DPI and thereby protect servers from being immediately blocked via IP. Pluggable Transports were first developed by The Tor Project to provide ways for tool developers to make their apps more resilient against DPI filtering.

Pluggable Transports make it harder for DPI to classify the connection and take an action against it. A Child’s Garden on Pluggable Transports provides a step-by step walkthrough of how The Tor Project obfuscated tor network traffic, and how early obfuscation approaches were identified and blocked.

How this escalates

In December 2016, Turkey escalated their censorship abilities from DNS blocking to DPI-based blocking, focusing on censoring VPN and Tor traffic.

Pluggable Transports continued to work despite this escalation.

Advanced Censorship

Let us now walk through some of the options for transports, and how they vary in their approaches. We’ll start with a very simplistic approach:

Simple obfuscation

One could easily “encrypt” traffic so it doesn’t look like the traffic that is being blocked. Using a Caesar cipher like ROT13, or minimal tweaks to parts of the traffic which are being used to identify it are examples - and have even worked for a while in some cases.

However, this is easily blocked by the adversary re-identifying the handshake and blocking based on that.

Making it look like noise

A significant step up from this is to work towards making the traffic look like nothing at all. The goal here is to eliminate any identifying characteristics of the traffic, forcing a censor towards more expensive attacks. This is the approach in Tor’s most famous “obfs” line of transports, and we refer to this as Scrambling.

To defeat scrambling, censors must either select only recognized and “approved” traffic out (whitelisting), scan the destination of each unrecognized stream of traffic and determine if it is legitimate or a circumvention tool, or find ways to interfere with or still identify the traffic.

China is famous for their “active probing” , and Iran for their willingness to terminate encrypted traffic after one minute. The newest attack appears to be from Kazakhstan, which is using a system which matches the timing of the obfs4 handshake and prevents it from successfully completing.

Making it look like something else

For adversaries willing or able to effectively combat scrambling, another approach is transforming the traffic to look like known - and approved - traffic. This faces its own challenges, as it becomes an arms race to ensure that this “shape-shifting” is good enough to continuously fool the censor - not just as the traffic, but also at the end-points. If, for example, you are shape-shifting your traffic into vanilla http, the server will need to respond like a real web server. The Parrot is Dead explains the challenges these protocols face.

However, using this approach can force even more resource-intense follow-up scanning (the censor must now determine if the server is “correct” or not).

Hiding in the crowd

Another approach leverages large cloud providers which are socially or economically difficult to block. Using Fronting, you can route traffic through an allowed service. This would force an adversary to block an entire cloud provider - and every other service hosted in it. Amazon advertises over a million active customers of its Web Services cloud, including AirBnB, Blackboard, Dow Jones, and Netflix. Blocking a circumvention tool that “hides” in Amazon’s cloud would cause immense strain. By a similar token, using Google’s App Engine to circumvent would require blocking the entirety of Google.

Some adversaries are willing to do this - but often only temporarily. The downside of this powerful technique is that is can be overwhelmingly financially expensive to route traffic through these services.

Another variant of this approach is using many, short-lived ephemeral connections. An initial foray into this was called flashproxy, which leveraged website visitors themselves as proxies for others via javascript. A new attempt at this is emerging, called Snowflake, which gets around many of the challenges flashproxy faced by using WebRTC.

Onwards

There is no one perfect solution, but this is where we are today.

Not every adversary seeking to limit access to information can or is willing to do all of the above, so creative application of these, building new versions, innovation around new approaches – and sharing of working options – allow app and service providers to ensure connectivity through everything but complete shutdowns.