CONNORBODE

Trust as we know it

When you visit any website on the internet, you establish a secure connection with that website using Public Key Infrastructure (PKI). An over-simplified explanation of PKI is this: imagine you are going on a blind date with Alice for the first time. You go to a restaurant, but you don't take your phone with you. Since you have never met Alice before, you don't know what she looks like. How do you identify her? Well, fortunately your friend Dave is there to tell you who Alice is. You know and trust Dave, and so you trust him not to lie about who Alice is.

In our example, Dave is a trusted third party who helps us identify Alice. Dave could easily lie about who Alice is. He could play a cruel joke and have us approach someone who is not Alice. We rely on Dave being honest.

Dave is what's known as a Root Certificate Authority (Root CA) in the PKI world. When we visit a website on the internet, that website will send back a certificate. We take that certificate and we verify it with a Root CA, and the Root CA will be able to tell us whether it is valid or not. If it's not valid, maybe we don't want to trust that website.

The Problem with PKI

As we mentioned above, our friend Dave has the ability to lie to us about who Alice is. He could play a cruel trick to have us approach another individual at the restaurant. In this example, we might end up embarrassed and Dave might enjoy a good laugh and maybe our friendship with Dave takes a turn for the worse.

With Root CAs, the stakes are much higher. Without getting into the technical details, it is possible for a trusted Root CA to eavesdrop, modify, or redirect messages. Much of the secure communication on the internet might not be as secure as we think.

Ok ok ok, so Connor wears a tinfoil hat and is spouting conspiracy theories. Why would I believe Root CAs are sniffing my communications?

When you buy a new laptop, or buy a phone, or install a web browser, they come bundled with trusted Root CAs. We trust Apple & Lenovo & Mozilla & Google & Samsung to bundle our devices with Root CAs from companies that will respect our privacy. Do we audit the list on our devices? For the average person, the answer is probably no. Do the product vendors audit the list? We hope so, but this is a point of failure for our security. Putting trust in a single malicious Root CA on our device means all communications are compromised (assuming there are no limitations on the root cert).

Trusting in consensus

Let's go back to our example of the blind date with Alice. She's in the restaurant somewhere, and the restaurant is packed with 200 people. Alice was able to prove to one person in the restaurant that she truly is Alice. Those 200 people chatted among themselves, and gradually they all came to an agreement about who Alice is.

Now, when we walk into the restaurant, we can choose a person at random, ask where Alice is, and trust that they tell us the truth. We are able to find Alice without trusting Dave.

That is the beauty of consensus algorithms.

If we can trust in the consensus mechanism of a distributed network we can eliminate the need for Root Certificate Authorities. Let's assume that the network is able to perform its consensus properly. Alice can upload her authentication credentials to a blockchain and we can query any node in the network to retrieve those credentials. We can trust those credentials and authenticate Alice without trusting any third party.

How does this work in practice?

I've built a quick & dirty prototype of a DNS resolver that runs locally, uses the Avalanche C-Chain / avvy.domains to look up the address of a server on the internet & authenticate it, establishing a secure communication channel without relying on root CAs.

It's a bit messy, but with this system:

1. We can eliminate query monitoring,
   so no one know which sites you are visiting. DNS queries are local, so lookups are private. UK government, for example, has laws that require ISPs to store logs so the gov't can know which sites citizens are visiting. DNS-over-HTTPS is the current solution to this problem, but with the prototype the DNS queries are all local and the queries to the Avalanche node are encrypted. We can also avoid Avalanche nodes performing query monitoring by running our own, but this has pretty hefty storage requirements (blockchain is around 80GB right now).
2. We can fetch the IP address of a server.
   This isn't really a special point, it's what a DNS resolver does.
3. We can avoid DNS hijacking.
   The only way to edit the DNS records is to have the private key of the account that can edit the domain name. That's it, there is no other workaround. If we want to fully trust that the DNS records are accurate, without trusting a third party, we download a copy of the blockchain and check. If we trust the consensus mechanism to do its job, then there is no way that the records have been tampered with (unless the private key for the account was compromised).
4. We can pull certificates to establish a secure channel of communication with the server, without trusting any third party.
   This is HUGE! As with the DNS records, we can be certain that these certificates haven't been tampered with. They can be downloaded to our machine & “trusted” (the same way that we trust root certificates, but with restrictions). Suddenly, we have secure communications.

I'll be writing more about this and developing prototypes. If you're interested, follow me on Twitter @connorbode!