It seems like security is now more important than ever in our industry. And just when we think we have things under control, vulnerabilities like Meltdown pop up, forever changing the security landscape as we know it. When we think about what we can do to prevent these vulnerabilities, writing perfect code and designing perfect systems would be great. Obviously that is not always possible, or realistic to expect. It is for these reasons that we design countermeasures. Things like firewalls, WAFs, advanced compilers, static analysis, SSL/TLS, and encryption, these are all examples of countermeasures that can greatly enhance the overall security of our systems. When used properly, these measures can neutralize entire classes of security vulnerabilities and security risks. It is with this in mind that we designed Varnish Total Encryption.

Varnish Total Encryption is cache encryption. However, Total Encryption is more than just making your cache unreadable to unwanted eyes. Varnish Total Encryption prevents an entire class of cache vulnerability, the cache leak. As both Cloudbleed and Meltdown have shown us, caches are uniquely vulnerable because they are designed to store large amounts of data in a tightly packed space with easy access. Caches are designed for speed and efficiency, and these tenants are usually, but not always, orthogonal to most security design tenants*. Meaning, caches are almost always designed to be fast and open and not secured and locked down. They rely on well thought out design and perfect execution. In the case of Cloudbleed, a bug in a cache feature resulted in a read overflow and an entire CDN slowly and randomly leaked out into the internet. In Meltdown, the cache isolation between processes was violated, resulting in the real possibility of total system compromise.

* Varnish Cache does an exceptional job in defensive coding practices, secure design, and maintaining cache integrity.

Varnish Total Encryption key generation

How does Varnish Total Encryption prevent these classes of vulnerabilities? With the use of keys. Specifically, assigning each and every cache object its own unique AES256 encryption key. Each request can only be assigned one key and that key is based on the unique fingerprint of that request, meaning it will be impossible for a request to return anything but its intended cache object. If that request read overflows into another object's cache (Cloudbleed), those bytes will be seen as garbage as it requires knowledge of that object's unique key and its associated request to decrypt. If any part of cache were to become readable (Meltdown), nothing can actually be seen as each cache object is uniquely encrypted using a key derived from data not stored with the object. Basically, leaking cache would require breaking AES256 encryption for each and every object in cache.

Varnish Total Encryption also relies on kernel memory security for the storage of all cryptographic keys. No object keys are ever stored longer than the request lifetime and all object keys are uniquely generated from a master key and the request fingerprint. When a key is stored into the kernel, it can never be read back out and it can be used as much as needed without ever being present in userspace. While Meltdown may have put kernel memory security in doubt, it is still the most practical and secure place on a system to store a secret and Varnish Total Encryption leverages this to the fullest extent.

How does Varnish Total Encryption work?

Varnish Total Encryption works with all Varnish Cache storage types including malloc, file, MSE, and MSE with persistence. Using Varnish Total Encryption is very simple, just add this one line to your VCL:

include "total-encryption/random_key.vcl";

And that's it. Your cache is completely, safely, and securely encrypted. Varnish Total Encryption works transparently with ESI, Edgestash, content encodings, and any and all VCL logic.

Varnish Total Encryption also works in streaming mode, meaning Varnish can produce encrypted and decrypted response streams. This is different than SSL/TLS transport encryption because Total Encryption encrypts and decrypts the data at rest. What this means is that Total Encryption produces 100% compliant and standard HTTP responses with the response payload and headers encrypted or decrypted in place. Varnish Total Encryption is not meant to replace SSL/TLS transport encryption, rather, it can compliment it for more robust security.

Total Encryption is implemented as pure VCL. This means many of the finer details of the implementation can be customized to match your setup. Things like the choice of the master key, whether it's randomly generated on each startup, loaded from disk, loaded from a USB drive, or even retrieved from a remote HTTP based service. What responses to encrypt, when and where to encrypt them, and when and where to decrypt them. You can even use as many master keys as you see fit, partitioning and customizing your cache encryption even further. Headers can also be optionally encrypted, decrypted, and used for validation.

Varnish Total Encryption uses standard and reproducible cryptographic building blocks. 

VCL based Encryption

Because Varnish Total Encryption is implemented as VCL, this gives us a lot of potential. As you know, VCL can be used to drive very advanced configurations and distributed edge architectures. This means we can now embed Total Encryption ideas into these larger architectures. Please see my second blog post about how we can use this idea to turn a CDN into a secured cloud transport without having any secret keys leave your servers.

Total Encryption Performance

Varnish Total Encryption performance is on par with any other AES implementation. First, all AES calculations are hardware accelerated and have been for most hardware built in the last five years. Still, Total Encryption will require double the CPU over what Varnish normally needs when processing traffic. So if a single Varnish Cache server is capable of supporting 260,000 req/sec, when using Total Encryption the capacity will be 130,000 req/sec. Or put more commonly, if your current Varnish setup is utilizing 18% CPU for a given level of traffic, with Total Encryption, CPU utilization will double to 36% with no change in traffic levels.

Total Encryption overhead on a 4 core server (100KB objects)

Availability

Varnish Total Encryption is exclusively available in our Varnish Solutions starting with our Varnish 6.0 release. Varnish Total Encryption will also available in our cloud marketplaces (Varnish Plus 6.0). Because of the importance of Total Encryption, we are going to recommend that all customers run Varnish with Total Encryption enabled. If you are an open source user and would like to use Total Encryption, please contact us or visit one of our cloud marketplaces to upgrade your current setup to Varnish Total Encryption.

To learn more about Varnish Total Encryption and ask questions, join us for a live webinar, "How to make your cache infrastructure GDPR compliant", on 13 February.