Meet Handshake: Decentralizing DNS to Improve the Security of the Internet

To understand how Handshake can improve the internet, let's first look at how security on the Internet works today. If you already know how TLS and CAs work, you can skip to Problems with CAs.

The Problem: HTTP

When you make an HTTP request to google.com, your browser first does a DNS lookup to find the IP address of Google's servers. Your browser then makes a request to that IP address. The request goes from your computer to Google's servers, but your request is routed through a variety of large interconnected networks before it reaches its destination. In some cases, it may even pass through another country before returning to your country. For instance, most of the internet traffic in South America routes through Miami. At any point along this journey, intermediaries may inspect or even attempt to modify the data you send to Google to another server that's not Google! This is known as a MITM (Man In The Middle) attack. In fact, Edward Snowden’s documents revealed that the NSA did exactly that when they performed MITM attacks on Google to collect data on people.

The Solution: HTTPS

We need Authentication, Integrity, and Encryption in order to prevent MITM attacks.The solution is to use HTTPS, which relies on TLS and CAs. 

Your browser encrypts traffic to websites using TLS (Transport Security Layer), which relies on public key cryptography. Public key cryptography is a method of asymmetric encryption using a pair of keys: a public key and a private key pair (as opposed to symmetric encryption with only one key). The public key is shared publicly and is used to verify signatures. The private key is used to decrypt messages encrypted by the public key. The private key is never shared.

When the browser makes an HTTPS request to Google, it initiates a TLS Handshake with Google and receives Google's public key. The browser then uses Google’s public key to verify that the rest of the messages in the TLS handshake are initiated by Google, because only Google has the private key for its public key. This way, even if intermediate networks spy on the request, they won't be able to decrypt the contents of it. If an intermediary routes the request to another server pretending to be Google, the browser will know because that server won't be able to respond to the request.

Certificate Authorities

How do you know that Google's public key is actually Google's public key? When you make that first request to Google, an intermediate network may have intercepted your request and returned a fake public key for Google. CAs attempt to solve this problem. CAs are trusted third parties that verify the authenticity of public keys for websites. Your operating system ships with a list of vetted CAs by default. When a website wants to support HTTPS requests, they register their public key with one of the trusted CAs. You verify that the public key you receive from Google is truly Google's public key by checking it with your CAs.

Problems with CAs

You may have noticed a fundamental assumption: You must trust the CAs. All of them. There are hundreds of CAs installed on your computer by default — Microsoft Windows comes with 390 certificates, and Mac OS X comes with 170 certificates. These CAs can delegate trust to intermediates, and those intermediates can delegate trust to even more child intermediates. You don’t know who all these CA intermediates are and if even a single one of them gets hacked, all your HTTPS traffic is vulnerable to MITM attacks. In the DigiNotar attack, the Iranian government hacked a Dutch CA and used it to MITM 300,000 Iranian citizens.

Fixing the CA problem 

While blockchain-based protocols can be slow and limited, they excel at addressing the issue of trusted third parties. Data stored on blockchains are immutable and all parties can verify that the data stored on a blockchain is correct. Take Bitcoin as an example. Wallets on Bitcoin have public keys that are used to sign transactions. Wallets also have data associated with them, including how many bitcoin are in the wallet. You can even associate arbitrary data with your wallet, such as the birth date of a baby stored on the Bitcoin blockchain.

You can imagine a system where instead of storing arbitrary data on the blockchain, you store names on the blockchain and their public keys. Instead of relying on an arbitrary list of CAs as your root of trust, you rely on a cryptographically-backed distributed root of trust. Name owners could associate their own keys to their name, and everyone would be able to verify that the public key for a name is the correct one. This would solve the issue of trusting CAs, and Handshake is precisely such a system!

Handshake

Handshake is a blockchain protocol that aims to solve the issue of trusting hundreds of CAs. It's a protocol that's similar to Bitcoin, except instead of using coins as money, you use Handshake coins to register names on the Handshake blockchain. These names are top-level domains (TLDs) like .com, .org, .net. Handshake decentralizes the root zone file, which is the ICANN-controlled file that determines who owns what TLD. Anyone can register their own TLD on the Handshake blockchain.

