Achieving security and speed

The O’Reilly Podcast: Nathan Moore discusses caching, CDNs, and scaling front end security and performance.

By Courtney Allen
November 17, 2016
Open windows. Open windows. (source: Unsplash)

In this episode of the O’Reilly podcast, I talk with Nathan Moore, CDN architect at StackPath. We discuss intelligent caching, building secure CDN solutions, and the future of front end security and performance.

Here are some highlights. The full conversation is available in the embed, below.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

What is caching?

Back in the old days, everyone would put up their own page. They’d host it somewhere, and then you would just count the hits as they popped up. But in the modern world, we have to scale up. As we get bigger, as we serve more and more pages and more and more people, there’s a need to be able to handle more than just your individual page.

The idea behind a cache is that you have a choice: you can either serve that page yourself or you can go out to take advantage of what’s called a proxy, which is a server that sits between the end user and the web page the end user wants to see. The idea is if that proxy can cache the content that’s coming from the origin, then that end user never has to talk to the origin but can always talk to the cache. The higher the cache hit ratio, the more requests can be served directly from that proxy, and the less work the origin has to do. As a result, origins can now scale much better. The web in general can run much faster, and end users wind up being much happier.

Common trade-offs between speed and security at the front end

One of the things that’s come up in recent years is the idea that a content delivery network shouldn’t just deliver content; it should also be actively engaged in securing that content. It should ensure that the content goes to the intended end user and not to malicious end users.  It should also protect the customer’s origin server.

Part of that is understanding where and how to encrypt the content. Obviously, if somebody does sniff, you want content to be unintelligible to them. Modern cryptography effectively does that. We can deploy SSL along the full path if that’s what the end user specifies. One of the problems with SSL is that it has a processing overhead associated with it. Part of the value proposition of a company like StackPath is the ability to provide security while offloading the inevitable performance side effects of that security. In other words, we better perform while serving encrypted content, and we better do that very, very well.

The other part is protecting the origin. This is where things like WAF (web application firewalls) start to come in, because we want to be able to dynamically view the requests and determine what’s a legitimate request and what’s not. You want to be able to apply all of these policies and filtering rules before they even hit the origin in the first place. This is why there’s this urgent need for a very secure CDN.

The horizon for front-end security and performance

There have been a number of very high-profile denial of service attacks recently. This is a very, very big concern. If denial of service attacks go on with no response, meaning the number of them increases and they continually try to take down major parts of the internet infrastructure, then the internet becomes useless. You start to ask yourself, ‘What is it that I can do to help mitigate against denial of service attacks?’ The way denial of service attacks work is you have a huge number of what look like legitimate requests hit a given server or service on the web. If there’s a super server that can handle and absorb this entire attack, then it’s all right. There are still resources available on that server to service the legitimate requests, not just the attacking requests.

Part of this requires scaling infrastructure. Obviously, we’ve done that; we have multiple POPs (points of presence) globally and many, many servers within the POP. You can also consider protecting the protocol itself. There are multiple protocols. We have the TCP protocol to handle the connections, so we have technologies and techniques to start dealing with TCP-level attacks. You also have HTP-level attacks. You can have this come up at a higher level in the technical stack. Things like the WAF all of a sudden become a very big deal, and we need to be able to protect the assets by identifying and denying illegitimate requests. This is very much in the forefront, and I think you will very quickly see some more technologies come out in order to address these sorts of things.

This post is a collaboration between O’Reilly and Stackpath.See our statement of editorial independence.

Post topics: Operations