This is a follow-up example to my introduction to Varnish Total Encryption. In that post, I introduce Varnish Total Encryption as a security countermeasure for cache leaks. Varnish Total Encryption is used to encrypt cache and works with all Varnish storage types. Total Encryption also supports streaming mode, meaning Total Encryption can be used to encrypt and decrypt any kind of HTTP traffic. I also explain that since Total Encryption is completely controlled by VCL, we can extend the ideas of Total Encryption to create larger secured architectures. In this example, we will examine how Total Encryption can use a CDN as secured cloud transport.

Varnish Total Encryption 2 Tier

Lets start off with a 2-tier caching cluster. In such a configuration, we call the front tier an edge tier and the back tier the fetch tier. The fetch tier can sometimes be referred to as a shield tier since it shields the backend from traffic. With this configuration, there is no need to decrypt and then re-encrypt data between these tiers. We only need to perform encryption when the data enters our cluster and decryption when data exits.

Varnish Total Encryption 3 Tier

Next, we can take our 2-tier edge/shield architecture and expand it to include a storage tier. This storage tier is comprised of dedicated storage nodes. These nodes will sit in between our edge and shield tiers and will simply act as dumb cache storage. All of our VCL logic sits on our shield and edge tiers. If a storage node cache hits, it immediately returns the object. If a storage node cache misses, it then sends the request back to another storage node or to the shield tier.

Also, since we have dedicated storage nodes, we do not need to cache on our shield tier. In this case, the shield tier will be streaming only. We can also optionally cache on our edge tier as well, and possibly make our edges streaming only as well. These tiers will still be performing encryption and decryption on our traffic. What this means is that all objects will be stored encrypted on our storage tier without the need to have any keys present on those servers. When objects leave our storage tier via the edge tier, they will be decrypted before being delivered to the client.

Varnish Total Encryption CDN

Finally, what if we replace our dedicated storage nodes with a CDN? From a functionality standpoint, there is no difference between a Varnish server and a CDN, they perform the same function. A CDN will have much bigger scale and possibly a global footprint, but in terms of our architecture, they are completely interchangeable.

In such a configuration, our shield tier sits behind the CDN and is responsible for encrypting traffic before it enters the CDN. The CDN is responsible for object storage and for routing traffic to our edge tier. When traffic exits the CDN and hits our edge, it will be decrypted and delivered to the client. What this means is that our data is safely encrypted while it's being stored and transported through the CDN without the CDN having any knowledge of our keys or the fact our data is encrypted. This mitigates any risk that our data could be exposed to 3rd parties as CDNs are very public and available to any and all parties.

When would such a configuration make sense? When serving highly sensitive data with personally identifiable information. Or when our user endpoints are known and local to specific areas. For example, our Varnish edges may reside in corporate office buildings and our data may contain sensitive customer and internal information. We could also optionally decrypt the data on the client itself as Varnish Total Encryption uses standard and reproducible cryptographic building blocks.

Cache Invalidation via Encryption Key

Since the keys used to encrypt and decrypt our data rest on our own servers and are never exposed to the CDN or clients, we can control our data via our key usage. What this means is that if we want to invalidate any or all of our data on the CDN, we can simply change our key. By doing so, any data encrypted using the retired key will be lost forever since that key can no longer be generated. This means our data could be stored on any number of public CDN nodes and just by changing our keys, that data has been instantly invalidated.

We could rotate our keys on a set schedule, for example daily, or we can change our keys when we want to change our data. Our keys could even incorporate a data fingerprint so when our data does change, our keys will automatically regenerate and make any previous versions of that data inaccessible.

Conclusion

Varnish Total Encryption is a powerful feature. Not only does it greatly increase the security of your cache, it can also be used to secure other systems, like a CDN. Varnish Total Encryption is exclusively available in Varnish Plus. 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.