Skip to content

(CVE-2020-24661) Invalid certificates not checked against locally pinned certificates when GCR support not available

If there is no read-write PKCS#11 store accessible by GCR (e.g, gnome-keyring-daemon is not installed, the gnome-keyring user PKCS#11 store is not installed or enabled, or gnome-keyring has dropped support for it, again), and an exception for an invalid TLS certificate has previously been allowed by the user for a specific server identity (e.g. the host name/IP address configured for the service), then subsequent connections to the same server identity will be accepted without comparing the certificate presented by the server with the certificate that was originally presented and pinned.

This allows e.g. MITM attacks against connections with the same configured identity when using invalid certificates.

This can be mitigated by any of: a) ensuring your system is correctly configured WRT PKCS#11 stores, b) not using invalid certificates (including self-signed certificates), c) not creating exceptions for invalid certificates.

Original description:

Bug Summary

Geary accepts self-signed X.509 certificates when doing STARTTLS (and probably also implicit TLS). This allows a Meddler-in-the-Middle (MitM) to steal emails and user credentials.

Your installation

Steps to reproduce

  1. Setup a local mailserver with an "invalid" X.509 certificate, i.e. self-signed, one where the root-CA is not trusted by the operating system, etc. (I used mkcert, https://github.com/FiloSottile/mkcert)
  2. Try to connect Geary to that mail server and observe that no warning is displayed.

What did you expect to happen?

Geary should under no circumstances just proceed with the connection. It must issue a warning and obtain user permission to do so. IMHO Thunderbird is a good example how to do it properly.

Relevant logs and/or screenshots

Edited by Michael Catanzaro