Bug 1611815

Summary: IMAP fetch against imap.gmail.com fails due to self-signed certificate when SNI not set.
Product: [Fedora] Fedora Reporter: Valdis Kletnieks <valdis.kletnieks>
Component: fetchmailAssignee: Vitezslav Crhonek <vcrhonek>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: anon.amish, matthias.andree, vcrhonek
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: fetchmail-6.3.26-22.fc30 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-24 10:27:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Set SNI to the server name none

Description Valdis Kletnieks 2018-08-02 19:14:27 UTC
Created attachment 1472812 [details]
Set SNI to the server name

Description of problem:

Connecting to imap.gmail.com has started throwing the following errors:

fetchmail: 6.3.26 querying imap.gmail.com (protocol IMAP) at Wed 01 Aug 2018 03:40:22 PM EDT: poll started
Trying to connect to 2607:f8b0:400d:c0c::6c/993...connected.
fetchmail: Server certificate:
fetchmail: Unknown Organization
fetchmail: Issuer CommonName: invalid2.invalid
fetchmail: Subject CommonName: invalid2.invalid
fetchmail: Server CommonName mismatch: invalid2.invalid != imap.gmail.com
fetchmail: imap.gmail.com key fingerprint: 90:4A:C8:D5:44:5A:D0:6A:8A:10:FF:CD:8B:11:BE:16
fetchmail: Server certificate verification error: self signed certificate
fetchmail: Missing trust anchor certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid

Yes, they passed back a self-signed cert.

From the OpenSSL project mailing list:

"In the world of SMTP, with SMTP server names determined indirectly
and generally insecurely from MX records, it is not generally clear
what name one would use in SNI, and many SMTP clients don't send it
at all.  Some authenticate servers against the nexthop domain (the
envelope recipient domain), others might authenticate the MX host,
or just do unauthenticated opportunistic TLS.  This has worked
acceptably well with TLS <= 1.2

Along comes 1.3, and suddenly some server operators have become
particularly keen on enforcing all sorts of constraints that at
first blush look rather aggressive.  Specifically, the Google
SMTP servers serving millions of domains (including gmail.com),
now only do TLS 1.3 when SNI is presented, and when SNI is missing,
not only negotiate TLS 1.2, but use an unexpected self-signed cert
chain that validating senders will fail to authenticate, and others
may find perplexing in their logs.  (Thanks to Phil Pennock, Bcc'd
for reporting this on the exim-dev list).
"
Full discussion here:
https://mta.openssl.org/pipermail/openssl-project/2018-April/000623.html

Fix?  Set the SNI.  Patch attached.


Version-Release number of selected component (if applicable):
fetchmail-6.3.26-20.fc29.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Vitezslav Crhonek 2018-08-08 07:52:16 UTC
Applied, thanks!

Comment 2 Matthias Andree 2018-09-13 18:20:27 UTC
The patch is inadequate, it lacks error checking.  Please reopen the bug report and back out the patch.

The upstream Git repository has had a proper solution for a year now, https://gitlab.com/fetchmail/fetchmail/commit/9b8b634312f169fab872f3580c2febe5af031615

Comment 3 Vitezslav Crhonek 2018-09-24 10:27:29 UTC
Thanks for heads-up. I've backported the upstream patch.

Comment 4 Fedora Update System 2018-09-24 10:42:22 UTC
fetchmail-6.3.26-22.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb46a96c04

Comment 5 Fedora Update System 2018-09-27 02:08:51 UTC
fetchmail-6.3.26-22.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-eb46a96c04

Comment 6 Fedora Update System 2018-10-09 00:04:53 UTC
fetchmail-6.3.26-22.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 7 Matthias Andree 2018-10-19 16:49:34 UTC
An Ubuntu bug report claims that downgrading to TLS v1.0 worked around the bug, but I do not recommend doing that.
https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1798786