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

[James Bottomley <James Bottomley HansenPartnership com>]

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