From nmav at gnutls.org Sun Dec 1 22:48:32 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 01 Dec 2019 22:48:32 +0100 Subject: [gnutls-help] gnutls 3.6.11 Message-ID: <550186432be545f624b14e102932df7fc67621b0.camel@gnutls.org> Hello, I've just released gnutls 3.6.11. This is a bug fix release on the stable 3.6.x branch. I'd like to thank everyone who contributed in this release: Dmitry Eremin-Solenikov, Tim R?hsen, Daiki Ueno, Tom Vrancken, Fiona Klute, Ludovic Court?s, Andreas Metzler, Nia Alarie, Bj?rn Jacke, Karsten Ohme, G?nther Deschner, Miroslav Lichvar and Ricardo M. Correia. The detailed list of changes follows; they can be seen in more detail in our milestone tracker: https://gitlab.com/gnutls/gnutls/-/milestones/25 Changes ======= * Version 3.6.11 (released 2019-12-01) ** libgnutls: Use KERN_ARND for the system random number generator on NetBSD. This syscall provides an endless stream of random numbers from the kernel's ChaCha20-based random number generator, without blocking or requiring an open file descriptor. ** libgnutls: Corrected issue with TLS 1.2 session ticket handling as client during resumption (#841). ** libgnutls: gnutls_base64_decode2() succeeds decoding the empty string to the empty string. This is a behavioral change of the API but it conforms to the RFC4648 expectations (#834). ** libgnutls: Fixed AES-CFB8 implementation, when input is shorter than the block size. Fix backported from nettle. ** certtool: CRL distribution points will be set in CA certificates even when non self-signed (#765). ** gnutls-cli/serv: added raw public-key handling capabilities (RFC7250). Key material can be set via the --rawpkkeyfile and --rawpkfile flags. ** 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: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.11.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.11.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 Mon Dec 2 13:40:10 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 2 Dec 2019 13:40:10 +0100 Subject: [gnutls-help] full-chain ocsp stapling In-Reply-To: <7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org> References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> <7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org> Message-ID: Hi, Isn't that the same as https://gitlab.com/gnutls/gnutls/issues/829 ? regards, Nikos On Sun, Nov 24, 2019 at 6:44 PM Jeremy Harris wrote: > > On 10/11/2019 20:45, Jeremy Harris wrote: > > GnuTLS 3.6.8 > > > > I'm testing $subject using a 3-layer cert chain, and stapled ocsp > > under TLS1.3 for which the middle item is non-valid. > ... > > but gnutls_ocsp_status_request_is_checked(state->session, 0) returns > > nonzero (meaning "valid"). > > > > I'm not quite clear what level of validity is being described here. > > Should it be checking that the OCSP response indicates non-revoked > > certificates, for all cert-chain elements covered? Or is it only > > saying that the stapled information is well-constructed and signed > > (meaning that I should be taking more actions to validate the > > certs; if so, what)? > > No answers on this? > -- > Cheers, > Jeremy > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From jgh at wizmail.org Mon Dec 2 16:48:56 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 2 Dec 2019 15:48:56 +0000 Subject: [gnutls-help] full-chain ocsp stapling In-Reply-To: References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> <7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org> Message-ID: On 02/12/2019 12:40, Nikos Mavrogiannopoulos wrote: > Isn't that the same as https://gitlab.com/gnutls/gnutls/issues/829 ? No; that was asking how the server could tell if the client requested stapling. This is a problem where an apparently invalid stapling (from the server) is being regarded as valid by the client. -- Cheers, Jeremy From nmav at gnutls.org Mon Dec 2 17:55:46 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 2 Dec 2019 17:55:46 +0100 Subject: [gnutls-help] full-chain ocsp stapling In-Reply-To: References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org> <7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org> Message-ID: Could report it as an issue and attach a reproducer to it? There are few ocsp tests in `tests/` that can serve as an inspiration for one. regards, Nikos On Mon, Dec 2, 2019 at 4:49 PM Jeremy Harris wrote: > > On 02/12/2019 12:40, Nikos Mavrogiannopoulos wrote: > > Isn't that the same as https://gitlab.com/gnutls/gnutls/issues/829 ? > > No; that was asking how the server could tell if the client > requested stapling. > > This is a problem where an apparently invalid stapling (from the server) > is being regarded as valid by the client. > -- > Cheers, > Jeremy > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From nicolas at babelouest.org Thu Dec 5 17:21:00 2019 From: nicolas at babelouest.org (Nicolas Mora) Date: Thu, 05 Dec 2019 16:21:00 +0000 Subject: [gnutls-help] certtool and add_extension Message-ID: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> Hello, In some tests procedures, I need to add the following extension to signing certificates: key: 1.3.6.1.4.1.45724.1.1.4 value: a 16 bytes value According to certtool documentation [1], I must use add_extension with an octet string: add_extension = "1.2.3.4 octet_string(0x0AAB01ACFE)" In my case, the add_extension parameter would be: add_extension = "1.3.6.1.4.1.45724.1.1.4 octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" Although, the generated certificate doesn't include the extension "1.3.6.1.4.1.45724.1.1.4" You can see the template file I use here: https://github.com/babelouest/glewlwyd/blob/master/test/cert/template-client-packed.cfg Is there a something I missed when using the certtool command? Thanks in advance /Nicolas [1] - https://www.gnutls.org/manual/html_node/certtool-Invocation.html From nmav at gnutls.org Fri Dec 6 10:54:22 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 6 Dec 2019 10:54:22 +0100 Subject: [gnutls-help] certtool and add_extension In-Reply-To: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> Message-ID: Hi, You may want to check your gnutls version. This template option was added at 3.5.3. regards, Nikos On Thu, Dec 5, 2019 at 5:59 PM Nicolas Mora wrote: > > Hello, > > In some tests procedures, I need to add the following extension to signing certificates: > key: 1.3.6.1.4.1.45724.1.1.4 > value: a 16 bytes value > > According to certtool documentation [1], I must use add_extension with an octet string: > add_extension = "1.2.3.4 octet_string(0x0AAB01ACFE)" > > In my case, the add_extension parameter would be: > add_extension = "1.3.6.1.4.1.45724.1.1.4 octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" > > Although, the generated certificate doesn't include the extension "1.3.6.1.4.1.45724.1.1.4" > > You can see the template file I use here: https://github.com/babelouest/glewlwyd/blob/master/test/cert/template-client-packed.cfg > > Is there a something I missed when using the certtool command? > > Thanks in advance > > /Nicolas > > [1] - https://www.gnutls.org/manual/html_node/certtool-Invocation.html > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From nicolas at babelouest.org Fri Dec 6 15:57:00 2019 From: nicolas at babelouest.org (Nicolas Mora) Date: Fri, 06 Dec 2019 14:57:00 +0000 Subject: [gnutls-help] certtool and add_extension In-Reply-To: References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> Message-ID: Hello, 6 d?cembre 2019 04:54 "Nikos Mavrogiannopoulos" a ?crit: > You may want to check your gnutls version. This template option was > added at 3.5.3. > Nevertheless, I use a Debian Buster with gnutls 3.6.7 Here is a gist with the script and template files I use for my demonstration: https://gist.github.com/babelouest/0c5076462d52f8ecf7c33c9862681687 The log file output is attached, and more specifically, the client certificate output is: Generating a signed certificate... X.509 Certificate Information: Version: 3 Serial Number (hex): 736c577633f2962c130569396e9c8532394975ea Validity: Not Before: Fri Dec 06 14:30:20 UTC 2019 Not After: Fri Nov 20 14:30:20 UTC 2020 Subject: C=CA,O=babelouest,OU=Authenticator Attestation,CN=glewlwyd_packed Subject Public Key Algorithm: EC/ECDSA Algorithm Security Level: High (256 bits) Curve: SECP256R1 X: 3d:ca:36:10:58:e0:f0:49:cc:61:47:57:ac:ee:83:60 45:29:c2:23:ab:50:1f:00:50:1b:9e:8e:51:e4:e7:8d Y: 58:e4:9c:5f:81:c0:dd:d7:44:8b:c9:a2:b4:04:48:16 d0:f1:86:46:d2:b5:2b:be:9b:f5:ce:76:af:3a:65:e7 Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Usage (critical): Digital signature. Subject Key Identifier (not critical): 945473da3bfe497d2b712dc3cef6e4a692be8b29 Authority Key Identifier (not critical): 6e245f7b8f84bb602631dc9b3a33af2fb58670f3 Other Information: Public Key ID: sha1:945473da3bfe497d2b712dc3cef6e4a692be8b29 sha256:9cccc45cc2996175ed3567a0033ef413309228d78b5364b8270ad962f14d49a0 Public Key PIN: pin-sha256:nMzEXMKZYXXtNWegAz70EzCSKNeLU2S4JwrZYvFNSaA= -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: extension.log URL: From ametzler at bebt.de Sat Dec 7 14:07:53 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 7 Dec 2019 14:07:53 +0100 Subject: [gnutls-help] nettle_cfb8_decrypt and nettle 5.1 Message-ID: <20191207130753.GA1435@argenau.bebt.de> Hello, gnutls 3.6.11 introduces this change in 98ac6220bdef67ba1153dc515613e4582e1419a2 "nettle: use included CFB8 implementation if nettle is 3.5": configure.ac # Check if nettle has CFB8 support +if test -z "$ac_cv_func_nettle_cfb8_encrypt"; then + # nettle_cfb8_decrypt in nettle 3.5 is known to be broken + ver=`$PKG_CONFIG --modversion nettle` + if expr "$ver" : '^3\.5\b' >/dev/null; then + ac_cv_func_nettle_cfb8_encrypt=no + fi +fi Which versions of nettle are broken? Is there a fixed release? The "expr" test hits not only for 3.5 but also for 3.5.1. 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 Tue Dec 10 15:15:26 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 10 Dec 2019 15:15:26 +0100 Subject: [gnutls-help] nettle_cfb8_decrypt and nettle 5.1 In-Reply-To: <20191207130753.GA1435@argenau.bebt.de> References: <20191207130753.GA1435@argenau.bebt.de> Message-ID: On Sat, Dec 7, 2019 at 2:26 PM Andreas Metzler wrote: > > Hello, > > gnutls 3.6.11 introduces this change in > 98ac6220bdef67ba1153dc515613e4582e1419a2 "nettle: use included CFB8 > implementation if nettle is 3.5": > > configure.ac > # Check if nettle has CFB8 support > +if test -z "$ac_cv_func_nettle_cfb8_encrypt"; then > + # nettle_cfb8_decrypt in nettle 3.5 is known to be broken > + ver=`$PKG_CONFIG --modversion nettle` > + if expr "$ver" : '^3\.5\b' >/dev/null; then > + ac_cv_func_nettle_cfb8_encrypt=no > + fi > +fi > > Which versions of nettle are broken? Is there a fixed release? > The "expr" test hits not only for 3.5 but also for 3.5.1. I believe it is every released version of nettle which includes cfb8. I think the 3.5.x match is intentional as the .1 releases in nettle are made only for targeted fixes and may not include the cfb8 fix. regards, Nikos From nmav at gnutls.org Tue Dec 10 15:22:35 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 10 Dec 2019 15:22:35 +0100 Subject: [gnutls-help] certtool and add_extension In-Reply-To: References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> Message-ID: Could you minimize the commands needed to reproduce the issue you are describing? If I do: $ echo add_extension = "7.0.1.5 octet_string(CAFEBEAF) >>tmpl $ certtool --generate-privkey --outfile key $ certtool --generate-self-signed --template tmpl --load-privkey key I see: Unknown extension 7.0.1.5 (not critical): ASCII: ...... Hexdump: 0404cafebeaf regards, Nikos On Fri, Dec 6, 2019 at 3:57 PM Nicolas Mora wrote: > > Hello, > > 6 d?cembre 2019 04:54 "Nikos Mavrogiannopoulos" a ?crit: > > > You may want to check your gnutls version. This template option was > > added at 3.5.3. > > > Nevertheless, I use a Debian Buster with gnutls 3.6.7 > > Here is a gist with the script and template files I use for my demonstration: > https://gist.github.com/babelouest/0c5076462d52f8ecf7c33c9862681687 > > The log file output is attached, and more specifically, the client certificate output is: > > Generating a signed certificate... > X.509 Certificate Information: > Version: 3 > Serial Number (hex): 736c577633f2962c130569396e9c8532394975ea > Validity: > Not Before: Fri Dec 06 14:30:20 UTC 2019 > Not After: Fri Nov 20 14:30:20 UTC 2020 > Subject: C=CA,O=babelouest,OU=Authenticator Attestation,CN=glewlwyd_packed > Subject Public Key Algorithm: EC/ECDSA > Algorithm Security Level: High (256 bits) > Curve: SECP256R1 > X: > 3d:ca:36:10:58:e0:f0:49:cc:61:47:57:ac:ee:83:60 > 45:29:c2:23:ab:50:1f:00:50:1b:9e:8e:51:e4:e7:8d > Y: > 58:e4:9c:5f:81:c0:dd:d7:44:8b:c9:a2:b4:04:48:16 > d0:f1:86:46:d2:b5:2b:be:9b:f5:ce:76:af:3a:65:e7 > Extensions: > Basic Constraints (critical): > Certificate Authority (CA): FALSE > Key Usage (critical): > Digital signature. > Subject Key Identifier (not critical): > 945473da3bfe497d2b712dc3cef6e4a692be8b29 > Authority Key Identifier (not critical): > 6e245f7b8f84bb602631dc9b3a33af2fb58670f3 > Other Information: > Public Key ID: > sha1:945473da3bfe497d2b712dc3cef6e4a692be8b29 > sha256:9cccc45cc2996175ed3567a0033ef413309228d78b5364b8270ad962f14d49a0 > Public Key PIN: > pin-sha256:nMzEXMKZYXXtNWegAz70EzCSKNeLU2S4JwrZYvFNSaA= From ametzler at bebt.de Tue Dec 10 19:23:02 2019 From: ametzler at bebt.de (Andreas Metzler) Date: Tue, 10 Dec 2019 19:23:02 +0100 Subject: [gnutls-help] nettle_cfb8_decrypt and nettle 5.1 In-Reply-To: References: <20191207130753.GA1435@argenau.bebt.de> Message-ID: <20191210182302.GB1711@argenau.bebt.de> On 2019-12-10 Nikos Mavrogiannopoulos wrote: > On Sat, Dec 7, 2019 at 2:26 PM Andreas Metzler wrote: > > gnutls 3.6.11 introduces this change in > > 98ac6220bdef67ba1153dc515613e4582e1419a2 "nettle: use included CFB8 > > implementation if nettle is 3.5": > > > > configure.ac > > # Check if nettle has CFB8 support > > +if test -z "$ac_cv_func_nettle_cfb8_encrypt"; then > > + # nettle_cfb8_decrypt in nettle 3.5 is known to be broken > > + ver=`$PKG_CONFIG --modversion nettle` > > + if expr "$ver" : '^3\.5\b' >/dev/null; then > > + ac_cv_func_nettle_cfb8_encrypt=no > > + fi > > +fi > > Which versions of nettle are broken? Is there a fixed release? > > The "expr" test hits not only for 3.5 but also for 3.5.1. > I believe it is every released version of nettle which includes cfb8. > I think the 3.5.x match is intentional as the .1 releases in nettle > are made only for targeted fixes and may not include the cfb8 fix. Hello, okay. I was asking because 3.5.1 /was/ released. But as you suspected there is no cf8 change included. 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 nicolas at babelouest.org Wed Dec 11 15:48:30 2019 From: nicolas at babelouest.org (Nicolas Mora) Date: Wed, 11 Dec 2019 14:48:30 +0000 Subject: [gnutls-help] certtool and add_extension In-Reply-To: References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> Message-ID: <6f8904bbb7968b7ecce8a0e237856429@babelouest.org> 10 d?cembre 2019 09:22 "Nikos Mavrogiannopoulos" a ?crit: > Could you minimize the commands needed to reproduce the issue you are > describing? > Here is a minimal set of commands to reproduce the problem: # Generate the ca certificate echo add_extension = "1.3.6.1.4.1.45724.1.1.4 octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" >>tmpl certtool --generate-privkey --outfile ca.key certtool --generate-self-signed --load-privkey ca.key --outfile ca.cert --template tmpl # generate the client key certtool --generate-privkey --outfile signed.key # Example 1: create a signed certificate without request certtool --generate-certificate --load-privkey signed.key --outfile signed.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key --template tmpl # Example 2: create a signed certificate with request certtool --generate-request --load-privkey signed.key --outfile signed-r.csr --template tmpl certtool --generate-certificate --load-request signed-r.csr --load-privkey signed.key --outfile signed-r.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key --template tmpl On the example 1, if I create a certificate signed with the ca.cert file without generating the request file first, the signed certificate contains the extension. On the example 2, if I create a certificate signed with the ca.cert file using the request, the signed certificate doesn't contain the extension /Nicolas From nmav at gnutls.org Thu Dec 12 07:07:11 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 12 Dec 2019 07:07:11 +0100 Subject: [gnutls-help] certtool and add_extension In-Reply-To: <6f8904bbb7968b7ecce8a0e237856429@babelouest.org> References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> <6f8904bbb7968b7ecce8a0e237856429@babelouest.org> Message-ID: On Wed, 2019-12-11 at 14:48 +0000, Nicolas Mora wrote: > 10 d?cembre 2019 09:22 "Nikos Mavrogiannopoulos" a > ?crit: > > > Could you minimize the commands needed to reproduce the issue you > > are > > describing? > > > Here is a minimal set of commands to reproduce the problem: > > # Generate the ca certificate > echo add_extension = "1.3.6.1.4.1.45724.1.1.4 > octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" >>tmpl > certtool --generate-privkey --outfile ca.key > certtool --generate-self-signed --load-privkey ca.key --outfile > ca.cert --template tmpl > > # generate the client key > certtool --generate-privkey --outfile signed.key > > # Example 1: create a signed certificate without request > certtool --generate-certificate --load-privkey signed.key --outfile > signed.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key -- > template tmpl > > # Example 2: create a signed certificate with request > certtool --generate-request --load-privkey signed.key --outfile > signed-r.csr --template tmpl > certtool --generate-certificate --load-request signed-r.csr --load- > privkey signed.key --outfile signed-r.cert --load-ca-certificate > ca.cert --load-ca-privkey ca.key --template tmpl > > On the example 1, if I create a certificate signed with the ca.cert > file without generating the request file first, the signed > certificate contains the extension. > On the example 2, if I create a certificate signed with the ca.cert > file using the request, the signed certificate doesn't contain the > extension When generating a certificate from a certificate request you should add: honor_crq_extensions to the template. Otherwise they are ignored. regards, Nikos From nmav at gnutls.org Thu Dec 12 09:50:34 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 12 Dec 2019 09:50:34 +0100 Subject: [gnutls-help] certtool and add_extension In-Reply-To: References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org> <6f8904bbb7968b7ecce8a0e237856429@babelouest.org> Message-ID: Hmm, actually what was the intention? Was the intention to read the extension from the certificate request, or to read the extension from the certificate template on the last step? On Thu, Dec 12, 2019 at 7:07 AM Nikos Mavrogiannopoulos wrote: > > On Wed, 2019-12-11 at 14:48 +0000, Nicolas Mora wrote: > > 10 d?cembre 2019 09:22 "Nikos Mavrogiannopoulos" a > > ?crit: > > > > > Could you minimize the commands needed to reproduce the issue you > > > are > > > describing? > > > > > Here is a minimal set of commands to reproduce the problem: > > > > # Generate the ca certificate > > echo add_extension = "1.3.6.1.4.1.45724.1.1.4 > > octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" >>tmpl > > certtool --generate-privkey --outfile ca.key > > certtool --generate-self-signed --load-privkey ca.key --outfile > > ca.cert --template tmpl > > > > # generate the client key > > certtool --generate-privkey --outfile signed.key > > > > # Example 1: create a signed certificate without request > > certtool --generate-certificate --load-privkey signed.key --outfile > > signed.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key -- > > template tmpl > > > > # Example 2: create a signed certificate with request > > certtool --generate-request --load-privkey signed.key --outfile > > signed-r.csr --template tmpl > > certtool --generate-certificate --load-request signed-r.csr --load- > > privkey signed.key --outfile signed-r.cert --load-ca-certificate > > ca.cert --load-ca-privkey ca.key --template tmpl > > > > On the example 1, if I create a certificate signed with the ca.cert > > file without generating the request file first, the signed > > certificate contains the extension. > > On the example 2, if I create a certificate signed with the ca.cert > > file using the request, the signed certificate doesn't contain the > > extension > > When generating a certificate from a certificate request you should > add: > honor_crq_extensions > > to the template. Otherwise they are ignored. > > regards, > Nikos > > From xnox at ubuntu.com Mon Dec 16 03:46:37 2019 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Mon, 16 Dec 2019 02:46:37 +0000 Subject: [gnutls-help] "built-in" gnutls config, with optional-only config file on disk Message-ID: In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind of like how on Fedora it is set to "@SYSTEM" and then a system config file defines what that actually means. Allowing users to override that system-wide. However, there are a few issues with that. It creates a hard dependency between libgnutls and config file on disk, and said config file must always specify [priorities] SYSTEM=, as otherwise setting default priorities fails. (and apparmor profile must allow reading said config, etc.) Prime example, gnutls testuite fails, as it uses a custom tests/system.prio without SYSTEM= specified. And for example, one can see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio' is done to unbreak the testsuite. It also means, that if one copies all the library dependencies of an app, without the config file into chroot/initrd/container/etc one may get non-working gnutls, or the one that behaves differently. Is there a way to provide built-in compiled defaults that operate with or without a config file on disk? I.e. something like use @SYSTEM if exists, otherwise fallback to "NORMAL"? That way, with or without config, default behaviour is the same, setting default-priority always works and users can still override it. What about for the other overrides? I.e. can one somehow compile-in default [overrides] that is used, unless system config specifies one? I.e. built-in config specifying [overrides] disabled-versions=tls1.0, with users able to turn it back on by creating the config and specifying like empty [overrides] paragraph, or like using reenable-versions=tls1.0. Maybe I am overthinking all of this, and what I really want is simply support for [overrides] default-priority-string = NORMAL Whilst the library itself is compiled with something stronger, i.e. --with-default-priority-string='NORMAL:-VERS-TLS1.0'. -- Regards, Dimitri. From nmav at gnutls.org Mon Dec 16 21:22:56 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Dec 2019 21:22:56 +0100 Subject: [gnutls-help] "built-in" gnutls config, with optional-only config file on disk In-Reply-To: References: Message-ID: On Mon, Dec 16, 2019 at 4:17 AM Dimitri John Ledkov wrote: > > In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind > of like how on Fedora it is set to "@SYSTEM" and then a system config > file defines what that actually means. Allowing users to override that > system-wide. > > However, there are a few issues with that. It creates a hard > dependency between libgnutls and config file on disk, and said config > file must always specify [priorities] SYSTEM=, as otherwise setting > default priorities fails. (and apparmor profile must allow reading > said config, etc.) > Prime example, gnutls testuite fails, as it uses a custom > tests/system.prio without SYSTEM= specified. And for example, one can > see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio' > is done to unbreak the testsuite. > > It also means, that if one copies all the library dependencies of an > app, without the config file into chroot/initrd/container/etc one may > get non-working gnutls, or the one that behaves differently. > > Is there a way to provide built-in compiled defaults that operate with > or without a config file on disk? I.e. something like use @SYSTEM if > exists, otherwise fallback to "NORMAL"? That way, with or without > config, default behaviour is the same, setting default-priority always > works and users can still override it. I believe you can do what you describe by specifying a priority string to applications as "@SYSTEM,NORMAL". With that, the fallback policy will be the default NORMAL. However that has the drawback that you cannot know which profile each application will be using. It would be quite difficult to tell the system state and the expected outcome of a connection. > What about for the other overrides? I.e. can one somehow compile-in > default [overrides] that is used, unless system config specifies one? > I.e. built-in config specifying [overrides] disabled-versions=tls1.0, > with users able to turn it back on by creating the config and > specifying like empty [overrides] paragraph, or like using > reenable-versions=tls1.0. > > Maybe I am overthinking all of this, and what I really want is simply > support for > [overrides] > default-priority-string = NORMAL > Whilst the library itself is compiled with something stronger, i.e. > --with-default-priority-string='NORMAL:-VERS-TLS1.0'. That sounds like something reasonable. There is an ongoing coversation on how to handle national standards like GOST with a similar mechanism at: https://gitlab.com/gnutls/gnutls/merge_requests/1119 Would you like to move that discussion there so that we combine the requirements? regards, Nikos From xnox at ubuntu.com Tue Dec 31 16:48:13 2019 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Tue, 31 Dec 2019 15:48:13 +0000 Subject: [gnutls-help] "built-in" gnutls config, with optional-only config file on disk In-Reply-To: References: Message-ID: On Mon, 16 Dec 2019 at 20:23, Nikos Mavrogiannopoulos wrote: > > On Mon, Dec 16, 2019 at 4:17 AM Dimitri John Ledkov wrote: > > > > In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind > > of like how on Fedora it is set to "@SYSTEM" and then a system config > > file defines what that actually means. Allowing users to override that > > system-wide. > > > > However, there are a few issues with that. It creates a hard > > dependency between libgnutls and config file on disk, and said config > > file must always specify [priorities] SYSTEM=, as otherwise setting > > default priorities fails. (and apparmor profile must allow reading > > said config, etc.) > > Prime example, gnutls testuite fails, as it uses a custom > > tests/system.prio without SYSTEM= specified. And for example, one can > > see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio' > > is done to unbreak the testsuite. > > > > It also means, that if one copies all the library dependencies of an > > app, without the config file into chroot/initrd/container/etc one may > > get non-working gnutls, or the one that behaves differently. > > > > Is there a way to provide built-in compiled defaults that operate with > > or without a config file on disk? I.e. something like use @SYSTEM if > > exists, otherwise fallback to "NORMAL"? That way, with or without > > config, default behaviour is the same, setting default-priority always > > works and users can still override it. > > I believe you can do what you describe by specifying a priority string > to applications as "@SYSTEM,NORMAL". With that, the fallback policy > will be the default NORMAL. However that has the drawback that you > cannot know which profile each application will be using. It would be > quite difficult to tell the system state and the expected outcome of a > connection. > Just that works, but it's not that useful. What I reallly wanted was something like: @ SYSTEM,NORMAL%PROFILE_MEDIUM But that fails.... |<2>| cfg: system priority /etc/gnutls/config has not changed |<2>| resolved 'SYSTEM' to '', next 'NORMAL%PROFILE_MEDIUM' |<2>| cfg: system priority /etc/gnutls/config has not changed |<2>| resolved 'NORMAL%PROFILE_MEDIUM' to '', next '' |<2>| unable to resolve @SYSTEM,NORMAL%PROFILE_MEDIUM I can do @SYSTEM,NORMAL:%PROFILE_MEDIUM but that is not quite the same, as it resolves to NORMAL:%PROFILE_MEDIUM or SYSTEM:%PROFILE_MEDIUM. I.e. people will not be able to negate %PROFILE_MEDIUM. I.e. users can only prepend, but not append things. I kind of wish for --priority='NORMAL:%PROFILE_MEDIUM:@SYSTEM,NONE' But that too fails to parse with: Syntax error at: @SYSTEM,NONE > > What about for the other overrides? I.e. can one somehow compile-in > > default [overrides] that is used, unless system config specifies one? > > I.e. built-in config specifying [overrides] disabled-versions=tls1.0, > > with users able to turn it back on by creating the config and > > specifying like empty [overrides] paragraph, or like using > > reenable-versions=tls1.0. > > > > Maybe I am overthinking all of this, and what I really want is simply > > support for > > [overrides] > > default-priority-string = NORMAL > > Whilst the library itself is compiled with something stronger, i.e. > > --with-default-priority-string='NORMAL:-VERS-TLS1.0'. > > That sounds like something reasonable. There is an ongoing coversation > on how to handle national standards like GOST with a similar mechanism > at: > https://gitlab.com/gnutls/gnutls/merge_requests/1119 > Would you like to move that discussion there so that we combine the > requirements? Possibly. At the moment I do not see any better way than to introduce [overrides]default-priority-string in the config file. As I want NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:%PROFILE_MEDIUM as the compiled-in default but a way for users to override this behaviour in a config file, which I don't see a way to do at the moment. Also there isn't a compiled-in default for the [overrides] verify-profile key, nor for the compiled-in [overrides] disabled-version key, nor a way to reenable compiled-in disabled-versions. Imho, any library should have sensible compiled-in defaults, which can be overridden with config files, such that one can have "available, but disabled by default" algos / protocol version / profile levels / etc, which users can opt-into anyway. This is separete to choosing to not even compile unwanted protocol versions (i.e. just disable tls1.3 at build time, and not include that functionality in the library at all). I wonder if as a distribution, I should be changing what "NORMAL" means. And compile gnutls with @SYSTEM,NORMAL, and change such that NORMAL means TLS1.2+ %PROFILE_MEDIUM with a distro patch. -- Regards, Dimitri.