End-to-end Encryption

or: How I Gave Up and Learned to Love Key Distribution Schemes

March 16, 2020

Plain Old HTTP

The internet was once a very trusting place. Authentication was a nice-to-have, and encrypted transmissions were rare. Your web traffic was sent, in clear readable text, across your network and up to the internet where your co-workers, ISP, or anyone along the route could read the full conversation if they felt like it. And depending on where someone sat in the communication stack they could even change the content you sent or received.

All of this was great for playing pranks on your friends. Really, the only limit was your imagination or maybe your conscience. It was less ideal for doing business or communicating about anything private.

HTTPS Diagram

The cleartext(unencrypted and directly readable version) of the message is available to all parties and anyone who might be able to listen into the connection.

There was also no real verification of who you were talking to. There are lots of ways to trick a computer into sending a request to the wrong location, and HTTP browsing doesn't protect you against that at all. So when you think you're sending your account information to example.com you're actually sending the request to badguy.com. HTTPS protects against this by giving a level of assurance that, even if you've been directed to the wrong server, you’ll be able to realize that you’re not dealing with the real example.com

HTTPS Diagram

In a normal case your requests are routed to the right server and all is well.

HTTPS Diagram

In this case you've been given bad directions on where to send your data. Without some other means of verification, like HTTPS, you wouldn't be able to tell that you've sent your data to the bad actor.

HTTPS

Https came around and provided a great solution to these problems, but certificates cost money and had to be configured, so it mostly wasn't added unless companies determined they needed it. Human behavior being what it is, this often wasn't until after there had been a significant problem.

There are two key capabilities that HTTPS brings to the table for us. First, HTTPS can ensure that you are actually talking to the server you intend to. In our example above, where you had been tricked into sending your data to badguy.com, the HTTPS protocol would prevent you from sending or receiving information to that attacker and browsers will alert you to the problem.

HTTPS Diagram

Here's how Chrome tells you that there's a problem with the security of the site you're trying to visit.

Second, if implemented correctly, all the traffic between you and the server is encrypted preventing eavesdropping at any point between you and the server. There are a lot of intricacies to how this works that are well beyond the scope of this post, but it's important to note that the encryption within HTTPS is constantly evolving to respond to new threats.

HTTPS Diagram

Here you can see the progression of data from the sender to the receiver and how HTTPS encrypts the information during transfers. In this case, only three parties have access to the clear text.

Gradually more and more traffic has migrated to HTTPS, which is a very good thing, but there’s still a lot of plain HTTP out there. Projects like LetsEncrypt and HTTPS Everywhere have been created with the goal of making web traffic universally encrypted.

Encrypted at rest

HTTPS has provided a great way to protect our data while it's being sent from one place to another, but what about when it's being saved? As recent history has shown data-breaches have become depressingly common. A data-breach is when an attacker gets access to the company’s internal systems and is able to walk away with potentially millions of user records at once. In a cost-benefit-analysis this is a great investment for an attacker. Instead of having to get one user’s data at a time, they can, with single, albeit hopefully harder, attack, get millions of times worth of data.

This is a tricky area for end-users, because, ultimately, it’s out of their hands. The companies managing the information are the only ones who can protect these databases and that’s not an easy task. Even with a dedicated and rigorous approach to security (Which unfortunately is NOT a normal posture), the attackers only need to get lucky once.

As regulations impose more disclosure requirements and penalties around data-breaches the consumer can also become more aware and help to demand services that take security more seriously.

This where the at-rest condition comes into play. If a company encrypts their customer's data when it has been saved and is not in active use that will lessen the risk by making the window where the data is truly vulnerable smaller. The challenge is that the data needs to be decrypted any time it’s operated on, so depending on how the attackers get in, the data can still be stolen.

HTTPS Diagram

Having the data encrypted at rest is a great step, but it doesn't completely protect against the data being breached, and doesn't protect at all from the company acting in bad faith with your data.

End-to-end Encryption

So far we've been working towards protecting ourselves from attackers, but what about the company itself? Should it always have full access to the consumer data it houses? In some cases that’s a clear yes. Your bank needs to hold your banking information, but should your email system house that same data?

This is where end to end encryption comes into play. End to end means that the data is encrypted before it’s ever sent to the server, and only decrypted after it’s arrived at its destination. Here, the company is only ever holding meaningless scrambled data.

First, lets revisit the data breach scenario above. What if the company never had the customer data in a readable state? If the data is breached what’s stolen is all encrypted and useless.

Second, what about the scenario where the company managing the data is really just a third-party between the users who actually do own, and should have access to it? In a perfect world, the company simply holds the data, takes the privacy of its users seriously and protects it to the best of their ability. All too often though, this data is looked at as a revenue stream. Customer data can be resold to third parties for data mining, ad targeting, machine learning training, etc.

HTTPS Diagram

End-to-end encryption is a great way to protect your data from attackers and third-parties who don't have business accessing, or sharing your data.

This is why a tool like end-to-end encryption is important. It allows companies to act as effective third-parties to facilitate communications while reducing the value of their data to attackers. Also, users are empowered to choose tools that respect their privacy not just through choice, but through the fundamental operating model of their systems.