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.
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.
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.
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:
Enables the browser to send encrypted application data even before the SSL negotiation is complete.
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.
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.
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.
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.