Doing some tests about how works the CRL in different browsers and devices, it has been observed that some of them that are very used, like Android does not check the CRL, thus, Android (and Chrome/Chromium) does not check the certificate validity through the CRL.
A CRL (Certificate Revocation List), as its name implies, it is a list of certificates that they are not valid anymore and any application/device should trust them. It is defined in the RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"
The website ssl.com contains a list of URLs with different websites with valid, expired and revoked certificates.
If we open the following URL (https://revoked-rsa-dv.ssl.com/) which has a revoked certificate in Firefox, we received the following error message.
The certificate contains the following CRL Distribution Points:
openssl s_client -connect revoked-rsa-dv.ssl.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > revoked-rsa-dv.ssl.com.pem
openssl x509 -noout -text -in revoked-rsa-dv.ssl.com.pem | grep -A 4 'X509v3 CRL Distribution Points'
Serial number of the certificate of revoked-rsa-dv.ssl.com:
openssl s_client -connect revoked-rsa-dv.ssl.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' | openssl x509 -noout -serialNow, we can download the CRL and verify the validity of the certificate of revoked-rsa-dv.ssl.com, although the verification can be done with openssl through verify parameter, it will be done manually with purpose of learning:
wget http://crls.ssl.com/SSLcom-SubCA-SSL-RSA-4096-R1.crl
openssl crl -inform DER -text -noout -in SSLcom-SubCA-SSL-RSA-4096-R1.crl At this point we can verify if the serial number of the certificate is revoked or not. In this case, we can see that it is revoked from August 23.
openssl crl -inform DER -text -noout -in SSLcom-SubCA-SSL-RSA-4096-R1.crl | grep -A 1 6AAEFB5046E7425ACE83E2FA1E145105
At this point how should an application works with security by default?
Obviously the CRL should be checked before establish the TLS connection, because by security the certificate validity should be verified. The CRL should be retrieve, to do this could be downloaded from different ways. A difference of the CRL, exist a protocol called OCSP, with the RFC 6960 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP" that defines a method about how to verify the validity of a certificate.
The main difference between CRL and OCSP is that the CLR needs to download the whole file before to establish the connection and OCSP only ask by the current certificate;
Verification using openssl and OCSP:
openssl s_client -connect revoked-rsa-dv.ssl.com:443 < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p' > certificate.pem
openssl s_client -showcerts -connect revoked-rsa-dv.ssl.com:443 < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p' > chain.pemFrom the certificate chain (chain.pem), remove all less the root certificate (in this case is the last certificate).
openssl ocsp -no_nonce -issuer chain.pem -cert certificate.pem -text -url http://ocsps.ssl.com
OCSP has two big problems:
- Performance: because before to establish the connection needs to wait the response of the OCSP responder; and
- Privacy: because the CA (and the OCSP responders) will known the sites you are visiting.
OCSP Stapling (the alternative to OCSP)
In this implementation is the server who queris to the OCSP responder and then caches the response. Thus in this case is the server who verifies the validity of the certificate and not the client. It is the method that It is by default in Chromium, read "What's the story with certificate revocation?" in [5]
As we have been shown in the first picture, Firefox verifies correctly the validity of the certificate, also it can be configure to disable it, but it is enabled by default. More information about how it works in Firefox [4]
I have been trying to configure it in Chromium version 108.0.5359.94 and I have not found the way (also in Chrome).
In Android, we find the same behaviour, the certificate validity through the CRL is not checked. Researching about why it is not implemented in Android, since this is related by the security and Android "says" that they are focused in security...
So, Google (and Android team) knows it from (at least) since 2014 when someone reports it through Google issuetracker (where the Android vulnerabilities are reported).
The Google answers was "2) Revocation checking generally doesn't work (as a security feature), and especially for mobile, greatly affects performance (negatively) and privacy (negatively)".
Reading this [1] and [2], Google does not seem that they will change it.
Mention that devices that are using Android but they are certified with Common Criteria and using the Protection Profile for Mobile Device Fundamentals of NIAP [3], they works correctly with OCSP and CRL. It is because the PP has a requirement called "FIA_X509_EXT.1 X.509 Validation of Certificates"
[1] https://issuetracker.google.com/issues/36993981
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=116838
[3] https://www.niap-ccevs.org/MMO/PP/MDF%203.3%20PP/
[4] https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox