Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1611810 - GnuTLS enables TLS 1.3 by default
Summary: GnuTLS enables TLS 1.3 by default
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nikos Mavrogiannopoulos
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-02 19:05 UTC by Ben Cotton
Modified: 2019-10-29 17:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-29 17:11:35 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

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
Note You need to log in before you can comment on or make changes to this bug.