What We Just Did to Make SSL Even Faster

A little over a month ago, we published a couple of blog posts about how we were making SSL faster. Specifically, we enabled OCSP stapling across our network. In brief, when you visit a page over HTTPS, your browser checks to see if the SSL certificate is still valid via a protocol called OCSP. Those checks can be slow so we took multiple steps to make them faster. The net effect was that, for browsers that supported OCSP stapling, visitors to HTTPS sites on CloudFlare would see about a 30% performance increase on their SSL handshakes.

That was the good news. What happened next was a number of people checked our SSL setup to validate our claims. While we had increased performance around OCSP checks, these investigations turned up a number of ways in which we weren't optimally deploying SSL. In particular, William Chan wrote a blog post looking at our SSL deployment and suggesting a number of things we could do to make it better.

We took this criticism to heart and today released an improved SSL process. Our goal is to provide the fastest, strongest SSL with the most ubiquitous browser support. Since a number of other cloud service providers are likely to face the same challenges, and since we haven't found anyone else that was automatically optimizing certificate bundles intelligently, we wanted to document what we did.

In the simple case, SSL is easy. When your browser connects to a website over HTTPS, the site's web server returns a SSL certificate back to the browser. This certificate is used to verify the identity of the website and encrypt data exchanged between the browser and the web server.

In order to perform these functions, the certificate has to be trusted by the browser. A website's SSL certificate is issued by a Certificate Authority (CA). CAs vouch for a website's certificate as being valid. The CAs then have what are known as root certificates that are trusted by the browser. Since the CA's root is trusted by the browser, and since the CA trusts the web server's SSL certificate, by the transitive property the browser trusts the SSL certificate and a secure HTTPS connection can be established.

The challenge is that the world of SSL isn't always that clean. To begin, most CAs don't use their root certificate to directly sign the SSL certificates they issue to clients. Instead they use "intermediate" certificates. The chain of intermediate certificates can be of any arbitrary length, strung together to pass trust from the root to the eventual final certificate used by the web server. More complicated still, one intermediate certificate can have multiple parent certificates that vouch for its identity. GoDaddy, for example, has a case where their own root certificate as well as Valicert's root certificate both vouch for a GoDaddy intermediate certificate.

While trust can pass along any length of SSL chain, the longer the chain is the more of a performance impact there is on setting up a HTTPS connection. While some of this overhead comes from validating all the certs in the chain, much also has to do with just having to transmit all the data that makes up the intermediate certificates.

As William Chan pointed out, CloudFlare was including more than we needed to and thereby overflowing the maximum amount of data per packet. This can have an especially large impact on web performance since SSL data is the first thing to be exchanged, no more data can be exchanged until after the SSL handshake takes place, so getting rid of a round trip on the SSL handshake can speed up everything else down the line.

For SSL certificates we issued ourselves (such as those we create for Pro customers), this wasn't a problem. However, for custom SSL certificates, like those available for Business and Enterprise subscribers, we were not being smart about what we were including in the SSL bundle. The lowest hanging fruit in terms of reducing the size of these certificates was to remove the root certificates from the certificate bundle. There's no reason to include these since they should already be present in browsers and, even if they're not, the browser won't trust them.

We wanted to be even smarter about how we build bundles, so we spent some time developing a system that would find the shortest path between a certificate a user uploads to our system and one of the root certificates present in browsers. To do this, we needed to build a directory of the web's most common intermediate certificates. You'd think that's something someone would have assembled and published. We searched around for quite some time to find all these and didn't find it anywhere, so we created one ourselves. (PS - So no one else has to go through this same painful exercise, we're going to be publishing the directory on GitHub in the next few days and will keep it updated as we find more intermediate certificates.)

Today, when someone uploads a custom SSL certificate, we use our directory of intermediate certificates to build all the possible chains from the uploaded cert to a trusted browser root. We then rank these chains based on a number of factors including:

1. The length of the certificate chain

2. The ubiquity of the root certificate in browsers and other clients

3. The security of each step in the chain (e.g., does their Extended Key Usage include Server Authentication)

4. The length of the validity period of all the steps in the chain

The result is a server bundle that is small, fast and strong while having ubiquitous browser and client support. These are all optimizations that organizations concerned with performance and security should be doing by hand. What we're excited about is that we've automated this process and made it easy for anyone who wants the fastest possible SSL for their given certificate. If you were already using SSL through CloudFlare, your SSL bundle has been automatically optimized. If your site seemed a bit faster, that's why.

Going forward, in addition to releasing the directory of intermediate SSL certificates on Github, we plan on releasing our SSL bundler as a free service so you can package up your SSL certificates as efficiently as possible, even if you're not using CloudFlare. Just one more way we're working to make the web fast and safe.