Did you know that Google’s Chrome browser trusts the majority of revoked web certificates? While the other major browsers support the industry standard, Google continues to pave its own path at the risk of making users of their popular browser vulnerable to attacks.
Contents
What is a Web Certificate?
A certificate is used to securely validate an entity’s identity, such as banking websites, and encrypts communication between the client and the resource being interacted with. Should the certificate be compromised, it would put that communication at risk of being exploited or intercepted. One of the immediate responses would be to invalidate the cert by revoking it. In fact, when a severe bug in OpenSSL was discovered in 2014, “Heartbleed” was coined for the vulnerability, prompting organizations to revoke their certificates and replacing them with new, secured ones. These revocations would go on the Certification Revocation List (CRL) so that web browsers would distrust any website that still used the vulnerable certs.
Certificate Revocation List
Google at the time claimed that the CRL implementation supported by every, major browser was not good enough and created its own method, the CRLSets. One reason was that large CRLs would put a strain on servers sending that list to browsers AND put a slight delay to loading web pages. Speed is of essence in the modern browser wars. The official Certificate Authority Security Council addressed these concerns through the use of OCSP Stapling and caching, dramatically improving performance while increasing real-time security.
Risks with Google’s Chrome
As it turned out and unknown to my colleagues and I, Gibson Research Corporation discovered in 2014 (Source) that Google’s Chrome browser trusted most of the revoked certificates they threw at it for testing. GRC shared steps on how to reproduce their findings. During last week’s “Security Now” podcast, the hosts shared that Google still fails the tests, putting users of one of the most dominant browsers at risk because the CRLSets only contain a fraction of the CRL used by Internet Explorer, Safari, Firefox, Edge, Opera, and the like.
The web is increasingly being required to be secured by certificates. Browsers are soon going to stop indicating when a site is protected and only call out unsecured sites as the majority moves to SSL certs. In fact, Google will lower a website’s ranking in the search results if it is not secured. The importance for checking for revoked certificates will become even greater as cybersecurity attacks continue to increase, and hopefully, Google will join the rest of the industry and use whichever method is the most secure.
Active Directory Certificate Services (AD CS)
As a side note, for those of you who use Microsoft’s Active Directory Certificate Services (AD CS) PKI, there is an OCSP Responder portion you can utilize to help speed up CRL checking. There are Pros and Cons with using OCSP, so be sure to check whether it would be appropriate for your environment.
Many AD CS administrators do not know this, but the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should NOT be enabled despite what a lot of web forums tell you otherwise, but that would be for another story. In the meantime, please read about it here and here.
Related Posts
- OpenSSL Command Reference: Convert, Check, Verify, Extract
- Certificate Security: Export Cert with Non-Exportable Private Key / Marked as “Not Exportable” (Windows PKI)
- FortiManager: CA-Signed Web Admin Certificate
