Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Geary Geary
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 466
    • Issues 466
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 34
    • Merge requests 34
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOMEGNOME
  • GearyGeary
  • Issues
  • #866
Closed
Open
Issue created May 29, 2020 by Damian Poddebniak@duesee1

(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

  • Geary version: geary-3.34.2 (NixOS)
  • Installation method: nix-env -i
  • Desktop environment: KDE
  • Operating system and version: https://channels.nixos.org/nixos-20.03/latest-nixos-x86_64-linux.ova
  • Email provider: not important

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 Aug 27, 2020 by Michael Catanzaro
Assignee
Assign to
Time tracking