How to fail at code-signing, the open-source edition (part I)


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:

Anonymizing proxies

“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?

Business-as-usual scenario

First let’s consider how users normally authenticate the source of their applications. There are several possibilities:

  1. 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.
  2. 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.**
  3. 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]

CP

** 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.

One thought on “How to fail at code-signing, the open-source edition (part I)

  1. Hi Cem, your comments on code signing are interesting. I’m a PM at Symantec and work on our code signing products. It’d be great to chat informally sometime and connect. I don’t have a specific agenda, but I’m just sort of reaching out.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s