Most experienced users of the web know to look for a little lock icon in their address bar if they want to be sure that their connection is encrypted.

But they often don’t know what that lock means or how it offers security.

An encrypted connection cannot be read by casual eavesdroppers. But encryption, by itself, is not guaranteed to protect your information, because of what’s known as a man-in-the-middle attack. A malicious attacker can present himself to you as the server you are trying to connect to, even offering you an encrypted connection. If he wants to cover his tracks, he can relay the information you provide to the correct server, and relay the server’s answers back to you. In this way, the attacker can discover your password, read your emails, or examine your bank records.

Without authenticating the identity of the server you are trying to connect to, encryption simply doesn’t buy you much security.

TLS, the cryptographic protocol represented by our friend the lock icon, tries to solve this by using a public key distribution system called X.509, in which the server presents a certificate signed by a known certificate authority (CA). The certificate authority is a trusted party whose job it is to verify that the public key represented in the certificate belongs to the true owner of the server.

This is a big job for just one certificate authority. So instead of using one CA, most operating systems and browsers have baked in the public keys of a few dozen root certificate authorities. Those dozens of root CAs can sign certificates for any server on the Internet. They can also delegate authority to intermediate CAs, of which there are around 1,000. As long as the server presents a certificate with a chain of signatures going back to one of the baked-in root CAs, your browser will trust the connection and display the lock icon.

A few problems

Most of the time when you’re browsing the “secure” web, therefore, there are over 1,000 different entities who might attest to the validity of your connection. All it takes is for a single one of these entities to get hacked for the entire system to be compromised. After all, any CA can sign the certificate for (almost) any domain name. In 2011, the Dutch certificate authority DigiNotar was hacked. The hackers issued more than 500 fraudulent certificates. When the hack was discovered, DigiNotar’s root certificate removed from operating systems and browsers, and the company went bankrupt, but much damage had already clearly been done.

Also troubling is the fact that several of the few dozen root CAs trusted by your computer are issued by governments. For example, here is the list of root certificate authorities trusted by Mac OS X Yosemite. Note, for example, the presence of DoD Root CA 2, of Federal Common Policy CA, and of CNNIC ROOT. CNNIC stands for China Internet Network Information Center, and it is an agency under the Ministry of Information Industry of the Chinese government.

If you’ve been paying attention so far, an uncomfortable truth is starting to dawn on you. Both the US Department of Defense and the Chinese government (as well as other governments) can issue a certificate for (almost) any website that your browser will accept as valid. They can conduct a targeted man-in-the-middle attack at any time. The “secure” web is actually not as secure as you might expect.

Some half measures

One way to solve this problem is for operating systems and browsers to know from the outset which certificates go with which servers. This solution is known as “certificate pinning,” and it is probably used by your OS to connect to its update service. Since Mac OS X knows that it will only be connecting to Apple’s servers to download software updates, it can specify that only Apple’s certificates are valid for those kinds of transfers. This prevents hackers or adversarial governments from using the software update process to install malware.

Certificate pinning works great as far as it goes. The problem is it doesn’t scale to the whole web. Netcraft estimates that there are 857,927,160 sites on the web. Given the need to constantly change and revoke website certificates, your OS can’t come with a pinned certificate for every one. This inevitably means that most of the web will be vulnerable to sophisticated eavesdroppers.

A partial solution that is under development is known as certificate transparency. This would create an auditable log of certificates issued by CAs, enabling domain owners to know if a fraudulent certificate was issued for one of their servers. Certificate transparency is a step in the right direction, but it still allows certificates to be fraudulently issued. The only difference is that the attacker would now be more likely to be caught. While this is valuable, in many cases the damage will already be done by the time the fraud is discovered.

Using the blockchain

An alternative to X.509 is to store public keys alongside domain names on a blockchain. This is the core idea behind DNSChain, an intriguing project by the okTurtles Foundation.

I have written in the past about how Namecoin can be used instead of the existing IANA/ICANN hierarchy for domain names. DNSChain solves the public key distribution problem by simply recording public keys alongside domain names. Since blockchains are both tamper-resistant and tamper-evident, this is much more secure than X.509.

For example, okTurtles has registered okturtles.bit on the Namecoin blockchain. The IP address of their server is 192.184.93.146. In the same record, they include their SHA1 fingerprint: 5F:8B:74:78:4F:55:27:19:DC:53:6B:9B:C8:99:CD:91:8A:57:DD:07.

Screenshot of the JSON file returned at http://api.dnschain.net/d/okturtles

If a user is able to access the Namecoin blockchain, or even a single trusted server that hosts the Namecoin blockchain, it will be virtually impossible to man-in-the-middle him when accessing okturtles.bit. DNSChain would replace a fragile hierarchy of trust with a much more robust limited-trust system.

More generally, the project shows how much of our current online life is vulnerable to trusted third parties, which, as Nick Szabo has persuasively argued, are security holes. Blockchains can fix this by serving as a fiduciary layer, running the most critical bits of code. Switching to blockchain-based systems will be a long and gradual process; overcoming entrenched coordination problems is never easy.

But in the meantime we are playing with fire. It’s only a matter of time until we get burned.