From ametzler at bebt.de Tue Nov 1 14:39:46 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Tue, 1 Nov 2016 14:39:46 +0100 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: References: Message-ID: <20161101133946.6zmarwxwnwxgwaqh@argenau.bebt.de> On 2016-10-31 Nikos Mavrogiannopoulos wrote: > Since version 3.5.3, gnutls uses the getrandom() system call on the > kernels that it is available, replacing the /dev/urandom based > initialization of the included RNG. However, that comes with few > side-effects. Because getrandom() blocks prior to the linux kernel RNG > being initialized (unlike /dev/urandom), that means that applications > that load early on boot and link with gnutls will be blocked until > that kernel initialization. > This has been already been seen in VMs, on the cases linked by [0]. A > work-around that can be applied to gnutls is delaying the internal RNG > initialization to the first call of gnutls_rnd(). That will allow > applications which do not use the RNG immediately to load faster, > while on the other hand introduces some complexity and does not > address the problem when for example the system is in FIPS140-2 mode > which requires some on-library-load tests which need to call > gnutls_rnd(). -(here I'm also worried about future additions that may > require random numbers on library load and negate any fixes for that > issue). > Any opinions on that? The bottom line, is that we cannot completely > solve the blocking issue, but we can improve it on the occasions > mentioned above. Should we try and introduce some complexity, or > should we ignore it and expect the kernel to address it? [...] Hello, I can certainly understand the problem. GnuTLS is automatically initialized through the library constructor at program startup. This might not even be necessary, the program might run without using GnuTLS functions ATM, or might just be an indirect dependency (e.g. cups). In these use cases GnuTLS should not waste a possible rare resource like entropy. So I would throw in a small unqualified vote for the split. 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 luto at amacapital.net Tue Nov 1 14:58:39 2016 From: luto at amacapital.net (Andy Lutomirski) Date: Tue, 1 Nov 2016 06:58:39 -0700 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: References: Message-ID: On Oct 31, 2016 2:34 AM, "Nikos Mavrogiannopoulos" < n.mavrogiannopoulos at gmail.com> wrote: > > Hi, > Since version 3.5.3, gnutls uses the getrandom() system call on the > kernels that it is available, replacing the /dev/urandom based > initialization of the included RNG. However, that comes with few > side-effects. Because getrandom() blocks prior to the linux kernel RNG > being initialized (unlike /dev/urandom), that means that applications > that load early on boot and link with gnutls will be blocked until > that kernel initialization. > > This has been already been seen in VMs, on the cases linked by [0]. A > work-around that can be applied to gnutls is delaying the internal RNG > initialization to the first call of gnutls_rnd(). That will allow > applications which do not use the RNG immediately to load faster, > while on the other hand introduces some complexity and does not > address the problem when for example the system is in FIPS140-2 mode > which requires some on-library-load tests which need to call > gnutls_rnd(). -(here I'm also worried about future additions that may > require random numbers on library load and negate any fixes for that > issue). I say delay initialization for reasons that have nothing to do with blocking: when you initialize early, the kernel is telling you that your seed may be predictable. So re-seeding later on is more secure. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Tue Nov 1 16:45:58 2016 From: jgh at wizmail.org (Jeremy Harris) Date: Tue, 1 Nov 2016 15:45:58 +0000 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: <20161101133946.6zmarwxwnwxgwaqh@argenau.bebt.de> References: <20161101133946.6zmarwxwnwxgwaqh@argenau.bebt.de> Message-ID: <038f7fb8-7a9d-57c3-7019-a3fc0bd97445@wizmail.org> On 01/11/16 13:39, Andreas Metzler wrote: > I can certainly understand the problem. GnuTLS is automatically > initialized through the library constructor at program startup. This > might not even be necessary, the program might run without using GnuTLS > functions Should application devs be encouraged to use dlopen()? Would that work with GnuTLS specifically? -- Cheers, Jeremy From nmav at gnutls.org Wed Nov 2 08:54:18 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 2 Nov 2016 08:54:18 +0100 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: <20161101133946.6zmarwxwnwxgwaqh@argenau.bebt.de> References: <20161101133946.6zmarwxwnwxgwaqh@argenau.bebt.de> Message-ID: On Tue, Nov 1, 2016 at 2:39 PM, Andreas Metzler wrote: >> Any opinions on that? The bottom line, is that we cannot completely >> solve the blocking issue, but we can improve it on the occasions >> mentioned above. Should we try and introduce some complexity, or >> should we ignore it and expect the kernel to address it? > I can certainly understand the problem. GnuTLS is automatically > initialized through the library constructor at program startup. This > might not even be necessary, the program might run without using GnuTLS > functions ATM, or might just be an indirect dependency (e.g. cups). In > these use cases GnuTLS should not waste a possible rare resource like > entropy. Well strictly speaking, with getrandom() there is no issue of "depleting" entropy (it is a cprng, it will provide as much data as asked). The issue is that the system can boot without it being initialized, and thus a call to it will block. Said that, I'm now also tending towards delaying that initialization because I see no other practical way to fix it (the linux kernel is usually the hardest thing to replace on a system, and even if the issue is fixed on a new version, all previous versions will be problematic). regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Nov 2 08:56:09 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 2 Nov 2016 08:56:09 +0100 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: References: Message-ID: On Tue, Nov 1, 2016 at 2:58 PM, Andy Lutomirski wrote: >> This has been already been seen in VMs, on the cases linked by [0]. A >> work-around that can be applied to gnutls is delaying the internal RNG >> initialization to the first call of gnutls_rnd(). That will allow >> applications which do not use the RNG immediately to load faster, >> while on the other hand introduces some complexity and does not >> address the problem when for example the system is in FIPS140-2 mode >> which requires some on-library-load tests which need to call >> gnutls_rnd(). -(here I'm also worried about future additions that may >> require random numbers on library load and negate any fixes for that >> issue). > I say delay initialization for reasons that have nothing to do with > blocking: when you initialize early, the kernel is telling you that your > seed may be predictable. So re-seeding later on is more secure. That's a good argument, but kinda assumes non-deterministic systems. I would have liked our computing systems to not try to emulate the real world :) From nmav at gnutls.org Fri Nov 4 08:13:19 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Nov 2016 08:13:19 +0100 Subject: [gnutls-devel] gnutls 2.12.24 Message-ID: <1478243599.2126.1.camel@gnutls.org> Hello,? ?I've just released gnutls 2.12.24. This is an update on the long-time deprecated 2.12.x branch. It fixes several interoperatibility issues present at this branch, removes support for legacy protocols and ciphersuites, and improves TLS 1.2 support. The update on this branch does not put 2.12.x into the maintained branches but it is rather a one-time update (sponsored by Red Hat) to extend the lifetime of systems which cannot upgrade to newer supported releases due to the ABI breakage. There are no other planned updates. Version 2.12.24 (released 2016-11-04) ** libgnutls: Fix in TLS server hello parsing (GNUTLS-SA-2014-3) ** libgnutls: Fix in TLS record decoding (GNUTLS-SA-2013-2) ** libgnutls: Fix in certificate verification (GNUTLS-SA-2014-1, ???GNUTLS-SA-2014-2, GNUTLS-SA-2015-1) ** libgnutls: Fix for MD5 downgrade in TLS 1.2 signatures. Reported by ???Karthikeyan Bhargavan (GNUTLS-SA-2015-2). ** libgnutls: Separated the logic of supported signature algorithms for ???CertificateRequest message and ClientHello. This allows the former ???be restricted to SHA1 and SHA256 due to internal limitations, while the ???latter can utilize any supported algorithms. ** libgnutls: Be less strict in TLS 1.2 signature algorithm adherence. This ???improves compatibility with sites that have a certificate with an enabled ???hash algorithm but necessarily enabled for TLS negotiation. ** libgnutls: No longer set SSL 3.0 as the record layer version by default ???This improves interoperability against broken servers which ???assume that this version is supported by the client. ** libgnutls: No longer include SSL 3.0 to the default protocol list. ???SSL 3.0 it must be explicitly enabled using a priority string. ** libgnutls: Prohibit DSA2 signatures when used with the libgcrypt ???backend. There are interoperability issues, and these algorithms are ???too rare to require a proper fix. ** libgnutls: The minimum Diffie-Hellman bits size was raised to 1023 from ???768. ** libgnutls: Removed support for EXPORT ciphersuites. The EXPORT priority ???string becomes an alias to NORMAL. ** libgnutls: Disabled random padding in the TLS protocol to improve compatibility ???with various broken servers. ** libgnutls: the ARCFOUR-128 cipher was removed from the default priority lists. ** libgnutls: Do not call the post client hello callback twice when resuming ???using session tickets. ** libgnutls: Corrected the setting of PSK hint for DHE-PSK ciphersuites. ** libgnutls: Do not link with libpthread unless necessary. ** libgnutls: Introduced the priority strings KX-ALL, VERS-ALL, CURVE-ALL (no-op) ???to improve compatibility with later versions of gnutls. ** 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/v2.12/gnutls-2.12.24.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v2.12/gnutls-2.12.24.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 nmav at gnutls.org Fri Nov 4 08:28:02 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 04 Nov 2016 08:28:02 +0100 Subject: [gnutls-devel] gnutls 3.5.6 Message-ID: <1478244482.2126.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.6. This is an enhancements and bugfix release for the 3.5.x branch. * Version 3.5.6 (released 2016-11-04) ** libgnutls: Enhanced the PKCS#7 parser to allow decoding old ???(pre-rfc5652) structures with arbitrary encapsulated content. ** libgnutls: Introduced a function group to set known DH parameters ???using groups from RFC7919. ** libgnutls: Added more strict RFC4514 textual DN encoding and decoding. ???Now the generated textual DN is in reverse order according to RFC4514, ???and functions which generate a DN from strings such gnutls_x509_crt_set_*dn() ???set the expected DN (reverse of the provided string). ** libgnutls: Introduced time and constraints checks in the end certificate ???in the gnutls_x509_crt_verify_data2() and gnutls_pkcs7_verify_direct() ???functions. ** libgnutls: Set limits on the maximum number of alerts handled. That is, ???applications using gnutls could be tricked into an busy loop if the ???peer sends continuously alert messages. Applications which set a maximum ???handshake time (via gnutls_handshake_set_timeout) will eventually recover ???but others may remain in a busy loops indefinitely. This is related but ???not identical to CVE-2016-8610, due to the difference in alert handling ???of the libraries (gnutls delegates that handling to applications). ** libgnutls: Reverted the change which made the gnutls_certificate_set_*key*? ???functions return an index (introduced in 3.5.5), to avoid affecting programs ???which explicitly check success of the function as equality to zero. In order ???for these functions to return an index an explicit call to gnutls_certificate_set_flags ???with the GNUTLS_CERTIFICATE_API_V2 flag is now required. ** libgnutls: Reverted the behavior of sending a status request extension even ???without a response (introduced in 3.5.5). That is, we no longer reply to a ???client's hello with a status request, with a status request extension. Although ???that behavior is legal, it creates incompatibility issues with releases in ???the gnutls 3.3.x branch. ** libgnutls: Delayed the initialization of the random generator at ???the first call of gnutls_rnd(). This allows applications to load ???on systems which getrandom() would block, without blocking until ???real random data are needed. ** certtool: --get-dh-params will output parameters from the RFC7919 ???groups. ** p11tool: improvements in --initialize option. ** API and ABI modifications: GNUTLS_CERTIFICATE_API_V2: Added GNUTLS_NO_TICKETS: Added gnutls_pkcs7_get_embedded_data_oid: Added gnutls_anon_set_server_known_dh_params: Added gnutls_certificate_set_known_dh_params: Added gnutls_psk_set_server_known_dh_params: Added gnutls_x509_crt_check_key_purpose: Added 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.6.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.6.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 nmav at gnutls.org Fri Nov 4 10:32:37 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Nov 2016 10:32:37 +0100 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: References: <20161101133946.6zmarwxwnwxgwaqh@argenau.bebt.de> Message-ID: On Wed, Nov 2, 2016 at 8:54 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Nov 1, 2016 at 2:39 PM, Andreas Metzler wrote: >>> Any opinions on that? The bottom line, is that we cannot completely >>> solve the blocking issue, but we can improve it on the occasions >>> mentioned above. Should we try and introduce some complexity, or >>> should we ignore it and expect the kernel to address it? >> I can certainly understand the problem. GnuTLS is automatically >> initialized through the library constructor at program startup. This >> might not even be necessary, the program might run without using GnuTLS >> functions ATM, or might just be an indirect dependency (e.g. cups). In >> these use cases GnuTLS should not waste a possible rare resource like >> entropy. > Well strictly speaking, with getrandom() there is no issue of > "depleting" entropy (it is a cprng, it will provide as much data as > asked). The issue is that the system can boot without it being > initialized, and thus a call to it will block. Said that, I'm now also > tending towards delaying that initialization because I see no other > practical way to fix it (the linux kernel is usually the hardest thing > to replace on a system, and even if the issue is fixed on a new > version, all previous versions will be problematic). To conclude that, I've included in GnuTLS 3.5.6 the delayed initialization of rng. That should address the issues found so far. If there are new issues found because of this change, it will be reconsidered. regards, Nikos From nmav at gnutls.org Fri Nov 11 11:18:35 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Nov 2016 11:18:35 +0100 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: <20161111100730.GA8108@redhat.com> References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> Message-ID: On Fri, Nov 11, 2016 at 11:07 AM, Daniel P. Berrange wrote: > IIUC, this is responsible for a change in behaviour seen by libvirt. > Previously the client cert DN would get reported as > > C=UK,CN=libvirt > > and with new version we're getting back > > CN=libvirt,C=UK > > This is causing a regression for libvirt. The libvirt server has ablity > to set a whitelist against the DN string, against which we do a regex > match. > > eg the sysadmin may have defined a whitelist of > > C=UK,CN=libvirt-client-* > > to allow all certs issed to libvirt clients. > This change in DN ordering by gnutls breaks any existing whitelists > our admins have setup, as well as breaking the libvirt test suite > which validates this. Any suggestions on how to mitigate that? Would a global flag to revert the library behavior and generate compatibility DNs be sufficient? regards, Nikos From berrange at redhat.com Fri Nov 11 11:07:30 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 11 Nov 2016 10:07:30 +0000 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: <1478244482.2126.3.camel@gnutls.org> References: <1478244482.2126.3.camel@gnutls.org> Message-ID: <20161111100730.GA8108@redhat.com> On Fri, Nov 04, 2016 at 08:28:02AM +0100, Nikos Mavrogiannopoulos wrote: > Hello,? > ?I've just released gnutls 3.5.6. This is an enhancements and > bugfix release for the 3.5.x branch. > > > * Version 3.5.6 (released 2016-11-04) > > ** libgnutls: Enhanced the PKCS#7 parser to allow decoding old > ???(pre-rfc5652) structures with arbitrary encapsulated content. > > ** libgnutls: Introduced a function group to set known DH parameters > ???using groups from RFC7919. > > ** libgnutls: Added more strict RFC4514 textual DN encoding and decoding. > ???Now the generated textual DN is in reverse order according to RFC4514, > ???and functions which generate a DN from strings such gnutls_x509_crt_set_*dn() > ???set the expected DN (reverse of the provided string). IIUC, this is responsible for a change in behaviour seen by libvirt. Previously the client cert DN would get reported as C=UK,CN=libvirt and with new version we're getting back CN=libvirt,C=UK This is causing a regression for libvirt. The libvirt server has ablity to set a whitelist against the DN string, against which we do a regex match. eg the sysadmin may have defined a whitelist of C=UK,CN=libvirt-client-* to allow all certs issed to libvirt clients. This change in DN ordering by gnutls breaks any existing whitelists our admins have setup, as well as breaking the libvirt test suite which validates this. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| From berrange at redhat.com Fri Nov 11 11:30:34 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 11 Nov 2016 10:30:34 +0000 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> Message-ID: <20161111103034.GD8108@redhat.com> On Fri, Nov 11, 2016 at 11:18:35AM +0100, Nikos Mavrogiannopoulos wrote: > On Fri, Nov 11, 2016 at 11:07 AM, Daniel P. Berrange > wrote: > > IIUC, this is responsible for a change in behaviour seen by libvirt. > > Previously the client cert DN would get reported as > > > > C=UK,CN=libvirt > > > > and with new version we're getting back > > > > CN=libvirt,C=UK > > > > This is causing a regression for libvirt. The libvirt server has ablity > > to set a whitelist against the DN string, against which we do a regex > > match. > > > > eg the sysadmin may have defined a whitelist of > > > > C=UK,CN=libvirt-client-* > > > > to allow all certs issed to libvirt clients. > > This change in DN ordering by gnutls breaks any existing whitelists > > our admins have setup, as well as breaking the libvirt test suite > > which validates this. > > Any suggestions on how to mitigate that? Would a global flag to revert > the library behavior and generate compatibility DNs be sufficient? A global flag feels rather dirty for something that's in a library, as an app linking to 2 libraries both in turn using gnutls, may have conflicting desires for the state of the global flag. I'm guessing just reverting to the old behaviour unconditionally is out of the question ? Personally I would have added a new API to request the changed behaviour, so apps wanting new behaviour can know for sure that they're getting it rather than silently getting different behaviour based on the version of gnutls they link to. If you don't want to change gnutls, then is it safe for libvirt to simply split the string on ',' and reverse the pieces to reassemble the original ordering ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| From nmav at gnutls.org Fri Nov 11 13:32:56 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Nov 2016 13:32:56 +0100 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: <20161111103034.GD8108@redhat.com> References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> <20161111103034.GD8108@redhat.com> Message-ID: On Fri, Nov 11, 2016 at 11:30 AM, Daniel P. Berrange wrote: >> Any suggestions on how to mitigate that? Would a global flag to revert >> the library behavior and generate compatibility DNs be sufficient? > A global flag feels rather dirty for something that's in a library, as > an app linking to 2 libraries both in turn using gnutls, may have > conflicting desires for the state of the global flag. > I'm guessing just reverting to the old behaviour unconditionally is out > of the question ? Personally I would have added a new API to request the > changed behaviour, so apps wanting new behaviour can know for sure that > they're getting it rather than silently getting different behaviour > based on the version of gnutls they link to. Maybe that makes sense. Maybe I should introduce new functions which obtain the textual DN which accept a flag to switch behavior (compat or default), and the old functions stay as wrappers to the new with the compat flag set. That will address both the need for the standard compliant version, and breaking the existing behavior. I'll try to schedule that for the next 3.5.x release. > If you don't want to change gnutls, then is it safe for libvirt to > simply split the string on ',' and reverse the pieces to reassemble > the original ordering ? Could also be, but in addition to not being simple (due to escaping etc), if you used the string that way, other applications may have done too, thus it would affect more than just libvirt. Addressing it in gnutls makes sense. regards, Nikos From berrange at redhat.com Fri Nov 11 13:46:39 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 11 Nov 2016 12:46:39 +0000 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> <20161111103034.GD8108@redhat.com> Message-ID: <20161111124639.GG8108@redhat.com> On Fri, Nov 11, 2016 at 01:32:56PM +0100, Nikos Mavrogiannopoulos wrote: > On Fri, Nov 11, 2016 at 11:30 AM, Daniel P. Berrange > wrote: > >> Any suggestions on how to mitigate that? Would a global flag to revert > >> the library behavior and generate compatibility DNs be sufficient? > > A global flag feels rather dirty for something that's in a library, as > > an app linking to 2 libraries both in turn using gnutls, may have > > conflicting desires for the state of the global flag. > > I'm guessing just reverting to the old behaviour unconditionally is out > > of the question ? Personally I would have added a new API to request the > > changed behaviour, so apps wanting new behaviour can know for sure that > > they're getting it rather than silently getting different behaviour > > based on the version of gnutls they link to. > > Maybe that makes sense. Maybe I should introduce new functions which > obtain the textual DN which accept a flag to switch behavior (compat > or default), and the old functions stay as wrappers to the new with > the compat flag set. That will address both the need for the standard > compliant version, and breaking the existing behavior. I'll try to > schedule that for the next 3.5.x release. Ok, that works for me. Lemme know if you want me to test anything prior to release to confirm the behaviour. > > If you don't want to change gnutls, then is it safe for libvirt to > > simply split the string on ',' and reverse the pieces to reassemble > > the original ordering ? > > Could also be, but in addition to not being simple (due to escaping > etc), if you used the string that way, other applications may have > done too, thus it would affect more than just libvirt. Addressing it > in gnutls makes sense. Yes, in fact QEMU is affected too - mostly because I wrote the same DN checking code for QEMU and libvirt :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| From nmav at gnutls.org Fri Nov 11 19:01:21 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Nov 2016 19:01:21 +0100 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: <20161111124639.GG8108@redhat.com> References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> <20161111103034.GD8108@redhat.com> <20161111124639.GG8108@redhat.com> Message-ID: On Fri, Nov 11, 2016 at 1:46 PM, Daniel P. Berrange wrote: >> Maybe that makes sense. Maybe I should introduce new functions which >> obtain the textual DN which accept a flag to switch behavior (compat >> or default), and the old functions stay as wrappers to the new with >> the compat flag set. That will address both the need for the standard >> compliant version, and breaking the existing behavior. I'll try to >> schedule that for the next 3.5.x release. > Ok, that works for me. Lemme know if you want me to test anything > prior to release to confirm the behaviour. A very quickly made patch to demo the idea is at: https://gitlab.com/gnutls/gnutls/merge_requests/140 Are the gnutls_*_get_dn() the functions you utilize to obtain the DN or do you use other functions for that? regards, Nikos From ametzler at bebt.de Sat Nov 12 14:07:58 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 12 Nov 2016 14:07:58 +0100 Subject: [gnutls-devel] gnutls-cli-debug segfaults after checking for inappropriate fallback (RFC7507) support Message-ID: <20161112130758.7skzvxnqsksg3mju@argenau.bebt.de> Hello, this is http://bugs.debian.org/844061 subnmitted by Daniel Kahn Gillmor: -------------------------------------------- I get a segfault from: gnutls-cli-debug --port 853 dns.cmrg.net [...] (gdb) run --port 853 dns.cmrg.net Starting program: /usr/bin/gnutls-cli-debug --port 853 dns.cmrg.net [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Warning: getservbyport(853) failed. Using port number as service. GnuTLS debug client 3.5.5 Checking dns.cmrg.net:853 for SSL 3.0 (RFC6101) support... no whether we need to disable TLS 1.2... no whether we need to disable TLS 1.1... no whether we need to disable TLS 1.0... no whether %NO_EXTENSIONS is required... no whether %COMPAT is required... no for TLS 1.0 (RFC2246) support... yes for TLS 1.1 (RFC4346) support... yes for TLS 1.2 (RFC5246) support... yes fallback from TLS 1.6 to... TLS1.2 for inappropriate fallback (RFC7507) support... yes Program received signal SIGSEGV, Segmentation fault. copy_record_version (version=0x555555790a5c "\003\002", htype=4294967295, session=0x55555578d370) at record.c:370 370 record.c: No such file or directory. (gdb) bt #0 copy_record_version (version=0x555555790a5c "\003\002", htype=4294967295, session=0x55555578d370) at record.c:370 #1 _gnutls_send_tlen_int (session=session at entry=0x55555578d370, type=type at entry=GNUTLS_ALERT, htype=htype at entry=4294967295, epoch_rel=epoch_rel at entry=70001, _data=_data at entry=0x7fffffffe340, data_size=data_size at entry=2, min_pad=0, mflags=1) at record.c:496 #2 0x00007ffff7ac7c28 in _gnutls_send_int (mflags=1, data_size=2, _data=0x7fffffffe340, epoch_rel=70001, htype=4294967295, type=GNUTLS_ALERT, session=0x55555578d370) at ./record.h:43 #3 gnutls_alert_send (session=session at entry=0x55555578d370, level=level at entry=GNUTLS_AL_WARNING, desc=desc at entry=GNUTLS_A_CLOSE_NOTIFY) at alert.c:165 #4 0x00007ffff7aa583c in gnutls_bye (session=0x55555578d370, how=GNUTLS_SHUT_WR) at record.c:297 #5 0x000055555555efae in ?? () #6 0x000055555555a5d1 in ?? () #7 0x00007ffff72a42b1 in __libc_start_main (main=0x55555555a230, argc=4, argv=0x7fffffffe5f8, init=, fini=, rtld_fini=, stack_end=0x7fffffffe5e8) at ../csu/libc-start.c:291 #8 0x000055555555a7ba in ?? () (gdb) I operate dns.cmrg.net: Please feel free to test connections against it :) --dkg -------------------------------------------- I have been able to reproduce the bug and have bisected the issue. It was introduced in 3.5.3 with commit 7e051ae28c288c218584f75dbc6c097a3b2564c9 Date: Tue Jul 26 10:33:24 2016 +0200 tools: TLS handling has been incorporated into socket_open() This is of particular usage to the server IP address loop, since we can detect fast open errors and retry handshake to the next IP address. 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 Nov 13 17:02:28 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Nov 2016 17:02:28 +0100 Subject: [gnutls-devel] gnutls-cli-debug segfaults after checking for inappropriate fallback (RFC7507) support In-Reply-To: <20161112130758.7skzvxnqsksg3mju@argenau.bebt.de> References: <20161112130758.7skzvxnqsksg3mju@argenau.bebt.de> Message-ID: In Sat, Nov 12, 2016 at 2:07 PM, Andreas Metzler wrote: > Hello, > > this is http://bugs.debian.org/844061 subnmitted by Daniel Kahn Gillmor: > -------------------------------------------- > I get a segfault from: > > gnutls-cli-debug --port 853 dns.cmrg.net Thanks, it seems that this was a quite drastic change for the tools. Hopefully that is the last side-effect. It can be addressed with the following patch: https://gitlab.com/gnutls/gnutls/commit/330dcc63b215152837caabda553c475a538fbc78 regards, Nikos From dkg at fifthhorseman.net Sun Nov 13 21:25:21 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Nov 2016 05:25:21 +0900 Subject: [gnutls-devel] session ticket key rotation Message-ID: <87fumvf7pq.fsf@alice.fifthhorseman.net> Hi GnuTLS folks-- I'm trying to add session tickets to a GnuTLS-enabled daemon. I'm using gnutls_session_ticket_enable_server(), but it looks like there is no way to smoothly rotate session ticket keys. That is, as soon as i call gnutls_session_ticket_enable_server(), all previously-issued session tickets become invalidated. What i'd prefer is for my server to have a pool of N session tickets keys, and for me to expire (and replace) one of them (in sequence) every K seconds. The tickets issued by this setup would have some reserved space that indicated which of the slots is in use (e.g. the top 3 bits, if N = 8). When encrypting, we'd always select the most recently-regeneratted slot, and we'd set those bits to correspond to the slot in use. When decrypting, we'd select the key to decrypt with based on the corresponding bits. With this scheme, tickets issued by each key would be good for at least (N-1)*K seconds (in the case where a ticket is issued from the key just before the next key is generated), and there would never be a hard cutover that invalidates all existing session tickets. Is there a way to do this in GnuTLS as it currently stands? If not, would you be interested in such a feature? I'm imagining that an opaque server-side API for this would look something like: struct gnutls_ticket_key_pool_int; typedef struct gnutls_ticket_key_pool_int *gnutls_ticket_key_pool_t; int gnutls_ticket_key_pool_init(gnutls_ticket_key_pool_t *pool, int numkeys); int gnutls_ticket_key_pool_free(gnutls_ticket_key_pool_t pool); int gnutls_ticket_key_pool_rotate(gnutls_ticket_key_pool_t pool); /* new value for gnutls_credentials_type_t */ GNUTLS_CRD_SESTKT_KEYPOOL Users would associate the ticket key pool with a session using gnutls_credentials_get and gnutls_credentials_set, making the workflow and memory ownership model aligned with existing use. The caller would be responsible for invoking gnutls_ticket_key_pool_rotate() at their selected intervals. The opacity of the object might cause trouble if you wanted to share the pool session ticket keys across a pool of front-end servers, or if you wanted session tickets to survive a server reboot. You could handle that situation by adding a pair of serialization/deserialization functions for the ticket key pool. Any thoughts? Is there already a good way to do something like this in the existing API and i'm just missing it? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From nmav at gnutls.org Mon Nov 14 10:38:38 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Nov 2016 10:38:38 +0100 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: <87fumvf7pq.fsf@alice.fifthhorseman.net> References: <87fumvf7pq.fsf@alice.fifthhorseman.net> Message-ID: On Sun, Nov 13, 2016 at 9:25 PM, Daniel Kahn Gillmor wrote: > Hi GnuTLS folks-- > I'm trying to add session tickets to a GnuTLS-enabled daemon. > I'm using gnutls_session_ticket_enable_server(), but it looks like there > is no way to smoothly rotate session ticket keys. That is, as soon as i > call gnutls_session_ticket_enable_server(), all previously-issued > session tickets become invalidated. Hi Daniel, Right, it was intended for the applications to handle such rotation, and a smooth rotation is not possible as I see with the current API. > What i'd prefer is for my server to have a pool of N session tickets > keys, and for me to expire (and replace) one of them (in sequence) every > K seconds. > The tickets issued by this setup would have some reserved space that > indicated which of the slots is in use (e.g. the top 3 bits, if N = 8). > When encrypting, we'd always select the most recently-regeneratted slot, > and we'd set those bits to correspond to the slot in use. > > When decrypting, we'd select the key to decrypt with based on the > corresponding bits. Seems reasonable. > Is there a way to do this in GnuTLS as it currently stands? If not, > would you be interested in such a feature? Certainly. My goal for the new releases is to make it as simple as possible for applications to use gnutls. I no longer try to push to applications all the hard parts :) > I'm imagining that an opaque server-side API for this would look > something like: > struct gnutls_ticket_key_pool_int; > typedef struct gnutls_ticket_key_pool_int *gnutls_ticket_key_pool_t; > > int gnutls_ticket_key_pool_init(gnutls_ticket_key_pool_t *pool, int numkeys); > int gnutls_ticket_key_pool_free(gnutls_ticket_key_pool_t pool); > int gnutls_ticket_key_pool_rotate(gnutls_ticket_key_pool_t pool); The tricky part would be making the rotate function semantics easy to use, even in multi-threaded environments, and allow efficient access to keys at the same time. You wouldn't want a multi-threaded server to hold a lock in order to access a ticket key. That's not an easy goal to achieve; something similar using atomic variables of C11 (with fallback) was done in gnutls_rnd() (see random.c and _gnutls_rnd_init). > Users would associate the ticket key pool with a session using > gnutls_credentials_get and gnutls_credentials_set, making the workflow > and memory ownership model aligned with existing use. The change in semantics by that would be that the credentials structure would no longer hold only read-only data. However, if the rotation is transparent for all types of applications, I have no objection on that. > The opacity of the object might cause trouble if you wanted to share the > pool session ticket keys across a pool of front-end servers, or if you > wanted session tickets to survive a server reboot. You could handle > that situation by adding a pair of serialization/deserialization > functions for the ticket key pool. Serialization and de/serialization would simplify things a lot for applications. It would require some versioning though to allow upgrading to a new ticket key handling at the future. > Any thoughts? Is there already a good way to do something like this in > the existing API and i'm just missing it? I do not think so. regards, Nikos From berrange at redhat.com Mon Nov 14 11:32:04 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Nov 2016 10:32:04 +0000 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> <20161111103034.GD8108@redhat.com> <20161111124639.GG8108@redhat.com> Message-ID: <20161114103204.GH8314@redhat.com> On Fri, Nov 11, 2016 at 07:01:21PM +0100, Nikos Mavrogiannopoulos wrote: > On Fri, Nov 11, 2016 at 1:46 PM, Daniel P. Berrange wrote: > >> Maybe that makes sense. Maybe I should introduce new functions which > >> obtain the textual DN which accept a flag to switch behavior (compat > >> or default), and the old functions stay as wrappers to the new with > >> the compat flag set. That will address both the need for the standard > >> compliant version, and breaking the existing behavior. I'll try to > >> schedule that for the next 3.5.x release. > > Ok, that works for me. Lemme know if you want me to test anything > > prior to release to confirm the behaviour. > > A very quickly made patch to demo the idea is at: > https://gitlab.com/gnutls/gnutls/merge_requests/140 The new APIs you added there look reasonable to me. > Are the gnutls_*_get_dn() the functions you utilize to obtain the DN > or do you use other functions for that? For this task, we only use: gnutls_x509_crt_get_dn Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| From berrange at redhat.com Mon Nov 14 11:58:18 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 14 Nov 2016 10:58:18 +0000 Subject: [gnutls-devel] gnutls 3.5.6 In-Reply-To: <20161114103204.GH8314@redhat.com> References: <1478244482.2126.3.camel@gnutls.org> <20161111100730.GA8108@redhat.com> <20161111103034.GD8108@redhat.com> <20161111124639.GG8108@redhat.com> <20161114103204.GH8314@redhat.com> Message-ID: <20161114105818.GJ8314@redhat.com> On Mon, Nov 14, 2016 at 10:32:04AM +0000, Daniel P. Berrange wrote: > On Fri, Nov 11, 2016 at 07:01:21PM +0100, Nikos Mavrogiannopoulos wrote: > > On Fri, Nov 11, 2016 at 1:46 PM, Daniel P. Berrange wrote: > > >> Maybe that makes sense. Maybe I should introduce new functions which > > >> obtain the textual DN which accept a flag to switch behavior (compat > > >> or default), and the old functions stay as wrappers to the new with > > >> the compat flag set. That will address both the need for the standard > > >> compliant version, and breaking the existing behavior. I'll try to > > >> schedule that for the next 3.5.x release. > > > Ok, that works for me. Lemme know if you want me to test anything > > > prior to release to confirm the behaviour. > > > > A very quickly made patch to demo the idea is at: > > https://gitlab.com/gnutls/gnutls/merge_requests/140 > > The new APIs you added there look reasonable to me. Just built that branch and confirmed it fixes the libvirt + QEMU test suites. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| From dkg at fifthhorseman.net Mon Nov 14 15:57:16 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Nov 2016 23:57:16 +0900 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: References: <87fumvf7pq.fsf@alice.fifthhorseman.net> Message-ID: <87r36ecdo3.fsf@alice.fifthhorseman.net> Hi Nikos-- On Mon 2016-11-14 18:38:38 +0900, Nikos Mavrogiannopoulos wrote: > and a smooth rotation is not possible as I see with the current API. ok, at least i wasn't missing anythingn obvious :/ > Certainly. My goal for the new releases is to make it as simple as > possible for applications to use gnutls. I no longer try to push to > applications all the hard parts :) This is the right choice, thanks :) >> I'm imagining that an opaque server-side API for this would look >> something like: >> struct gnutls_ticket_key_pool_int; >> typedef struct gnutls_ticket_key_pool_int *gnutls_ticket_key_pool_t; >> >> int gnutls_ticket_key_pool_init(gnutls_ticket_key_pool_t *pool, int numkeys); >> int gnutls_ticket_key_pool_free(gnutls_ticket_key_pool_t pool); >> int gnutls_ticket_key_pool_rotate(gnutls_ticket_key_pool_t pool); > > The tricky part would be making the rotate function semantics easy to > use, even in multi-threaded environments, and allow efficient access > to keys at the same time. You wouldn't want a multi-threaded server to > hold a lock in order to access a ticket key. Is the problem the expense of taking a read lock itself, or is the problem a risk of uninitialized memory access? > That's not an easy goal to achieve; something similar using atomic > variables of C11 (with fallback) was done in gnutls_rnd() (see > random.c and _gnutls_rnd_init). Is it possible that it doesn't matter? Consider the following (very rough) implementation (error checking omitted for concision): 1 typedef char[SESTKTKEYLEN] _session_ticket_key; 2 3 struct gnutls_ticket_key_pool_int { 4 int numkeys; 5 _session_ticket_key *keys; 6 int current_key; 7 } 8 9 int gnutls_ticket_key_pool_init(gnutls_ticket_key_pool_t *pool, int numkeys) { 10 *pool = malloc(sizeof(gnutls_ticket_key_pool_int)); 11 (*pool)->numkeys = numkeys; 12 (*pool)->keys = malloc(sizeof(_session_ticket_key) * numkeys); 13 (*pool)->current_key = 0; 14 gnutls_rnd(GNUTLS_RND_KEY, (*pool)->keys, sizeof(_session_ticket_key) * numkeys); 15 16 } 17 int gnutls_ticket_key_pool_rotate(gnutls_ticket_key_pool_t pool) { 18 _session_ticket_key newkey; 19 gnutls_rnd(GNUTLS_RND_KEY, newkey, sizeof(newkey)); 20 int newkeyidx = (pool->current_key + 1)%pool->numkeys; 21 memcpy(pool->keys[newkeyidx], newkey, sizeof(newkey)); 22 pool->current_key = newkeyidx; 23 } if someone offers a session ticket that belongs to the oldest keyslot (the one that's about to be overwritten), and the crypto code that accesses it to decrypt the ticket is in use during the memcpy on line 21, what's the worst that could happen? It seems to me like the decryption would fail, and the session wouldn't be able to resume. This is the *same* outcome as if it were to happen *after* the the function completes (because that specific key has been overwritten by data that can't dcrypt any subsequent message. The outcome is, the client has to go through a full handshake. doesn't seem too bad... > The change in semantics by that would be that the credentials > structure would no longer hold only read-only data. However, if the > rotation is transparent for all types of applications, I have no > objection on that. What different kind of application types should i be concerned about that might behave differently? > Serialization and de/serialization would simplify things a lot for > applications. It would require some versioning though to allow > upgrading to a new ticket key handling at the future. a bytewise copy of the pool->keys member seems like it ought to do the trick, and the reasoning about write-collisions looks to me like a full-buffer memcpy is equivalent to the discussion about internal key rotation, no? wdyt? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From nmav at gnutls.org Mon Nov 14 17:47:03 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Nov 2016 17:47:03 +0100 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: <87r36ecdo3.fsf@alice.fifthhorseman.net> References: <87fumvf7pq.fsf@alice.fifthhorseman.net> <87r36ecdo3.fsf@alice.fifthhorseman.net> Message-ID: On Mon, Nov 14, 2016 at 3:57 PM, Daniel Kahn Gillmor wrote: > Hi Nikos-- >> The tricky part would be making the rotate function semantics easy to >> use, even in multi-threaded environments, and allow efficient access >> to keys at the same time. You wouldn't want a multi-threaded server to >> hold a lock in order to access a ticket key. > > Is the problem the expense of taking a read lock itself, or is the > problem a risk of uninitialized memory access? > >> That's not an easy goal to achieve; something similar using atomic >> variables of C11 (with fallback) was done in gnutls_rnd() (see >> random.c and _gnutls_rnd_init). > > Is it possible that it doesn't matter? Consider the following (very > rough) implementation (error checking omitted for concision): > > 1 typedef char[SESTKTKEYLEN] _session_ticket_key; > 2 > 3 struct gnutls_ticket_key_pool_int { > 4 int numkeys; > 5 _session_ticket_key *keys; > 6 int current_key; > 7 } > 8 > 9 int gnutls_ticket_key_pool_init(gnutls_ticket_key_pool_t *pool, int numkeys) { > 10 *pool = malloc(sizeof(gnutls_ticket_key_pool_int)); > 11 (*pool)->numkeys = numkeys; > 12 (*pool)->keys = malloc(sizeof(_session_ticket_key) * numkeys); > 13 (*pool)->current_key = 0; > 14 gnutls_rnd(GNUTLS_RND_KEY, (*pool)->keys, sizeof(_session_ticket_key) * numkeys); > 15 > 16 } > 17 int gnutls_ticket_key_pool_rotate(gnutls_ticket_key_pool_t pool) { > 18 _session_ticket_key newkey; > 19 gnutls_rnd(GNUTLS_RND_KEY, newkey, sizeof(newkey)); > 20 int newkeyidx = (pool->current_key + 1)%pool->numkeys; > 21 memcpy(pool->keys[newkeyidx], newkey, sizeof(newkey)); > 22 pool->current_key = newkeyidx; > 23 } One question is whether we would like the key_pool_rotate to protect from parallel calls of the same function, or from calls with small time difference. > if someone offers a session ticket that belongs to the oldest keyslot > (the one that's about to be overwritten), and the crypto code that > accesses it to decrypt the ticket is in use during the memcpy on line > 21, what's the worst that could happen? What about CPUs where writing to a memory location is not an atomic operation... i.e., if on line 22, some reader instead of getting the old or the new value of pool->current_key, gets some intermediate value? Are these of a concern? >> The change in semantics by that would be that the credentials >> structure would no longer hold only read-only data. However, if the >> rotation is transparent for all types of applications, I have no >> objection on that. > What different kind of application types should i be concerned about > that might behave differently? I cannot think of any. regards, Nikos From dkg at fifthhorseman.net Tue Nov 15 07:14:04 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 15 Nov 2016 15:14:04 +0900 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: References: <87fumvf7pq.fsf@alice.fifthhorseman.net> <87r36ecdo3.fsf@alice.fifthhorseman.net> Message-ID: <87fumtb783.fsf@alice.fifthhorseman.net> On Tue 2016-11-15 01:47:03 +0900, Nikos Mavrogiannopoulos wrote: > One question is whether we would like the key_pool_rotate to protect > from parallel calls of the same function, or from calls with small > time difference. I think locking key_pool_rotate against itself doesn't sound like it would be harmful, but i also don't see why it would matter. in the worst case, you just make it so that some sessions cannot be resumed, which means that clients would fall back to slightly longer handshakes. And if someone really wants to invalidate all existing session tickets without destroying the ticket pool, i don't see why they shouldn't be allowed to rapidly cycle the pool. So i guess simpler seems better to me -- i don't see the need for locks. > What about CPUs where writing to a memory location is not an atomic > operation... i.e., if on line 22, some reader instead of getting the > old or the new value of pool->current_key, gets some intermediate > value? Are these of a concern? So i can imagine, say, the first half of the RAM being from key N and the second half of the RAM being from key N+1 for that slot. In that case, no existing tickets for that slot (which had been issued nearly a full rotation cycle ago) would validate during that window. but that's fine, they're about to be invalidated anyway. The bigger risk would be if new tickets were issued during that case, but that wouldn't happen because we update current_key *after* the key is updated. So i still don't see a problem. Thanks for the thoughtful review! let me know if you have any other concerns or suggestions about the proposal. If you think it's in decent shape, should i open a gitlab ticket to track it? I don't know if i can get around to implementing it soon, alas, but i know it would be useful for at least a couple implementations i'm concerned about. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 962 bytes Desc: not available URL: From nmav at gnutls.org Tue Nov 15 08:26:38 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 15 Nov 2016 08:26:38 +0100 Subject: [gnutls-devel] session ticket key rotation In-Reply-To: <87fumtb783.fsf@alice.fifthhorseman.net> References: <87fumvf7pq.fsf@alice.fifthhorseman.net> <87r36ecdo3.fsf@alice.fifthhorseman.net> <87fumtb783.fsf@alice.fifthhorseman.net> Message-ID: On Tue, Nov 15, 2016 at 7:14 AM, Daniel Kahn Gillmor wrote: >> What about CPUs where writing to a memory location is not an atomic >> operation... i.e., if on line 22, some reader instead of getting the >> old or the new value of pool->current_key, gets some intermediate >> value? Are these of a concern? > So i can imagine, say, the first half of the RAM being from key N and > the second half of the RAM being from key N+1 for that slot. In that > case, no existing tickets for that slot (which had been issued nearly a > full rotation cycle ago) would validate during that window. but that's > fine, they're about to be invalidated anyway. The bigger risk would be > if new tickets were issued during that case, but that wouldn't happen > because we update current_key *after* the key is updated. So i still > don't see a problem. The thing is that there is no guarrantee from the language about the contents of the intermediate values. For practical purposes though, I think variables which are word-aligned should be ok to access (though the safe C11 version is something I prefer, even if it is within ifdefs). > Thanks for the thoughtful review! let me know if you have any other > concerns or suggestions about the proposal. If you think it's in decent > shape, should i open a gitlab ticket to track it? Makes sense. regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Nov 16 10:58:07 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 16 Nov 2016 10:58:07 +0100 Subject: [gnutls-devel] rfc7613 password normalization Message-ID: Hi, The merge request [0] introduces UTF8 password "canonicalization" according to RFC7613. That is, a UTF8 or UTF16 password (in case of PKCS#12 files) will be transformed to a unique form prior to being used to generate a key. The problems are: 1. No other library performs this canonicalization of passwords, meaning that for some of the generated files (e.g., pkcs8 or pkcs12 keys) may not be usable with other libraries. Files generated with previous versions of gnutls (at least prior to 3.5.x branch) should be ok because they prohibited internationalized passwords. 2. That "canonicalization" is being used even if the specs for PKCS#8, PKCS#12, PKCS#10, or SRP (rfc2945), do not require it. They fact is that they, predate that draft, and most likely they are receiving no updates. Given that it is possible for applications to provide a UTF8 password in multiple different strings, I think it makes sense to introduce this canonicalization, despite the drawbacks. It will allow gnutls applications to behave right when given the same password, and decrypt files, irrespective of how the UTF8 password was formed. What do you think? A side-effect of this change, is that gnutls will also depend on libunistring (which is in the process of being relicensed to lgplv3+gplv2), for proper unicode support. [0]. https://gitlab.com/gnutls/gnutls/merge_requests/137 regards, Nikos From ametzler at bebt.de Mon Nov 21 20:00:23 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 21 Nov 2016 20:00:23 +0100 Subject: [gnutls-devel] rfc7613 password normalization In-Reply-To: References: Message-ID: <20161121190023.2udfjnsybya4kpac@argenau.bebt.de> On 2016-11-16 Nikos Mavrogiannopoulos wrote: > Hi, > The merge request [0] introduces UTF8 password "canonicalization" > according to RFC7613. That is, a UTF8 or UTF16 password (in case of > PKCS#12 files) will be transformed to a unique form prior to being > used to generate a key. [...] > A side-effect of this change, is that gnutls will also depend on > libunistring (which is in the process of being relicensed to > lgplv3+gplv2), for proper unicode support. > [0]. https://gitlab.com/gnutls/gnutls/merge_requests/137 I would appreciate if the merge happened after libunistring was relicensed. 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 n.mavrogiannopoulos at gmail.com Mon Nov 21 21:18:27 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 21 Nov 2016 21:18:27 +0100 Subject: [gnutls-devel] rfc7613 password normalization In-Reply-To: <20161121190023.2udfjnsybya4kpac@argenau.bebt.de> References: <20161121190023.2udfjnsybya4kpac@argenau.bebt.de> Message-ID: <1479759507.2939.1.camel@gmail.com> On Mon, 2016-11-21 at 20:00 +0100, Andreas Metzler wrote: > On 2016-11-16 Nikos Mavrogiannopoulos > wrote: > > Hi, > > ?The merge request [0] introduces UTF8 password "canonicalization" > > according to RFC7613. That is, a UTF8 or UTF16 password (in case of > > PKCS#12 files) will be transformed to a unique form prior to being > > used to generate a key. > > [...] > > A side-effect of this change, is that gnutls will also depend on > > libunistring (which is in the process of being relicensed to > > lgplv3+gplv2), for proper unicode support. > > [0]. https://gitlab.com/gnutls/gnutls/merge_requests/137 > > I would appreciate if the merge happened after > libunistring was relicensed. A few hours too late :) As I see the relicense is already done on gnulib, though I don't know if there is a proper (non-gnulib) release. If you want to avoid the linking with the old libunistring which is under lgplv3+, you can use temporarily the --with-included-unistring option which will use the already relicensed gnulib sources. regards, Nikos PS. I just realized that the gnulib-tool does not properly copy the license if the --lgpl=3orGPLv2 flag is given. I'll send an patch to gnulib for that. From dbaryshkov at gmail.com Wed Nov 30 10:04:11 2016 From: dbaryshkov at gmail.com (Dmitry Eremin-Solenikov) Date: Wed, 30 Nov 2016 12:04:11 +0300 Subject: [gnutls-devel] GnuTLS & setting KX algorithm for session Message-ID: Hello, I'm developing new KX handler in GnuTLS (for GOST TLS). Right now I'm observing that during the call to gnutls_generate_client_crt_vrfy() callback, the gnutls_kx_get() function returns 0 (KX_UNKNOWN) for this session instead of the correct KX. Is it my fault, bug or misfeature? -- With best wishes Dmitry From nmav at gnutls.org Wed Nov 30 15:27:25 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 30 Nov 2016 15:27:25 +0100 Subject: [gnutls-devel] GnuTLS & setting KX algorithm for session In-Reply-To: References: Message-ID: On Wed, Nov 30, 2016 at 10:04 AM, Dmitry Eremin-Solenikov wrote: > Hello, > > I'm developing new KX handler in GnuTLS (for GOST TLS). Right now I'm observing > that during the call to gnutls_generate_client_crt_vrfy() callback, > the gnutls_kx_get() > function returns 0 (KX_UNKNOWN) for this session instead of the correct KX. > > Is it my fault, bug or misfeature? Thanks, nice catch. It is both a bug and a feature. Key usage violations were tolerated since 3.1.4 due to many server misconfigurations (e.g., server restricting the certificate to signining but attempting encryption). So it seems that at some point the checking code became a no-op. You finding is a good opportunity to rewrite that part and enable such detection without damaging usability. regards, Nikos From adrien.beraud at savoirfairelinux.com Wed Nov 30 20:27:00 2016 From: adrien.beraud at savoirfairelinux.com (Adrien =?utf-8?Q?B=C3=A9raud?=) Date: Wed, 30 Nov 2016 14:27:00 -0500 (EST) Subject: [gnutls-devel] Wrong return value from gnutls_x509_crl_verify Message-ID: <1142791462.69621.1480534020474.JavaMail.zimbra@savoirfairelinux.com> While using gnutls_x509_crl_verify I noticed it returned 1 for a valid CRL. The documentation only mention 0 on success and a negative code on failure. It turned out the value comes from _gnutls_x509_verify_data which takes its value from pubkey_verify_data which returns 1 on success. Attached is a patch to fix the issue. best regards, Adrien B?raud Savoir-faire Linux diff --git a/lib/x509/verify.c b/lib/x509/verify.c index ecd2369..d4966d0 100644 --- a/lib/x509/verify.c +++ b/lib/x509/verify.c @@ -1477,13 +1477,13 @@ gnutls_x509_crl_verify(gnutls_x509_crl_t crl, /* error. ignore it */ if (verify) *verify |= GNUTLS_CERT_SIGNATURE_FAILURE; - result = 0; } else if (result < 0) { gnutls_assert(); if (verify) *verify |= GNUTLS_CERT_INVALID; goto cleanup; } + result = 0; } { -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_verify_result.patch Type: text/x-patch Size: 455 bytes Desc: not available URL: