Censorship vs. Tor browser-bundle
There is an interesting connection between recent episodes of Internet censorship in Turkey and primitive approaches used to authenticate the integrity of open-source software. To recap:
- Twitter was blocked by a court order in Turkey.
- The block was initially implemented at DNS level by local ISPs; attempts to look up the IP address for twitter.com returned bogus results.
- This was at best an imperfect approach; soon instructions for switching to Google DNS started circulating and its IP address began to appear as graffiti on building walls, instructing passersby in the arcane art of reconfiguring Windows DNS settings.
- Wised-up telecoms up their censorship game, this time blocking Twitter IP range as well as Google DNS itself.
“There is never a shortage of solutions in democracies” as one Turkish politician has stated. A resourceful nation responded by resorting to using proxies and VPN services, all of which bypass the IP-level blocking by first connecting to one or more intermediate “jumping stones” which then routes traffic to the intended destination. Tor is by far the most popular option, operated as a free service by volunteers running nodes on their own machines. Given the difficulty of setting up Tor (despite advances since publication of that paper, including one-stop user-friendly Tor browser bundle containing a preconfigured Firefox build) it was impressive how quickly Tor usage spiked in Turkey, peaking at twice the baseline. In theory Tor is decentralized; there is no single point of failure, no single server that could be taken out to cut off access to the network. But for practical purposes, when an entire nation is trying to alter its web browsing habits, there is one choke point: getting the Tor client software. Sure enough the censorship soon moved to also block the main Tor website.
Verifying code integrity
So what does any of this have to do with code authentication? Consider a user trying to download and install the Tor browser bundle. They can no longer download it from the main website or any popular mirrors– ISPs will surely wake up and block these. More likely people will turn to their own social network, start emailing each other links to obscure servers hosting the software or even the entire binary as attachment. Some of these emails will be sent by well-meaning people trying to help their friends. Others may actually be attempts to distribute malware by capitalizing on the sudden demand for a popular piece of free software. Does the average user have a fighting chance of distinguishing these cases?
First let’s consider how users normally authenticate the source of their applications. There are several possibilities:
- Installed from an app-store doing some level of vetting on authorship and pedigree of applications, which varies based on the philosophy of the market operator. Apple carefully curates the offerings, Google takes a laissez-faire approach and ends up with frequent occurrence of malware on Play Store.
- Downloaded from a trusted website. This is really a generalization of the first case. The distribution point acts as a proxy for the trustworthiness of the application. For example we assume that code downloaded over SSL from the Mozilla website is unlikely to be malicious.**
- Code signing. By far the most prevalent example of this is the Authenticode format used for software distribution on Windows.
Signing only helps if users can verify
What about the Tor browser bundle? At the time of this writing, it is not found on the Microsoft store, although it could very well have been submitted there to make life easier for Windows users, the main audience in this case. The situation is not any better for Mac users. For iOS there is an Onion Browser in app-store but it is not free. (Worse there has been a bogus Tor app riddled with spyware which Apple did not take any action on for months.) The paucity of these choices rules out option #1 for most users. Because of active censorship, it can not be downloaded from the official Tor project website, also ruling out option #2. Individuals can create additional mirrors but trust in those will be necessarily limited to those in that person’s immediate social-network.
That leaves code signing. As it turns out, TBB is in fact cryptographically signed using PGP format. It is a detached signature, meaning that the signature is not part of the installer itself and must be located independently. While it is easier to verify signatures that are part of the file-format, this is not a major obstacle. (In fact Authenticode also has support for detached signatures, since some file formats do not afford an easy way to sneak in extra data to contain the signature.) While the cryptography is sound, this is another case where Tor project has gone on a flight of fancy in terms of what can be expected of mainstream users.
[continue to part II]
** There is also a primitive approach usually seen in open-source software that involves publishing MD5 or SHA1 hashes and then serving the actual download from some other untrusted location. This also boils down to relying on location; trust is bootstrapped by based on the website which contains these hashes used to verify the integrity of the bulk data downloaded. Amusingly many download sites serve these hashes over unprotected HTTP connections, which makes the entire scheme into security theater.