Earlier this year, Mozilla noted that the Web had reached an important tipping point: the average volume of encrypted internet traffic exceeded the average volume of unencrypted traffic for the first time. The encryption level that HTTPS provides is a welcome development for developers, organizations and ultimately consumers concerned about the privacy and security of their data.
As secure HTTPS becomes more pervasive, it is worth asking: why should you end-to-end encrypt data when HTTPS is pretty secure? The answer is that HTTPS is an important but small piece of the crypto puzzle. Organizations determining what additional security requirements are needed should start the process by answering a few key questions:
● How many times does data get decrypted and re-encrypted in its journey from your user to your system?
● How many systems get access to the plain text along the way?
● And how many departments are responsible for this elaborate journey?
Once those questions have been answered, it is important to understand the limitations of HTTPS, and benefits that end-to-end crypto can deliver.
Limitations of HTTPS
The fact that more websites have been able to progress from unencrypted sites to the little green lock at the top of the page for adding HTTPS is a positive development. But HTTPS has its limitations. Scammers can make fraudulent sites appear secure, leading users to assume that it is safe to enter personal data or credit card information.
And although HTTPS makes it look like data is encrypted, it's much too simplistic. It leaves out encryption of data at rest, which impacts the security of both ends of the transmission. It also completely ignores what happens to the data after HTTPS termination, which may be further out on the edge of your network than you know; at your load balancer for instance.
This leaves you open to attack at 3 points of processing (the app, the load balancer, the server), two points of storage (mobile, server), and one point of transmission (“internal” traffic). And that's the simple version. If your “server” is the endpoint of your web API, but you have different services for processing, analyzing, sharing, and backing-up your data, this just gets worse. You may be using HTTPS, but you can't really say that you're encrypting data. On the other hand, when you end-to-end encrypt your data, it's secure at each point of the process.
Traditional crypto is not enough
If you're doing an above-average job of crypto, you've written robust, well-tested code in your app to encrypt data at rest, you've used HTTPS and IPSec on your network, and you've enabled transparent database crypto. But even above-average crypto has a big attack surface. Now only the various network processing points have access to the plain text, where data gets decrypted and re-encrypted for the next step. That's better, but still results in a large attack surface, and you have to ask yourself, “why the heck do these services need the data in plain text anyway?” They often don't.
The security gaps inherent in having plain text data handled by so many services are made worse because different individuals or departments are accountable for security at these various points. Without end-to-end crypto, accountability is spread across departments:
● On the mobile side, your development team or vendor had to write some code (or at least implement HTTPS right). Or your Mobile Device Management (MDM) system encapsulates the data, or maybe you're relying on the user to check the “encrypt phone” box and the OS vendor to do something sensible there.
● In the network, IT, operations, or DevOps is accountable for provisioning certificates and ensuring that HTTPS is well configured, which isn't always that easy.
● On your server, you're counting on IT and DevOps to secure internal access to your systems, and you're counting on the cloud provider and database vendor to implement “transparent” database crypto. Many organizations consider the inside of their network secure and don't hold security standards as high as on the outside. This mistake, while less common than in years past, still leaves organizations vulnerable once the adversary gets inside the firewall.
Each one of these solutions uses different ciphers, libraries, and key sizes. You're counting on a lot of people to get a lot of things right. That's a problem.
End-to-end encrypt for consolidation and control
End-to-end encryption is essentially encrypting the data at the point of creation and only decrypting it at the point of use. It's called “end-to-end” because the data is not decrypted and re-encrypted at intermediate points. Many people have heard of end-to-end encryption between end user like the secure chat app Signal, but in fact the two “ends” can be whatever they need to be:
● End-to-end encrypt data between a user app and your data processing server.
● End-to-end encrypt data between two users, from one app to another. This is what apps like WhatsApp are doing for chat and ProtonMail for email.
● End-to-end encrypt data from the same user on multiple devices. They can see their data in plain text wherever they go, but it's encrypted in the interim. This is what some password managers do.
● End-to-end encrypt data between servers in your environment.
End-to-end encrypt for data security, not infrastructure security
The data-centric approach is vastly more secure. You are in cryptographic control of the data at all times, it's never decrypted and re-encrypted, and it reduces the attack surface since fewer systems handle plain text data. Put simply, each step in the chain handles an encrypted data object instead of the data itself.
As a result, each point in the infrastructure is secure in relation to the data because the data itself is secure from the point of origination. The application code enforces security. If the unencrypted systems are ever hit by an attacker, they can only get the encrypted data object. No one wants to get breached, but encrypting data end-to-end significantly reduces the exposure if data does get leaked, and many compliance approaches treat encrypted data as a non-breach.
Many of the more secure organizations have been using HTTPS for years. Its use is getting more widespread, but attackers aren't standing still either. Organizations who want to keep up should start by asking how many times is their data decrypted and re-encrypted in its journey from your user to your system. If you're a developer or product owner, consider building end-to-end crypto into your system. If you're an IT purchaser, you should start asking this of your vendors.
