From nmav at gnutls.org Wed Sep 6 13:12:11 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 6 Sep 2017 13:12:11 +0200 Subject: [gnutls-devel] GnuTLS 3.6.0 released In-Reply-To: <20170829152335.GF25801@redhat.com> References: <1503298804.9015.4.camel@gnutls.org> <20170829152335.GF25801@redhat.com> Message-ID: On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange wrote: > On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote: >> We are proud to announce a new GnuTLS release: Version 3.6.0. >> >> GnuTLS is a modern C library that implements the standard network >> security protocol Transport Layer Security (TLS), for use by network >> applications. GnuTLS is developed for GNU/Linux, but works on many >> Unix-like systems as well as Windows. >> >> The GnuTLS library is distributed under the terms of the GNU Lesser >> General Public License version 2 (or later). >> >> The project pages of the library are available at: >> http://www.gnutls.org/ > > [snip] > >> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification >> of certificates signed with SHA1 is now considered insecure and will >> fail, unless flags intended to enable broken algorithms are set. Other uses >> of SHA1 are still allowed. This can be reverted on compile time with the configure >> flag --enable-sha1-support. > > FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will > be generating certs that will never validate, since that API is hardcoded to > use SHA1. This tripped up the libvirt & QEMU test suites which used that API. > I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256 > explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign() > to use SHA256 too, or must it stick with SHA1 for backcompat reasons ? It is documented as signing with SHA1, so changing will introduce a behavioral "breakage", though I am not sure whether it matters in the end. > If so, it would be worth putting a note in the API docs that any use of > gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted. The options seem to be: * deprecate the API and force applications specify explicitly a hash for signing * Update/break the ABI for 3.6 and make the underlying algorithm used to be undefined (i.e., a secure but unspecified one). I kind of like the second option, as applications may hard-code a digest which will bring the problem back when that hash is broken. Any other opinions/options? regards, Nikos PS. I have still not managed to run the libvirt and openconnect test suites under CI. gitlab runners for some reason cannot detect errors from fedpkg and a failing build is detected as successful. I'd appreciate any help on that item. https://gitlab.com/gnutls/gnutls/merge_requests/477 https://gitlab.com/gnutls/gnutls/-/jobs/29756798 From berrange at redhat.com Wed Sep 6 13:28:31 2017 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 6 Sep 2017 12:28:31 +0100 Subject: [gnutls-devel] GnuTLS 3.6.0 released In-Reply-To: References: <1503298804.9015.4.camel@gnutls.org> <20170829152335.GF25801@redhat.com> Message-ID: <20170906112831.GN15510@redhat.com> On Wed, Sep 06, 2017 at 01:12:11PM +0200, Nikos Mavrogiannopoulos wrote: > On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange wrote: > > On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote: > >> We are proud to announce a new GnuTLS release: Version 3.6.0. > >> > >> GnuTLS is a modern C library that implements the standard network > >> security protocol Transport Layer Security (TLS), for use by network > >> applications. GnuTLS is developed for GNU/Linux, but works on many > >> Unix-like systems as well as Windows. > >> > >> The GnuTLS library is distributed under the terms of the GNU Lesser > >> General Public License version 2 (or later). > >> > >> The project pages of the library are available at: > >> http://www.gnutls.org/ > > > > [snip] > > > >> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification > >> of certificates signed with SHA1 is now considered insecure and will > >> fail, unless flags intended to enable broken algorithms are set. Other uses > >> of SHA1 are still allowed. This can be reverted on compile time with the configure > >> flag --enable-sha1-support. > > > > FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will > > be generating certs that will never validate, since that API is hardcoded to > > use SHA1. This tripped up the libvirt & QEMU test suites which used that API. > > I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256 > > explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign() > > to use SHA256 too, or must it stick with SHA1 for backcompat reasons ? > > It is documented as signing with SHA1, so changing will introduce a > behavioral "breakage", though I am not sure whether it matters in the > end. > > > If so, it would be worth putting a note in the API docs that any use of > > gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted. > > The options seem to be: > * deprecate the API and force applications specify explicitly a hash > for signing > * Update/break the ABI for 3.6 and make the underlying algorithm used > to be undefined (i.e., a secure but unspecified one). > > I kind of like the second option, as applications may hard-code a > digest which will bring the problem back when that hash is broken. Any > other opinions/options? Is there any way to let gnutls_x509_crt_sign2() take a system priority as an alternative to a fixed algorithm ? That way we can just pass "@SYSTEM" when generating a cert and be confident that gnutls will pick an algorithm that works when a session is set to use "@SYSTEM" priority string too. > PS. I have still not managed to run the libvirt and openconnect test > suites under CI. gitlab runners for some reason cannot detect errors > from fedpkg and a failing build is detected as successful. I'd > appreciate any help on that item. > https://gitlab.com/gnutls/gnutls/merge_requests/477 > https://gitlab.com/gnutls/gnutls/-/jobs/29756798 Perhaps it is confused by having multiple entries in the script: block. Does it work if you just chain them all together in a single command. eg make && make install && fedpkg-wrapper apps/libvirt && .... Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From nmav at gnutls.org Wed Sep 6 13:39:44 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 6 Sep 2017 13:39:44 +0200 Subject: [gnutls-devel] GnuTLS 3.6.0 released In-Reply-To: <20170906112831.GN15510@redhat.com> References: <1503298804.9015.4.camel@gnutls.org> <20170829152335.GF25801@redhat.com> <20170906112831.GN15510@redhat.com> Message-ID: On Wed, Sep 6, 2017 at 1:28 PM, Daniel P. Berrange wrote: > On Wed, Sep 06, 2017 at 01:12:11PM +0200, Nikos Mavrogiannopoulos wrote: >> On Tue, Aug 29, 2017 at 5:23 PM, Daniel P. Berrange wrote: >> > On Mon, Aug 21, 2017 at 09:00:04AM +0200, Nikos Mavrogiannopoulos wrote: >> >> We are proud to announce a new GnuTLS release: Version 3.6.0. >> >> >> >> GnuTLS is a modern C library that implements the standard network >> >> security protocol Transport Layer Security (TLS), for use by network >> >> applications. GnuTLS is developed for GNU/Linux, but works on many >> >> Unix-like systems as well as Windows. >> >> >> >> The GnuTLS library is distributed under the terms of the GNU Lesser >> >> General Public License version 2 (or later). >> >> >> >> The project pages of the library are available at: >> >> http://www.gnutls.org/ >> > >> > [snip] >> > >> >> ** libgnutls: SHA1 was marked as insecure for signing certificates. Verification >> >> of certificates signed with SHA1 is now considered insecure and will >> >> fail, unless flags intended to enable broken algorithms are set. Other uses >> >> of SHA1 are still allowed. This can be reverted on compile time with the configure >> >> flag --enable-sha1-support. >> > >> > FWIW, as a result of this change, apps that use gnutls_x509_crt_sign() will >> > be generating certs that will never validate, since that API is hardcoded to >> > use SHA1. This tripped up the libvirt & QEMU test suites which used that API. >> > I'm switching libvirt/qemu to use gnutls_x509_crt_sign2() passing SHA256 >> > explicitly, but I wondered if you'd considered updating gnutls_x509_crt_sign() >> > to use SHA256 too, or must it stick with SHA1 for backcompat reasons ? >> >> It is documented as signing with SHA1, so changing will introduce a >> behavioral "breakage", though I am not sure whether it matters in the >> end. >> >> > If so, it would be worth putting a note in the API docs that any use of >> > gnutls_x509_crt_sign() now almost certainly broken due SHA1 being untrusted. >> >> The options seem to be: >> * deprecate the API and force applications specify explicitly a hash >> for signing >> * Update/break the ABI for 3.6 and make the underlying algorithm used >> to be undefined (i.e., a secure but unspecified one). >> >> I kind of like the second option, as applications may hard-code a >> digest which will bring the problem back when that hash is broken. Any >> other opinions/options? > > Is there any way to let gnutls_x509_crt_sign2() take a system priority > as an alternative to a fixed algorithm ? That way we can just pass > "@SYSTEM" when generating a cert and be confident that gnutls will pick > an algorithm that works when a session is set to use "@SYSTEM" priority > string too. The @SYSTEM applies to TLS sessions only, and there is nothing similar to global configuration for non-TLS functionality. >> PS. I have still not managed to run the libvirt and openconnect test >> suites under CI. gitlab runners for some reason cannot detect errors >> from fedpkg and a failing build is detected as successful. I'd >> appreciate any help on that item. >> https://gitlab.com/gnutls/gnutls/merge_requests/477 >> https://gitlab.com/gnutls/gnutls/-/jobs/29756798 > > Perhaps it is confused by having multiple entries in the script: > block. Does it work if you just chain them all together in a single > command. eg > make && make install && fedpkg-wrapper apps/libvirt && .... I've pushed a version like that: https://gitlab.com/gnutls/gnutls/-/jobs/31497850 regards, Nikos From dkg at fifthhorseman.net Wed Sep 6 17:57:09 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Sep 2017 11:57:09 -0400 Subject: [gnutls-devel] [gnutls-help] GnuTLS 3.6.0 released In-Reply-To: References: <1503298804.9015.4.camel@gnutls.org> <20170829152335.GF25801@redhat.com> Message-ID: <87y3prbz1m.fsf@fifthhorseman.net> On Wed 2017-09-06 13:12:11 +0200, Nikos Mavrogiannopoulos wrote: > The options seem to be: > * deprecate the API and force applications specify explicitly a hash > for signing > * Update/break the ABI for 3.6 and make the underlying algorithm used > to be undefined (i.e., a secure but unspecified one). fwiw, i prefer the second option. It's always good to have a "do what you currently think is best" simple API. This also resolves the request for a "@SYSTEM" mechanism for _sign2(), since the way to do that would just be to use _sign(). I don't even think this is a large enough API/behavioral change to _sign() to warrant an SONAME bump, personally, esp. since SHA1 is deprecated for this purpose. Thanks for thinking this through! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From nmav at gnutls.org Fri Sep 8 10:16:30 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 8 Sep 2017 10:16:30 +0200 Subject: [gnutls-devel] [gnutls-help] GnuTLS 3.6.0 released In-Reply-To: <87y3prbz1m.fsf@fifthhorseman.net> References: <1503298804.9015.4.camel@gnutls.org> <20170829152335.GF25801@redhat.com> <87y3prbz1m.fsf@fifthhorseman.net> Message-ID: On Wed, Sep 6, 2017 at 5:57 PM, Daniel Kahn Gillmor wrote: > On Wed 2017-09-06 13:12:11 +0200, Nikos Mavrogiannopoulos wrote: >> The options seem to be: >> * deprecate the API and force applications specify explicitly a hash >> for signing >> * Update/break the ABI for 3.6 and make the underlying algorithm used >> to be undefined (i.e., a secure but unspecified one). > > fwiw, i prefer the second option. It's always good to have a "do what > you currently think is best" simple API. > > This also resolves the request for a "@SYSTEM" mechanism for _sign2(), > since the way to do that would just be to use _sign(). I don't even > think this is a large enough API/behavioral change to _sign() to warrant > an SONAME bump, personally, esp. since SHA1 is deprecated for this > purpose. A merge request incorporating these: https://gitlab.com/gnutls/gnutls/merge_requests/504/ From thomas2.klute at uni-dortmund.de Fri Sep 15 15:41:53 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Fri, 15 Sep 2017 15:41:53 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache Message-ID: Hi, I have discovered that GnuTLS servers ignore the SNI extension when resuming a TLS session from cache (but not when using tickets). The function gnutls_server_name_get() always returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when called on the resumed session, breaking virtual server systems (e.g. virtual hosts with Apache and mod_gnutls). You can reproduce the issue with gnutls-serv and gnutls-cli (paths from dev build): ./src/gnutls-serv --x509keyfile=doc/credentials/x509/key-rsa.pem --x509certfile=doc/credentials/x509/cert-rsa.pem -p 4433 --sni-hostname server.example.com --noticket ./src/gnutls-cli --resume --sni server.example.com -p 4433 --x509cafile=doc/credentials/x509/ca.pem localhost The server will warn about the missing server name during resumption: Warning: client did not include SNI extension, using default host The proper fix appears to be to reclassify SNI as a "mandatory" extension, because if implemented at all it must be parsed on session resumption according to RFC 6066, Section 3: "A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name." The attached one line patch changes the parse type of the Server Name extension to GNUTLS_EXT_MANDATORY. For applications that include the server name in their session cache handling this fix is sufficient, but adding a check to the resumption code might still be reasonable. Best regards, Thomas Klute -------------- next part -------------- A non-text attachment was scrubbed... Name: sni_ext_parse_mandatory.diff Type: text/x-patch Size: 523 bytes Desc: not available URL: From nmav at gnutls.org Mon Sep 18 07:53:13 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 18 Sep 2017 07:53:13 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: References: Message-ID: On Fri, Sep 15, 2017 at 3:41 PM, Thomas Klute wrote: > Hi, > I have discovered that GnuTLS servers ignore the SNI extension when > resuming a TLS session from cache (but not when using tickets). The > function gnutls_server_name_get() always returns > GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when called on the resumed > session, breaking virtual server systems (e.g. virtual hosts with Apache > and mod_gnutls). > > You can reproduce the issue with gnutls-serv and gnutls-cli (paths from > dev build): > > ./src/gnutls-serv --x509keyfile=doc/credentials/x509/key-rsa.pem > --x509certfile=doc/credentials/x509/cert-rsa.pem -p 4433 --sni-hostname > server.example.com --noticket > > ./src/gnutls-cli --resume --sni server.example.com -p 4433 > --x509cafile=doc/credentials/x509/ca.pem localhost > > The server will warn about the missing server name during resumption: > > Warning: client did not include SNI extension, using default host > > The proper fix appears to be to reclassify SNI as a "mandatory" > extension, because if implemented at all it must be parsed on session > resumption according to RFC 6066, Section 3: > > "A server that implements this extension MUST NOT accept the request > to resume the session if the server_name extension contains a > different name." > > The attached one line patch changes the parse type of the Server Name > extension to GNUTLS_EXT_MANDATORY. For applications that include the > server name in their session cache handling this fix is sufficient, but > adding a check to the resumption code might still be reasonable. Thank you Thomas. That seems like a reasonable fix. Would you like to send it as a merge request? regards, Nikos From thomas2.klute at uni-dortmund.de Mon Sep 18 08:28:15 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Mon, 18 Sep 2017 08:28:15 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: References: Message-ID: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> Am 18.09.2017 um 07:53 schrieb Nikos Mavrogiannopoulos: > On Fri, Sep 15, 2017 at 3:41 PM, Thomas Klute > wrote: >> Hi, >> I have discovered that GnuTLS servers ignore the SNI extension when >> resuming a TLS session from cache (but not when using tickets). The >> function gnutls_server_name_get() always returns >> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when called on the resumed >> session, breaking virtual server systems (e.g. virtual hosts with Apache >> and mod_gnutls). >> >> You can reproduce the issue with gnutls-serv and gnutls-cli (paths from >> dev build): >> >> ./src/gnutls-serv --x509keyfile=doc/credentials/x509/key-rsa.pem >> --x509certfile=doc/credentials/x509/cert-rsa.pem -p 4433 --sni-hostname >> server.example.com --noticket >> >> ./src/gnutls-cli --resume --sni server.example.com -p 4433 >> --x509cafile=doc/credentials/x509/ca.pem localhost >> >> The server will warn about the missing server name during resumption: >> >> Warning: client did not include SNI extension, using default host >> >> The proper fix appears to be to reclassify SNI as a "mandatory" >> extension, because if implemented at all it must be parsed on session >> resumption according to RFC 6066, Section 3: >> >> "A server that implements this extension MUST NOT accept the request >> to resume the session if the server_name extension contains a >> different name." >> >> The attached one line patch changes the parse type of the Server Name >> extension to GNUTLS_EXT_MANDATORY. For applications that include the >> server name in their session cache handling this fix is sufficient, but >> adding a check to the resumption code might still be reasonable. > > Thank you Thomas. That seems like a reasonable fix. Would you like to > send it as a merge request? At the moment the one-line parse type change is the only fix I have, please just apply that so gnutls_server_name_get works with a session cache. If I have time to add server name checks for resumption I'll look into Gitlab's merge requests, or maybe just send a normal Git pull request. Regards, Thomas From nmav at gnutls.org Tue Sep 19 11:20:45 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 19 Sep 2017 11:20:45 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> References: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> Message-ID: On Mon, Sep 18, 2017 at 8:28 AM, Thomas Klute wrote: > Am 18.09.2017 um 07:53 schrieb Nikos Mavrogiannopoulos: >> On Fri, Sep 15, 2017 at 3:41 PM, Thomas Klute >> wrote: >>> Hi, >>> I have discovered that GnuTLS servers ignore the SNI extension when >>> resuming a TLS session from cache (but not when using tickets). The >>> function gnutls_server_name_get() always returns >>> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when called on the resumed >>> session, breaking virtual server systems (e.g. virtual hosts with Apache >>> and mod_gnutls). >>> >>> You can reproduce the issue with gnutls-serv and gnutls-cli (paths from >>> dev build): >>> >>> ./src/gnutls-serv --x509keyfile=doc/credentials/x509/key-rsa.pem >>> --x509certfile=doc/credentials/x509/cert-rsa.pem -p 4433 --sni-hostname >>> server.example.com --noticket >>> >>> ./src/gnutls-cli --resume --sni server.example.com -p 4433 >>> --x509cafile=doc/credentials/x509/ca.pem localhost >>> >>> The server will warn about the missing server name during resumption: >>> >>> Warning: client did not include SNI extension, using default host >>> >>> The proper fix appears to be to reclassify SNI as a "mandatory" >>> extension, because if implemented at all it must be parsed on session >>> resumption according to RFC 6066, Section 3: >>> >>> "A server that implements this extension MUST NOT accept the request >>> to resume the session if the server_name extension contains a >>> different name." >>> >>> The attached one line patch changes the parse type of the Server Name >>> extension to GNUTLS_EXT_MANDATORY. For applications that include the >>> server name in their session cache handling this fix is sufficient, but >>> adding a check to the resumption code might still be reasonable. >> >> Thank you Thomas. That seems like a reasonable fix. Would you like to >> send it as a merge request? > > At the moment the one-line parse type change is the only fix I have, > please just apply that so gnutls_server_name_get works with a session > cache. If I have time to add server name checks for resumption I'll look > into Gitlab's merge requests, or maybe just send a normal Git pull request. I will not have much time to check into that soon (tls1.3 support is my priority at the moment). Would it make sense to open an issue on gitlab to track it? regards, Nikos From thomas2.klute at uni-dortmund.de Wed Sep 20 08:00:08 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Wed, 20 Sep 2017 08:00:08 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: References: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> Message-ID: <440b1472-e5ad-7224-499a-2fd15c804e2f@uni-dortmund.de> Am 19.09.2017 um 11:20 schrieb Nikos Mavrogiannopoulos: > On Mon, Sep 18, 2017 at 8:28 AM, Thomas Klute > wrote: >> Am 18.09.2017 um 07:53 schrieb Nikos Mavrogiannopoulos: >>> On Fri, Sep 15, 2017 at 3:41 PM, Thomas Klute >>> wrote: >>>> Hi, >>>> I have discovered that GnuTLS servers ignore the SNI extension when >>>> resuming a TLS session from cache (but not when using tickets). The >>>> function gnutls_server_name_get() always returns >>>> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when called on the resumed >>>> session, breaking virtual server systems (e.g. virtual hosts with Apache >>>> and mod_gnutls). >>>> >>>> You can reproduce the issue with gnutls-serv and gnutls-cli (paths from >>>> dev build): >>>> >>>> ./src/gnutls-serv --x509keyfile=doc/credentials/x509/key-rsa.pem >>>> --x509certfile=doc/credentials/x509/cert-rsa.pem -p 4433 --sni-hostname >>>> server.example.com --noticket >>>> >>>> ./src/gnutls-cli --resume --sni server.example.com -p 4433 >>>> --x509cafile=doc/credentials/x509/ca.pem localhost >>>> >>>> The server will warn about the missing server name during resumption: >>>> >>>> Warning: client did not include SNI extension, using default host >>>> >>>> The proper fix appears to be to reclassify SNI as a "mandatory" >>>> extension, because if implemented at all it must be parsed on session >>>> resumption according to RFC 6066, Section 3: >>>> >>>> "A server that implements this extension MUST NOT accept the request >>>> to resume the session if the server_name extension contains a >>>> different name." >>>> >>>> The attached one line patch changes the parse type of the Server Name >>>> extension to GNUTLS_EXT_MANDATORY. For applications that include the >>>> server name in their session cache handling this fix is sufficient, but >>>> adding a check to the resumption code might still be reasonable. >>> >>> Thank you Thomas. That seems like a reasonable fix. Would you like to >>> send it as a merge request? >> >> At the moment the one-line parse type change is the only fix I have, >> please just apply that so gnutls_server_name_get works with a session >> cache. If I have time to add server name checks for resumption I'll look >> into Gitlab's merge requests, or maybe just send a normal Git pull request. > > I will not have much time to check into that soon (tls1.3 support is > my priority at the moment). Would it make sense to open an issue on > gitlab to track it? My immediate concern is getting SNI parsing during session resumption fixed, because the bug breaks mod_gnutls virtual hosts with different certificates or cipher suites if tickets are disabled. If you'd like I can look into adding a reproducer script for the test suite. Tracking the question of checking SNI values on resumption separately makes sense in my opinion. Regards, Thomas From nmav at gnutls.org Wed Sep 20 18:35:08 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 20 Sep 2017 18:35:08 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: <440b1472-e5ad-7224-499a-2fd15c804e2f@uni-dortmund.de> References: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> <440b1472-e5ad-7224-499a-2fd15c804e2f@uni-dortmund.de> Message-ID: <1505925308.1982.4.camel@gnutls.org> On Wed, 2017-09-20 at 08:00 +0200, Thomas Klute wrote: > > > > Thank you Thomas. That seems like a reasonable fix. Would you > > > > like to > > > > send it as a merge request? > > > > > > At the moment the one-line parse type change is the only fix I > > > have, > > > please just apply that so gnutls_server_name_get works with a > > > session > > > cache. If I have time to add server name checks for resumption > > > I'll look > > > into Gitlab's merge requests, or maybe just send a normal Git > > > pull request. > > > > I will not have much time to check into that soon (tls1.3 support > > is > > my priority at the moment). Would it make sense to open an issue on > > gitlab to track it? > > My immediate concern is getting SNI parsing during session resumption > fixed, because the bug breaks mod_gnutls virtual hosts with different > certificates or cipher suites if tickets are disabled. If you'd like > I > can look into adding a reproducer script for the test suite. > > Tracking the question of checking SNI values on resumption separately > makes sense in my opinion. A reproducer would certainly speed things up! From thomas2.klute at uni-dortmund.de Thu Sep 21 11:27:45 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Thu, 21 Sep 2017 11:27:45 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: <1505925308.1982.4.camel@gnutls.org> References: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> <440b1472-e5ad-7224-499a-2fd15c804e2f@uni-dortmund.de> <1505925308.1982.4.camel@gnutls.org> Message-ID: <9669efe6-be75-e6ed-d3d0-6ac508b8a366@uni-dortmund.de> Am 20.09.2017 um 18:35 schrieb Nikos Mavrogiannopoulos: > A reproducer would certainly speed things up! Attached my fix with a detailed commit message, and a reproducer/test case. Regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ensure-the-SNI-extension-is-parsed-during-cache-base.patch Type: text/x-patch Size: 1775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-tests-New-test-for-SNI-parsing-during-cache-based-se.patch Type: text/x-patch Size: 3505 bytes Desc: not available URL: From nmav at gnutls.org Sat Sep 23 08:30:26 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 23 Sep 2017 08:30:26 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: <9669efe6-be75-e6ed-d3d0-6ac508b8a366@uni-dortmund.de> References: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> <440b1472-e5ad-7224-499a-2fd15c804e2f@uni-dortmund.de> <1505925308.1982.4.camel@gnutls.org> <9669efe6-be75-e6ed-d3d0-6ac508b8a366@uni-dortmund.de> Message-ID: <1506148226.2122.1.camel@gnutls.org> On Thu, 2017-09-21 at 11:27 +0200, Thomas Klute wrote: > Am 20.09.2017 um 18:35 schrieb Nikos Mavrogiannopoulos: > > A reproducer would certainly speed things up! > > Attached my fix with a detailed commit message, and a reproducer/test > case. > Thank you. I've created a merge request at: https://gitlab.com/gnutls/gnutls/merge_requests/520 The reason for not reading the extension at resumption was in order to enforce the previously received SNI, on the first connection. However, as I understand that is not the case. Anyway, your analysis is right, and we should prevent the resumption from happening inside gnutls in _gnutls_check_resumed_params(). For that, I've enhanced the pull request above. Could you check whether it addresses the bug you raised? regards, Nikos From thomas2.klute at uni-dortmund.de Sat Sep 23 21:57:08 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Sat, 23 Sep 2017 21:57:08 +0200 Subject: [gnutls-devel] Bug: SNI is ignored when resuming session from cache In-Reply-To: <1506148226.2122.1.camel@gnutls.org> References: <3e17a94e-b39c-e894-b839-d77cf3cedb09@uni-dortmund.de> <440b1472-e5ad-7224-499a-2fd15c804e2f@uni-dortmund.de> <1505925308.1982.4.camel@gnutls.org> <9669efe6-be75-e6ed-d3d0-6ac508b8a366@uni-dortmund.de> <1506148226.2122.1.camel@gnutls.org> Message-ID: <54f7ea85-0a25-45d1-08b6-14e6d20dd346@uni-dortmund.de> Am 23.09.2017 um 08:30 schrieb Nikos Mavrogiannopoulos: > On Thu, 2017-09-21 at 11:27 +0200, Thomas Klute wrote: >> Am 20.09.2017 um 18:35 schrieb Nikos Mavrogiannopoulos: >>> A reproducer would certainly speed things up! >> >> Attached my fix with a detailed commit message, and a reproducer/test >> case. >> > > Thank you. I've created a merge request at: > https://gitlab.com/gnutls/gnutls/merge_requests/520 > > The reason for not reading the extension at resumption was in order to > enforce the previously received SNI, on the first connection. However, > as I understand that is not the case. > > Anyway, your analysis is right, and we should prevent the resumption > from happening inside gnutls in _gnutls_check_resumed_params(). > For that, I've enhanced the pull request above. Could you check whether > it addresses the bug you raised? Yes, mod_gnutls can retrieve SNI data when linked against a build of the tmp-sni-fixes branch. Thank you. The code and test you've added to check SNI data on resumption looks reasonable and works on my system. I don't have an account on Gitlab, so please just go ahead and merge. :-) Regards, Thomas From ametzler at bebt.de Sun Sep 24 19:14:40 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 24 Sep 2017 19:14:40 +0200 Subject: [gnutls-devel] gnutls build-error with gtk-doc-tools 1.26 (gtkdoc-mktmpl is no longer available) Message-ID: <20170924171440.3vcsotldonyn5bac@argenau.bebt.de> Hello, gnutls also fails to build against gtk-doc-tools 1.26: Making all in reference make[6]: Entering directory '/build/1st/gnutls28-3.5.15/doc/reference' DOC Scanning header files DOC Rebuilding template files /bin/bash: gtkdoc-mktmpl: command not found Makefile:1671: recipe for target 'tmpl-build.stamp' failed make[6]: *** [tmpl-build.stamp] Error 127 Find attached a minimal patch to fix this (just for review, proper patch should also cleanup .gitignore). As with libtasn1 gtkdoc-check is run on make check but only displays the errors without triggering a testsuite error. This is not creative work. I have checked on which gtkdoc version the included snippets were based, noted down the differences, copied the new files and carried over gnutls' modifications. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: 35_modernize_gtkdoc.diff Type: text/x-diff Size: 18540 bytes Desc: not available URL: From nmav at gnutls.org Wed Sep 27 09:33:49 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Sep 2017 09:33:49 +0200 Subject: [gnutls-devel] gnutls build-error with gtk-doc-tools 1.26 (gtkdoc-mktmpl is no longer available) In-Reply-To: <20170924171440.3vcsotldonyn5bac@argenau.bebt.de> References: <20170924171440.3vcsotldonyn5bac@argenau.bebt.de> Message-ID: On Sun, Sep 24, 2017 at 7:14 PM, Andreas Metzler wrote: > Hello, > > gnutls also fails to build against gtk-doc-tools 1.26: > Making all in reference > make[6]: Entering directory '/build/1st/gnutls28-3.5.15/doc/reference' > DOC Scanning header files > DOC Rebuilding template files > /bin/bash: gtkdoc-mktmpl: command not found > Makefile:1671: recipe for target 'tmpl-build.stamp' failed > make[6]: *** [tmpl-build.stamp] Error 127 > > Find attached a minimal patch to fix this (just for review, proper patch > should also cleanup .gitignore). As with libtasn1 gtkdoc-check is run on > make check but only displays the errors without triggering a testsuite > error. Thank you. I've created this merge request to check it: https://gitlab.com/gnutls/gnutls/merge_requests/527 Would you like to send a patch with the Signoff-by line? > -#TESTS = $(GTKDOC_CHECK) > +TESTS = $(GTKDOC_CHECK) Would that enable tests for gtk-doc? regards, Nikos From ametzler at bebt.de Wed Sep 27 19:54:00 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 27 Sep 2017 19:54:00 +0200 Subject: [gnutls-devel] gnutls build-error with gtk-doc-tools 1.26 (gtkdoc-mktmpl is no longer available) In-Reply-To: References: <20170924171440.3vcsotldonyn5bac@argenau.bebt.de> Message-ID: <20170927175400.xsfxfjmwk3spfslk@argenau.bebt.de> On 2017-09-27 Nikos Mavrogiannopoulos wrote: > On Sun, Sep 24, 2017 at 7:14 PM, Andreas Metzler wrote: >> gnutls also fails to build against gtk-doc-tools 1.26: [...] >> Find attached a minimal patch to fix this (just for review, proper patch >> should also cleanup .gitignore). As with libtasn1 gtkdoc-check is run on >> make check but only displays the errors without triggering a testsuite >> error. > Thank you. I've created this merge request to check it: > https://gitlab.com/gnutls/gnutls/merge_requests/527 > Would you like to send a patch with the Signoff-by line? Hello, attached. >> -#TESTS = $(GTKDOC_CHECK) >> +TESTS = $(GTKDOC_CHECK) > Would that enable tests for gtk-doc? s/enable/disable/ - Yes. Find also attached a 2nd version of the patch that uses upstream gtk-doc.make unmodified (no "only displays the errors without triggering a testsuite error.") and instead disbles the check by commenting "TESTS = $(GTKDOC_CHECK)". Feel free to choose. ;-) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: Signed-off_0001-Modernize-gtk-doc-support.patch Type: text/x-diff Size: 19161 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Modernize-gtk-doc-support.patch Type: text/x-diff Size: 19010 bytes Desc: not available URL: From tim.ruehsen at gmx.de Fri Sep 29 16:11:52 2017 From: tim.ruehsen at gmx.de (=?UTF-8?Q?Tim_R=c3=bchsen?=) Date: Fri, 29 Sep 2017 16:11:52 +0200 Subject: [gnutls-devel] TLS 1.2 Session Ticket reviewed Message-ID: <7719d66b-d8f4-087e-41c7-0beca528cec2@gmx.de> Hi, here [1] is an interesting read about TLS 1.2 session tickets and why we should not use them. Not totally new, but a good summary of the status and a nice reading for anyone interested in network security. [1] https://blog.filippo.io/we-need-to-talk-about-session-tickets/ With Best Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From microhttpd at bjerkeset.com Fri Sep 29 20:47:21 2017 From: microhttpd at bjerkeset.com (Svein Olav Bjerkeset) Date: Fri, 29 Sep 2017 20:47:21 +0200 Subject: [gnutls-devel] Possible dereferencing error on pthread mutexes in 3.6.0 Message-ID: <3c97d71cf42b2d07738cbee74a498a26@bjerkeset.com> Hi, During an attempt to build libmicrohttpd on RHEL5, I tried a combination of libmicrohttpd-0.9.55 and GnuTLS 3.6.0. It consistantly core dumped with a segfault when trying to increment at mutex value (gnutls_atomic_uint_st) during https connections. The increment occurs at lib/priority.c:563: gnutls_atomic_increment(&priority->usage_cnt); Running the test https server through gdb, I find that the reason for the crash, is that pthread_mutex_lock is eventually called with a null pointer argument from gnutls_system_mutex_lock. Debuging seems to show that the mutex initialization works as intended, but not lock and unlock. Here is the backtrace: (gdb) bt #0 0x00000031c7a08dd0 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00002b9de625d2fc in gnutls_system_mutex_lock (priv=) at system/threads.c:119 #2 0x00002b9de624bd13 in gnutls_atomic_increment (session=0x13d64e20, priority=0x13d5e440) at atomic.h:58 #3 gnutls_priority_set (session=0x13d64e20, priority=0x13d5e440) at priority.c:563 #4 0x00002b9de5ffd5a0 in internal_add_connection (daemon=0x13d64bd8, client_socket=6, addr=0x2b9de88ff050, addrlen=16, external_add=false, non_blck=true) at daemon.c:2321 #5 0x00002b9de5ffdd41 in MHD_accept_connection (daemon=0x13d64bd8) at daemon.c:2953 #6 0x00002b9de5ffe1d8 in MHD_poll_all (daemon=0x13d64bd8, may_block=1) at daemon.c:3681 #7 MHD_poll (daemon=0x13d64bd8, may_block=1) at daemon.c:3786 #8 0x00002b9de5ffefae in MHD_select_thread (cls=) at daemon.c:4372 #9 0x00000031c7a0683d in start_thread () from /lib64/libpthread.so.0 #10 0x00000031c6ed4fdd in clone () from /lib64/libc.so.6 Unfortunately, I do not know the GnuTLS code, so I am not able to say where the error may be. I ended up using an older version of GnuTLS myself, but just wanted to report on my findings here. Best regards, Svein Olav Bjerkeset From n.mavrogiannopoulos at gmail.com Sat Sep 30 15:01:06 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 30 Sep 2017 15:01:06 +0200 Subject: [gnutls-devel] Possible dereferencing error on pthread mutexes in 3.6.0 In-Reply-To: <3c97d71cf42b2d07738cbee74a498a26@bjerkeset.com> References: <3c97d71cf42b2d07738cbee74a498a26@bjerkeset.com> Message-ID: <1506776466.1982.1.camel@gmail.com> On Fri, 2017-09-29 at 20:47 +0200, Svein Olav Bjerkeset wrote: > Hi, > > During an attempt to build libmicrohttpd on RHEL5, I tried a > combination? > of libmicrohttpd-0.9.55 and GnuTLS 3.6.0. It consistantly core > dumped? > with a segfault when trying to increment at mutex value? > (gnutls_atomic_uint_st) during https connections. The increment > occurs? > at lib/priority.c:563: > > gnutls_atomic_increment(&priority->usage_cnt); > > Running the test https server through gdb, I find that the reason > for? > the crash, is that pthread_mutex_lock is eventually called with a > null? > pointer argument from gnutls_system_mutex_lock. > > Debuging seems to show that the mutex initialization works as > intended,? > but not lock and unlock. Thank you. That seems to be the same case as the issue fixed by the following merge request: https://gitlab.com/gnutls/gnutls/merge_requests/491 It is triggered on older systems without atomic integers. The fix will be included in the 3.6.1 release. regards, Nikos From nmav at gnutls.org Sat Sep 30 16:08:36 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Sep 2017 16:08:36 +0200 Subject: [gnutls-devel] TLS 1.2 Session Ticket reviewed In-Reply-To: <7719d66b-d8f4-087e-41c7-0beca528cec2@gmx.de> References: <7719d66b-d8f4-087e-41c7-0beca528cec2@gmx.de> Message-ID: <1506780516.1982.3.camel@gnutls.org> On Fri, 2017-09-29 at 16:11 +0200, Tim R?hsen wrote: > Hi, > > here [1] is an interesting read about TLS 1.2 session tickets and why > we > should not use them. Not totally new, but a good summary of the > status > and a nice reading for anyone interested in network security. > > > [1] https://blog.filippo.io/we-need-to-talk-about-session-tickets/ That's a very nice write-up and kind of underlines the importance of session key rotation suggested by Daniel [0]. Although TLS 1.3 is coming, we will have to live with TLS 1.2 for at least a decade. That post also stresses the importance of forward secrecy, which few years ago would have completely agreed with. However, in the long run, sessions which use forward secrecy with elliptic curves today, will be attacked more effectively by quantum computers as opposed to pure pre- shared keys. Nevertheless, that's the long run, and as they say, we all die in the long run. regarsd, Nikos [0]. https://gitlab.com/gnutls/gnutls/issues/184