The case for encryption by proxy

Frankly, we’ve struggled with terminology for years.

Evervault is a solution that intercepts and encrypts data before it reaches your servers. We provide encryption as a service—EaaS, if you will. But in a world full of encryption at rest versus encryption in transit articles, we also want an epithet that describes what we do.

We’ve played with preemptive encryption at rest. But that doesn’t capture how data is decrypted. Another candidate was strong encryption in transit, in comparison to the common weak encryption in transit, but that’s a bit reductive.

The best description is encryption by proxy. In short, we see encryption by proxy as a (paid) replacement for encryption at rest. In our worldview, encryption by proxy is better for two reasons:

• It is more secure, as it delegates encryption to a third party (disputable).
• It is more convenient to install and manage (basically indisputable).

The second bullet, that encryption by proxy is more convenient, is easily evidenced by our documentation. Encryption by proxy simplifies key rotation, encryption, decryption, etc.

But the first bullet is where things get dicey. Encryption by proxy is like trusting a digital notary—it adds another layer to an application. We believe that layer acts as a layer of authentication, a positive feature in regard to security. Critics might argue, however, that by increasing the attack surface area, apps are more at risk.

In an age where outsourced security is heavily scrutinized due to recent incidents (e.g., LastPass), it’s extremely important for companies to be thoughtful about when to entrust security to a third party.

Today, we’ll discuss exactly that.

Quick reminders

Let’s first remind ourselves what encryption in transit and encryption at rest are:

Encryption in transit (enc-transit) is when network endpoints collaborate to encrypt and decrypt data so it cannot be intercepted and read mid-transit. The most common enc-transit system is TLS/SSL.

Encryption at rest (enc-rest) is when the data is kept encrypted in storage, typically via AES (Advanced Encryption Standard).

At a high level, combining both enc-transit and enc-rest might sound like an ironclad strategy for always keeping data encrypted. Sadly, it is not. There is still a moment where data is decrypted—after it is received by the network gateway and before it is ingested into the database:

This temporary decryption is necessary because enc-transit and enc-rest operate on different encryption protocols. Sometimes, this is necessary; data often needs to be available in plain-text to be processed. However, there is also super sensitive data (like SSNs or HIPAA-relevant health data) that should never be decrypted until it is dispatched to an external service (like a background check API).

If an attacker gained access to company servers, they could install a packet sniffer that reads data from network requests, even network requests dispatched with enc-transit. One phished employee could compromise all client data.

This opens the case for encryption by proxy.

What is encryption by proxy?

Encryption by proxy (enc-proxy) is when data is intercepted and encrypted during the network request by a relay server. Enc-proxy ensures that any sensitive data dispatched by the sender is encrypted before it reaches the server. This is in contrast to enc-rest, in which data is encrypted only in storage (e.g., Postgres).

Enc-proxy has data double-encrypted while in transit, assuming that enc-transit is also used. The relay server should exist within an attested enclave (a codespace with verification that the code deployed is equivalent to the code committed by a trusted developer). This ensures the relay server is isolated from the core infrastructure.

Enc-proxy also decrypts the data when it is dispatched to the client or an external API.

Enc-proxy solves an issue that enc-transit and enc-rest collectively fail to—preventing an application from touching sensitive data at any point. Enc-proxy can foil hackers even if they manage to install malicious code.

The in-house variant

A great question to ask is if you could set up an enc-proxy system in-house. The answer is yes and no.

Isolation

The no case is simple; building an enc-proxy service in-house means that it could be compromised in the same event that the other servers were compromised. In other words, building an enc-proxy system in-house doesn’t isolate it nearly as much as entrusting a third party would.

In the yes case, a sufficiently large company could craft a network layer that’s strictly accessible to a security-focused team of highly-trained, well-authenticated employees. This could reasonably make enc-proxy a reality for an in-house implementation with a non-trivial internal investment.

Infrastructure

Infrastructure doesn’t dictate whether an in-house variant is or isn’t possible; however, building an in-house proxy service isn’t trivial. Enc-proxy services need to accomplish three things:

