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.

SSL: A Chain of Trust

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.

Long Chain = Slow Performance

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.

CloudFlare’s Smarter SSL Bundler

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.)

Build the Chains, Pick the Best

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.

Via Cloudflare.com