From n.mavrogiannopoulos at gmail.com Fri Jun 2 11:56:45 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 2 Jun 2017 11:56:45 +0200 Subject: [gnutls-devel] DER decoding errors due to time format In-Reply-To: References: <20170509184709.idwqqb3nmccrclmb@roeckx.be> <20170511164631.d7v7i7nmjg5yt5cc@roeckx.be> Message-ID: On Wed, May 31, 2017 at 9:37 AM, Tim R?hsen wrote: >>> >>> And today someone filed this in Debian: >>> https://bugs.debian.org/862335 >> >> I have a patch set which will tolerate incorrectly formatted dates to >> work around these issues in openssl: >> https://gitlab.com/gnutls/gnutls/merge_requests/400 >> >> I am still not sure that tolerating invalid formatted data is a good >> thing, however, in case of infrastructure already deployed based on >> openssl tools, there is not much an administrator/user can do. What >> I'm thinking to do is set a cut-off date after which the original >> strict behavior will be re-instated, though I cannot see how would >> that help eliminating that issue. > > OpenSSL just 'allows' an invalid format, it's not really buggy (at least > not 1.1.1-dev, maybe older versions !?). The question is how many public > deployments are really affected, e.g. how many of the top 1M sites use > certs with invalid dates ? I guess none. My concern are the non-public deployments. E.g., imagine a custom CA infrastructure used to authenticate mobile applications or things like that. These may have had a timezone included in the date which renders the certificate invalid, meaning no gnutls application could be used with that PKI. regards, Nikos From n.mavrogiannopoulos at gmail.com Tue Jun 6 18:21:24 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 6 Jun 2017 18:21:24 +0200 Subject: [gnutls-devel] removing compression Message-ID: Hi, As I dig into TLS 1.3 support where compression is no longer supported, I realized that keeping compression for TLS 1.2 or earlier would only cause problems by making complex code even more complicated. As TLS compression is already considered insecure, I would like to drop that support completely (an MR is at [0]), unless there are serious objections. If none, I'll merge that removal by the end of this month. [0]. https://gitlab.com/gnutls/gnutls/merge_requests/408 regards, Nikos From nmav at gnutls.org Wed Jun 7 07:47:48 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 07 Jun 2017 07:47:48 +0200 Subject: [gnutls-devel] gnutls 3.5.13 Message-ID: <1496814468.4884.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.13. This is a bug fix release on the 3.5.x branch. * Version 3.5.13 (released 2017-06-07) ** libgnutls: fixed issue with AES-GCM in-place encryption and decryption in ???aarch64. Resolves gitlab issue #204. ** libgnutls: no longer parse the ResponseID field of the status response ???TLS extension. The field is not used by GnuTLS nor is made available to ???calling applications. That addresses a null pointer dereference on server ???side caused by packets containing the ResponseID field. Reported ???by Hubert Kario. [GNUTLS-SA-2017-4] ** libgnutls: tolerate certificates which do not have strict DER time encoding. ???It is possible using 3rd party tools to generate certificates with time fields ???that do not conform to DER requirements. Since 3.4.x these certificates were rejected ???and cannot be used with GnuTLS, however that caused problems with existing private ???certificate infrastructures, which were relying on such certificates (see gitlab ???issue #196). Tolerate reading and using these certificates. ** minitasn1: updated to libtasn1 4.11. ** certtool: allow multiple certificates to be used in --p7-sign with ???the --load-certificate option. Patch by Karl Tarbe. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.13.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.13.tar.xz.sig Note that it has been signed with my openpgp key: pub???3104R/96865171 2008-05-04 [expires: 2028-04-29] uid??????????????????Nikos Mavrogiannopoulos gnutls.org> uid??????????????????Nikos Mavrogiannopoulos gmail.com> sub???2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub???2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From dkg at fifthhorseman.net Wed Jun 7 16:17:21 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 Jun 2017 10:17:21 -0400 Subject: [gnutls-devel] removing compression In-Reply-To: References: Message-ID: <87bmpzc26m.fsf@fifthhorseman.net> On Tue 2017-06-06 18:21:24 +0200, Nikos Mavrogiannopoulos wrote: > As I dig into TLS 1.3 support where compression is no longer > supported, I realized that keeping compression for TLS 1.2 or earlier > would only cause problems by making complex code even more > complicated. As TLS compression is already considered insecure, I > would like to drop that support completely (an MR is at [0]), unless > there are serious objections. If none, I'll merge that removal by the > end of this month. I support this change. Application protocols that want to compress can do it in the application layer, where they have some hope of avoiding compression that mixes untrusted data with trusted data (see the recent work on improving NNTP over TLS). Uniform compression over the entire stream just doesn't make sense from a security standpoint, and it makes for a security toolkit to put that kind of footgun out of reach of casual users. Thanks for making this change, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From home_pw at msn.com Wed Jun 7 19:27:19 2017 From: home_pw at msn.com (Peter Williams) Date: Wed, 7 Jun 2017 17:27:19 +0000 Subject: [gnutls-devel] removing compression In-Reply-To: <87bmpzc26m.fsf@fifthhorseman.net> References: , <87bmpzc26m.fsf@fifthhorseman.net> Message-ID: Ssl record layer has no notion of trusted and trusted payloads. The cipher suite controlling which security services are applied to which payload is given an implied security label , which implicitely tags the resultant bytes. The label is a function of the labels within the end point certs (and their chains). This has not changed since ssl v3, and its fortezza support (fortezza certs has securty labels in the public key byte block). In a military datacenter that strips the tls at a front end processor, the (recomputed) tag (from the coearyext handshake) indicates which vlan (segmented trust level) the payloads may travel, now as TCP fragment. On the vlan, per vlan security services are applied including the mac-layer equivalent of ipsec packet tagging of the security label. Per vlan encryption and compression may be applied. The stuff about compression is a red herring. That security services bundled as assurance classes of cipher suites must be properly be tied to their intended operating theatre (web vs the stuff above) is obvious. Sent from my iPhone > On Jun 7, 2017, at 7:36 AM, Daniel Kahn Gillmor wrote: > >> On Tue 2017-06-06 18:21:24 +0200, Nikos Mavrogiannopoulos wrote: >> As I dig into TLS 1.3 support where compression is no longer >> supported, I realized that keeping compression for TLS 1.2 or earlier >> would only cause problems by making complex code even more >> complicated. As TLS compression is already considered insecure, I >> would like to drop that support completely (an MR is at [0]), unless >> there are serious objections. If none, I'll merge that removal by the >> end of this month. > > I support this change. Application protocols that want to compress can > do it in the application layer, where they have some hope of avoiding > compression that mixes untrusted data with trusted data (see the recent > work on improving NNTP over TLS). Uniform compression over the entire > stream just doesn't make sense from a security standpoint, and it makes > for a security toolkit to put that kind of footgun out of reach of > casual users. > > Thanks for making this change, > > --dkg > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From dkg at fifthhorseman.net Thu Jun 8 20:11:51 2017 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 08 Jun 2017 14:11:51 -0400 Subject: [gnutls-devel] gnutls ASSERT lines even when not using TLS on knot-resolver Message-ID: <87wp8mpcwo.fsf@fifthhorseman.net> Hi GnuTLS folks-- Over on: https://gitlab.labs.nic.cz/knot/resolver/merge_requests/287#note_48109 Vladim?r ?un?t (cc'ed here) reports that the following log messages appear even when knot-resolver isn't listening on TLS: [tls] gnutls: (3) ASSERT: pk.c[_wrap_nettle_pk_verify]:750 [tls] gnutls: (3) ASSERT: pubkey.c[pubkey_verify_hashed_data]:1913 Presumably this has to do with the fact that knot-resolver is using nettle to do DNSSEC verification, but i don't understand the linkage between GnuTLS and nettle well enough to know why this would be happening just because the gnutls logging function is set. Any ideas about how to explain this? Regards, --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 Sat Jun 10 11:26:48 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Jun 2017 11:26:48 +0200 Subject: [gnutls-devel] gnutls ASSERT lines even when not using TLS on knot-resolver In-Reply-To: <87wp8mpcwo.fsf@fifthhorseman.net> References: <87wp8mpcwo.fsf@fifthhorseman.net> Message-ID: On Thu, Jun 8, 2017 at 8:11 PM, Daniel Kahn Gillmor wrote: > Hi GnuTLS folks-- > > Over on: > > https://gitlab.labs.nic.cz/knot/resolver/merge_requests/287#note_48109 > > Vladim?r ?un?t (cc'ed here) reports that the following log messages > appear even when knot-resolver isn't listening on TLS: > > [tls] gnutls: (3) ASSERT: pk.c[_wrap_nettle_pk_verify]:750 > [tls] gnutls: (3) ASSERT: pubkey.c[pubkey_verify_hashed_data]:1913 > > Presumably this has to do with the fact that knot-resolver is using > nettle to do DNSSEC verification, but i don't understand the linkage > between GnuTLS and nettle well enough to know why this would be > happening just because the gnutls logging function is set. My guess is that it uses the gnutls signing/verification functions rather than nettle directly. The knot developers may be in better position to answer that. regards, Nikos From nmav at gnutls.org Sun Jun 11 08:48:25 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 11 Jun 2017 08:48:25 +0200 Subject: [gnutls-devel] gnutls ASSERT lines even when not using TLS on knot-resolver In-Reply-To: <0feb6755-1490-bba7-f99a-8d4d5b5fb2fa@nic.cz> References: <87wp8mpcwo.fsf@fifthhorseman.net> <0feb6755-1490-bba7-f99a-8d4d5b5fb2fa@nic.cz> Message-ID: On Sat, Jun 10, 2017 at 11:58 AM, Vladim?r ?un?t wrote: > On 06/10/2017 11:26 AM, Nikos Mavrogiannopoulos wrote: > > On Thu, Jun 8, 2017 at 8:11 PM, Daniel Kahn Gillmor > wrote: > > [tls] gnutls: (3) ASSERT: pk.c[_wrap_nettle_pk_verify]:750 > [tls] gnutls: (3) ASSERT: pubkey.c[pubkey_verify_hashed_data]:1913 > > Presumably this has to do with the fact that knot-resolver is using > nettle to do DNSSEC verification, but i don't understand the linkage > between GnuTLS and nettle well enough to know why this would be > happening just because the gnutls logging function is set. > > My guess is that it uses the gnutls signing/verification functions > rather than nettle directly. The knot developers may be in better > position to answer that. > > Right, I didn't realize that gnutls is used indirectly for DNSSEC stuff > (through libdnssec), so we started catching messages from more than just > TLS. > > Still, how can I/we check if such assertion messages mean anything "wrong" > is happening? I can't see any pointers in the documentation around > http://gnutls.org/manual/gnutls.html#Debugging-and-auditing Only the messages through the audit interface may indicate something wrong. Everything else is debugging information to assist when something goes wrong. regards, Nikos From ametzler at bebt.de Sun Jun 11 11:43:49 2017 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 11 Jun 2017 11:43:49 +0200 Subject: [gnutls-devel] GNUTLS-SA-2017-4 (was: gnutls 3.5.13) In-Reply-To: <1496814468.4884.1.camel@gnutls.org> References: <1496814468.4884.1.camel@gnutls.org> Message-ID: <20170611094349.ibltjfztj7aoqn5i@argenau.bebt.de> On 2017-06-07 Nikos Mavrogiannopoulos wrote: > Hello,? > ?I've just released gnutls 3.5.13. This is a bug fix release on the > 3.5.x branch. [...] > ** libgnutls: no longer parse the ResponseID field of the status response > ???TLS extension. The field is not used by GnuTLS nor is made available to > ???calling applications. That addresses a null pointer dereference on server > ???side caused by packets containing the ResponseID field. Reported > ???by Hubert Kario. [GNUTLS-SA-2017-4] [...] Hello, do you know to which versions of GnuTLS this applies? Afaict it seems to apply to 3.3.8, too. TIA 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' From nmav at gnutls.org Sun Jun 11 16:27:15 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 11 Jun 2017 16:27:15 +0200 Subject: [gnutls-devel] GNUTLS-SA-2017-4 (was: gnutls 3.5.13) In-Reply-To: <20170611094349.ibltjfztj7aoqn5i@argenau.bebt.de> References: <1496814468.4884.1.camel@gnutls.org> <20170611094349.ibltjfztj7aoqn5i@argenau.bebt.de> Message-ID: <1497191235.2058.1.camel@gnutls.org> On Sun, 2017-06-11 at 11:43 +0200, Andreas Metzler wrote: > On 2017-06-07 Nikos Mavrogiannopoulos wrote: > > Hello,? > > ?I've just released gnutls 3.5.13. This is a bug fix release on the > > 3.5.x branch. > > [...] > > ** libgnutls: no longer parse the ResponseID field of the status > > response > > ???TLS extension. The field is not used by GnuTLS nor is made > > available to > > ???calling applications. That addresses a null pointer dereference > > on server > > ???side caused by packets containing the ResponseID field. Reported > > ???by Hubert Kario. [GNUTLS-SA-2017-4] > > [...] > > Hello, > > do you know to which versions of GnuTLS this applies? Afaict it seems > to apply to 3.3.8, too. Hi, It certainly applies to 3.3.x branch; I have not investigated other versions (though 2.12.x are not vulnerable as this extension is not supported). There is a patch on the 3.3.x branch for it. regards, Nikos From n.mavrogiannopoulos at gmail.com Thu Jun 22 15:53:50 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 22 Jun 2017 15:53:50 +0200 Subject: [gnutls-devel] removing compression In-Reply-To: References: Message-ID: On Tue, Jun 6, 2017 at 6:21 PM, Nikos Mavrogiannopoulos wrote: > Hi, > As I dig into TLS 1.3 support where compression is no longer > supported, I realized that keeping compression for TLS 1.2 or earlier > would only cause problems by making complex code even more > complicated. As TLS compression is already considered insecure, I > would like to drop that support completely (an MR is at [0]), unless > there are serious objections. If none, I'll merge that removal by the > end of this month. > > [0]. https://gitlab.com/gnutls/gnutls/merge_requests/408 Merged. From tim.kosse at filezilla-project.org Mon Jun 26 22:15:39 2017 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Mon, 26 Jun 2017 22:15:39 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension Message-ID: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> Hi, I've recently been made aware of a problem [1][2] connecting the FileZilla FTP client (linked against GnuTLS 3.5.13) to a recent ProFTPD server (linked against OpenSSL). To prevent data connection theft, FTP over TLS has to rely [3] on TLS session resumption for the data connection. If using a certificate that has the status_request tlsfeatures X.509 certificate extension [4] ("OCSP must staple"), any handshakes using TLS session resumption fail with GNUTLS_CERT_MISSING_OCSP_STATUS. Unfortunately it looks like an oversight of RFC7633, it does not specify how must-staple interacts with resumed session. I'm not quite sure who who's at fault here and where to implement a fix: GnuTLS or OpenSSL/ProFTPD? Regarding GnuTLS: If using a resumed session, assuming the program using GnuTLS did not deliberately ignore verification errors on the initial handshake, we know that the initial session already had a properly stapled OCSP response. Would it be feasible to just ignore a missing OCSP response in resumed sessions? Regarding the latter: Do the TLS specifications allow for a CertificateStatus handshake packet to be sent in a resumed session? If so, I think this issue is something TJ needs to investigate further in ProFTPD, possibly escalating it as OpenSSL bug. Regards, Tim [1] https://forum.filezilla-project.org/viewtopic.php?t=45684 [2] https://forums.proftpd.org/smf/index.php/topic,12187.0/all.html [3] https://forum.filezilla-project.org/viewtopic.php?p=137191#p137191 [4] https://tools.ietf.org/html/rfc7633 From tim.kosse at filezilla-project.org Tue Jun 27 08:52:51 2017 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Tue, 27 Jun 2017 08:52:51 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> Message-ID: Hi TJ, On 27.06.2017 08:37, TJ Saunders wrote: > Not all FTP servers require session resumption for their data > connections, so to be thorough, I assume FileZilla would want to ensure > that the TLS session for the data connection was indeed resumed, before > going on to ignore a missing OCSP response for that resumed TLS session? Correct, ignoring the missing OCSP response on a non-resumed session would be a really bad idea. > There *is* a ProFTPD (or rather, an OpenSSL) bug, for which I've filed > this ticket: > > https://github.com/proftpd/proftpd/issues/528 > > The above specifically cites text from RFC 6066, which covers dealing > with TLS extensions and resumed sessions. That text, fortunately, > covers the case of the "status_request" extension; it does not, sadly, > also cover the case of the "must-staple" X509v3 extension. Thanks for linking this issue. I'm not sure your conclusion to not staple the OCSP response is quite correct, note RFC 6606 saying "In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session." The way I understand it, the server, even though replying with empty extensions on server hello, must otherwise behave as if the extensions were initially negotiated and thus the CertficateStatus handshake packet should be sent. Regards, Tim From tj at castaglia.org Tue Jun 27 09:05:52 2017 From: tj at castaglia.org (TJ Saunders) Date: Tue, 27 Jun 2017 00:05:52 -0700 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> Message-ID: <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> > I'm not sure your conclusion to not staple the OCSP response is quite > correct, note RFC 6606 saying "In this case, the > functionality of these extensions negotiated during the original > session initiation is applied to the resumed session." > > The way I understand it, the server, even though replying with empty > extensions on server hello, must otherwise behave as if the extensions > were initially negotiated and thus the CertficateStatus handshake packet > should be sent. My understanding is based on this sentence in that section 1.1 portion of RFC 6066: "If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types." To me, this means that if the session is resumed, then the extensions _in the ClientHello_ (including the status_request extension) are to be ignored. And if that client-sent extension is ignored, then this text, from Section 8, becomes relevant, I think: "Note in addition that a server MUST NOT send the "CertificateStatus" message unless it received a "status_request" extension in the client hello message and sent a "status_request" extension in the server hello message. If the "status_request" extension in the ClientHello is to be ignored for resumed sessions, and we should send a ServerHello with none of the extensions, then we cannot send a stapled OCSP response. Cheers, TJ From a at juaristi.eus Tue Jun 27 09:13:28 2017 From: a at juaristi.eus (Ander Juaristi) Date: Tue, 27 Jun 2017 09:13:28 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> Message-ID: On 27/06/17 09:05, TJ Saunders wrote: > >> I'm not sure your conclusion to not staple the OCSP response is quite >> correct, note RFC 6606 saying "In this case, the >> functionality of these extensions negotiated during the original >> session initiation is applied to the resumed session." >> >> The way I understand it, the server, even though replying with empty >> extensions on server hello, must otherwise behave as if the extensions >> were initially negotiated and thus the CertficateStatus handshake packet >> should be sent. > > My understanding is based on this sentence in that section 1.1 portion > of RFC 6066: > > "If, on the other hand, the older session is resumed, then the server > MUST ignore the extensions and send a server hello containing none of > the extension types." > > To me, this means that if the session is resumed, then the extensions > _in the ClientHello_ (including the status_request extension) are to be > ignored. And if that client-sent extension is ignored, then this text, > from Section 8, becomes relevant, I think: > > "Note in addition that a server MUST NOT send the "CertificateStatus" > message unless it received a "status_request" extension in the client > hello message and sent a "status_request" extension in the server > hello message. > > If the "status_request" extension in the ClientHello is to be ignored > for resumed sessions, and we should send a ServerHello with none of the > extensions, then we cannot send a stapled OCSP response. > If things are this way then (and I understand this might not be a GnuTLS-specific issue, but just popped out from my head), what happens if the certificate has been revoked in the time span between the initial session establishment and the later resumption? The client can check that by sending a "normal" OCSP status request, but would lose the benefit of stapled OCSP? > Cheers, > TJ > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel > From stbuehler at lighttpd.net Tue Jun 27 10:11:52 2017 From: stbuehler at lighttpd.net (=?UTF-8?Q?Stefan_B=c3=bchler?=) Date: Tue, 27 Jun 2017 10:11:52 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> Message-ID: Hi, On 06/27/2017 09:05 AM, TJ Saunders wrote: > >> I'm not sure your conclusion to not staple the OCSP response is quite >> correct, note RFC 6606 saying "In this case, the >> functionality of these extensions negotiated during the original >> session initiation is applied to the resumed session." >> >> The way I understand it, the server, even though replying with empty >> extensions on server hello, must otherwise behave as if the extensions >> were initially negotiated and thus the CertficateStatus handshake packet >> should be sent. > > My understanding is based on this sentence in that section 1.1 portion > of RFC 6066: > > "If, on the other hand, the older session is resumed, then the server > MUST ignore the extensions and send a server hello containing none of > the extension types." > > To me, this means that if the session is resumed, then the extensions > _in the ClientHello_ (including the status_request extension) are to be > ignored. And if that client-sent extension is ignored, then this text, > from Section 8, becomes relevant, I think: > > "Note in addition that a server MUST NOT send the "CertificateStatus" > message unless it received a "status_request" extension in the client > hello message and sent a "status_request" extension in the server > hello message. > > If the "status_request" extension in the ClientHello is to be ignored > for resumed sessions, and we should send a ServerHello with none of the > extensions, then we cannot send a stapled OCSP response. I think "negotiated extensions" includes the extensions sent in the ServerHello in the original session initiation. If you sent a status_request extension back then, the functionality applies to the current session, which allows sending a stapled OCSP response. cheers, Stefan From tj at castaglia.org Tue Jun 27 17:19:10 2017 From: tj at castaglia.org (TJ Saunders) Date: Tue, 27 Jun 2017 08:19:10 -0700 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> Message-ID: <1498576750.3459984.1022946472.4F87C133@webmail.messagingengine.com> > > To me, this means that if the session is resumed, then the extensions > > _in the ClientHello_ (including the status_request extension) are to be > > ignored. And if that client-sent extension is ignored, then this text, > > from Section 8, becomes relevant, I think: > > > > "Note in addition that a server MUST NOT send the "CertificateStatus" > > message unless it received a "status_request" extension in the client > > hello message and sent a "status_request" extension in the server > > hello message. > > > > If the "status_request" extension in the ClientHello is to be ignored > > for resumed sessions, and we should send a ServerHello with none of the > > extensions, then we cannot send a stapled OCSP response. > > > > If things are this way then (and I understand this might not be a > GnuTLS-specific issue, but just popped out from my head), what happens if > the certificate has been revoked in the time span between the initial session > establishment and the later resumption? > > The client can check that by sending a "normal" OCSP status request, but > would lose the benefit of stapled OCSP? Or, if the client was wary of such an occurrence, it would simply not offer the session ID (or session ticket) in its ClientHello, thus preventing the possibly of a resumed session and forcing a full handshake, with its stapled OCSP response. Another refinement would be for that client, if it sees a session resumed "too many times" (determined by that client implementation/configuration), to then connect to the server without session ID or ticket, requesting the stapled OCSP response -- this way the client would get most of the benefit of session resumption, and the benefit of OCSP stapling, with a way to "double check" that certificate validation in the face of resumed sessions. Since the session resumption timing is ultimately left up to the server, and that timing is not conveyed back to the client, it is something of a question of trust. Does the client trust the server to implement an "acceptable" (for whatever that means) policy of session caching? If so, then it should trust the resumed session without its stapled OCSP response. If not, then perhaps that client should not be connecting to the server at all. Cheers, TJ From tj at castaglia.org Tue Jun 27 17:22:04 2017 From: tj at castaglia.org (TJ Saunders) Date: Tue, 27 Jun 2017 08:22:04 -0700 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> Message-ID: <1498576924.3460457.1022953248.57E33D18@webmail.messagingengine.com> > > My understanding is based on this sentence in that section 1.1 portion > > of RFC 6066: > > > > "If, on the other hand, the older session is resumed, then the server > > MUST ignore the extensions and send a server hello containing none of > > the extension types." > > > > To me, this means that if the session is resumed, then the extensions > > _in the ClientHello_ (including the status_request extension) are to be > > ignored. And if that client-sent extension is ignored, then this text, > > from Section 8, becomes relevant, I think: > > > > "Note in addition that a server MUST NOT send the "CertificateStatus" > > message unless it received a "status_request" extension in the client > > hello message and sent a "status_request" extension in the server > > hello message. > > > > If the "status_request" extension in the ClientHello is to be ignored > > for resumed sessions, and we should send a ServerHello with none of the > > extensions, then we cannot send a stapled OCSP response. > > I think "negotiated extensions" includes the extensions sent in the > ServerHello in the original session initiation. If you sent a > status_request extension back then, the functionality applies to the > current session, which allows sending a stapled OCSP response. If we are to ignore the ClientHello extensions for a resumed session, then we would not send the stapled OCSP response. The RFC 6066 Section 1.1 text, in my reading, says that the ServerHello emitted by the TLS server, for a resumed session, MUST NOT contain any of the TLS extensions -- and this would include the stapled OCSP response. That is, the ServerHello of the resumed session must be different; it is not described as being a "replay" of the original ServerHello. Cheers, TJ From tj at castaglia.org Tue Jun 27 19:40:48 2017 From: tj at castaglia.org (TJ Saunders) Date: Tue, 27 Jun 2017 10:40:48 -0700 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> Message-ID: <1498585248.365745.1023113512.382403D3@webmail.messagingengine.com> > On 27.06.2017 08:37, TJ Saunders wrote: > > Not all FTP servers require session resumption for their data > > connections, so to be thorough, I assume FileZilla would want to ensure > > that the TLS session for the data connection was indeed resumed, before > > going on to ignore a missing OCSP response for that resumed TLS session? > > Correct, ignoring the missing OCSP response on a non-resumed session > would be a really bad idea. Also, on the topic of how a client might handle the case where the TLS session is resumed, and the server certificate bears the "must staple" X509v3 extension, I think Section 4.2.3.1 of RFC 7633 is relevant: https://tools.ietf.org/html/rfc7633#section-4.2.3.1 Specifically: "A client MAY accept a TLS configuration despite it being inconsistent with the TLS feature declaration if the validity of the certificate chain presented can be established through other means (for example, by successfully obtaining the OCSP data from another source)." If the server does not provide the stapled OCSP response in the resumed session (per RFC 6066), and the server certificate contains that "must staple" X509v3 extension, then the client might choose to accept the handshake anyway -- on the _assumption_ that the client did already verify that a stapled OCSP response was provided as part of another source -- the original TLS handshake. Cheers, TJ From tim.kosse at filezilla-project.org Tue Jun 27 20:07:26 2017 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Tue, 27 Jun 2017 20:07:26 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: <1498576924.3460457.1022953248.57E33D18@webmail.messagingengine.com> References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> <1498576924.3460457.1022953248.57E33D18@webmail.messagingengine.com> Message-ID: <630a96fa-5a08-adc9-1a1a-30c40ef2f718@filezilla-project.org> Hi, On 2017-06-27 17:22, TJ Saunders wrote: > If we are to ignore the ClientHello extensions for a resumed session, > then we would not send the stapled OCSP response. The RFC 6066 Section > 1.1 text, in my reading, says that the ServerHello emitted by the TLS > server, for a resumed session, MUST NOT contain any of the TLS > extensions -- and this would include the stapled OCSP response. That > is, the ServerHello of the resumed session must be different; it is not > described as being a "replay" of the original ServerHello. The stapled OCSP reponse is sent in a separate CertificateStatus handshake packet, it is not part even part of the ServerHello. Regards, Tim From tj at castaglia.org Wed Jun 28 01:43:00 2017 From: tj at castaglia.org (TJ Saunders) Date: Tue, 27 Jun 2017 16:43:00 -0700 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: <630a96fa-5a08-adc9-1a1a-30c40ef2f718@filezilla-project.org> References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> <1498576924.3460457.1022953248.57E33D18@webmail.messagingengine.com> <630a96fa-5a08-adc9-1a1a-30c40ef2f718@filezilla-project.org> Message-ID: <1498606980.437901.1023459648.6B0D68A8@webmail.messagingengine.com> > > If we are to ignore the ClientHello extensions for a resumed session, > > then we would not send the stapled OCSP response. The RFC 6066 Section > > 1.1 text, in my reading, says that the ServerHello emitted by the TLS > > server, for a resumed session, MUST NOT contain any of the TLS > > extensions -- and this would include the stapled OCSP response. That > > is, the ServerHello of the resumed session must be different; it is not > > described as being a "replay" of the original ServerHello. > > The stapled OCSP reponse is sent in a separate CertificateStatus > handshake packet, it is not part even part of the ServerHello. True, but if we are not to include the "status_request" extension in the ServerHello (because we are ignoring the "status_request" extension in the ClientHello, because it's a resumed session), then we should not send the CertificateStatus message; the client would not know to look for a CertificateStatus message unless there is also the "status_request" extension in the ServerHello. Cheers, TJ From tim.kosse at filezilla-project.org Wed Jun 28 09:11:00 2017 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Wed, 28 Jun 2017 09:11:00 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: <1498606980.437901.1023459648.6B0D68A8@webmail.messagingengine.com> References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> <1498576924.3460457.1022953248.57E33D18@webmail.messagingengine.com> <630a96fa-5a08-adc9-1a1a-30c40ef2f718@filezilla-project.org> <1498606980.437901.1023459648.6B0D68A8@webmail.messagingengine.com> Message-ID: Hi, On 2017-06-28 01:43, TJ Saunders wrote: > True, but if we are not to include the "status_request" extension in the > ServerHello (because we are ignoring the "status_request" extension in > the ClientHello, because it's a resumed session), Correct so far. > then we should not > send the CertificateStatus message; the client would not know to look > for a CertificateStatus message unless there is also the > "status_request" extension in the ServerHello. The server must use the ServerHello (and thus the ClientHello) of the original handshake as reference for the extensions: "In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session." During the initial handshake, both ClientHello and ServerHello contained the status_request extension, so the client is prepared to receive a CertificateStatus. There is an example for a different extension in RFC 6066, see the description of the "truncated_hmac" extension in chapter 7, at the end it says "The negotiated HMAC truncation size applies for the duration of the session including session resumptions". Even though the ServerHello of a resumed session does not include "truncated_hmac" the HMACs would still be truncated if they originally were. It's not stated explicitly in the RFC, but it follows for the client that the contents of the extensions list in the ServerHello of the resumed handshake are to be ignored, with the client having to use the extensions negotiated with the original ServerHello. This From tim.kosse at filezilla-project.org Wed Jun 28 09:28:35 2017 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Wed, 28 Jun 2017 09:28:35 +0200 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> Message-ID: Hi, On 2017-06-27 09:13, Ander Juaristi wrote:> what happens if the> certificate has been revoked in the time span between the initial session> establishment and the later resumption?> > The client can check that by sending a "normal" OCSP status request, but would> lose the benefit of stapled OCSP? It's not much of a deal. On a non-resumed handshake the server can still use the revoked certificate for a while if it keeps stapling the old OCSP response until it expires. Regards, Tim From tj at castaglia.org Wed Jun 28 18:46:26 2017 From: tj at castaglia.org (TJ Saunders) Date: Wed, 28 Jun 2017 09:46:26 -0700 Subject: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension In-Reply-To: References: <4d19d941-b5c3-078d-b11d-c22ec2ba9091@filezilla-project.org> <1498545444.2586965.1022439232.4FCAC2BF@webmail.messagingengine.com> <1498547152.2592804.1022456072.51B54AE1@webmail.messagingengine.com> <1498576924.3460457.1022953248.57E33D18@webmail.messagingengine.com> <630a96fa-5a08-adc9-1a1a-30c40ef2f718@filezilla-project.org> <1498606980.437901.1023459648.6B0D68A8@webmail.messagingengine.com> Message-ID: <1498668386.2068693.1024296376.4EA22D85@webmail.messagingengine.com> > > then we should not > > send the CertificateStatus message; the client would not know to look > > for a CertificateStatus message unless there is also the > > "status_request" extension in the ServerHello. > > The server must use the ServerHello (and thus the ClientHello) of the > original handshake as reference for the extensions: > > "In this case, the functionality of these extensions negotiated during > the original session initiation is applied to the resumed session." > > During the initial handshake, both ClientHello and ServerHello contained > the status_request extension, so the client is prepared to receive a > CertificateStatus. That is one interpretation, but not the only interpretation; "the functionality of these extensions" is vague when applied in the context of what happens during the handshake exchange itself. > It's not stated explicitly in the RFC, but it follows for the client > that the contents of the extensions list in the ServerHello of the > resumed handshake are to be ignored, with the client having to use the > extensions negotiated with the original ServerHello. That is one possible reading, yes. But not the only possible reading. YMMV. It would be interesting to survey existing TLS client implementations to see how many (if they even implement code for these edge cases being discussed) do that, and how many not. Since it is not explicitly stated in the RFC, we are in the area of "undefined behavior". Cheers, TJ