== Summary == This change enables TLS 1.3 (draft28) support on the gnutls crypto library.
== Owner == * Name: Nikos Mavrogiannopoulos
== Detailed Description ==
This change will enable the TLS 1.3 protocol (draft28) on the gnutls library. TLS 1.3 is the latest version of the TLS protocol which addresses few shortcomings of the previous versions. The protocol has already been approved by IETF and is on its final publication stage, with only minor editorial changes expected. The change for gnutls depending is transparent to existing applications.
More information for applications using gnutls: * https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html
== Benefit to Fedora ==
* This brings the latest TLS protocol support to applications depending on gnutls, when crypto policies are updated for TLS1.3.
== Scope == * Proposal owners: * Other developers: N/A (not a System Wide Change)
== Upgrade/compatibility impact == That change should have no impact on upgrade or compatibility. The TLS 1.3 protocol is designed in a way that does not cause incompatibility issues with existing (and even broken) implementations.
== How To Test == * Existing work-flows which include secure communications should be tested * Command line applications which use TLS (e.g., wget, lftp), should be tested against web-sites using TLS 1.3 (e.g., www.google.com)
== User Experience == That change should not be noticeable by users except for applications which report the connected protocol. Other things users will notice - Latency on TLS sessions will be reduced - Performance of establishment of TLS sessions will be improved due to ed25519/x25519 support - Privacy of TLS sessions will be improved from the perspective of passive eavesdroppers; no client certificate will be sent in the clear - Transparent rekey of long-running sessions
== Dependencies ==
GNOME, samba, rsyslog, wget, lftp, ...
== Contingency Plan ==
If the expected transparent addition of TLS 1.3 cannot be assured (e.g., important issues are reported), the enablement of TLS1.3 protocol will be postponed for the next fedora release.
* Contingency mechanism: The gnutls maintainer will not enable TLS1.3 by default in the build * Contingency deadline: Fedora 29 beta * Blocks release? No; the contingency plan is sufficient and can avoid a release block
== Documentation == * https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html * https://www.gnutls.org/manual/gnutls.html#Upgrading-from-previous-versions
On Wed, 18 Jul 2018 17:26:06 -0400, Ben Cotton wrote:
This change enables TLS 1.3 (draft28) support on the gnutls crypto library.
== Upgrade/compatibility impact == That change should have no impact on upgrade or compatibility. The TLS 1.3 protocol is designed in a way that does not cause incompatibility issues with existing (and even broken) implementations.
== User Experience == That change should not be noticeable by users except for applications which report the connected protocol.
Apparently, this change breaks Google Mail IMAP for Claws Mail. https://bugzilla.redhat.com/1629151
On Sat, Sep 22, 2018 at 3:32 PM, Michael Schwendt mschwendt@gmail.com wrote:
Apparently, this change breaks Google Mail IMAP for Claws Mail. https://bugzilla.redhat.com/1629151
You'll need to add a call to gnutls_server_name_set(), see:
https://www.gnutls.org/manual/gnutls.html#Server-name-indication
The problem is explained quite well in the other linked bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1611815
Hope that helps,
Michael
On Sat, 22 Sep 2018 16:32:07 -0500, mcatanzaro gnome org wrote:
You'll need to add a call to gnutls_server_name_set(), see:
https://www.gnutls.org/manual/gnutls.html#Server-name-indication
That an update for SNI may be required is clear, but it doesn't answer the question where a change will be needed.
The problem is explained quite well in the other linked bug:
No, it isn't, because fetchmail doesn't use gnutls. Claws Mail does, and additionally it is based on libetpan, which uses gnutls internally, too.
On Sun, Sep 23, 2018 at 7:57 AM, Michael Schwendt mschwendt@gmail.com wrote:
That an update for SNI may be required is clear, but it doesn't answer the question where a change will be needed.
The Claws Mail developers will have to investigate. The right place will be close to all the other uses of GnuTLS, though, after creating the gnutls_session_t, before connecting to the server.
On Sun, Sep 23, 2018 at 7:57 AM, Michael Schwendt mschwendt@gmail.com wrote:
No, it isn't, because fetchmail doesn't use gnutls. Claws Mail does, and additionally it is based on libetpan, which uses gnutls internally, too.
There's really nothing more to say about the problem than what's explained there. If you want to connect to Google with TLS 1.3 you're going to have to use SNI, because Google has decided to require it. It's unfortunate that this artificially introduces an incompatibility for applications that are turning on TLS 1.3 when so much effort has gone into ensuring the protocol is backwards-compatible and resistant to so many ways of breaking that.
You could also just turn off TLS 1.3 with gnutls_set_default_priority_append(). Of course, that will break in a few years when Google starts refusing TLS 1.2 connections. Better to use SNI.
Michael
Le dimanche 23 septembre 2018 à 09:40 -0500, mcatanzaro@gnome.org a écrit :
There's really nothing more to say about the problem than what's explained there. If you want to connect to Google with TLS 1.3 you're going to have to use SNI, because Google has decided to require it.
??? That's not a Google choice, SNI is one of the Mandatory-to-Implement Extensions in TLS 1.3. You'll need it to connect to anything that claims TLS 1.3 (which will be everyone as soon as someone publishes a hole in TLS 1.2)
Of course Google *was* heavily involved in the TLS 1.3 draft, and *is* working on obsoleting SNI as it exists today in favour of an encrypted variant.
On Sun, Sep 23, 2018 at 10:14 AM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
??? That's not a Google choice, SNI is one of the Mandatory-to-Implement Extensions in TLS 1.3. You'll need it to connect to anything that claims TLS 1.3 (which will be everyone as soon as someone publishes a hole in TLS 1.2)
Of course Google *was* heavily involved in the TLS 1.3 draft, and *is* working on obsoleting SNI as it exists today in favour of an encrypted variant.
I didn't know that!
In that case... well, that requires changes in all applications using GnuTLS that don't already use gnutls_server_name_set(). They will either need to call gnutls_server_name_set(), or else disable TLS 1.3. Correct?
Michael
On Sun, Sep 23, 2018 at 10:14 AM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
??? That's not a Google choice, SNI is one of the Mandatory-to-Implement Extensions in TLS 1.3. You'll need it to connect to anything that claims TLS 1.3 (which will be everyone as soon as someone publishes a hole in TLS 1.2)
Of course Google *was* heavily involved in the TLS 1.3 draft, and *is* working on obsoleting SNI as it exists today in favour of an encrypted variant.
I didn't know that!
In that case... well, that requires changes in all applications using GnuTLS that don't already use gnutls_server_name_set(). They will either need to call gnutls_server_name_set(), or else disable TLS 1.3. Correct?
If they want to be compatible with certain servers:
| Additionally, all implementations MUST support the use of the | "server_name" extension with applications capable of using it. | Servers MAY require clients to send a valid "server_name" extension. | Servers requiring this extension SHOULD respond to a ClientHello | lacking a "server_name" extension by terminating the connection with | a "missing_extension" alert.
https://tools.ietf.org/html/rfc8446
There is no requirement in TLS 1.3 to actually send the SNI extension, which is why GNUTLS still negotiates TLS 1.3 even if no SNI has been configured by the application.
To be honest, this looks like a misconfiguration of the Google servers.
Thanks, Florian
Le dimanche 23 septembre 2018 à 22:39 +0200, Florian Weimer a écrit :
On Sun, Sep 23, 2018 at 10:14 AM, Nicolas Mailhot
To be honest, this looks like a misconfiguration of the Google servers.
Actually, this is probably a "we can finally declare IE6 dead and use SNI everywhere" moment on the part of Google. Because IE6 was really the only remaining reason to bother avoiding SNI.
They certainly took the pain to make it explicit in the spec
- The "server_name" [RFC6066] and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. […]
Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert.
So, don't be confused by the "MAY"s. The only thing a server that wants to use SNI owes clients that do not support it is a clean termination message.
And from the server side point of view, why would you want to pass on SNI? That requires provisioning one dedicated IPs per server name, at a time IPv4 adresses get exhausted, and virtualisation pretty makes sures you are sharing things right and left.
Regards,
* Nicolas Mailhot:
Le dimanche 23 septembre 2018 à 22:39 +0200, Florian Weimer a écrit :
On Sun, Sep 23, 2018 at 10:14 AM, Nicolas Mailhot
To be honest, this looks like a misconfiguration of the Google servers.
Actually, this is probably a "we can finally declare IE6 dead and use SNI everywhere" moment on the part of Google. Because IE6 was really the only remaining reason to bother avoiding SNI.
Clearly not, as this thread shows.
And from the server side point of view, why would you want to pass on SNI? That requires provisioning one dedicated IPs per server name, at a time IPv4 adresses get exhausted, and virtualisation pretty makes sures you are sharing things right and left.
There's no name-based virtual hosting involved. RFC 7817 suggests that there is currently no scalable solution for virtual IMAP hosting (section 5.1, Notes on Hosting Multiple Domains).
In Google's case, there is only one server, imap.gmail.com:
https://developers.google.com/gmail/imap/imap-smtp
Among other things, this avoids the scalability problems mentioned in RFC 7817.
Thanks, Florian
Le 2018-09-24 08:49, Florian Weimer a écrit :
- Nicolas Mailhot:
Le dimanche 23 septembre 2018 à 22:39 +0200, Florian Weimer a écrit :
In Google's case, there is only one server, imap.gmail.com:
That's the public name, nothing stops them from sharing part of the entry point with google@work stuff.
Among other things, this avoids the scalability problems mentioned in RFC 7817.
The RFC clearly states there is ongoing work to remove any issue that would prevent use of SNI everywhere. And you assume Google cares more about scalability, than about mixing traffic as much as possible, to avoid third parties interfering with the way it wants its network flow to reach end users.
* Nicolas Mailhot:
The RFC clearly states there is ongoing work to remove any issue that would prevent use of SNI everywhere. And you assume Google cares more about scalability, than about mixing traffic as much as possible, to avoid third parties interfering with the way it wants its network flow to reach end users.
Actually, I assume Google simply made a mistake here. But this is getting off-topic.
Florian
On Mon, 24 Sep 2018 11:27:49 +0200, Florian Weimer wrote:
Actually, I assume Google simply made a mistake here. But this is getting off-topic.
As I've mentioned in the Fedora bugzilla ticket, pointing at the gnutls API is not a solution. libetpan upstream would appreciate a pull request.
https://github.com/dinhviethoa/libetpan/issues/258#issuecomment-423823453
Patching Claws Mail won't be enough.
On Sat, 2018-09-22 at 22:32 +0200, Michael Schwendt wrote:
On Wed, 18 Jul 2018 17:26:06 -0400, Ben Cotton wrote:
This change enables TLS 1.3 (draft28) support on the gnutls crypto library. == Upgrade/compatibility impact == That change should have no impact on upgrade or compatibility. The TLS 1.3 protocol is designed in a way that does not cause incompatibility issues with existing (and even broken) implementations. == User Experience == That change should not be noticeable by users except for applications which report the connected protocol.
Apparently, this change breaks Google Mail IMAP for Claws Mail. https://bugzilla.redhat.com/1629151
I get what I think is a similar error with the google 'Online accounts'
I get a certificate error. The message is:
"No SNI provided; please fix your client."
Would this be a related issue?
On Wed, 26 Sep 2018 09:20:30 -0600, Nathanael D. Noblet wrote:
I get what I think is a similar error with the google 'Online accounts'
I get a certificate error. The message is:
"No SNI provided; please fix your client."
Would this be a related issue?
Yes. If Google hands out certificates for other secure services in the same way as it does on its IMAP servers, any other TLS based client will need to be developed further.
On Thu, 2018-10-04 at 21:33 +0200, Michael Schwendt wrote:
Yes. If Google hands out certificates for other secure services in the same way as it does on its IMAP servers, any other TLS based client will need to be developed further.
Ok, so should I be filing a bug and if so against which component? I wasn't sure if the google online accounts part of GNOME used GnuTLS or not.
On Fri, Oct 5, 2018 at 4:54 PM, Nathanael D. Noblet nathanael@gnat.ca wrote:
Ok, so should I be filing a bug and if so against which component? I wasn't sure if the google online accounts part of GNOME used GnuTLS or not.
It uses glib-networking, which does use GnuTLS. glib-networking already enables SNI (off the top of my head, in GTlsClientConnectionGnutls.c), so some further debugging is going to be required here to see if indeed it's true that the SNI extension is not being sent for some reason.
On Fri, 2018-10-05 at 17:14 +0200, mcatanzaro@gnome.org wrote:
On Fri, Oct 5, 2018 at 4:54 PM, Nathanael D. Noblet < nathanael@gnat.ca> wrote:
Ok, so should I be filing a bug and if so against which component? I wasn't sure if the google online accounts part of GNOME used GnuTLS or not.
It uses glib-networking, which does use GnuTLS. glib-networking already enables SNI (off the top of my head, in GTlsClientConnectionGnutls.c), so some further debugging is going to be required here to see if indeed it's true that the SNI extension is not being sent for some reason.
Ok, I can help with the debugging if needed. I just didn't know what stack this was built on. Let me know if/what you'd like me to do.
On Fri, Oct 5, 2018 at 5:21 PM, Nathanael D. Noblet nathanael@gnat.ca wrote:
Ok, I can help with the debugging if needed. I just didn't know what stack this was built on. Let me know if/what you'd like me to do.
Honestly I have no clue since the code seems foolproof. A bug report at https://gitlab.gnome.org/GNOME/glib-networking/issues would be a good place to start so we can get it onto some bugtracker, at least.