January 11, 2018
4 min read time

How to use Varnish to make your cache infrastructure GDPR compliant

secure-1

All European businesses (and in fact all companies that do business with Europe) have at least one thing in common until May 25, 2018. They are all busting their balls to comply with the new General Data Protection Regulation (GDPR) when it comes into force at that time. The reason? The consequence of non-compliance can result in a hefty fine worth 4% of the company’s annual revenue. For most businesses, getting such a fine is not a risk worth taking.

What is GDPR?

The GDPR is considered to be the most significant piece of European data protection legislation to be introduced in Europe for decades. It replaces the European Data Protection Directive from 1995 and seeks to unify data protection laws across Europe. Its purpose is to give back control of their own personal data to private citizens. Not only do companies need to be able to show evidence that they handle personal data with respect and care, they are also strongly encouraged to encrypt that data to protect it from getting into the hands of the wrong people, for example via malicious cyber attacks.

Encryption is the key

It is a well-known fact that cybercrime is on the rise and the damages it causes are predicted to reach $6 trillion annually by 2021. Out of more than 9 billion data records that have been stolen since 2013 only 4% were encrypted. The lucky few who had encrypted their data records rendered the stolen data useless. This means that out of 9 billion data records, only 360 million were encrypted while the remaining 8.6 billion got used by cyber criminals.

How can Varnish help you encrypt & protect your data?

Varnish offers integrated SSL/TLS support with both a client-facing TLS and a backend TLS, which in combination form one modern, minimalistic and fast TLS proxy.

Client-side SSL/TLS

Hitch is a scalable, open-source network proxy that terminates SSL/TLS connections and forwards the unencrypted traffic to one of the available backends. It can handle up to 3,000 TLS protocol negotiations per second. Its process-per-core model architecture lets it manage tens of thousands of connections on multicore machines.

In addition to supporting TLS 1.0, 1.1 and 1.2, it also offers:

  • SNI, with and without wildcard certificates
  • Support for HAproxy’s PROXY protocol

Backend SSL/TLS

Varnish Plus offers SSL/TLS connections for the backend side of your architecture to safeguard it from possible attacks/leaks. This means that any request handled by Varnish will be encrypted before it’s sent to the backend server(s).

Many companies require their inter-machine connections to be TLS connections. Thus, when caches are distributed around the world to serve different regions it is of utmost importance to encrypt data exchange between the caching nodes and the backend servers. For example, when using Varnish within a CDN the long-haul connections that are transferred through the public internet will benefit from encryption. With the upcoming GDPR adoption this type of encryption is strongly recommended and may become crucial to protect the data your web server produces and analyses from cyber attacks.

Total encryption

Our engineers are currently working on a brand new feature, which is designed to encrypt all your caches across Varnish instances at all times. This Total Encryption feature will help prevent bugs like Cloudbleed from causing leaks of sensitive data from your caches. You can read more details about the Total Encryption feature in an upcoming blog post. And you can learn all there is to know about total encryption as well as Varnish & SSL/TLS during our upcoming webinar “How to make your cache infrastructure GDPR compliant”.

Minimizing your GDPR-related vulnerabilities

Among the several new rules that make up GDPR, there is one which states that businesses must notify their local data protection authority if they experience a security incident that affects the integrity, confidentiality or security of the personal data that they hold. Said breach must be reported if and only if the leaked data can result in identity theft, fraud or any other type of damages for the data subjects (the people whose personal information has been leaked).

Businesses who have implemented appropriate security measures, protecting both the leaked data and the data subjects, will not need to notify about such breaches as the stolen data will be useless to the perpetrators. Thus, if the leaked data is encrypted and therefore can’t be used, then no reports of such leaks must be made.

That’s yet another good reason to lock down your data and connections to deliver a safe and performant experience for your users.

REGISTER FOR THE WEBINAR