No More EV Certificate Overhead in Chrome 106

Starting with version 106, Chrome will no longer be doing Online Certificate Status Protocol (OCSP) revocation checks by default for Extended Validation (EV) certificates, providing an immediate performance improvement for any sites still using an EV certification.

Ok. It’s entirely possible, probable in fact, that that last sentence sounded like complete and utter gibberish (it’s definitely a bit of a tongue-twister) but free performance wins are rare, so let’s take a closer look at what’s changing, and how to understand whether or not your site is one of those getting a free performance boost as a result.

#anchorAn OC-what now?

During every connection to a secure domain (something served via HTTPS), the browser must go through an SSL negotiation phase. During this process, the browser is trying to establish a secure connection to the server. To do this, a few things have to happen:

• The browser and server must figure out which version of TLS to use
• The browser and server need to agree on which cipher suites to use to communicate, and generate session keys to use for encryption
• The browser needs to verify the identity of the server using the server’s public key and SSL certificate

It’s that last bit—verifying the identity of the server—that we’re focused on here.

If a site’s SSL certificate has been compromised (someone manages to get ahold of the private key, for example), the certificate must be revoked—basically, the browser needs to be told that “hey, this certificate has been compromised and can no longer be trusted”.

One of the primary ways this has been done is by performing OCSP revocation checks. During an OCSP revocation check, the browser will send a request out to an OCSP responder, providing some information about the certificate it is trying to verify. The responder will then respond (hence the name) to the browser to let it know if the certificate can still be trusted.

This request, like any other request from a website, takes time. It requires the same basic steps: the browser must establish a connection to the responder, send the request, and wait for the response.

This entire process takes place during the SSL negotiation phase of the initial request, slowing that process down.

For most certificate types, Chrome doesn’t do these revocation checks by default, preferring to use CRLSets instead. However, for Extended Validation certificates (EV), Chrome (prior to version 106) always does the OCSP revocation check, each time the site is loaded, resulting in a long SSL negotiation time.

#anchorLet’s see an example

To show what this looks like, let’s look at a WebPageTest test for Digicert.com, run on Chrome version 105, from Dallas, over a 4G connection.

Digicert.com, probably unsurprisingly, uses an EV cert for their domain. So when the request (request #2 above) is made for the home page, you can see that during the SSL negotiation phase (the purple shaded bar), Chrome fires off another request to ocsp.digicert.com to ensure the certificate can still be trusted.

It’s not a cheap process. In this run the revocation check takes 573ms to complete, delaying the actual request itself from starting until after the check has been completed.

All of that delay gets factored into the SSL negotiation time for the main connection to digicert.com. So in this case, our SSL negotiation phase takes 755ms. When you factor in the TCP connection and DNS lookup, you’re staring at 1.175s before the server can even start to send anything back.

And thanks to the use of an EV cert, it’s a cost that’s paid consistently, each time a new connection is made to that domain. Looking at the plot full results graphs, we can see that the SSL negotiation time is consistently in that 750-800ms range.

#anchorLife in a post 106 world

Perhaps ironically, since EV certs were originally positioned as providing enhanced security benefits, Chrome is ceasing to perform the OCSP revocation checks because they’re a privacy concern, as Ryan Dickson explained:

OCSP requests reveal details of individuals' browsing history to the operator of the OCSP responder. These can be exposed accidentally (e.g., via data breach of logs) or intentionally (e.g., via subpoena). This is part of why Chrome doesn't do OCSP checks for Domain Validated (DV) or Organization Validated (OV) certificates by default, and starting in version 106, Chrome won't do them for Extended Validation (EV) certificates either, to better protect users' privacy.

With the OCSP revocation check out of the picture, the performance improvement is both immediate and noticeable.

Here’s the same page, tested again from Dallas over a 4G connection, only this time, we’ve tested on Chrome version 106.

This time, there is no extra revocation check and, as a result, the SSL negotiation time is much faster, taking only 183ms.

If we compare the full results of the page loaded in version 105 to version 106, we see the SSL negotiation time is consistently and dramatically better—shaving off 588ms at the mean.

While the impact is most apparent on the SSL negotiation time, thanks to indirect improvements, there’s a trickle down effect where because the SSL time is fast, the TTFB tends to be faster, which causes the paint metrics to tend to be faster and so on—it’s a nice little speed boost that requires no work.

#anchorSeeing the Impact On Your Site

Have you ever finished a task that you needed to get done, but then when you go to your to-do list, you see it’s not there for you to cross out? Depending on how you’ve been measuring your performance this might be a little bit like that.

Most synthetic tools do not apply throttling at the packet level, and instead use DevTools throttling. Unfortunately that doesn’t apply at this level, which means that even if you were testing on slower networks, you never really saw the overhead associated with these checks.

Similarly, most tools don’t show the OCSP checks at all—you have to be doing some low-level parsing to realize that they’re going on.

So in short, in all likelihood, if you weren’t using a tool that surfaced the requests and applied that sort of network throttling, you probably had no idea you had a performance problem.

If you’re reading this before version 106 ships (currently scheduled for September 27) and you’re using an extended validation certificate, you can run a test in WebPageTest to collect information on how much of a delay it was causing. You can run a test on Chrome Beta (currently version 106 at the time of writing this) as well to see how much of a benefit you’re going to get.

You’ll also want to keep an eye on your Real User Monitoring (RUM) data. Your RUM data should be able to show you SSL negotiation and Time to First Byte, and if you were using an EV certificate, you’ll likely see an improvement in those metrics when comparing Chrome 106 to prior versions.

While there’s nothing you need to do to get the improvements, it’s probably also a good time to ping your security team about maybe ditching the expensive EV certificate—the revocation check was the last remaining supposed benefit for those certificates, and with that gone, you can likely safely move on from them altogether.