Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-16 at 09:05 +0200, Milan Crha via evolution-hackers wrote: > On Wed, 2019-05-15 at 15:49 -0700, James Bottomley wrote: > > gnutls Add support for timeouts on GnuTLS pulls > > > > So if you apply that on top of 2.54.1, the test programme works > > again. > > Hi, > do you see from the server logs whether the patched code tried TLS > v1.3, and then v1.2? I'm only wondering. My expectation based on the patch is that 1.3 is negotiated successfully. I tested against googlemail.com (so no server logs). I've currently got an email user out travelling who can't upgrade until I get the machine back, so I can't test on my server until they come back on Friday to avoid breaking them. > After re-reading the previous messages in this thread, you found that > the development version 2.55.2 works fine. As it's a development > version, the (usual) distributions may pick the stable version, > 2.56.0 or later. Or they can find which patch fixed it between 2.55.1 > and 2.55.2 and backport only that one (you referenced that change > above). openSUSE has chosen the backport to 2.54.1 route. > Thinking of it, maybe it's a nonsense to ask them about the TLS > version downgrade on the fly. My "suggestion" would be over- > complicated. > > In any case, thank you for your time and help on this. You're welcome, Regards, James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 18:00 +0200, Milan Crha via evolution-hacker > Consider filling a bug against glib-networking [1] and ask them > whether they can do anything about it. You've a clear view what is > going on in the background, thus you'd be able to explain the problem > to them. Feel free to use the test program to your liking. openSUSE triaged this to commit 0795cd14651c965659ccef33630872a53a7bc8ec Author: Olivier Crête Date: Fri Jul 3 12:43:45 2015 +0100 gnutls Add support for timeouts on GnuTLS pulls So if you apply that on top of 2.54.1, the test programme works again. I tried to file a bug but I can't seem to recover my account credentials for the new gitlab system. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
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= 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 0x0a014142015385736a0b85eca708, 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 18:42 +0200, Milan Crha via evolution-hackers wrote: > On Thu, 2019-05-09 at 08:37 -0700, James Bottomley via evolution- > hackers wrote: > > 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 > > Hi, > dealing with such requests is better either through the user list > (evolution-list), or through bugzilla - see the "bugs" section of: > https://wiki.gnome.org/Apps/Evolution/#Online_Support > not talking that your Evolution it rather old, the current stable > version is 3.32.2. > > Nonetheless, I do not expect that Evolution update would help, > because Evolution doesn't use gnutls. It doesn't use it directly. > Evolution relies on glib-networking and on whatever it uses, which is > gnutls in this case. Ah, right, that's why I couldn't find the direct connection. > I guess those developers would appreciate any help, > especially if the code is broken for them. If you wish, I can try to > create some simple test program (a .c file), which would open a > stream towards specified server and ask for capabilities or > something, which can be done in an unauthenticated state, on which > you can verify: > a) it's really in glib-networking, b) whether more recent version of > it will help. I can certainly test things out. To be honest, I've had problems with TLSv1.3 every time it's been negotiated, so disabling it is a reasonable thing to do. I suppose there's no gntuls-cli equivalent for glib-networking? That would be the best way to test it. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 09:17 +0200, Milan Crha via evolution-hackers wrote: > On Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution- > hackers wrote: [...] > > I think the solution is to simply bar glib-networking below 2.55.2 > > from using gnutls VERS-TLS1.3 which looks like it can be done > > reasonably well in g_tls_connection_gnutls_init_priorities() > > There are some issues with it: a) the function is a private function, > I didn't find it in any of the header files under /usr/include/; b) > it's a very specific function, there's a branch to support also > openssl in glib-networking, where this would do nothing; c) getting > such change into an old evolution-data-server or glib-networking > might be tricky, especially with Long Term Support distributions; d) > as Sasa showed (if I understand it correctly), limiting TLS version > may lead to rejected connections on otherwise working system (it's > when the server increases TLS version requirement, but the "proposed > change" would limit what can be used). With glib-networking < 2.55.2 there seems to be no way of supporting TLSv1.3. All current TLSv1.3 systems also support at least 1.2 (the allegedly more secure ones may have turned off 1.0 and 1.1 for various reasons), so disabling only 1.3 seems like a useful solution. As for how to apply the fix (assuming we can find it), this is a hard one. Clearly the bug was always present, but the conditions that trip it remained untested until people started turning on TLSv1.3. I think the best way forward is to open bugs with the distros and see what they want to do: Either find and fix the bug or update to 2.55.2. > That said, when the server requires recent TLS version, the users > need to update their system to also support such TLS version. It > makes sense (once one knows where the problem is, which I wasn't sure > at all at the beginning). Just to clarify, the server isn't requiring a particular version, it's offering a set of options and we're choosing TLSv1.3 which we then can't negotiate successfully, so the bug is client side but triggered both by the client going to a gnutls (or probably openssl but I can't test that) version that makes 1.3 possible and the server offering it as an option. > Thank you James for all the testing and finding that out. > It's good to know that glib has it fixed already. You're welcome ... I just wish I could identify the actual fix. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Fri, 2019-05-10 at 08:41 +0200, Milan Crha via evolution-hackers
wrote:
> On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> > I can certainly test things out.
>
> Hi,
> that's great, thanks.
>
> > To be honest, I've had problems with TLSv1.3 every time it's been
> > negotiated, so disabling it is a reasonable thing to do.
>
> I see. If you are still willing to help, then it'll be appreciated.
>
> > I suppose there's no gntuls-cli equivalent for glib-
> > networking? That
> > would be the best way to test it.
>
> I agree, but I'm not aware of anything like that (which doesn't mean
> it
> doesn't exist). I made a little test program as promised, see the
> attachment. The first line contains a comment with a command to
> compile
> and run it (against Google's IMAP server). It's only a test program,
> mimic-ing what Evolution (or better Camel library from evolution-
> data-
> server) does. You may have installed development packages for glib
> and,
> if split, also for glib's gio, to be able to compile it.
>
> Bye,
> Milan
>
> P.S.: The result of the run as is in the file itself is below:
>
>
> $ ./imap-conn imap.googlemail.com 993
>
> Connected to imap.googlemail.com:993
> Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}
>
> Request: A01 CAPABILITY
> Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID
> XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN
> AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
> A01 OK Thats all she wrote! {SOMETOKEN}
>
> Request: A02 LOGOUT
> Response: * BYE Logout Requested {SOMETOKEN}
> A02 OK Quoth the raven, nevermore... {SOMETOKEN}
So when I run it against my current setup (TLSv1.3 disabled) I get this
as expected:
jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
Connected to bedivere.hansenpartnership.com:993
Response: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
Request: A01 CAPABILITY
Response: * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
LITERAL+ AUTH=PLAIN
Request: A02 LOGOUT
Response: A01 OK Pre-login capabilities listed, post-login capabilities have
more.
But when I enable TLSv1.3 in dovecot on the server I get this:
jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
Connected to bedivere.hansenpartnership.com:993
Failed to read data from the server: Error reading data from TLS socket: The
specified session has been invalidated for some reason.
Which isn't particularly helpful, although it does prove the issue is
indeed in glib-networking. Is there further debugging I should turn
on?
James
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Fri, 2019-05-10 at 23:23 +0200, Sasa Ostrouska via evolution-hackers wrote: > Hi all, and thanks Milan for the program. I also run an old version > of evolution 3.20.x and I get the following: > > rc@rc-laptop:~/Downloads$ gcc `pkg-config --cflags --libs glib-2.0 > gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn > imap.googlemail.com 993 > Connected to imap.googlemail.com:993 > Failed to read data from the server: Error reading data from TLS > socket: The specified session has been invalidated for some reason. > > I neded to #include on my slackware linux. Me too, but it was a trivial update. I did a bit of build bisection. Most of the failing glib-networking packages are 2.54.1 and below. 2.55.2 is the first working version (2.55.1 doesn't build due to missing glib-pacrunner). So, clearly, whatever the TLSv1.3 bug was it was fixed in this version, but I can find neither a bugzilla nor a commit obviously identifying the problem. 2.54.1 was the last version that used autoconf, 2.55.2 uses meson, which probably explains why a few distributions are stuck on 2.54.1. I think the solution is to simply bar glib-networking below 2.55.2 from using gnutls VERS-TLS1.3 which looks like it can be done reasonably well in g_tls_connection_gnutls_init_priorities() James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
