It has been shown that Heartbleed can be used to leak SSL private keys (if the attackers are lucky). So now many experts are recommending that you revoke and re-issue SSL certificates for your web server. Can the certificate revocation mechanism cope?
— Fedor Indutny (@indutny) April 11, 2014
Quick background on Certificate Revocation Lists (CRLs)
If we look at the SSL certificate for the Nexor web site (by going to https://www.nexor.com, and clicking the padlock symbol), we can see the certificate as:
I have highlighted a field called the CRL distribution point. If we now go to the URL specified (http://crl2.alphassl.com/gs/gsalphag2.crl), we can see the CRL revocation list. On the tab “Revocation List”, we can see a list of the serial numbers of all the certificates that have been revoked…
Today, this list contains about 1,200 items.
In theory (sadly, theory and practice deviate) every time you visit https://www.nexor.com your browser should check the certificate. Part of this process is to check that the certificate the web site is producing is not on the CRL, if it is, it is bad, and you should not trust the site. Your browser should download this CRL and check the list; if they don’t you cannot trust the site.
Spot the problem caused by Heartbleed – this list will get very large, instead of thousands we could see (according to some estimates) 6.5 million certificates needing to be revoked. This will slow your browser down considerably, to the extent it will probably break.
This problem has been forseen, and the Online Certificate Status Protocol (OCSP) was invented to deal with the situation. In short, you call out to a server that has downloaded the CRL for you, and ask it to search the list for the certificate you are interested in. Dealing with large lists is seen as a must-have capability of OCSP servers, but it is not clear how many do.
Even this can take time, so a mechanism called OCSP stapling was invented, in which the web site ‘staples’ the OCSP response to the SSL query. FireFox can do OCSP stapling, but like all browsers is dependent upon the web server cooperating.
Google uses its own mechanism in Chrome.
What is not clear is how widely OCSP and the variations are actually implemented. This tweet from the guys that discovered SSL private keys can be leaked by Heartbleed, suggest not as widely as it needs to be…
Now we finally see that OCSP is a future and CRL is just impossible to maintain, though no one has expected it to be used on that scale
— Fedor Indutny (@indutny) April 12, 2014
Heartbleed is certainly going to cause many headaches long into the future while these issues are sorted out – in the interim its hard to know what can be trusted…