One benefit of TLDs on Handshake is that they have public keys associated with them that can be verified to be authentic. Only the name owners can associate DNS data and other arbitrary data with their name that everyone can verify on the blockchain instead of trusting CAs.

There's another significant benefit of Handshake names — they are resistant to censorship, seizure, and tampering because Handshake names are stored on the blockchain. Like Bitcoin wallets, only the name owners can update their names or transfer their names as long as they keep their private keys safe.

A consequence of this is that names are their own root of trust. They can simply pin the TLS keys they use instead of relying on external trust in CAs. This allows Handshake names to avoid attacks against CAs that exist in the current system.

How do you use Handshake names as a name owner?

Your name is a TLD, so you can point it to a nameserver and issue your own domains. Domain registrars like GoDaddy and Namecheap operate their own nameservers for domains, but to use Handshake you’d need to run your own nameserver (or use Namebase!). If you own .joke, you can point it to your nameserver and create good.joke and great.joke. You can even sell bad.joke. 

Amazingly, you can point your TLD to an IP address directly and use your TLD as a domain! In the recording below we pointed .namebase to the same server as namebase.io and visited it by typing in namebase/.

Your name can also have arbitrary data associated with it using TXT records, which opens the door to numerous use cases. For instance, you can associate a Bitcoin wallet address with your name, in addition to using your name as a domain. You could visit your friend's website at satoshi/ and then send bitcoin to satoshi/ with your crypto wallet.

How do you use Handshake names as an end-user?

Handshake is backward compatible with existing DNS protocols. All you need to do to use it is point your computer's DNS resolver or your router's DNS resolver to a Handshake resolver. It's similar to using existing resolvers like Cloudflare's 1.1.1.1 and Google's 8.8.8.8. That’s how we got an iPhone to resolve namebase/ in the recording above. 

The community will run public resolvers once the mainnet launches. You can run your own as well — Handshake is the only naming blockchain launching with a lightweight recursive DNS resolver. A recursive DNS resolver is a piece of software that can recursively resolve domain names to IP addresses. If you’ve never heard of recursive resolvers, think of DNS as a tree stemming from the root down to the individual domain (pic). Recursive resolvers traverse the entire tree (recursively!) to find the information that a domain points to. The light client can trustlessly resolve Handshake names using only 10mb of memory and virtually zero CPU. It’s the most secure way to use Handshake because it doesn’t require trusting any third party resolvers that can inspect your DNS traffic.

The light client is critical to Handshake's adoption because it drastically increases the surface area of where people can safely use Handshake. You can easily embed the light client into browsers, apps, and embedded devices. Without it, consumers would need to run full-nodes to trustlessly resolve names, and empirically no consumer wants to do that (even if you’re a crypto enthusiast, how many people do you know who run Bitcoin full-nodes?).

How Handshake conflicts with ICANN

All 1500 of the existing ICANN TLDs are blacklisted on Handshake for backwards-compatibility. This means that end-users resolving their DNS through Handshake can still access .com domains as normal. New ICANN TLDs can theoretically conflict with Handshake TLDs, but ICANN isn't issuing new TLDs for another few years. When ICANN does issue new TLDs, they’ll only allow at most 500 new TLDs per year. The likelihood of conflict is low even though conflicts can technically happen. In the future, it's up to the community to decide which names take precedence. We believe Handshake names will take precedence because people will find them more useful, and I’ll cover why I think Handshake can gain adoption even in the face of ICANN’s network effects in another blog post.

TL;DR

Handshake can make the Internet more secure by replacing Certificate Authorities with a cryptographically-backed distributed root of trust. As long as Handshake name owners control their private keys, their names are resistant to censorship, seizure, and tampering. If you’re interested in using Handshake, sign up for updates on our website, join our community (forum, Telegram), or check out the source code!