[Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade

[James Bottomley <James Bottomley HansenPartnership com>]

On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing

gnutls-3.6.7-lp150.9.1.x86_64

Lead to evolution failing on my dovecot imap server with

Error reading data from TLS socket: The specified session has been invalidated for some reason

Turning on ssl verbose debugging on the dovecot server shows this

May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 early data
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read finished
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x20, ret=1: SSLv3/TLS write session ticket
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished 
successfully
May  9 07:44:05 bedivere dovecot: imap-login: Debug: SSL alert: close notify
May  9 07:44:05 bedivere dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, 
rip=153.66.160.226, lip=153.66.160.254, TLS, session=<rwVTe3WIEuiZQqDi>

So dovecot thinks the session was negotiated successfully, but
evolution doesn't and thus no authentication attempts are made.

gnutls-cli doesn't seem to have a problem connecting at TLSv1.3:

jejb@jarvis:~> gnutls-cli -d 1 -p 993 bedivere.hansenpartnership.com
Processed 405 CA certificate(s).
Resolving 'bedivere.hansenpartnership.com:993'...
Connecting to '66.63.167.143:993'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=bedivere.hansenpartnership.com', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', 
serial 0x0328497b8aaa5af37e798c749a130cfb8d10, RSA key 2048 bits, signed using RSA-SHA256, activated 
`2019-05-05 08:23:13 UTC', expires `2019-08-03 08:23:13 UTC', 
pin-sha256="X1hoRFoc2Dx7VFEFk8krheR0zwy5hYxE/xNrG0B+Qoo="
        Public Key ID:
                sha1:12218c287996b0041d8eaec4782010a1999d9539
                sha256:5f5868445a1cd83c7b54510593c92b85e474cf0cb9858c44ff136b1b407e428a
        Public Key PIN:
                pin-sha256:X1hoRFoc2Dx7VFEFk8krheR0zwy5hYxE/xNrG0B+Qoo=

- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital 
Signature Trust Co.', serial 0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', 
pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
- Status: The certificate is trusted. 
- Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Options:
- Handshake was completed

- Simple Client Mode:

* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.

So it's something within evolution itself.

I've fixed this temporarily by disabling TLSv1.3 on the server, but
since dovecot doesn't have a way to do this, I had to do it in
openssl.cnf which is somewhat less optimal (although I'd already
disabled TLSv1.3 for apache because of its failure to handle client
certificates, so I think it's safe).

James