It doesn’t matter where you live: in a dictatorship or in a democracy, Internet censorship is already in place or coming very soon now. But since “the Internet views censorship as damage and routes around it,” this post will summarize effective circumvention techniques that you can leverage against the current brand of censorship technology. Granted, this is — yet again — trying to solve a social problem with technical means, but since we can’t fix social diseases, we can at least resist them with technology as much as we can.
So, what kind of censorship are we talking about? Let’s peek at the current hottest contenders:
- DNS-based censorship resolves names of forbidden sites to bogus or rogue IPs.
- IP-based censorship blocks single IPs or IP blocks at the backbone router.
- CleanFeed-like systems intercept HTTP traffic to single pages.
In this post, we will look at these techniques and suggest ways to circumvent all of them. Beware that circumventing censorship may be illegal in your part of the world, and can subject you to draconian measures, including capital punishment. Use with caution and proceed carefully.
Most people use their ISP’s DNS servers to resolve names to IP addresses. ISPs can be forced by law to manipulate their DNS servers in such a way that censored names resolve to false IP addresses, or even worse, to honeypot addresses used by the police to collect evidence against offenders. But even without the ISPs direct involvement, super firewalls such as those used at the national level, can intercept and modify DNS flow upstream. As long as DNSSEC hasn’t been rolled out and being widely adopted, DNS meddling will be part of every national censorship infrastructure for some time to come.
To circumvent DNS-based censorship, you’ll obviously have to rely on an uncensored DNS server. Alternatively, you’ll have to get the actual name-to-IP mapping through out-of-band channels (i.e. not through DNS).
- The easiest work around, if your ISP allows bypassing their DNS servers, is to set up your own caching-only DNS server. BIND (named) can be configured on Unix systems to bootstrap from an official root server, or from an alternative root server.
- If the ISP blocks UDP port 53 (DNS), you’ll need outside help. Use technical forums or mailing lists to find someone who would start a DNS server and have it listen on a port that is usually not filtered. Then configure your caching-only DNS server to act as a forwarder and send all queries to this unconventional port.
- If the ISP also uses deep packet inspection to detect DNS traffic on unconventional ports, you’ll need to establish an encrypted channel to the outside server. An SSH connection would be the easiest work around (that is, unless SSH traffic is filtered as well — hint: try SSH over an alternative port != 22).
- If an SSH channel doesn’t work for you, route your DNS traffic through an encrypted VPN tunnel. You may need to sign up with a commercial VPN provider, or ask your friends abroad to set up a VPN channel for you.
Use the method that works best for you.
Suggested coding project #1
You can make a difference, if you’re a coder. Here are a couple of programs that you could write to easily bypass DNS-based censorship:
- Write an Apache module that scans HTML, and does the DNS resolution on the server side for each A HREF link. Append to that link the IP address.
- Write a Firefox add-on that parses the extended A HREF link from #1, and accesses the remote server via the provided IP addresses.
The basic idea here is that the server appends IP addresses to the DNS names of A HREF links, perhaps like this, hijacking the rel attribute:
The add-on would extract the IPv4 address from the rel attribute, and make Firefox access the following address instead:
This alone wouldn’t be enough, of course, because many virtual domains could be hosted on that IP. The add-on would thus also instruct Firefox to add Host: www.example.com to the HTTP headers of the request, so that the right virtual host is selected.
The combination of this Apache module and Firefox add-on would be to send non-modified IP addresses alongside the links to a client, which would then access the IP address directly, bypassing the forged DNS replies it would get from its government- or ISP-censored DNS server. The key here is that the DNS resolution is done at the server side in a different country (or on a different network that doesn’t censor this particular address), and not at the client side where it would have been intercepted.
Of course, your ISP could still catch the rel=”IPv4=192.168.0.1″ part of the reply and transparently redirect that as well, but there are two easy workarounds:
- Encrypt and digitally sign the IP address, so that we get something like rel=”oij20f02309vjwdvb0Xfwo”. Obfuscating may be enough though.
- Serve the page via SSL/TLS (HTTPS).
In the first case, the censoring ISP could still strip the rel entry entirely (and would cause problems to other legitimate applications), or it could try to modify its content. But if methods like HMAC are used, the client would notice the tampering and would refuse to follow the corrupted link. Alternatively, all mappings could be (steganographically) hidden in a .jpg, .gif, … or even in a .css comment (!) that would be loaded alongside the page.
In the second case, there’s not much the censoring ISP could do, besides preventing SSL/TLS entirely (which would cause even more damage, as a lot of eCommerce and banking sites rely on encryption).
Suggested coding project #2
You probably have a shared hosting account with some hoster for your web site, blog, etc. This hoster is probably in another country as well. If you’re lucky, that country doesn’t apply DNS censorship to the sites you would like to access. Now, you have the ideal anti-DNS-censorship tool, if you’re willing to do a little bit of coding:
- Define an XML-RPC protocol for simple DNS queries.
- Write an XML-RPC server that can be activated with CGI and install that on the shared hosting account in the non-censoring country.
- Write an XML-RPC client (e.g. as a firefox plugin, as a stand alone Python program, …).
The only job of the server in #2 is to resolve names to IP addresses, using the DNS server of the web hoster, and return the result via HTTP to the client. Notice that the DNS query is performed outside the censored realm, and is being transmitted over HTTP just like any other regular web page. This way, it is highly unlikely to be filtered, because it doesn’t look like DNS traffic. If, however, the censoring ISP uses deep packet inspection to catch the forbidden names in the XML-RPC request, or the numerical IP addresses in the XML-RPC reply, just throw in some form of encryption: the client will encrypt and sign the query, and the server will encrypt and sign the reply. This way, the DPI will have no chance to see what’s going on. For good measure, access this server via HTTPS (SSL/TLS), if possible.
Suggested coding project #3
In DNS, name to IP mappings have a limited time to live (TTL), typically between 1800 seconds and 86400 seconds, but at most a couple of days. A DNS caching server will automatically destroy the mappings after that. But this information is still valuable, because web sites typically don’t move every couple of days, but only every couple of months (if at all). So it could be useful to cache the mappings for a much longer time, and try them, even if the DNS-based censorship removed them upstream. So, try this:
- Modify your DNS server in such a way that it permanently saves mappings to a file or database.
- Change the resolution logic of the DNS server so, that when it gets a NX (not found), or a bogus honeypot IP address, it returns the addresses it saved in #1.
The outdated entries returned by this modified DNS server may not be always accurate, and will break sites that rely on load balancing (Akamai?), but they can be useful in a censorship-infested environment.
Hint: there are already SQL-based DNS servers out there. You may want to start with one of those and extend them accordingly. Isn’t open source beautiful?
Government-sponsored DNS fraud is just one way to block sites. As we’ve seen, this is trivially circumvented. Much more effective are blocks at the IP level itself. ISP routers can easily accommodate government-edited big access control lists (ACL) that block whole IP addresses or IP address blocks. Furthermore, some countries are reported to employ a central choke point with technology provided courtesy of Siemens and Nokia no less, to filter all inbound and outbound IP and telephony traffic. Of course, this kind of filtering will also affect innocent sites (on shared hosting accounts), but governments don’t care about collateral damage.
So how can one work around this heavy handed approach? With increasing levels of sophistication:
- Find a list of open web proxies (Google is your friend) and instruct your browser to use one of those proxies to access blocked sites. If you’re using Firefox, FoxyProxy is a useful add-on which lets you easily switch proxies. If possible, use a HTTPS instead of a HTTP proxy to prevent DPI.
- Use a SOCKS proxy instead of a HTTP proxy. A list of SOCKS proxy servers is easily found with Google.
- Use web-to-mail converters. Basically, you send an (PGP-encrypted) email to such a converter abroad with the URL(s) of the requested page(s). The converter fetches the requested pages, packages them into a container (zip etc…), and sends the (PGP-encrypted) result back to you as e-mail. Such programs are easily implemented as CGI and installed on a web hoster account outside the censorship realm.
- Route all your regular traffic through encrypted VPN tunnels. There are some good VPN providers out there (and here), but you have to expect your government to have an extensive list of VPN providers on their filters, so it may prove somewhat difficult to use them. Use forums and chat rooms to find relatively obscure VPN providers, or some activists who would be willing to set up a VPN channel just for you.
- Route all your traffic through anonymizing networks like TOR, if you have the necessary bandwidth. Keep in mind though, that TOR traffic is a primary target for censorship. You may want to use some additional obfuscation techniques if you want to pass through those central choke points.
- Host your information outside the web using Freenet. This is especially useful if you can’t establish or find a TOR exit node, so #5 wouldn’t work. Freenet users outside the censorship realm could always pick up your data and mirror it on the regular internet, and vice-versa.
- Use the POTS (plain old telephone system) and a modem and dial-in to an ISP abroad. Lists of dial-in ISPs are easily found with Google. You may want to encrypt the PPP connection to prevent DPI. Additionally, you may want to embed the PPP data inside a FAX connection, since most central choke points on the POTS usually don’t filter out Faxes, just PPP. You could also use some other data-link protocol, like Xmodem, Ymodem, or the more modern Zmodem or even more obscure and exotic protocols (if supported by the remote ISP), as those are unlikely to be filtered nowadays.
- Use packet radio (satellite or HAM/DX), if your country decided to block all telephone traffic. If you opt for a satellite solution, it all boils down to finding a satellite phone operator and using your satellite phone to establish a PPP connection. Beware that uplink can be sniffed many hundred meters around, and downlink is universally sniffable. Keep also in mind that satellite channels can be interrupted by local jamming stations. If you use HAM without a license, you are acting outside the law, but circumventing censorship is illegal anyway. Keep in mind that HAM radio can be easily located in a very short amount of time (minutes at most), using triangulation by surveillance vans. Always use a different city or spot, and only a few minutes max. (and only when absolutely necessary).
Again, use the method that works best for you, but keep in mind that you’re running a high personal risk.
In the UK, the IWF watchdog maintains a (secret) list of URLs which they claim contains CP. To enforce this block, many ISPs in the UK participate in a technology called CleanFeed, which is nothing more than an instance of deep packet inspection where they look at the HTTP protocol headers. The “advantage” of CleanFeed over DNS blocking is its finer granularity, i.e. the censors can block individual URLs within a site (as they did with an image on the Wikipedia entry of the heavy metal band Virgin Killer, causing a lot of trouble to UK users of the Wikipedia), as opposed to a whole site / server.
Circumventing Cleanfeed-like censorship is relatively easy:
- Use HTTPS instead of HTTP to access a site that contains the blocked items. The VK-block in the UK was easily circumventable by accessing the Wikipedia through the Secure Wikimedia server(s). As long as the whole secure server interface isn’t also backlisted, CleanFeed-like deep packet inspection can’t peer into SSL/TLS encrypted connections used to access the secure server (they only have the option of blocking the whole site, or to not block it at all).
- Use an HTTP proxy or SOCKS proxy. A list of HTTP proxies is easily found with Google. You can also try the Distributed Coral Cache by appending “.nyud.net” to the blocked item. Chances are that the blacklist doesn’t contain the modified URL and doesn’t block the IP address of the proxy or peer-to-peer caching server.
- If #1 and #2 don’t work for you, you can use any of the methods in the section IP-based censorship above that works for you.
Non-IP based networks
Prior to IP, UUCP networks of interconnected nodes were the norm. Those nodes used modems and the POTS to exchange data in batches. Even in a totally censored IP infrastructure, there’s always the possibility to bypass censorship by setting up a UUCP network over ISDN or POTS, and use that network to escape censorship. For this to work, UUCP-to-IP gateways are needed, and we may very well see more and more volunteers set up those gateways in many parts of the world as censorship gets worse over time.
Sometimes telecommunication networks are just totally unusable or unavailable. You may prefer to exchange information by offline means, like swapping hard drives, USB sticks, CD-Rs, DVD-Rs, etc… (be careful not to be caught, and remember to encrypt everything!) or even paper and voice. Be creative. Hiding information is always possible. Even totalitarian regimes like the former Soviet Union couldn’t effectively clamp down on samizdat.
Information wants to be free, and there is always a way to bypass and circumvent any roadblock an oppressive government or dumb politician puts in your way. However, thumbing an informational nose to Big Brother can cause serious harm to you, to your relatives’ and to your closest friends’ health. Use at your own risk, slippery when wet. You may prefer to enjoy our Brave New World and live in blissful ignorance of the outside world.