Bug 339385

Summary:	Kleopatra (and KMail) need about 5 minutes to receive CRLs when CACert certificates are involved
Product:	[Applications] kleopatra	Reporter:	kolAflash <kolAflash>
Component:	general	Assignee:	Andre Heinecke <aheinecke>
Status:	RESOLVED FIXED
Severity:	normal	CC:	aheinecke, mutz
Priority:	NOR
Version:	git master
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	http://commits.kde.org/kdepim/94cad004c62f05ce47a471fb892ef4ffd513b317	Version Fixed In:
Sentry Crash Report:

Description kolAflash 2014-09-25 15:24:02 UTC

Load some CACert certificates into your Kleopatra.

http://www.cacert.org


Then configure Kleopatra to use CRLs instead of OCSP.
(This was actually the default on my system)

Settings => Configure Kleopatra => S/MIME
Check certificate validity every: hour
Validate certificates using CRLs: YES


Now completely quit Kleopatra (also the icon in the KDE Control-Bar).
Also quit KMail and every other application which might uses x509 certificates at the moment (for me it was KMail and Kleopatra).

Then quit all "dirmngr" instances. For example by using:
>pkill -e dirmngr

Then clear the "dirmngr" cache:
> dirmngr --flush

Kill "dirmngr" again, just to be sure it doesn't still uses any old cache-data.


If you now start Kleopatra, all certificate lists will be shown empty!!!

There is no information to the user why this is happening.
Actually in background "dirnmgr" is used to load the CRLs from CACert. If you run:

> netstat -np | grep 'dirmngr'

you'll see a connection to "213.154.225.236" which is "crl.cacert.org".
You can use tcpdump to see what it's doing:

> sudo /usr/sbin/tcpdump -n -v -i any host 213.154.225.236

For me it takes about 5 minutes until this process is finished. Until this happens, no certificates are shown in Kleopatra at all.

After that time, all my certificates are back again in Kleopatra. None of them has been lost, but it really looked like that for the last 5 minutes!


There should be a notification to the user!
For example:
> Your certificates have not been deleted! Just be a little patient, I'm receiving "Certificate Revocation Lists" from the Server to find out if any certificate became invalid.



KMail also suffers from that problem, if dirmngr is receiving the CRLs in background (because the cache was flushed or the "Check certificate validity every ..." time interval ran out).
If you read an S/MIME signed email, KMail will tell you:

> Please wait while the signature is being verified...

That's OK, but it should add: "This may take several minutes, if CRLs have to be refreshed from server".

If you answer a S/MIME signed+encrypted email, KMail will hang completly and nothing will happen until "dirmngr" completed it's work.
There isn't even a message telling me, why KMail hangs.
And by the way my whole KMail is blocked for that time. I can't even work on other emails, except I kill and restart KMail.

Reproducible: Always

Comment 1 Andre Heinecke 2015-07-07 16:21:09 UTC

The problem here is the following:
- Kleopatra wants to get the information which S/MIME Certificates are trusted and which are not. To get this information it used GPGME_KEYLIST_MODE_VALIDATE. This is the only keylist mode that did Trustchain checks.
- When GPGME_KEYLIST_MODE_VALIDATE is used gpgsm also does CRL checks on the certificates.

This is bad for a full keylisting. I have ~60 S/MIME Certs in my keyring and event with all CRLs cached it took 1m40s to list all certificates because of CRL Checks for expired / broken certificates where dirmngr was unable to obtain a CRL and thus could not cache it and ran into timeouts each time.

But even without broken certificates, the mentioned CA Cert certificates can take ages.

Disabling CRL checks altogether is obviously bad and can not be the default. We want a CRL check when we encrypt to a certificate or verify a signature from a certificate. As this is the usual workaround for this bug though, this bug is probably compromising security a bit.

To properly fix this we will disable CRL checks for the initial keylisting but leave them active for normal operations. This is a bit involved as it requires API changes to GnuPG, GpgME, GpgME++ and Kleopatra.

We are currently working on this. (Thats why I take this bug)

The first change required for this was part of gnupg 2.1.6
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=2c9c46e2a2b8f9a1bdc1ef46a135b5fc7d1a8073

Theres also a patch available for gpgme: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=patches/gpgme-1.5.5/0001-Add-offline-mode-support-for-CMS-keylisting.patch

I also have uncommited patches avaiable for gpgme++ and kleopatra. But this depends on getting the patch into gpgme first.

A fix for this will probably be part of the next gpg4win release.

For GNU/Linux it might make sense only to fix this for KDE 5 as it depends on GnuPG 2.1 which is not yet part of the stable distributions.

Comment 2 Andre Heinecke 2015-08-28 08:33:42 UTC

Git commit 94cad004c62f05ce47a471fb892ef4ffd513b317 by Andre Heinecke.
Committed on 28/08/2015 at 08:27.
Pushed by aheinecke into branch 'master'.

Use offline mode for keylist with validation

We need to list keys in keylist mode validate to
get trust and trustchain information for X509
certificates. By default this includes CRL / OCSP
checks. The new "offline" mode introduced with
gpgsm 2.1.6 allows us to list all keys with validation
but without consulting remote sources.

This speeds up the time until Kleopatra is usable
as an application or as an UI Server drastically
as CRL checks can be infinitley slow and old keyrings
with a lot of certificates might also include a lot
of broken CRL servers that would be queried until
the fetch operation times out.
REVIEW: 124950

M  +1    -1    CMakeLists.txt
M  +7    -0    libkleo/backends/qgpgme/qgpgmebackend.cpp

http://commits.kde.org/kdepim/94cad004c62f05ce47a471fb892ef4ffd513b317