SSL/TLS Performance Diary #3: Optimizing Data Encryption
This post is one in a series of posts about properly implementing SSL/TLS. This post is excerpt from our recent Moz article, Enabling HTTPS Without Sacrificing Your Web Performance. We’ll cover additional topics from this article in future posts to our SSL Diary. In previous SSL/TLS diary posts, we discussed optimizing the certificate chain, as well as forcing visitors to securely access your site with Strict Transport Security.
A fast website is a crucial component of a great user experience. So much so that a few years ago Google announced that they were using page load time as a factor in search engine rankings. More recently, Google also announced that they would be favoring websites that use Transport Layer Security (TLS) in its search rankings. TLS encrypts a website’s traffic preventing other entities from monitoring its communications. However, adding this protection introduces more complexity to your website and how it communicates with your visitors. In our SSL/TLS diary series, we are looking at how to implement TLS on your website while keeping it fast and responsive.
Conventions and Disclaimers
Before we start, a quick note on naming. Beside TLS, you may have also heard the term SSL. SSL was the original encrypted connection protocol created by Netscape in the mid '90s. TLS is the industry standard protocol that grew out of SSL and has continued to evolve and improve while development of SSL has ceased. In the past, SSL and TLS have been largely interchangeable terms. However, the final version of SSL, SSLv3, was recently found to be not secure. All versions of SSL now have known security problems and no one should be using any version of SSL. To avoid confusion, we will not mention SSL again and talk exclusively about TLS.
Additionally, while TLS does help protect your websites's visitors from eavesdroppers, it does not magically make your site "secure" from security flaws like Cross-site scripting or SQL injection. If you store personal data or conduct commerce through your website, you should explore more rigorous web application security options.
Finally, any type of guide, tutorial, or how-to post on security is highly time sensitive. Attackers are constantly evolving and new attacks are always discovered. Advice about optimizing TLS performance from even 2 years ago, such as using RC4, would today leave your site unsecured. You should always maintain vigilance and make sure you trust your sources.
Optimizing Data Encryption
Establishing a secure connection between the client and the server is known as the TLS handshake. It can be fairly involved and has a number of areas where you can improve the performance. We will discuss optimizing the TLS handshake in a future post. For now, I will focus on what happens after the TLS handshake: the encryption of data traveling between the client and the server.
TLS essentially adds another 2 steps to the process of how a browser and web server communicates. The sender has to work to encrypt the data before transmitting it, and receiver has to decrypt the data before it can process it. Since these operations are occurring on all of your web traffic all of the time, you want this exchange to be as efficient as possible. Let’s see how we can optimize this data encryption.
There are a large number of ciphers that can be used to perform this encryption/decryption. Some, such as 3DES, were originally designed to be implemented in hardware and can perform slowly when implemented in software on your computer or phone’s browser. Others, such as AES, are so popular that CPU makers like Intel have added dedicated instructions to their chips to make them run faster.
A decade ago, TLS data encryption added significant overhead. Today, Moore's law and dedicated support for certain ciphers in CPUs has essentially eliminated this overhead, provided you select the right cipher. The consensus from both security engineers and administrators that run large TLS websites is to use AES, with 128 bit keys. We can see this in the chart below, created by Simon Kuhn, comparing the throughput speeds of different ciphers. AES, when running on a CPU that support built-in AES instructions (denoted by the label AES-NI), is by far the fastest cipher you can use.
Specifying which cipher and options to use can be quite challenging and intimidating. Luckily, Mozilla maintains an excellent page with example cipher configurations to ensure fast and secure connections. These example configurations work with all browsers, and they default to using the faster algorithms like AES. These are constantly updated when new security threats come out and I highly suggest following Mozilla's guidance.
As mentioned, to get the most out of AES, your web server will need using a CPU that support the dedicated AES instructions. These instructions are known as AES-NI. Most server-grade CPUs made in the last 5 years, such as Intel’s Xeon line, support AES-NI. However, older virtualized servers and cloud servers often don't support these instructions. Amazon's M1 class of EC2 instances do not support AES-NI. Amazon's current class of M3 instances do. If you are using a hosted service, check with your hosting provider about what TLS options they support and whether your hosting computer supports AES-NI.
In short, by configuring your web server to use AES ciphers and terminating your TLS connections on a machine with CPU with support for AES-NI instructions, you can mitigate the performance penalty of data encryption.
- Enable AES are your preferred cipher, following Mozilla's guidelines.
- Verify that web server is running on a system with a CPU that support AES-NI instructions.
In our next SSL Diaries post, we’ll discuss optimizing the TLS Handshake in more detail.If you’d like to stay on top of your website performance, consider joining the free Zoompf Alerts beta to automatically scan your website every day for the common causes of slow website performance.