· engineering · 4 min read
mTLS and CDN: Ideal use case, missed opportunity.
Exploring a killer, yet unrealised, use case for mTLS in content delivery networks.
Table of Contents
Most internet users today are familiar with Transport Layer Security (TLS).
They might not know it by name—perhaps only as its predecessor, SSL—or simply as what puts the ‘s’ in HTTPS and gives the browser that nice padlock icon indicating the connection is secure.
But in any case, browsers have done a pretty good job of informing people that sites have certificates, and these certificates are essential - with the certificate your client can tell the server is authentic.
How does this work the other way round? How can a server be sure the client is who they claim to be?
The answer, in most cases, is they can’t, and it doesn’t matter too much.
When a client makes a claim, the server usually asks the client to authenticate itself using traditional methods, such as passwords, tokens, or certificates issued by the server. For end-users this is usually sufficient.
But there is an alternative.
A client can have a certificate, and the server can require a valid certificate in order to establish a connection. This is mutual TLS (mTLS).
Where to find mTLS
You’re unlikely to encounter mTLS when browsing the web. The need for provisioning end-user certificates, managing and rotating them, makes it extremely complex. Trying to walk end-users through this makes it doubly so. Nonetheless, most modern browsers support mTLS and it isn’t unheard of.
But while end-users might rarely need this level of security, mTLS is absolutely invaluable in machine to machine communication.
Equipping clients you control, be they apps, desktop computers, IoT devices, or your own microservices, with certificates is generally much more feasible, and in these cases we can use mTLS to provide a much higher level of security, by simply refusing to communicate without a valid certificate.
mTLS is zero trust implemented right down to the network connection.
mTLS in CDNs - sorely absent
While mTLS isn’t feasible for general web traffic, it would be ideal for securing the connection between a content delivery network (CDN) and the server (origin).
A CDN intercepts requests for resources, then communicates behind the scenes to the origin to fetch the requested resource. Typically the CDN will terminate the TLS connection, establishing it’s own connection to the origin.
If this connection could be established with mTLS - then we could ensure that only traffic from our CDN can speak to our origin.
Given that CDNs are often responsible for filtering requests — enforcing authentication, geoblocking, web application firewalls, etc. — the possibility of bypassing them entirely represents a considerable risk.
Despite this, it’s not as simple to lock your origins down as you might expect - with AWS Cloudfront for example, solutions such as whitelisting CDN IPs (which can change), or adding “secret headers” (which can be intercepted, leaked, or spoofed) to the requests are recommended. These methods are hardly foolproof.
With mTLS, this problem could be solved easily. CloudFront would present a client certificate to the origin during the TLS handshake, and the origin would verify it. This would guarantee that only traffic from CloudFront (or any other CDN that supports mTLS) is allowed to reach your backend, entirely eliminating the risks associated with headers and IP-based security.
Despite the clear benefits, mTLS between CDNs and backend services isn’t widely implemented. Issuing and rotating certificates across the many edge locations that CDNs operate from would, of course, be complicated. However particularly within a single ecosystem such as AWS it ought to be feasible, and the benefits would be considerable.
Conclusion
As Zero Trust architecture becomes more prevalent, mTLS is being increasingly used for securing network connections.
Yet its absence from CDNs is a missed opportunity, and one that needs addressing.
By not adopting mTLS, CDNs force developers to rely on workarounds that are less secure and harder to manage.
The ability to lock down traffic between CloudFront and an ALB (or any other backend service) using mTLS could offer the kind of robust, zero-trust security that many organizations desperately need.
Next time you speak to your account manager or your CDN provider asks for feedback, request mTLS with the origin—it’s the best way to ensure that origin servers remain secure and CDN security measures aren’t being bypassed.
About James Babington
A cloud architect and engineer with a wealth of experience across AWS, web development, and security, James enjoys writing about the technical challenges and solutions he's encountered, but most of all he loves it when a plan comes together and it all just works.
No comments yet. Be the first to comment!