1. They need to intercept and encrypt all incoming traffic (i.e., data submitted by users or APIs).
2. They need to intercept and decrypt all outgoing traffic (data dispatched to users or APIs).
3. They need robust mechanisms to store and safeguard rotatable keys.

These requirements call for highly available ingress and egress gateways. They also call for extremely efficient code—anything that adds noticeable network latency is a no-go.

Some additional features that enc-proxies should possess include:

• Allowlists and blocklists for destinations
• Connection request monitoring (without saving packet data)
• Error dispatching in the case of a fault
• TLS connection support

In short, building enc-proxies in-house is possible to an extent, but it requires significant effort and team structuring to achieve the security returns. We’re biased, of course, as an external enc-proxy service, but this reasoning is exactly why Evervault was built.

External enc-proxy solutions

Let’s now discuss how external enc-proxy solutions like Evervault tackle the aforementioned hindrances head-on.

Better isolation

Grasping how an enc-proxy solution offers better security lives in the details. At a high level, if employee credentials are compromised, so might the enc-proxy solution’s credentials. But in reality, an enc-proxy solution complicates things for hackers.

With an enc-proxy solution in place, hackers need to:

• Gain access to the encrypted data
• Access the enc-proxy API keys
• Access the destinations that the enc-proxy dispatches decrypted data to

Or, they could:

• Gain access to the encrypted data
• Gain access to the enc-proxy admin accounts and change the destinations

This dramatically decreases the attack space. In either attack, the hacker needs to gain access to three different things; or, to administrative credentials to the enc-proxy service, which limits targetable employees down to admins.

Of course, enc-proxy access keys should be safeguarded by secrets managers like Doppler. This prevents attackers from getting a “freebie” by just compromising source code.

In short, an external enc-proxy service like Evervault makes it difficult for bad actors to access decrypted data by simply installing a packet listener.

Instant infrastructure (and maintenance)

An enc-proxy service makes it easier to add robust encryption. An enc-proxy service handles a lot of things, including:

• Managing a network of highly available, fast encryption gateways
• Handling proxying network requests for both incoming and outgoing requests
• Providing observability over general encryption activity
• Dispatching errors for common, repeatable issues
• Rotating keys to maximize protection

Enc-proxy services provide a level of encryption that just isn’t easy to build, deploy, and manage in-house.

What if the enc-proxy provider is compromised?

The real concern with enc-proxy providers (like us) is what happens if the provider gets compromised. Just like how hackers can access data by installing listeners on arbitrary servers, they could accomplish the same on proxy servers.

While enc-proxy services don’t store data, compromised proxy servers are equivalent to breached customer data. We cannot speak to all enc-proxy services, but there are a few precautions we at Evervault take to avoid this scenario:

• Using enclaves to ensure that code that touches private keys is attested to be the same code committed by a trusted developer. This prevents hackers from installing code on proxy servers that aren’t approved by an Evervault developer.
• Strongly training employees against phishing scams. Phishing has been a major vector of attack lately to gain credentialed access to sensitive resources. Phished employee credentials is how LastPass was infiltrated by bad actors.
• Implementing strict 2FA, requiring employees to only use company-approved machines, and creating strong password storage rules.

Nothing Evervault does security-wise is special to Evervault. We encourage all companies to use these techniques to avoid a breach. But because our job is protecting client data, our main priority is preventing a breach.

On the flip side, security companies are often targeted by hackers. While we are confident that our security measures will foil any possible hacks, it’s an important consideration to make before trusting an enc-proxy service for encryption.

Closing thoughts

Encryption by proxy (enc-proxy) is a fantastic technique to keep data encrypted at all times and throughout its lifecycle on company machines. It’s particularly handy for sensitive data like social security numbers that are collected to dispatch to external APIs, rather than for internal processing. Enc-proxy services are often used by companies in healthcare, finance, or any other space that handles sensitive data.

Enc-proxy is a potential replacement with encryption at rest (enc-rest), but data could also be double-encrypted. Enc-proxy is not a replacement for encryption in transit (enc-transit) and should always be used in conjunction with enc-transit.