Secure Sockets Layer (SSL) is a protocol used to establish secured connections, typically between a server and web browser. All information sent through a SSL connection is encrypted, so it can only be accessed by the intended recipient. This facilitates the secure exchange of sensitive data, including login details, credit card information and email content, thereby countering the risk of being eavesdropped on by a third party in a “man-in-the-middle” attack.
As of 2015, the last version of SSL (3.0) was officially deprecated. It has been replaced by TLS (Transport Layer Security), which provides stronger encryption while serving a similar function. However, the original name has stuck; many still refer to TLS as “SSL/TLS” or simply “SSL”.
First introduced in 1995, SSL/TLS plays an important role in Internet evolution, providing it with the trust factor required to serve as a place of business. Google officially added TLS to its list of ranking factors in 2014, further reinforcing the protocol’s importance and accelerating its already wide adoption.
There is a lot more to be said about SSL/TLS from a security and business perspective. In this guide, however, our focus is on the performance and security aspects of using SSL in conjunction with content delivery network (CDN)—an increasingly popular choice for many website owners.
How a CDN Can Bolster SSL/TLS Performance
The Issue: The Overhead of SSL/TLS Handshake
To understand how using a CDN can improve SSL performance, let’s first review how an SSL connection differs from it regular TCP counterpart.
A typical TCP connection is established through a process known as a three-way handshake. In it, a client sends out a connection request (SYN), receives an acknowledgment (SYN/ACK) and then responds with an acknowledgment of its own (ACK). This closes the loop and establishes the connection.
One, two and three…forth, back and forth. Assuming there are no hiccups, the time it takes to complete the handshake should be exactly equal to a single round trip time (RTT).
On the other hand, negotiating a SSL/TLS connection requires a few additional back-and-forths. This is because the browser and server now also need to:
- Agree upon a mutually-compatible method of encryption.
- Go through a process of mutual verification.
- Generate symmetric keys, used to encode and decode all information exchanged during the session.
These extra interactions add overhead to the process, resulting in two additional round trips—or more, depending on your server’s configuration.
For example
If the round trip time from San Francisco to your London server is 50 ms, then establishing a SSL/TLS handshake will take at least 150 ms.
Solution: Use a CDN to Reduce Round Trip Time
For most, SSL security benefits far outweigh the drawback of longer connection times. Still, the overhead can be a nuisance, which is why many online businesses use CDNs to compensate for some of the added latency.
Shortening round trip time is a core function of CDN—a service specifically designed to improve response speeds by reducing the physical distance between your website and its users.
By cutting down on the round trip time, CDN also speeds up all interactions during the SSL/TLS negotiation process. Because the handshake requires at least three round trips, you get thrice the effect for every millisecond a CDN shaves off.
For example
If the round trip time from San Francisco to your London server is 50 ms, then establishing a SSL/TLS handshake will take at least 150 ms.
Keep an Eye Out for Keep-alive
Note that the scenario described above is only true if your CDN already has an open connection to the origin server. Otherwise, after the first leg of the SSL/TLS connection is in place, the CDN still needs to initiate a second negotiation process. Here, the SSL overhead remains the same (or may even be a bit longer).
What is important here is to ensure that your CDN has a keep-alive functionality, also referred to as a persistent connection. With a keep-alive, a CDN maintains an open connection with the server between different user sessions for a few minutes at a time.
This means that, as long as your website is visited once every few minutes, the CDN and origin server won’t have to reengage in additional SSL/TLS negotiations. All of your visitors benefit from faster handshake times.
For example
After the SSL connection with the LA proxy is established, in the absence of a keep-alive functionality, the CDN has to re-open the connection with the origin server in London.
The round trip time between LA and London is 30 ms, so it will take 90 ms to negotiate the second SSL connection. This brings the total handshake time back to 150 ms.
Using CDN for Out-of-the-Box Optimization
As mentioned, the amount of round trips required for a SSL/TLS handshake depends on your server’s configuration. For example, extra round trips occur when your server isn’t optimized to handle TLS records above a certain size, resulting in additional back-and-forth interactions.
Additionally, some server configurations can accelerate SSL/TLS communications, including:
False Start
Enables the browser to send encrypted application data even before the SSL negotiation is complete.
Session Resumption
Caches a visitor’s and server’s information to reduce negotiation times for repeat visitors.
Most modern CDNs are preconfigured for optimized SSL/TLS communications. Just by using a CDN, then, you automatically eliminate all potential bottlenecks and benefit from optimized TLS performance—right out of the box.
Note that it’s advisable to review your origin server configuration as well. This is mostly to ensure that optimal performance is maintained when it reengages with a CDN and opens a new persistent connection.
How CDNs Can Bolster SSL/TLS Security
The Issue: Low Grade Certificates and Suboptimal Implementations
As you likely already know, SSL/TLS communications rely on the existence of SSL certificates. These contain information about your domain and organization, in addition to the public key used to initiate the encrypted communications.
Here, it’s important to note that SSL certificates vary in terms of their quality and trustworthiness.
First, there is a difference between those SSL certificates purchased from an official certificate authority (CA), and free (self-signed) ones that can be generated using the OpenSSL toolkit.
Of the two, a CA certificate is clearly a much better and more trusted option—so much so that using a self-signed certificate causes all of your visitors to get an alarming message every time they try to access your HTTPS assets. This can result in a huge dent in your traffic.
Second, all SSL/TLS certificates are graded based on the quality of their individual implementation, usually based on the following criteria:
- Protocol support – Preference is given to implementations that enforce the latest and most secure protocols.
- Key exchange support – Preference is given to implementations using stronger cryptography when encoding session keys (e.g., Diffie-Hellman 2048-bit parameter).
- Cipher support – Preference is given to implementations enforcing ciphers having stronger encryption (e.g., 256-bit).
Since your certificate grade is public knowledge and is easily determined using SSLLabs or a similar tool, it also reflects on user opinion of your website.
However, beyond a negative psychological impact, this score informs you as to how secure your SSL/TLS implementation really is and how likely it can be compromised. Obviously the latter can lead to financial losses and long-term damage to your brand and your business.
Solution: CDN for an No-Hassle Grade A+ Certificate
Using a CDN means that the first leg of your SSL/TLS connection is always established using the provider’s own certificate, hosted on a CDN proxy. This has the benefit of auto-optimizing the security aspects of your SSL communications.
Your own SSL implementation may be suboptimal, and you may only be using a free self-signed certificate. From the moment you start using a CDN proxy, however, all of your visitors will be immediately protected by a grade A+ certificate, signed by one of the world’s most trusted CAs.
Finally, when new SSL vulnerabilities emerge—as they sometimes do—your CDN provider is likely to respond to them much more quickly than you can, updating its SSL implementation as part of your managed service.
This was the case with Heartbleed and POODLE vulnerabilities. CDN users were among the first to be protected—almost as soon as the news of the vulnerabilities emerged.
Free SSL Gets Better with Let’s Encrypt
Let’s Encrypt is an open certificate authority that allows you to easily create free SSL certificates. One of the benefits of these certificates is that they do not trigger the above mentioned browser alarms.
Let’s Encrypt is sponsored by the Internet Security Research Group (ISRG), the Mozilla Foundation and several additional major organizations.
Two Are Better Than One
Even with a CDN auto-optimizing the first leg of your SSL connection, it’s still advisable to improve the implementation on the second leg by tweaking the SSL configuration on your origin server.
While it’s true that attack scenarios on the second leg are very unlikely, the age old principal of “better safe than sorry” applies—especially if you’re running a prominent business that is likely to be on the receiving end of a targeted cyber attack.
CDNs for Easy HSTS Activation
HTTP Strict Transport Security (HSTS) is a security feature that ensures that your domain are only accessed via a SSL/TLS connection. HSTS is particularly useful to websites having multiple subdomains, since it can be used to effortlessly manage SSL/TLS across all of of them in bulk.
Most modern CDNs make HSTS implementation a snap, offering it as an out-of-the-box feature, manageable directly from their dashboard.
