Page MenuHome GnuPG

GpgOL: Mitigate S/MIME Denial of Service due to CRL stalling
Open, WishlistPublic


Some X509 Certificate authorities (see T3907), mostly cacert, provide their CRLs so slow that for the user it looks like GpgOL is broken.

E.g. a first verification of an S/MIME mail can take up to 30 minutes by default. During the verification GpgOL does not show the contents of the mail. So it can take up to 30 minutes for a user until she can read a signed S/MIME mail. This amounts to a denial of service.

An idea could be to blacklist CA's that are so slow with their CRL's. My idea would be to skip the verification if it takes more then 5 seconds. Keep it running in the background but do just another verify in offline mode. The second verify would only be used as an integrity check. So for that second verify do not treat the result as a valid signature (no green bar, no trusted sender address) and show in the details "is not valid because the CRL was not known" the next time the mail is viewed it will hopefully have the CRL cached and then it will be quick.



Event Timeline

I wonder if the best thing here might be another flag in the trustlist to disable CRL/OCSP checks for a single root certificate chain. I had such a request in the Gpg4win forums. Someone had a single unreacable CRL / OCSP and had to disable globally all checks for all other certs, too.

Interesting idea but it does not help against attacks because all root CA are considered equal (virtually cross-signed). Thus a single not checked root CA allows to subvert all certificates.

No I do not think so. Because that would already be currently the case. If you had a subverted Root CA of course you can attack. But we are only talking about CRL / OCSP here. A root CA that does not provide a CRL for certificate X is OK. As long as the Root CA that issued X issues a CRL for that. Well the usual CRL / OCSP denial of service is still possible but I don't see any subversion.

This is resolved with the preview feature in GpgOL-2.4.6 Gpg4win-3.1.12

Ah no, this is about the sending part, where we only encrypt to online validated keys, that is not mitigated at all. Disregard my last comment.