gpgsm: should default to --disable-crl-checks
Open, NormalPublic


currently, gpgsm sends a request to the dirmngr for a crl check when verifying signatures.

This is a metadata leak that is at least as bad as --auto-key-retrieve by default. Potentially, it's even worse, because the S/MIME certificate could include arbitrary URLs to hit up for a CRL.

I think gpgsm should default to --disable-crl-checks, and we should think more clearly about other ways to ensure that an X.509 certificate is still valid.

dkg created this task.Aug 14 2017, 11:14 PM
dkg created this object in space S1 Public.

Debian Bug 842291 shows some performance impact of the CRL checks (as well as the potential for privacy problems).

dkg added a comment.Aug 15 2017, 1:38 AM

Making matters worse, i note that some CRLs, like those issued by MIT's Lincoln Lab are quick and easy to fetch over the Internet directly, but hang or timeout when fetched via Tor.

When dirmngr prefers Tor, this triggers an even longer delay.

marcus added a subscriber: marcus.Aug 15 2017, 5:40 PM

If the certificate is signed by a trusted root CA, doesn't that mean that we at least trust the URLs in the certificate chain for CRL and OCSP access?

dkg added a comment.Aug 15 2017, 5:50 PM

I see at least two different kinds of "trust" here.

  1. I am willing to rely on you to identify the parties with whom i communicate.
  2. I am willing for you to learn about my communications patterns.

When something is a "trusted root CA", i think people are saying (1).

I don't think that saying (1) is (or should be) a proxy for saying (2).

My comment was only in response to this:

Potentially, it's even worse, because the S/MIME certificate could include arbitrary URLs to hit up for a CRL.

This seems to me to be only worse if gpgsm does crl or ocsp lookups for non-trusted certificates. I did not check if that is the case.

I don't have a response to your broader point.

dkg added a comment.Aug 16 2017, 10:33 PM

i think it's strictly worse, even when the certificates are "trusted" in sense (1) -- with OpenPGP keyserver lookups, at least it is the client who decides which keyserver to use, on what protocol, to look up the given issuer fingerprint.

So with OpenPGP, The client could happen to pick a keyserver that the monitoring adversary doesn't control.

With the X.509 CRL lookup, the certificate issuer controls the specific host, protocol, and path that the client is obliged to fetch.

marcus removed a subscriber: marcus.Aug 16 2017, 11:44 PM
werner added a subscriber: werner.

I would suggest that MUAs who care about privacy do no use S/MIME at all or at least direct GPGME to not consider CRLs during signature verification. We don't have such a feature in GPGME right now but I think that is the right place to add it. X.509 is way to complicated to avoid meta data leaks.

werner triaged this task as Normal priority.Aug 24 2017, 5:23 PM
dkg added a comment.Jan 30 2018, 5:46 PM

Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

What we could do is to reject loading new CRLs if we are in --use-tor mode.

dkg added a comment.Jan 31 2018, 5:04 PM

it is the decision of the user to use such a certificate.

It is the decision of the certificate holder to use such a certificate. but the crl lookups have an impact on the relying party, who made no such decision. this bug report is about the decisions made by the relying party, and the impact those decisions make on:

  • their privacy (i.e. "phoning home" without explicit consent)
  • the efficiency of their gpgsm-related workflow (i.e. what to do when checking a signature and the CRL or OCSP responder is not responsive)

If anything, --use-tor *avoids* the privacy leakage implied by the lookup, so it's not clear to me that that's the right way to resolve the problem. perhaps the other way around (don't check CRLs *unless* you've got --use-tor enabled)?

That still leaves the efficiency concern, however.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

I would strongly suggest not to use S/MIME if you are concerned about leaking meta data.

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.