What is end-to-end encryption and why it's such a confusing term
What is and what isn't e2e encryption
What is end-to-end encryption
Let's say you sit in a coffee shop and want to check something. You connect to the local WiFi, open up a browser, and use the Google search. Conceptually, your phone is communicating with the Google servers and all you notice is that the search results appear. Internet protocols do a good job of hiding all the complexity of routing to a remote machine.
But in reality, this connection goes through a lot of intermediary nodes, starting with the WiFi router you are connected to.
For example, a traceroute, a tool that can show the path each packet goes through to reach its destination, shows these routers along the way to the google.com server:
10.176.98.1
10.176.2.3
173.205.39.229
213.200.120.54
69.174.23.134
108.170.240.97
216.239.54.107
172.217.7.206
These are only the ones that can be identified remotely. There are likely others that are hidden from the outside eye. As all packets pass through these nodes, whatever you send, all these nodes can read it.
This is why HTTPS and other encrypted communication protocols are useful. By encrypting the traffic so that only the intended recipient can decrypt it, you can use the same intermediary nodes without fearing they might listen in to the conversation.
This is called transport-level encryption as it protects data in-flight, i.e. when it is transmitted between nodes. In the above example, the browser encrypts the data and only the Google server can decrypt it. It makes a private channel between the two participants.
In the above example, the two ends (the browser and the Google server) are the only ones that can read the communication and it does not matter how many nodes it passes through and who controls them. In the coffee house example, you can be oblivious to all the routers in the communication stream as they are unable to read the things you send.
This is end-to-end encryption.
What is not end-to-end encryption
But what if you are communicating with a node that proxies the connection? Let's say you found a search result interesting and clicked on the link. For the sake of example, the website you are visiting is using Cloudflare as a proxy.
In this case, your browser connects to Cloudflare and Cloudflare connects to the website. The part between the browser and the proxy uses HTTPS so that the WiFi router, the ISP, and all the other parts of the Internet that stands between you and Cloudflare can not read what is sent over the wire.
But what about the part between Cloudflare and the website? Is using encryption there makes this connection end-to-end encrypted?
No, the connection between the browser and the website is not end-to-end encrypted as there is a box between them that can read the communication. It does not matter if all the edges use encryption if there is an intermediary node that can read the communication.
Why end-to-end encryption is a confusing term
Picking the ends
Let's switch hats and become an AWS architect! Your task is to run a website for a startup that is destined (at least in the pamphlets handed out to investors) to become the next Facebook with billions of users worldwide. You decide to use a fleet of EC2 instances behind a load balancer and CloudFront for worldwide content delivery.
CloudFront works similarly to Cloudflare in the above scenario. It is a proxy that breaks the encryption and sends the traffic to the load balancer either by reencrypting it or in plain-text.
Is this architecture end-to-end encrypted?
Of course, you might say, as users use an encrypted connection that ends in your architecture.
But wait, how is it different than the Cloudflare case? The users are communicating with your EC2 servers and there is a box that can read the traffic!
The problem with end-to-end encryption is that depending on how you pick the ends the same architecture can be considered end-to-end encrypted or not.
Usually, in the case of one-to-one or group messaging, the two ends are the participants. You send a message to a friend via WhatsApp. If WhatsApp can read the message then it is not end-to-end encrypted. But what are the ends when you post the same message to the Facebook wall of a private group? In this case, end-to-end means communication with Facebook, even though you are still kind of sending a message to multiple people.
In-flight encryption
It's easy to confuse full in-flight encryption with end-to-end encryption. There are many questions about whether a connection with a TLS-terminating proxy still counts as end-to-end encrypted. It does not.
If you look carefully, documentations usually not mention end-to-end encryption in these cases. In the CloudFront developer documentation:
For example, you can configure CloudFront to help enforce secure, end-to-end connections using HTTPS SSL/TLS encryption. (emphasis mine)
It does not say that the connection is end-to-end encrypted. It says that the connection uses TLS encryption for all communications end-to-end. This is not the same, as CloudFront can still read the requests and responses.
Similarly, Cloudflare's documentation:
Cloudflare recommends end-to-end encryption of traffic between site visitors and the Cloudflare network and between Cloudflare’s network and your origin web server. (emphasis mine)
An end-to-end encrypted connection to and from Cloudflare does not make the whole connection end-to-end encrypted. Again, Cloudflare can read the requests and responses.
Key management
To make things more complicated, end-to-end encryption also depends on key management. When using HTTPS it's done by the protocol itself, so we tend to think less about who generates and knows the key. But it's also a vital part of the definition of end-to-end encryption. It is important that only the two ends know the keys and nobody else.
Zoom's is a particularly nasty case of broken key management. They said that the connection between the meeting participants is end-to-end encrypted because one end encrypts the data and only the other end decrypts it. But in their blog they say:
To ensure this entire process meets the needs of our customers around the clock and around the world, Zoom currently maintains the key management system for these systems in the cloud. (emphasis mine)
This means Zoom can read and modify the data sent from one participant to the other, even though it's encrypted. This is not end-to-end encryption. After some controversy, the Federal Trade Commission investigated and forced them to implement proper end-to-end encryption.
Data encryption
Usually, transport-level encryption is equated with HTTPS as it encrypts traffic between the two communicating parties, and wherever unencrypted HTTP is used is seen as non-secure. But it also depends on whether the data is encrypted or not.
For example, a PGP-encrypted message is end-to-end encrypted no matter how it's delivered. You can write it to a billboard and it's still secure as only the recipient has the key to decrypt it.
Conclusion
End-to-end encryption means that only the two ends of the communication can read the messages. It provides strong guarantees of privacy and thus it's preferable to in-flight or at-rest encryption.
But deciding whether a scheme is end-to-end encrypted or not can be tricky. It depends on the choice of the ends, where in-flight encryption is terminated, and what party manages the keys.
