Bug 1611810

Summary: GnuTLS enables TLS 1.3 by default
Product: [Fedora] Fedora Reporter: Ben Cotton <bcotton>
Component: Changes TrackingAssignee: Nikos Mavrogiannopoulos <nmavrogi>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: bitlord0xff, bugs.michael, bugzilla, nmavrogi, pasik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-29 17:11:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ben Cotton 2018-08-02 19:05:28 UTC
This is a tracking bug for Change: GnuTLS enables TLS 1.3 by default
For more details, see: https://fedoraproject.org/wiki/Changes/GnuTLS-TLS1.3

This change enables TLS 1.3 (draft28) support on the gnutls crypto library.

Comment 1 Jan Kurik 2018-08-14 11:01:42 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 2 Ben Cotton 2018-08-14 13:12:59 UTC
According to the Fedora 29 schedule[1], today is the deadline for changes to be in a testable state. If your change is ready to be tested, please set the status to ON_QA. A list of incomplete changes will be sent to FESCo tomorrow for evaluation. If you know your change will not be ready for Fedora 29, you can set the version to rawhide and notify bcotton.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Comment 3 Chris Murphy 2018-09-12 05:19:45 UTC
If I point Firefox at https://tls13.crypto.mozilla.org/ then I get a failure. If I point wget to the same URL I get an index.html which contains "You've reached a demo server that's running TLS 1.3 (draft 28) using NSS."

Is this a reasonable test and are the results expected?

Comment 4 Nikos Mavrogiannopoulos 2018-09-13 06:28:24 UTC
Yes that's a reasonable test. Note that we should provide a new update of gnutls to use the final tls1.3 version instead of the draft 28.

Comment 5 Branko Grubić 2018-09-22 13:56:31 UTC
Hi,

Sorry for spamming this tracker bug. Is anyone who understands this able to take a look at bug #1629151 claws-mail started behaving strangely, displaying invalid2.invalid certificates like in bug #1611815 . Is it possible that it's a bug in claws-mail triggered by this change?

Thanks

Comment 6 Michael Schwendt 2018-09-22 20:50:24 UTC
As a side-note here, comparing gnutls package EVR between F28 and F29 was the first I had done, since the culprit had to be outside Claws Mail.

  gnutls-3.6.3-4.fc28
  gnutls-3.6.3-4.fc29

Unfortunately, the %changelog does not mention the switch to TLS 1.3 and doesn't mention the conditional build changes either.

:-(

It would have been helpful, if the %changelog had been more accurate about the difference between F28, F29 and later.

Comment 7 Michael Schwendt 2018-09-23 14:43:51 UTC
If it cannot be avoided within gnutls, libetpan is the second package that would need to be developed further, since being the backend lib that Claws Mail uses. 

https://github.com/dinhviethoa/libetpan/blob/master/src/data-types/mailstream_ssl.c#L597

There's an old SNI feature request for it here:
https://github.com/dinhviethoa/libetpan/issues/258

Comment 8 Nikos Mavrogiannopoulos 2018-09-24 07:28:52 UTC
That server seems to have different behavior when operating under TLS1.3 in comparison with TLS1.2. TLS1.3 enablement was the trigger for this issue, but didn't cause it.

https://bugzilla.redhat.com/show_bug.cgi?id=1629151#c16