Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 07:59 -0700, James Bottomley wrote: > 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. Hi, I see. That would work until a new version of the TLS is released and implemented and advertised by the servers with clients which probably know about it (due to new enough gnutls being installed, right?), but its usage in glib-networking failing for whatever reason. > 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. Oh, you are right, I'm sorry for misinterpreting it. Maybe the glib-networking can be changed to try a lower version(s) (when allowed to), when the best it thinks it can use fails with this error (meaning if the server advertises TLS versions 1.2 and 1.3, the client can try with 1.3 and if it fails, then retry with 1.2). I'd expect such naive "solution" would work on the gnutls level transparently though. I do not know gnutls, nor glib-networking, thus this is really just a very naive idea. 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. By the way, the openssl implementation for glib-networking is very new, released as part of the 2.60.0, on March 11 [2]. Bye, Milan [1] https://gitlab.gnome.org/GNOME/glib-networking/issues/new [2] https://gitlab.gnome.org/GNOME/glib-networking/blob/2.60.0/NEWS#L1 ___ 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 Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution- hackers wrote: > 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: Hi, the more important is glib/glib-networking/gnutls version, than evolution(-data-server) version. Sometimes also the system crypto policy setting (/etc/crypto-policies/config on Fedora), though it works the other way, it disables the old algorithms and "forces" use of the newer, which can break connection against legacy servers. > > 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. The error is returned from gio/glib-networking and I agree it's not obvious what it is about. Maybe it means that the current code doesn't have new-enough implementation of the TLS. It looks like that, at least. > > I neded to #include on my slackware linux. > > Me too, but it was a trivial update. Hrm, weird, it might be probably due to that strlen() usage. No idea what pulled it in here, that it didn't claim any issue on my side. I'm sorry about that. > 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). 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). Thank you James for all the testing and finding that out. It's good to know that glib has it fixed already. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
