Following on from the announcement of Heartbleed, it's fair to assume that there will be a huge amount of certificate revocations both in progress and in the days and weeks to come. With an increased number of revocations, there's the potential that OCSP/CRL responses may start to take a little longer as the Certificate Authorities load up their lists. Whilst Google Chrome does have a form of certificate revocation check, it's not what you might expect. You need to enable 'normal' revocation checking yourself.
UPDATE: This feature has now been removed from Chrome and it depends on CRLsets for revocation checking.
How does Chrome deal with certificate revocations?
Google Chrome actually utilises its own method of checking for a revoked certificate called
CRLSets. In short, Google scoops up all the Certificate Revocation Lists from participating Certificate Authorities, trims the list down to include certificates that they think are important and then sends it out to the browser. This means that the browser doesn't need to contact the Certificate Authority itself and removes the performance and privacy overheads, much like
OCSP Stapling does. The only problem here is that the list is not definitive. If Chrome doesn't have a CRL for a particular CA, it will always trust certificates, even though they may have been revoked. Not only that, but the lists are not definitive and only include certificates that Google choose. For me, if a certificate is revoked, it's revoked and should be known as such. Further to this, Google "have to be mindful of size" when adding certificates to the CRLset as they don't want to be pushing down a huge file each time a change is made. Where does that leave us post Heartbleed? The hard limit is actually
250Kb and if any CA has a CRL that pushes the CRLset over that size limit, it is typically dropped and the CA notified. You can use the
CRL Set Tools to download the latest CRLset and at the time of writing we're up to version 1567 and a size of 4.107Kb. Not exactly a heavyweight file, I know, but it has the potential to explode in size over the coming days and weeks.
How do I enable normal checks?
It's really easy to enable standard revocation checking in Google Chrome. Navigate to the Chrome settings window,
chrome://settings/, click on "Show advanced settings" and then scroll down to the "HTTPS/SSL" section. Once there, you need to tick the "Check for server certificate revocation" option. That's it!
What's the catch?
The effectiveness of certificate revocation checking has been covered in great length
many times. The main issues boil down to:
Performance
Because the client needs to communicate with the CA, there is an added DNS and TCP overhead with making the request. The client needs to request the IP of the CRL/OCSP server and then wait for a DNS resolution. Then, it needs to make a request for the revocation status of the certificate and wait for a response again. All of this can add anywhere between 300ms and 1s or more depending on the circumstances but can be countered with OCSP stapling.
Soft-Fail
If a client is dependant on performing a revocation request before making a secure connection, any downtime at the CA would be a disaster. Without the ability to check the revocation status of a certificate, huge numbers of sites could go offline if a CA was having difficulties. For this reason, browsers will normally allow you to connect if the revocation check has some difficulties or fails. With this, an attacker can interfere with the revocation check and prevent the browser from completing a request for a revocation status on a certificate they are using in an attack. This means a user will believe they are browsing with a secure connection when in fact, they are not. However, I can't help but wonder that if an attacker has access to your transport layer to interfere with the revocation check, could they just as easily block access to the Chrome CRLset?
Privacy
When making an OCSP request to a CA, you're divulging your own IP address and the host name of the site you're visiting in the certificate. This means that a CA could build up a fairly accurate record of the sites that you visit for which they issue a certificate. Whilst this could potentially represent a privacy concern, it can easily be mitigated alongside the performance aspect with OCSP stapling.
In the wake of Heartbleed
With what must be an astronomical number of revocations taking place each and every hour, I wonder how effective the CRLset can remain. Nothing similar to the scope of Heartbleed has ever occurred and I imagine that revocation lists are growing beyond what anyone previously thought was ever likely. Every certificate must remain in the CRL until its own expiry date, at which point a browser will discard it if presented as a part of the normal SSL handshake, because it will be out of date. It will be interesting to see what impact, if any, this has on the infrastructure of Certificate Authorities and equally the CRLset in Chrome. I will be closely monitoring the size of the CRLset and any changes that take place in the coming days to see what kind of effect Heartbleed will have.
