CDN SSL/TLS | CDN security

What are the security risks to a CDN?

Like all networks exposed to the Internet, CDNs must guard against on-path attacks, data breaches, and attempts to overwhelm the network of the targeted origin server using DDoS attacks. A CDN can have multiple strategies for mitigating vulnerabilities including proper SSL/TLS encryption and specialized encryption hardware.

What is SSL/TLS encryption?

Transport Layer Security (TLS) is a protocol for encrypting data that is sent over the Internet. TLS grew out of Secure Sockets Layer (SSL), the first widely-adopted web encryption protocol, in order to fix most of the earlier protocol’s security flaws. The industry still uses the terms somewhat interchangeably for historical reasons. Any website that you visit starting with https:// rather than http:// is using TLS/SSL for communication between a browser and a server.

Proper encryption practices are a necessity in order to prevent attackers from accessing important data. Because the Internet is designed in such a way that data is transferred across many locations, it is possible to intercept packets of important information as they move across the globe. Through the utilization of a cryptographic protocol, only the intended recipient is able to decode and read the information and intermediaries are prevented from decoding the contents of the transferred data.

The TLS protocol is designed to provide 3 components:

1. Authentication - The ability to verify the validity of the provided identifications
2. Encryption - The ability to obfuscate information sent from one host to another
3. Integrity - The ability to detect forgery and tampering

Learn more about free SSL/TLS from Cloudflare.

What is an SSL certificate?

To enable TLS, a site needs an SSL certificate and a corresponding key. Certificates are files containing information about the owner of a site, and the public half of an asymmetric key pair. A certificate authority (CA) digitally signs the certificate to verify that the information in the certificate is correct. By trusting the certificate, you are trusting that the certificate authority has done its due diligence.

Operating systems and browsers typically have a list of certificate authorities that they implicitly trust. If a web site presents a certificate that is signed by an untrusted certificate authority, the browser warns the visitor that something could be afoot.

Certificates and the way they are implemented can also be independently rated based on strength, protocol support and other characteristics. Ratings can change over time as newer, better implementations become available or other factors result in reduction of overall security of a certification implementation. If an origin server has an older lower grade SSL security implementation it will typically be graded more poorly and may be vulnerable to compromise.

A CDN has the added benefit of providing security to visitors of properties hosted within its network using a CDN provided certificate. Because visitors connect to only the CDN, an older or less secure certificate in use between the origin server and the CDN will not affect the client’s experience.

Realistically, this weaker server-to-edge security still represents a vulnerability and should be avoided, especially given the ease with which it is possible to upgrade the security of an origin server by using free origin encryption.

Proper security is also important to organic search; encrypted web properties result in stronger ranking on Google search.

An SSL/TLS connection operates differently than a traditional TCP/IP connection. Once the initial stages of the TCP connection have been made, a separate exchange occurs to set up the secure connection. This article will refer to the device requesting the secure connection as the client and the device serving up the secure connection as the server, as is the case with a user loading a webpage encrypted with SSL/TLS.

First the TCP/IP handshake is made in 3 steps:

1. The client sends a SYN packet to the server in order to initiate the connection.
2. The server than responds to that initial packet with a SYN/ACK packet, in order to acknowledge the communication.
3. Finally, the client returns an ACK packet to acknowledge the receipt of the packet from the server. After completing this sequence of packet sending and receiving, the TCP connection is open and able to send and receive data.

Once the TCP/IP handshake has occurred, the TLS encryption handshake begins. The detailed processes behind a TLS handshaking implementation are beyond the scope of this guide. Instead we will focus on the core purpose of the handshake and the time required to complete the process.

From a high level, there are three main components to a TLS handshake:

1. The client and the server negotiate TLS versions and the type of cryptography cipher to be used in the communication.
2. The client and server take steps to ensure mutually authentic communication.
3. A key is exchanged to be used in future encrypted communications.

In the diagram below, each of the steps involved in a TCP/IP handshake and a TLS handshake are visualized. Keep in mind that each arrow represents a separate communication which must travel physically between the client and the server. Since the total number of messages back and forth are increased when using TLS encryption, web page load times are increased.

For illustrative purposes it can be said the TCP handshake takes about 50ms, the TLS handshake may take about 110ms. This is largely a result of the time it takes for data to be sent both ways between the client and server. The idea of round-trip time (RTT), which is the amount of time it takes for information to travel from one device to another and back again, can be used to quantify how “expensive” a connection is to create. If left unoptimized and without the use of a CDN, additional RTT represents increases in latency and load times for end-users. Luckily, there are optimizations that can be made to improve total load time and reduce the number of trips back and forth.

How can SSL latency be improved?

SSL optimizations can reduce RTT and improve page load time. Here are 3 of the ways a TLS connection can be optimized:

TLS Session Resumption - a CDN can keep a connection alive between the origin server and the CDN network for longer by resuming the same session for additional requests. Keeping the connection alive saves time spent renegotiating the connection between the CDN and the origin server when the client requires an uncached origin fetch. As long as the origin server receives additional requests while the connection to the CDN is maintained, additional visitors to the site will experience lower latency.

The overall cost of a session resumption is less than 50% of a full TLS handshake, mainly because session resumption only costs one round-trip while a full TLS handshake requires two. Additionally, a session resumption does not require any large finite field arithmetic (new sessions do), so the CPU cost for the client is almost negligible compared to that in a full TLS handshake. For mobile users, the performance improvement by session resumption means a much more reactive and battery-life-friendly surfing experience.

Enable TLS False Start - when a visitor is viewing the site for the first time, the session resumption mentioned above will not be helpful. TLS False Start allows the sender to send application data without a complete TLS handshake.

The False Start does not modify the TLS protocol itself, it only modifies the timing in which data is transferred. Once the client begins the key exchange, encryption can be assured and data transfer begins. This modification reduces the total number of roundtrips, cutting down the latency required by 60ms.

Zero Round Trip Time Resumption (0-RTT) - 0-RTT allows for session resumption without addition RTT latency added to the connection. For resumed connections using TLS 1.3 and 0-RTT, connection speed is improved, leading to a faster and smoother web experience for web sites that users visit regularly. This speed boost is especially noticeable on mobile networks.

0-RTT is an effective improvement, but is not without some security tradeoffs. To overcome the risk of what is known as a replay attack, a CDN service may implement restriction on the type of HTTP requests and the allowed parameters. To learn more, explore an introduction to 0-RTT.

CDN protection from DDoS attacks

One of the most substantial security vulnerabilities of web properties on the modern Internet is the use of distributed denial-of-service (DDoS) attacks. Over time DDoS attacks have increased in size and complexity, with attackers utilizing botnets to target websites with attack traffic. A large and properly configured CDN has the potential benefit of scale as a protective factor against DDoS; by having enough data center locations and sizable bandwidth capabilities, a CDN is able to withstand and mitigate an amount of incoming attack traffic that would easily overwhelm the targeted origin server.

Other steps can be taken to secure a TLS connection. Learn more about the Cloudflare CDN and staying on top of TLS attacks. Check your website for proper HTTPS usage in the Cloudflare Diagnostic Center.