From n.mavrogiannopoulos at gmail.com Fri Oct 13 13:50:58 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 13 Oct 2017 13:50:58 +0200 Subject: [gnutls-devel] support of stapled OCSP responses under TLS1.3 Message-ID: Hi, I'm going through the support of stapled OCSP responses under TLS1.3. The major change in TLS1.3 is that there can be an OCSP response for each certificate sent, rather than one response for the end-certificate, and such responses can be provided also for the client certificate. Supporting multiple responses when verifying the certificates seems straightforward as we were doing that transparently without the application intervening. On the server side, the APIs we provide at the moment to set responses are: int gnutls_certificate_set_ocsp_status_request_function2 (gnutls_certificate_credentials_t res, unsigned idx, gnutls_status_request_ocsp_func ocsp_func, void *ptr); int gnutls_certificate_set_ocsp_status_request_file (gnutls_certificate_credentials_t res, const char *response_file, unsigned idx); That is, a function to set a callback, and another to set a response from file. The index (idx) in both cases is the index of the certificate chain for servers with multiple end-certificates (e.g., an rsa and an ecdsa one). Now, the question is how can we handle the multiple responses per chain? The functions above can be used to obtain a single item per session. I think that the current interfaces are beyond saving. So I'm considering the following: 1. Provide another certificate retrieval callback, replacing gnutls_certificate_retrieve_function2() with gnutls_certificate_retrieve_function3(), which will retrieve the certificate and key in addition to certificate status request. 2. Enhance gnutls_certificate_set_ocsp_status_request_file to read the OCSP response and associate with the appropriate certificate in the chain. That would allow applications which first loaded the certificates, to call the set_status_request_file() multiple times, to set the files which correspond to certificates in the chain. What do you think? Would that leave any applications using gnutls unable to take advantage of OCSP status responses? Any other suggestions? regards, Nikos From jgh at wizmail.org Fri Oct 13 14:10:45 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 13 Oct 2017 13:10:45 +0100 Subject: [gnutls-devel] support of stapled OCSP responses under TLS1.3 In-Reply-To: References: Message-ID: On 13/10/17 12:50, Nikos Mavrogiannopoulos wrote: > Any other > suggestions? Cache the ocsp status in memory, for some time bounded by (but in general we perhaps want less than?) the status validity. -- Cheers, Jeremy From lubomir.carik at gmail.com Sat Oct 14 05:08:25 2017 From: lubomir.carik at gmail.com (=?UTF-8?B?xL11Ym9tw61yIENhcmlr?=) Date: Sat, 14 Oct 2017 05:08:25 +0200 Subject: [gnutls-devel] support of stapled OCSP responses under TLS1.3 In-Reply-To: References: Message-ID: drevo!++$ 2017-10-13 14:10 GMT+02:00 Jeremy Harris : > On 13/10/17 12:50, Nikos Mavrogiannopoulos wrote: > > Any other > > suggestions? > > Cache the ocsp status in memory, for some time bounded by > (but in general we perhaps want less than?) the status > validity. > > -- > Cheers, > Jeremy > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Oct 16 12:24:30 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Oct 2017 12:24:30 +0200 Subject: [gnutls-devel] support of stapled OCSP responses under TLS1.3 In-Reply-To: References: Message-ID: On Fri, Oct 13, 2017 at 2:10 PM, Jeremy Harris wrote: > On 13/10/17 12:50, Nikos Mavrogiannopoulos wrote: >> Any other >> suggestions? > > Cache the ocsp status in memory, for some time bounded by > (but in general we perhaps want less than?) the status > validity. That looks like a good optimization. It is not though directly related to TLS1.3 or multiple OCSP responses, thus it may be better to track it as a separate issue. Would you like to create a new issue at the issue tracker? [0]. https://gitlab.com/gnutls/gnutls/issues From jgh at wizmail.org Mon Oct 16 12:58:42 2017 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 16 Oct 2017 11:58:42 +0100 Subject: [gnutls-devel] support of stapled OCSP responses under TLS1.3 In-Reply-To: References: Message-ID: <0c41141c-f704-5846-5a01-8ff17806f7b4@wizmail.org> On 16/10/17 11:24, Nikos Mavrogiannopoulos wrote: > That looks like a good optimization. It is not though directly related > to TLS1.3 or multiple OCSP responses, thus it may be better to track > it as a separate issue. Would you like to create a new issue at the > issue tracker? Done, #309 -J From nmav at gnutls.org Mon Oct 16 13:31:02 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Oct 2017 13:31:02 +0200 Subject: [gnutls-devel] support of stapled OCSP responses under TLS1.3 In-Reply-To: <0c41141c-f704-5846-5a01-8ff17806f7b4@wizmail.org> References: <0c41141c-f704-5846-5a01-8ff17806f7b4@wizmail.org> Message-ID: On Mon, Oct 16, 2017 at 12:58 PM, Jeremy Harris wrote: > On 16/10/17 11:24, Nikos Mavrogiannopoulos wrote: >> That looks like a good optimization. It is not though directly related >> to TLS1.3 or multiple OCSP responses, thus it may be better to track >> it as a separate issue. Would you like to create a new issue at the >> issue tracker? > > Done, #309 Thank you. From thomas2.klute at uni-dortmund.de Wed Oct 18 19:57:39 2017 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Wed, 18 Oct 2017 19:57:39 +0200 Subject: [gnutls-devel] [PATCH] gnutls_server_name_set: Clarify meaning of the name_length parameter Message-ID: Hi, please commit the attached clarification. I fell into that trap while implementing SNI for proxy connections in mod_gnutls. ;-) Best regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gnutls_server_name_set-Clarify-meaning-of-the-name_l.patch Type: text/x-patch Size: 1029 bytes Desc: not available URL: From nmav at gnutls.org Thu Oct 19 10:02:41 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 19 Oct 2017 10:02:41 +0200 Subject: [gnutls-devel] [PATCH] gnutls_server_name_set: Clarify meaning of the name_length parameter In-Reply-To: References: Message-ID: Thank you. Applied. On Wed, Oct 18, 2017 at 7:57 PM, Thomas Klute wrote: > Hi, > > please commit the attached clarification. I fell into that trap while > implementing SNI for proxy connections in mod_gnutls. ;-) > > Best regards, > Thomas > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Sat Oct 21 09:41:38 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Oct 2017 09:41:38 +0200 Subject: [gnutls-devel] gnutls 3.5.16 Message-ID: <1508571698.3494.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.16. This is a bug fix release on the current stable branch. Note that, I've also switched the release cadence to bi-monthly as less and less bug fixes/updates accumulate each month on this branch. * Version 3.5.16 (released 2017-10-21) ** libgnutls: Fixed issue which causes 1-byte handshake fragments to be refused. ???Reported by Bal?zs K?ri. ** libgnutls: Refuse to resume a session which had a different SNI advertised. That ???improves RFC6066 support in server side. Reported by Thomas Klute. ** libgnutls: Fixed interoperability issue with openssl when safe renegotiation was ???used. Resolves gitlab issue #259. ** libgnutls: When selecting a client side signature algorithm, prefer the signature ???schemes in the enabled list (Since 3.5.5 client certificates can be used even ???if they contain disallowed algorithms for a session, to allow utilizing old ???client certificates -like DSA-SHA1 without enabling DSA for the server certificate). ** p11tool: The options --set-pin and --set-so-pin can be used with all operations ???not only with --initialize. ** p11tool: Mark all generated objects as sensitive by default. ** certtool: Enable certificate fingerprint generation with sha512 (#295). ** 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.16.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.16.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 Sat Oct 21 09:51:47 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Oct 2017 09:51:47 +0200 Subject: [gnutls-devel] gnutls 3.6.1 Message-ID: <1508572307.3494.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.6.1. This is a bug fix release for the 3.6.x branch. The releases on this branch will continue on a bi-monthly period. * Version 3.6.1 (released 2017-10-21) ** libgnutls: Fixed interoperability issue with openssl when safe renegotiation was ???used. Resolves gitlab issue #259. ** libgnutls: gnutls_x509_crl_sign, gnutls_x509_crt_sign, ???gnutls_x509_crq_sign, were modified to sign with a better algorithm than ???SHA1. They will now sign with an algorithm that corresponds to the security ???level of the signer's key. ** libgnutls: gnutls_x509_*_sign2() functions and gnutls_x509_*_privkey_sign() ???accept GNUTLS_DIG_UNKNOWN (0) as a hash function option. That will signal ???the function to auto-detect an appropriate hash algorithm to use. ** libgnutls: Removed support for signature algorithms using SHA2-224 in TLS. ???TLS 1.3 no longer uses SHA2-224 and it was never a widespread algorithm ???in TLS 1.2. As such, no reason to keep supporting it. ** libgnutls: Refuse to use client certificates containing disallowed ???algorithms for a session. That reverts a change on 3.5.5, which allowed ???a client to use DSA-SHA1 due to his old DSA certificate, without requiring him ???to enable DSA-SHA1 (and thus make it acceptable for the server's certificate). ???The previous approach was to allow a smooth move for client infrastructure ???after the DSA algorithm became disabled by default, and is no longer necessary ???as DSA is now being universally depracated. ** libgnutls: Refuse to resume a session which had a different SNI advertised. That improves RFC6066 support in server side. Reported by Thomas Klute. ** p11tool: Mark all generated objects as sensitive by default. ** p11tool: added options --sign-params and --hash. This allows testing ???signature with multiple algorithms, including RSA-PSS. ** 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.6.1.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.6.1.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 noloader at gmail.com Sun Oct 22 07:57:26 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 22 Oct 2017 01:57:26 -0400 Subject: [gnutls-devel] How to get more verbosity from 'make check' Message-ID: Hi Everyone, I'm working through some failed self tests for GnuTLS 3.5.15. The project was configured with Autotools: --prefix=/usr/local --libdir=/usr/local/lib64 The Autotools configuration also includes CPPFLAGS="-I/usr/local/include -DNDEBUG" ... LDFLAGS="-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64" When I examine the output artifacts, I see gnutls-cli is using the expected libraries: $ LD_LIBRARY_PATH="lib/.libs" ldd src/.libs/gnutls-cli linux-vdso.so.1 (0x00007ffdcdf51000) libgnutls.so.30 => lib/.libs/libgnutls.so.30 (0x00007fc618237000) libgnutls-dane.so.0 => not found libidn2.so.0 => /usr/local/lib64/libidn2.so.0 (0x00007fc618019000) libc.so.6 => /lib64/libc.so.6 (0x00007fc617c48000) libz.so.1 => /usr/local/lib64/libz.so.1 (0x00007fc617a2a000) libp11-kit.so.0 => /usr/local/lib64/libp11-kit.so.0 (0x00007fc6177bd000) libunistring.so.2 => /usr/local/lib64/libunistring.so.2 (0x00007fc617435000) libiconv.so.2 => /usr/local/lib64/libiconv.so.2 (0x00007fc617145000) ... I have not been able to run `make install` because the library has not passed `make check`. I can't tell if the self tests and programs like gnutls-cli are being run with LD_LIBRARY_PATH="lib/.libs". I ran them with `make check V=1` but I don't see the output other than PASS? or FAIL. For example: $ make check V=1 ... PASS: tls-rehandshake-cert-2 PASS: custom-urls ../build-aux/test-driver: line 107: 29109 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: set_x509_key_mem ../build-aux/test-driver: line 107: 29119 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: set_x509_key_file PASS: mini-chain-unsorted PASS: x509-verify-with-crl PASS: mini-dtls-mtu ../build-aux/test-driver: line 107: 29158 Segmentation fault (core dumped) "$@" > $log_file 2>&1 FAIL: privkey-verify-broken PASS: mini-dtls-record-asym PASS: openpgp-callback The lack of verbosity makes it hard to determine what file is being run, and determine the environment its being run in. If I knew what file was being run and its environment like LD_LIBRARY_PATH, then I could do things like run it myself under a debugger. How do I have `make check` display its output verbosely ? Thanks in advance. Jeff From tim.ruehsen at gmx.de Sun Oct 22 12:23:26 2017 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Sun, 22 Oct 2017 12:23:26 +0200 Subject: [gnutls-devel] How to get more verbosity from 'make check' In-Reply-To: References: Message-ID: <1640478.rtWsDCPmP4@debian> On Sonntag, 22. Oktober 2017 01:57:26 CEST Jeffrey Walton wrote: > Hi Everyone, > > I'm working through some failed self tests for GnuTLS 3.5.15. The > project was configured with Autotools: > > --prefix=/usr/local > --libdir=/usr/local/lib64 > > The Autotools configuration also includes > > CPPFLAGS="-I/usr/local/include -DNDEBUG" > ... > LDFLAGS="-Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64" > > When I examine the output artifacts, I see gnutls-cli is using the > expected libraries: > > $ LD_LIBRARY_PATH="lib/.libs" ldd src/.libs/gnutls-cli > linux-vdso.so.1 (0x00007ffdcdf51000) > libgnutls.so.30 => lib/.libs/libgnutls.so.30 (0x00007fc618237000) > libgnutls-dane.so.0 => not found > libidn2.so.0 => /usr/local/lib64/libidn2.so.0 (0x00007fc618019000) > libc.so.6 => /lib64/libc.so.6 (0x00007fc617c48000) > libz.so.1 => /usr/local/lib64/libz.so.1 (0x00007fc617a2a000) > libp11-kit.so.0 => /usr/local/lib64/libp11-kit.so.0 (0x00007fc6177bd000) > libunistring.so.2 => /usr/local/lib64/libunistring.so.2 > (0x00007fc617435000) libiconv.so.2 => /usr/local/lib64/libiconv.so.2 > (0x00007fc617145000) ... > > I have not been able to run `make install` because the library has not > passed `make check`. > > I can't tell if the self tests and programs like gnutls-cli are being > run with LD_LIBRARY_PATH="lib/.libs". I ran them with `make check V=1` > but I don't see the output other than PASS? or FAIL. For example: > > $ make check V=1 > ... > PASS: tls-rehandshake-cert-2 > PASS: custom-urls > ../build-aux/test-driver: line 107: 29109 Segmentation fault > (core dumped) "$@" > $log_file 2>&1 > FAIL: set_x509_key_mem > ../build-aux/test-driver: line 107: 29119 Segmentation fault > (core dumped) "$@" > $log_file 2>&1 > FAIL: set_x509_key_file > PASS: mini-chain-unsorted > PASS: x509-verify-with-crl > PASS: mini-dtls-mtu > ../build-aux/test-driver: line 107: 29158 Segmentation fault > (core dumped) "$@" > $log_file 2>&1 > FAIL: privkey-verify-broken > PASS: mini-dtls-record-asym > PASS: openpgp-callback > > The lack of verbosity makes it hard to determine what file is being > run, and determine the environment its being run in. If I knew what > file was being run and its environment like LD_LIBRARY_PATH, then I > could do things like run it myself under a debugger. > > How do I have `make check` display its output verbosely ? Hi Jeff, make [check] V=1 switches verbose output on just for the build steps (e.g. compile + link commands). To see the logs from the test run, cd into the appropriate test directory and e.g. 'more set_x509_key_file.log'. If that isn't enough, build everything with -g (include debug symbols) and run the tests again with valgrind: 'make check LOG_COMPILER=valgrind'. But AFAIR, gnutls uses valgrind by default (see ./configure --help|grep valgrind). You can even run single tests: - cd into the appropriate test directory - e.g. 'make check TESTS=set_x509_key_file' Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: