Archive for

April 24th, 2013

...

Internet Censorship and Fragmentation

Comments Off

Two Google brass, Executive Chairman Eric Schmidt and Director of Google Ideas Jared Cohen, have co-written an interesting piece on Internet censorship in today’s Guardian. They warn that the Internet might be moving to a fragmented network, filtered and censored by regional political, cultural and religious interests. They even speculate that some states might try to build their own national intranet, completely disconnected from the global Internet. A list of examples are mentioned, including the existing elephant in the room, which is China; but also hypothetical scenarios, where former Soviet states seek to prevent Russian influence; and Arab or Sunni nations that might create a network according to their religious and cultural interests.

However, for all the imagined scenarios, they fail to mention the second elephant: the US, and its heavy handed way of forcing other nations to filter and police their net-citizen, in the interest of US content “owners”. Through international trade agreements (e.g. ACTA); covert diplomacy (e.g. Russian AllOfMp3, and Swedish Pirate Bay raid and court case, and blocking in many countries); and boots on the ground in the MegaUpload raid, to give a few examples, the US is shaping the Internet and international law in their economic interests.

Schmidt and Cohen also speculate that in the future, Internet access will require some form of “passport”, and visiting other “regions” would require an “Internet visa”. Users would be forced to register before they’d gain access, they imagine. Well, Mr. Schmidt, that is happening right now. In Germany, hotel owners have been pressured into registering, with signature, every device they let on their network, so that they are not finned for “illegal” activity of their guests. Again, it is US business interests who have forced through this kind of filtering and surveillance.

Indeed, there are many unfortunate scenarios which might remove the value of the Internet for some users. However, we don’t have to come up with hypothetical scenarios, and point fingers at “other nations”. Instead, first take the plank out of your own eye, and then you will see clearly to remove the speck from your brother’s eye.

Comments Off

iodine – IP over DNS

1 comment

A recent stay in a couple of Germany hotels revealed a few things: First, American cultural imperialism has spun out of control, to the point where hotel receptionists are now footsoldiers for those who claim ownership of music and movie content. One hotel owner told us he had been fined two thousand Euros for MP3s downloaded by guests. While in another hotel I was hard pressed to get a second access code on their WiFi, and was not allowed to sign for the it on behalf of my wife. No wonder the The German Pirate Party has wind in its sails.

Secondly, even without these surveillance tactics in place, connecting to the abundance of half-open WiFi networks without authenticating can be useful. They are open in the sense that WiFi encryption is not used, and you can acquire a local IP without password. Most of the time, these networks are set up with a local log-in page, which grants you access for a specific device (MAC based) typically for a fixed amount of time. However, before the authentication code and password is entered, some traffic is let through: DNS requests have to work to get to the log-in page, and local hotel page. This is the basis of several TCP/IP over DNS protocols. I choice iodine, and successfully used the hotel network without log-in.

iodine is a bespoke server/client protocol which lets you tunnel IP4 data over DNS requests/responses. It works by setting up an extra network interface (TUN/TAP device) on both server and client, so that any traffic can be tunnelled. It takes care of a lot of the nitty-gritty settings itself, and probes for best settings. Finally, iodine is available for most popular platforms, including GNU/Linux (in the default repositories of Fedora and Ubuntu), *BSD, Android. However, make sure the same version is running on both client and server, as the author states that compatibility between versions is not a project goal.

Detailed setup is covered by several people, including their own HowTo and README; a CentOS compile example; and one for Debian. Thus, I wont repeat those details, and only cover some of the gotchas I stumbled upon and lessons I learnt:

  1. Start small and expand: The client/server can be brought up on the same machine, so make sure to try that first. Then try on the same local network, or remote but open networks, and finally on a semi-open network.
  2. Watch your firewall! The default DNS port, 53, is typically blocked, so you’ll have to punch through and forward that. Also make sure you open for UDP on that port! Use nmap from different locations to confirm that the port is open throughout. nc (Netcat) is useful in debugging the connection, but again make sure it’s UDP.
  3. Make sure the DNS entries for your domain are correct. You need two entries, and with some providers, it might not be obvious how to fill in their web-form to achieve the exact settings. I found this example most helpful.
  4. Debug the DNS setup using the CLI command dig, and the DNS web-tool by MXTools. For dig usage, this comment was useful.
  5. Use the test page provided by the author of iodine. It gives detailed and useful error reports on how far you’ve come with your setup.

With some luck, you’ll have a working setup, and will now be prepared for the next time the hotel receptionist does not give you enough WiFi vouchers for all your devices. Having said that, it does not really replace full access, as the connection will be “modem-slow”, or even worse. However, you do get access, which is sometimes what counts.

A client is is also available for Android from iodine, and Marcel goes into details on how to compile and run. I’ve not tried yet, and it seems there’s room for an easy to install F-Droid package there. More about that later.