Сheck this out to protect your apps’ data like a pro 💎.
So, the situation is quite pragmatic: Alice wants to ensure no one eavesdrops on her love messages 🕊️ to Bob. In this video by @vixentael, you can see the difference between application-level encryption (ALE) and transport layer security (TLS). Let’s talk about their use cases.
Both ALE and TLS are ways to protect data between applications by encrypting it. The difference lies in where and who encrypts/decrypts the data.
The main thing about ALE is that encryption is done on application-level—inside your application, inside your code. You write a code on how to encrypt and decrypt the data, you decide which cypher to use, where to get the encryption key, and send the data encrypted from your app.
Imagine Alice sends a JSON love message. Using ALE, you can encrypt the whole JSON or only a particular field, like “message” in this example:
No matter which underlying transport and/or at-rest encryption are used, your data is encrypted within the application, as long as you choose it. So, with ALE, Alice’s messages are protected within the app context from Eve—from physical disk access risks, leakage through logs, snapshots, and automated backups. 😌
Now, let’s have a closer look at TLS.
TLS protects data from eavesdropping between servers (like leakage and tampering of network traffic on the internet) and adds authentication for node-to-node links if you set it up correctly. All websites use TLS, and most mobile & desktop applications do too. As a developer, you often don’t need to do anything inside your applications to support TLS, only to generate TLS certificates for their server’s domain name.
But at the same time, TLS protects messages only during network transmission. Before and after—messages are not protected.
Thus, if Alice uses TLS to encrypt messages to Bob, and Eve has physical access to Alice’s or Bob’s computer or logs—she can read their messages. TLS protection does not cover such security events as physical access to servers, privileged DB access, as well as backups, logs, and snapshot issues. 😕🕳️ See the table below.
Does Alice need to use ALE all the time? It depends, it depends. Use TLS by default, and add ALE when data is sensitive, and you can improve your application with some cryptographic code. To choose ALE/TLS more smartly, we need to consider threat models relevant to the case. 🤔
TLS protects data in transit but won’t help against insiders with access to the database. When insiders and APTs are realistic threat vectors, ALE becomes more relevant. And what’s essential—ALE provides many security guarantees in one shot.
To learn more about ALE, dive into Application Level Encryption for Software Architects article by Eugene Pilyankevich or watch @Anastasiia Voitova explaining why End-to-end encrypted doesn't mean secure.
And you’re always welcome to follow @cossacklabs for data security updates on Twitter, YouTube, LinkedIn, GitHub, and website. 👋🧡🔐
Top comments (0)