Are CDNs Secure?

A CDN is a type of overlay network that moves a website’s content closer to the end user in order to improve performance. Typical services offered by Internet overlay networks include edge caching, SSL offloading and edge routing.

Internet overlay networks allow websites to benefit from third party infrastructure to improve performance and security. Instead of setting up build regional data centre infrastructure, a web site provider can effectively “rent” overlay network infrastructure at a fraction of the cost.

CDNs are becoming an ever more popular choice for individuals and companies wishing to increase the speed of their websites. But could such overlay networks be making trade-offs between performance and security? This article describes potential security issues for overlay networks and CDNs.

Possibly the best known CDN service is CloudFlare, who suffered a high-profile security bug known as Cloudbleed, discovered in February 2017 affecting its reverse proxies.

CDN Security

When assessing security issues for overlay networks web and mobile app providers should consider three key architectural issues:-

1.     Stateful vs Stateless Overlay Networks:

The type of edge service performed by the overlay network is important. Some examples are caching, routing, and SSL offload. Storing sensitive content across many edge nodes can raise security risks.

Most CDNs cache content at many geographically distributed locations. By contrast, some overlay networks are “stateless”, with no sensitive content stored in the edge nodes. Caching static and publicly available content in a CDN is very low risk. For example, public images, videos, and fonts are commonly and safely cached in CDNs.

If, on the other hand, security is a major concern, a public CDN may not be a good solution. In particular,  hosting JavaScript libraries in third party CDNs can be risky. For sensitive content, restricting the number of data centres is good practice.

To address these security issues, there are two types of stateless overlay networks:

SSL offload: an edge node can handle the SSL handshake with the end user on behalf of the origin server. This can greatly decrease the overhead of supporting an SSL connection. The cost is that it requires the origin web site to share its SSL keys.

Edge routing: an edge node can handle TCP termination and optimize routing back to the origin server. This can improve performance without requiring SSL certificates.

2.     SSL key required vs Keyless Overlay Networks

Requiring SSL keys can provide better performance. The potential cost, however, is new security vulnerabilities. This is especially true if content is being cached within edge nodes.

An overlay network can perform an SSL handshake with end users through an edge node. This requires an SSL certificate from the origin web site. Although traffic between the end user and the edge node is encrypted, content within the cache is generally not. This makes these caches potential targets for hacking attempts.

Overlay networks that can accelerate traffic without requiring SSL certificates reduce security risks for web and mobile app providers. CloudFlare is one of the leaders in promoting keyless SSL as a more secure network overlay architecture.

3.     Shared vs Shared Nothing Overlay Networks

Shared infrastructure means other websites problems can become your problem. Isolation can reduce the risk.

Overlay network vendors typically make significant investments in security infrastructure. Yet their very size and success threatens CDN security and attracts attack. In short, CDN Points of Presence (POPs) increase the attack surface for potential hackers. This risk to web sites grows even more when they share SSL certificates with an overlay network provider.

The benefit of a CDN is to limit network congestion in serving up static content. However the security risk is that any user with root-like permissions on a CDN server can access and replace content. This in turn requires that CDN customers trust the security for every CDN POP.

In addition, having many web sites share the same network infrastructure creates more cloud security challenges. For example, Cloudflare operates a large, shared infrastructure. In fact, only about 3,000 of CloudFlare’s web sites had malformed HTML tags. Even so, the resulting bug leaked private data from over 7 million web sites.

A different approach is for overlay networks to operate separate and isolated virtual networks on a per customer basis. In some cases, segregation can be on a per URL basis. This “shared nothing” approach helps ensure that even if one virtual network is compromised, other networks will not be affected. With isolation between customers, a bug like CloudBleed poses a far lower risk.

Finally

The CloudBleed bug dramatically raised awareness of the potential CDN security issues associated with distributing content and SSL keys. Web application providers should look at a variety of factors to determine the optimal overlay network solution that meets their requirements.

If you think your business could be affected by the security issues raised in this article, KRYPSYS may be able to help. Please feel free to contact us at www.krypsys.com/contact-us/