9

I am a Firefox user and recently stumbled upon the Liu, Yabing, et al. "An end-to-end measurement of certificate revocation in the web's PKI." Proceedings of the 2015 Internet Measurement Conference. ACM, 2015 study and after a moment of worry, I found myself wondering if the revocation lists checks or the OCSP were still unimplemented or partially implemented in the most recent versions of not only Firefox but other browsers as well. Even though I crawled the web for a while looking for latest updates as far as revocation lists checking and OCSP is concerned (my search was mostly confined to Firefox updates, I have to admit), I could not find anything meaningful.

Do any of you have recent updates for this ? Would a lot of the table enclosed below (taken from previously cited study) remain crossed in red if the whole assessment was done all over again ? I am under the impression that such a reassessment should be conducted.

enter image description here

Another approach, taken by Chrome and Firefox for instance, are embedded CRL sets. How frequently are they updated and is the set update delay sufficiently small to avoid the majority of attacks ?

Cobalt Scales
  • 123
  • 9
  • 1
    It should be noted that CRL's are slowly being replaced by [OCSP](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol), which browsers do indeed check. –  Oct 11 '19 at 10:22
  • Yes indeed let me reformulate my question. – Cobalt Scales Oct 11 '19 at 10:23
  • 4
    @MechMK1: browsers often don't check OCSP. Chrome and Firefox use a different mechanism (CRLset, OneCRL) which includes only some of the revoked certificates. See also https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3 – Steffen Ullrich Oct 11 '19 at 11:38
  • @SteffenUllrich I think the content of this link, together with its references, are pretty much the answer to this question. –  Oct 11 '19 at 12:15
  • 1
    @CobaltScales While this is indeed an interesting question, I am not sure if the second part is on-topic (or answerable) here. If you would like to do this as your master thesis, suggest it to your supervisor. –  Oct 11 '19 at 12:17
  • Good point. Removing this part of the question. – Cobalt Scales Oct 12 '19 at 01:35
  • The only thing that is really working, in a cross-browser way, is short certificate validity periods: even if a certificate is compromised somehow, this is just a temporal issue since the certificate will become invalid anyway soon. – eckes Jan 06 '20 at 10:31
  • [CRLite](https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/) has a potential to change this significantly, but Mozilla have been quiet on it since early 2020 – Beni Cherniavsky-Paskin Jun 27 '21 at 13:32

1 Answers1

6

Not very well.

In theory, the system should work. In practice, it doesn't. The implementations intended to manage revocation - namely CRL and OCSP - both have problems. Most of this answer is based on this article by Alexey Samoshkin, as well as this article by Scott Helme.

What about CRLs?

A certificate revocation list is a remarkably simple way of determining if a certificate is valid or not. It is in essence a list of all certificates that have been revoked. If you would like to check if a certificate has been revoked, you need to check the associated revocation list.

This list is potentially very large, slow to download and requires you to be online in order to be able to verify the validity of a certificate. While the online requirement seems like a non-issue for browsers, there are more uses for certificates than to authenticate a web-server, which may indeed be offline.

In practice, CRLs are considered an outdated mechanism that deliver far too much overhead and are infeasible to do in practice.

What about OCSP?

OCSP was designed to be the golden goose that solves all the problems with CRLs. In practice, it introduced a set of new problems.

  • Increased latency due to the need to make an inline request to the OCSP endpoint.
  • Dependency of OCSP endpoint availability.
  • Privacy compromise to the CA, since you need to transmit for which certificate (and thus which domains) you would like to have OCSP information.

What about failures?

What happens if a CRL or OCSP endpoint is not available? Turns out, nothing. If the status of the certificate can't be validated, browsers default to considering them legitimate. This means an attacker that can successfully get my browser to "give up" on trying to get OCSP data (e.g. by dropping all packets intended to go to an OCSP endpoint), even revoked certificates are considered valid.

Will we ever fix revocation or should we just give up?

There are attempts to mitigate these problems. Chrome uses CRLSet, and Mozilla uses OneCRL. The idea is basically that my browser contains a list of all CRLs and periodically (e.g. once per day) updates them.

Another attempt made is OCSP Stapling, which shifts the burden of proof to the server again. The idea is that the server periodically asks the CA if the certificate is still valid, and then gets a timed response, which the server includes with the certificate.

This fixes several of the above mentioned problems:

  • The certificate and its revocation status are sent in one transmission, reducing latency.
  • The CA does not get information about which domains are requested by the user.
  • The OCSP endpoint of the CA can have reduced availability, since messages are valid for some time.
  • The OCSP endpoint has a lower load, since it is distributed more among web servers.

So where is the catch?

I mentioned that the current status of certificate revocation is bad, so obviously there must be a catch. Turns out that web servers aren't really that good at implementing OCSP stapling. I won't go into all the details, since Alexey's article does a fine job at explaining it. The basic gist is that even if enabled, some servers may not immediately send out stapled responses. Some servers, like nginx, don't send a response if the certificate has been revoked. This means even if the web server knows the certificate is revoked, it will not tell the user because...reasons?

What about must-staple?

Glad you asked! The idea is simple, the certificate includes a flag that indicates that a server must staple an OCSP response, or otherwise verification will fail. Sounds good in theory, so where is the catch?

The catch is that browsers react weirdly to this flag. Firefox throws MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING, which only somewhat makes kind of sense when you already know what it's supposed to mean - only slightly better than throwing us a T_PAAMAYIM_NEKUDOTAYIM. Chrome, on the other hand, doesn't care at all. Chrome doesn't support OCSP at all, so it's only logical that an extension that requires it is just being ignored.

In conclusion, certificate revocation is broken and there is very little each of us can do to fix it.

schroeder
  • 123,438
  • 55
  • 284
  • 319