I started writing a post about S3 encryption and thought it would be a good idea to have a separate post that covers encryption at rest and encryption in transit.

It’s a short read, so go on and take 4 minutes to read it before returning to the original post.

Encryption in transit

When we want to ensure that information stays private while it moves across the network, we implement encryption.

We call it encryption in transit.

Why would we want to encrypt the data while it is moving along the network?

1. An attacker could be listening to the network traffic somewhere along the way and read the clear text as it passes through the wire. This could be someone listening on a coffeeshop’s Wi-Fi or something on a larger scale like a BGP hijacking attack operated by a “state player”.
2. Someone could potentially manipulate the data while it moves around. One example is injecting a malicious payload to an innocent and trusted source.

There are a few ways to achieve encryption in transit, but the most common way is using network/application-level protocols that perform the encryption.

The first example that should pop to mind is the HTTPS protocol that uses SSL or TLS to encrypt your website sessions (and provide trust, but that’s another topic).

Another example could be a VPN connection that uses secure protocols to encrypt the traffic, regardless of the higher-level protocol - meaning a clear text http request over an IPSEC VPN connection would still be encrypted most of the way through.

An encrypted protocol is terminated somewhere. This could be “End to End” or maybe a dedicated network device that handles the encryption and then moves the data in clear text up to the server.

Encryption at rest

When you want to protect data while stored on a hard drive or on cloud storage, you want to make sure it’s encrypted at rest.

Rest as in resting, just sitting there, not as in REST API.

Suppose that someone steals your laptop and yanks out your hard drive.

At this point, he could connect it to another computer and read all of your documents, look at your pictures and do a whole lot of damage.

The same goes for stealing a hard drive from a server farm.

But what happens if someone hacks a server containing encrypted data?

This is where it gets a little more complicated, but technically, depending on the implementation, an attacker may not be able to read the encrypted data on a compromised server.

This leads me to the next topic, which is blind spots.

The Blind Spots

At one point, data will be in a state where it is clear text.

If you think of a database server, unless the data in each record is encrypted, the engine will decrypt the data and keep it in memory to access it.

An application reading a secret from an encrypted store will keep it as clear text in memory. And even if you perform some tricks, the password or key for that data will be there in clear text.

This is how you still hear about leaked information, even though the company did put effort into securing it.

Performance is another thing to consider. Take the database where you store encrypted records as an example.

In this scenario, searching the database becomes problematic, and you may need to add clear text metadata.

Another issue is your application’s performance, where it needs to decrypt (a taxing action), each record it fetches from the database.

All of this means that you shouldn’t take encryption too lightly and always try to understand the big picture.

So when you go through your compliance checklist, make sure that you understand what each item means before checking it as you may not be off the hook by implementing one form of encryption.