SSL certificates – The Revival Of The Certificate Revocation List

The Management Problem With SSL Certificates

It is hard to believe, but there is one topic in IT security that has yet to be forgotten: the management of SSL certificates. Because up to now, there has been no universal method by which a compromised SSL certificate can be blocked and thus withdrawn from circulation. And so, for example, shortening the term of SSL certificates is “only” the attempt to at least shorten the period in which a compromised certificate is in circulation, giving less time for its misuse and any attacks – the one with its associated administration effort for certification authorities and end users included.

However, there needed to be a satisfactory solution to the problem of managing SSL certificates. But there is news: Apple and Mozilla are now demanding a revival of the certificate revocation lists – and they also have a heavyweight on board with the world’s most considerable certification authority, Let’s Encrypt.

SSL Certificate And Key In A Nutshell

We all know that an SSL certificate ensures the identity of a website and encrypts data traffic. Logically, a key is required to encrypt data – and another to decrypt it. Therefore, one key pair consisting of a public and a private key is required. While the public key encrypts a message, it can only be decrypted with the matching private key.

However, if this private, secret key has been stolen and made public, the entire SSL certificate is compromised and must be revoked by the issuer, the Certification Authority (CA).

Review: CRLs And OCSP

In the past, two mechanisms flagged SSL certificates as revoked if compromised: CRLs and OCSP.

The query via Certificate Revocation Lists

If a CA has blocked an SSL certificate, it enters this certificate in a Certificate Revocation List (CRL). The problem is that these lists can quickly become several MBytes in size. Since these lists also have to be downloaded by the client first, they are unsuitable for a quick check as to whether a revoked certificate is in them or not: the transmission to the client and the actual inspection take far too much time. In addition, blocklists are only sometimes up-to-date because they are only created at specific intervals.

Die Alternative: Online Certificate Status Protocols

In a further development, the alternative to CRLs should be the Online Certificate Status Protocol. With the help of the Online Certificate Status Protocol, OCSP for short, a query to a server (a so-called OCSP responder) can be used to determine whether an SSL certificate has been blocked or is still valid.

A client or browser, therefore, finds out whether an SSL certificate has been revoked when it makes a successful request to a server (OCSP responder – “OCSP response service” ): If the response is “good”, the SSL certificate is not revoked, if it is “revoked”, the SSL certificate is revoked. The status cannot be determined if the answer is “unknown”. The group cannot be selected.

Criticism and OCSP

OCSP has three significant problems. First, there is the privacy issue. The OCSP responder receives every website request and thus also gets the entire search history of a person, with all their confidential data.

On top of that, attackers can use a man-in-the-middle attack to redirect and take over an encrypted connection, using a revoked SSL certificate and thus blocking the OCSP queries. In this case, the browser or client would not receive a response from the server and would assume that the SSL certificate was OK. In this case, experts speak of a “fail open” or a “soft fail”. It would be more helpful to receive an error message if there is no answer, i.e. a “fail close” or “hard fail”.

It doesn’t even need an attack. Because if a browser does not receive an answer within a specific time after an OCSP request, it simply ignores this status and accepts a certificate as valid – even if it may have been blocked. However, attempts by browser manufacturers to change this have shown that this would not be practicable. There are too many false alarms because the OCSP infrastructure is not of the quality required for smooth operation.

A third point of criticism: The OCSP response often requires the distributed page components to be retrieved via multiple servers, which can lead to significantly longer loading times for website calls.

Apple and Mozilla Require Complete Blocklists.

These three reasons were enough for browser manufacturers not to make OCSP mandatory. Own certificate revocation lists for emergencies and shorter certificate terms should limit the risk. All in all a very unsatisfactory situation.

Now Apple and Mozilla require CA certificates to provide complete revocation lists. The manufacturers want to include these blocklists in the trust store of their browsers.

New: intermediate station Truststore

The trust stores should function as an intermediate station: they should collect the certificate revocation lists centrally and then forward them to their browsers as a compact list. This intermediate station allows enough optimisation to solve the scaling and performance problems of the traditional CRLs.

And what about Google?

Google has long since said goodbye to the Online Certificate Status Protocol and works with so-called CRLSets in its Chrome browser. With these, the browser receives the most important entries in the blocking lists via the update mechanism. However, the Heartbleed bug (OpenSSL) revealed that this does not work reliably for mass bans.

While at least the largest CA, Let’s Encrypt, seems to be enthusiastic about Mozilla’s and Apple’s proposal and has already put the new CRLs into operation, Google, of all people, which at least has a dominant position in the market with its Chrome browser, has not (yet) joined the new CRLs have had their say. Google is quite active when it comes to guidelines for digital certificates. If the group has something against the advance of Apple and Mozilla, it should be difficult for the two to assert themselves against the top dog. However, no answer does not mean a rejection – so we can remain curious.

Also Read: SSL Certificate – Definition, Types And functions

Conclusion On Certificate Revocation Lists

This long-known SSL certificate management problem is finally moving forward. Even if it is still unclear whether the other browser manufacturers, let alone the CAs themselves, will get involved directly, the “rush forward” by Mozilla and Apple should at least build up a certain amount of pressure. We’ll stay on the ball for you – and who knows, we’ll soon be able to report on a first test here in our blog.