From nmav at gnutls.org Sat Feb 1 23:36:18 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 01 Feb 2020 23:36:18 +0100 Subject: [gnutls-help] gnutls 3.6.12 Message-ID: <01aa71a9aab71871c014d00800bf37ce68c8be60.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 Baryshkov, Tim R?hsen, Daiki Ueno, Dimitri John Ledkov, Andreas Metzler, Bjoern Jacke, Edward Stangler, Fiona Klute, Lili Quan, Ludovic Court?s, and Vitezslav Cizek. The detailed list of changes follows; they can be seen in more detail in our milestone tracker: https://gitlab.com/gnutls/gnutls/-/milestones/26 Changes ======= * Version 3.6.12 (released 2020-02-01) ** libgnutls: Introduced TLS session flag (gnutls_session_get_flags()) to identify sessions that client request OCSP status request (#829). ** libgnutls: Added support for X448 key exchange (RFC 7748) and Ed448 signature algorithm (RFC 8032) under TLS (#86). ** libgnutls: Added the default-priority-string option to system configuration; it allows overriding the compiled-in default-priority-string. ** libgnutls: Added support for GOST CNT_IMIT ciphersuite (as defined by draft-smyshlyaev-tls12-gost-suites-07). By default this ciphersuite is disabled. It can be enabled by adding +GOST to priority string. In the future this priority string may enable other GOST ciphersuites as well. Note, that server will fail to negotiate GOST ciphersuites if TLS 1.3 is enabled both on a server and a client. It is recommended for now to disable TLS 1.3 in setups where GOST ciphersuites are enabled on GnuTLS-based servers. ** libgnutls: added priority shortcuts for different GOST categories like CIPHER-GOST-ALL, MAC-GOST-ALL, KX-GOST-ALL, SIGN-GOST-ALL, GROUP-GOST-ALL. ** libgnutls: Reject certificates with invalid time fields. That is we reject certificates with invalid characters in Time fields, or invalid time formatting To continue accepting the invalid form compile with --disable-strict-der-time (#207, #870). ** libgnutls: Reject certificates which contain duplicate extensions. We were previously printing warnings when printing such a certificate, but that is not always sufficient to flag such certificates as invalid. Instead we now refuse to import them (#887). ** libgnutls: If a CA is found in the trusted list, check in addition to time validity, whether the algorithms comply to the expected level prior to accepting it. This addresses the problem of accepting CAs which would have been marked as insecure otherwise (#877). ** libgnutls: The min-verification-profile from system configuration applies for all certificate verifications, not only under TLS. The configuration can be overriden using the GNUTLS_SYSTEM_PRIORITY_FILE environment variable. ** libgnutls: The stapled OCSP certificate verification adheres to the convention used throughout the library of setting the 'GNUTLS_CERT_INVALID' flag. ** libgnutls: On client side only send OCSP staples if they have been requested by the server, and on server side always advertise that we support OCSP stapling (#876). ** libgnutls: Introduced the gnutls_ocsp_req_const_t which is compatible with gnutls_ocsp_req_t but const. ** certtool: Added the --verify-profile option to set a certificate verification profile. Use '--verify-profile low' for certificate verification to apply the 'NORMAL' verification profile. ** certtool: The add_extension template option is considered even when generating a certificate from a certificate request. ** API and ABI modifications: GNUTLS_SFLAGS_CLI_REQUESTED_OCSP: Added GNUTLS_SFLAGS_SERV_REQUESTED_OCSP: Added gnutls_ocsp_req_const_t: Added Getting the Software ==================== GnuTLS may be downloaded directly from < ftp://ftp.gnutls.org/gcrypt/gnutls/>;. A list of GnuTLS mirrors can be found at < http://www.gnutls.org/download.html> Here are the XZ compressed sources: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.12.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.12.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 tim.ruehsen at gmx.de Sun Feb 2 11:23:51 2020 From: tim.ruehsen at gmx.de (=?UTF-8?Q?Tim_R=c3=bchsen?=) Date: Sun, 2 Feb 2020 11:23:51 +0100 Subject: [gnutls-help] [gnutls-devel] gnutls 3.6.12 In-Reply-To: References: Message-ID: <2a333080-d057-a066-fc1c-b884fe95726a@gmx.de> On 01.02.20 23:36, Development of GNU's TLS library wrote: > Hello, > I've just released gnutls 3.6.11. This is a bug fix release on the > stable 3.6.x branch. 3.6.11 -> 3.6.12 ;-) Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From xnox at ubuntu.com Tue Feb 4 14:25:49 2020 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Tue, 4 Feb 2020 13:25:49 +0000 Subject: [gnutls-help] gnutls 3.6.12 In-Reply-To: <01aa71a9aab71871c014d00800bf37ce68c8be60.camel@gnutls.org> References: <01aa71a9aab71871c014d00800bf37ce68c8be60.camel@gnutls.org> Message-ID: On Sat, 1 Feb 2020 at 22:36, Nikos Mavrogiannopoulos wrote: > > Hello, > I've just released gnutls 3.6.11. This is a bug fix release on the > stable 3.6.x branch. > I've now noticed that CI tests are gone from the tarball that are used in Debian CI ( https://ci.debian.net/packages/g/gnutls28/unstable/amd64/ ) and Ubuntu Autopkgtest frameworks ( http://autopkgtest.ubuntu.com/packages/gnutls28 ) The below commit has removed them: commit caf49d007c2a91b8340037fb9213df91c0d9d59c Date: Fri Jan 3 08:53:55 2020 +0100 tests/suite: do not include scripts into dist However, in Debian & Ubuntu these tests are triggered whenever gnutls or its reverse-dependencies are changed to e.g. prevent a broken OpenSSL getting released in Debian/Ubuntu if gnutls cannot connect to it anymore. In Debian these tests are performed on amd64, in Ubuntu these tests are performed on amd64/i386/s390x/ppc64el/armhf/arm64 giving a much wider architecture coverage that the current upstream CI is performing. Furthermore this gating is not only done for the Development releases of Debian/Ubuntu, but for stable release updates & security uploads. Can you please resurrect these scripts, and re-release 3.6.12.1 tarball with them included? These tests have caught bugs in raising seclevel to 2 in OpenSSL in ubuntu, hence I was motivated to improve them further in https://gitlab.com/gnutls/gnutls/-/merge_requests/1168 -- Regards, Dimitri. From mk at cognitivedissonance.ca Tue Feb 4 23:16:09 2020 From: mk at cognitivedissonance.ca (MK) Date: Tue, 4 Feb 2020 17:16:09 -0500 Subject: [gnutls-help] Generating self-signed cert requires PIN?? Message-ID: <20200204171609.7a5c4e0e0cf1747fa6a07344@cognitivedissonance.ca> Hi! I've been using certtool intermittently for years and I don't recall ever having this problem trying to generate a self-signed signing (CA) cert. First the private key (there are many examples like this in the docs, online, etc including, pretty much verbatim, the man page): certtool --generate-privkey --password $pword --outfile CAkey.pem Then for the cert: certtool -s --template ca.conf --outfile CAcert.pem --load-privkey CAkey.pem --password $pword The template is just: country=CA cn=myAuthority ca cert_signing_key And what happens: Generating a self signed certificate... No PIN given. The cert is never produced. There's also a note about using "the GNUTLS_PIN or GNUTLS_SO_PIN environment variables". I have no idea what this PIN is for, but searching online a bit implies it has to do with PKCS11 hardware, which has nothing to do with what I am doing. I tried this: export GNUTLS_PIN=1234 And presto, no more issue. However, this worries me a bit. Will I really have to keep using this PIN with that key/cert? Or it is totally spurious? Sincerely, Mark Eriksen From nmav at gnutls.org Wed Feb 5 12:05:29 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Feb 2020 12:05:29 +0100 Subject: [gnutls-help] gnutls 3.6.12 In-Reply-To: References: <01aa71a9aab71871c014d00800bf37ce68c8be60.camel@gnutls.org> Message-ID: On Tue, Feb 4, 2020 at 2:26 PM Dimitri John Ledkov wrote: > > On Sat, 1 Feb 2020 at 22:36, Nikos Mavrogiannopoulos wrote: > > > > Hello, > > I've just released gnutls 3.6.11. This is a bug fix release on the > > stable 3.6.x branch. > > > > I've now noticed that CI tests are gone from the tarball that are used > in Debian CI ( https://ci.debian.net/packages/g/gnutls28/unstable/amd64/ > ) and Ubuntu Autopkgtest frameworks ( > http://autopkgtest.ubuntu.com/packages/gnutls28 ) > > The below commit has removed them: > commit caf49d007c2a91b8340037fb9213df91c0d9d59c > Date: Fri Jan 3 08:53:55 2020 +0100 > > tests/suite: do not include scripts into dist > > However, in Debian & Ubuntu these tests are triggered whenever gnutls > or its reverse-dependencies are changed to e.g. prevent a broken > OpenSSL getting released in Debian/Ubuntu if gnutls cannot connect to > it anymore. > > In Debian these tests are performed on amd64, in Ubuntu these tests > are performed on amd64/i386/s390x/ppc64el/armhf/arm64 giving a much > wider architecture coverage that the current upstream CI is > performing. > > Furthermore this gating is not only done for the Development releases > of Debian/Ubuntu, but for stable release updates & security uploads. Oh, sorry for that, I didn't know. These tests were only include by a mistake, the suite/ directory is not run on tarballs, nor is guaranteed to. Would it make sense to mirror the "upstream" tests for these test suites? > Can you please resurrect these scripts, and re-release 3.6.12.1 > tarball with them included? I do not think so, as these tests do not run during 'make check' nor are necessary for gnutls' use. I understand this is inconvenient now, but I the reason for this change is to make that part of the test suite a little more robust and fail when some dependency is missing so we don't miss coverage when something changes in CI unexpectedly. They are not run nor supposed to be on the released tarball. Are there any alternative options suitable for you? regards, Nikos From nmav at gnutls.org Thu Feb 6 16:42:18 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 6 Feb 2020 16:42:18 +0100 Subject: [gnutls-help] Generating self-signed cert requires PIN?? In-Reply-To: <20200204171609.7a5c4e0e0cf1747fa6a07344@cognitivedissonance.ca> References: <20200204171609.7a5c4e0e0cf1747fa6a07344@cognitivedissonance.ca> Message-ID: Hi, Which version of gnutls is that? If you think it is a bug would you like to report it at gitlab.com/gnutls/gnutls/issues ? regards, Nikos On Tue, Feb 4, 2020 at 11:32 PM MK wrote: > > Hi! > > I've been using certtool intermittently for years and I don't recall ever having this problem trying to generate a self-signed signing (CA) cert. First the private key (there are many examples like this in the docs, online, etc including, pretty much verbatim, the man page): > > certtool --generate-privkey --password $pword --outfile CAkey.pem > > Then for the cert: > > certtool -s --template ca.conf --outfile CAcert.pem --load-privkey CAkey.pem --password $pword > > The template is just: > > country=CA > cn=myAuthority > ca > cert_signing_key > > And what happens: > > Generating a self signed certificate... > No PIN given. > > The cert is never produced. There's also a note about using "the GNUTLS_PIN or GNUTLS_SO_PIN environment variables". > > I have no idea what this PIN is for, but searching online a bit implies it has to do with PKCS11 hardware, which has nothing to do with what I am doing. I tried this: > > export GNUTLS_PIN=1234 > > And presto, no more issue. However, this worries me a bit. Will I really have to keep using this PIN with that key/cert? Or it is totally spurious? > > Sincerely, > Mark Eriksen > > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From jgh at wizmail.org Thu Feb 6 22:07:11 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 6 Feb 2020 21:07:11 +0000 Subject: [gnutls-help] false start Message-ID: <8d79696a-7bdc-470a-3111-169e6cc191de@wizmail.org> Hi, https://www.gnutls.org/manual/html_node/False-Start.html describes a restriction on "negotiated parameters" being HIGH or better, for False Start to be used. Is there some way of extracting these parameters from the session state? -- Cheers, Jeremy From jgh at wizmail.org Fri Feb 7 14:44:07 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 7 Feb 2020 13:44:07 +0000 Subject: [gnutls-help] false start In-Reply-To: <8d79696a-7bdc-470a-3111-169e6cc191de@wizmail.org> References: <8d79696a-7bdc-470a-3111-169e6cc191de@wizmail.org> Message-ID: <25830346-78bf-3292-b458-323059aab971@wizmail.org> gnutls_session_get_desc() seems to not be usefully callable immediately after gnutls_handshake() returns, with False Start in play, which is reasonable. However it also isn't returning useful info when called during a handshake-done callback set up with gnutls_handshake_set_hook_function(state->session, GNUTLS_HANDSHAKE_FINISHED, GNUTLS_HOOK_POST, ... I suspect the cause is the obvious flag "initial_negotiation_completed", set in handshake_client() only after the state-machine has terminated. Lacking the access via callback, I assume I have to check on every data read to see if I've acquired the info yet - which is ugly. Could the info be made accessible earlier? How early? Are other API call limited in when they are callable? Specifically gnutls_certificate_get_peers() gnutls_certificate_verify_peers2() gnutls_alert_send() -- Cheers, Jeremy From nmav at gnutls.org Fri Feb 7 15:52:54 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 7 Feb 2020 15:52:54 +0100 Subject: [gnutls-help] false start In-Reply-To: <25830346-78bf-3292-b458-323059aab971@wizmail.org> References: <8d79696a-7bdc-470a-3111-169e6cc191de@wizmail.org> <25830346-78bf-3292-b458-323059aab971@wizmail.org> Message-ID: On Fri, Feb 7, 2020 at 2:45 PM Jeremy Harris wrote: > > gnutls_session_get_desc() seems to not be usefully > callable immediately after gnutls_handshake() returns, > with False Start in play, which is reasonable. > However it also isn't returning useful info when called > during a handshake-done callback set up with > > gnutls_handshake_set_hook_function(state->session, > GNUTLS_HANDSHAKE_FINISHED, GNUTLS_HOOK_POST, ... > > I suspect the cause is the obvious flag > "initial_negotiation_completed", set in handshake_client() > only after the state-machine has terminated. > > Lacking the access via callback, I assume I have to > check on every data read to see if I've acquired the > info yet - which is ugly. > > Could the info be made accessible earlier? How early? Out of curiosity what is the reason you would like to know whether parameters in relation to false start are acceptable early? There is very little you can do at this point. The existing tests are in _gnutls_kx_allows_false_start() function which pretty much checks the prime size suitability or the curve size. It may be easy to replicate those tests, or even better if you have control of the server, ensure that only good parameters are offered. > Are other API call limited in when they are callable? > Specifically > gnutls_certificate_get_peers() > gnutls_certificate_verify_peers2() I believe these are only limited to having received the certificate, and they are expected to be called asynchronously at the certificate verification callback. > gnutls_alert_send() That can be called at any time. regards, Nikos From jgh at wizmail.org Fri Feb 7 16:51:55 2020 From: jgh at wizmail.org (Jeremy Harris) Date: Fri, 7 Feb 2020 15:51:55 +0000 Subject: [gnutls-help] false start In-Reply-To: References: <8d79696a-7bdc-470a-3111-169e6cc191de@wizmail.org> <25830346-78bf-3292-b458-323059aab971@wizmail.org> Message-ID: On 07/02/2020 14:52, Nikos Mavrogiannopoulos wrote: > On Fri, Feb 7, 2020 at 2:45 PM Jeremy Harris wrote: >> gnutls_session_get_desc() seems to not be usefully >> callable immediately after gnutls_handshake() returns, >> with False Start in play, which is reasonable. >> However it also isn't returning useful info when called >> during a handshake-done callback set up with >> >> gnutls_handshake_set_hook_function(state->session, >> GNUTLS_HANDSHAKE_FINISHED, GNUTLS_HOOK_POST, ... >> >> I suspect the cause is the obvious flag >> "initial_negotiation_completed", set in handshake_client() >> only after the state-machine has terminated. >> Could the info be made accessible earlier? How early? > > Out of curiosity what is the reason you would like to know whether > parameters in relation to false start are acceptable early? These are just the general-info items for the connection, for observability and reporting - the ciphersuite etc. I'm not needing to modify anything. Absent False Start, the obvious time to gather them is once the connection is made - ie. right after gnutls_handshake() returns - but obviously that no longer works. -- Cheers, Jeremy From nmav at gnutls.org Fri Feb 7 23:13:36 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 7 Feb 2020 23:13:36 +0100 Subject: [gnutls-help] false start In-Reply-To: References: <8d79696a-7bdc-470a-3111-169e6cc191de@wizmail.org> <25830346-78bf-3292-b458-323059aab971@wizmail.org> Message-ID: On Fri, Feb 7, 2020 at 4:53 PM Jeremy Harris wrote: > > On 07/02/2020 14:52, Nikos Mavrogiannopoulos wrote: > > On Fri, Feb 7, 2020 at 2:45 PM Jeremy Harris wrote: > >> gnutls_session_get_desc() seems to not be usefully > >> callable immediately after gnutls_handshake() returns, > >> with False Start in play, which is reasonable. > >> However it also isn't returning useful info when called > >> during a handshake-done callback set up with > >> > >> gnutls_handshake_set_hook_function(state->session, > >> GNUTLS_HANDSHAKE_FINISHED, GNUTLS_HOOK_POST, ... > >> > >> I suspect the cause is the obvious flag > >> "initial_negotiation_completed", set in handshake_client() > >> only after the state-machine has terminated. > > >> Could the info be made accessible earlier? How early? > > > > Out of curiosity what is the reason you would like to know whether > > parameters in relation to false start are acceptable early? > > These are just the general-info items for the connection, > for observability and reporting - the ciphersuite etc. > I'm not needing to modify anything. > > Absent False Start, the obvious time to gather them is once > the connection is made - ie. right after gnutls_handshake() > returns - but obviously that no longer works. Maybe I'm stating the obvious, but you know (via the flags) when false start happened. In that case you also know that you can get these parameters right after the first (successful) call to gnutls_record_recv(). Is that sufficient for your use-case? If that's too late, you could also try to get this earlier by combining gnutls_record_recv() and gnutls_handshake_get_last_in(). That is, even if gnutls_record_recv() doesn't succeed (e..g, returns E_AGAIN), you could verify whether the last message received is the finished one which will indicate that you can call the functions you're interested at. I do not think we have a test for this scenario though. regards, Nikos From hs at schlittermann.de Thu Feb 27 11:02:35 2020 From: hs at schlittermann.de (Heiko Schlittermann) Date: Thu, 27 Feb 2020 11:02:35 +0100 Subject: [gnutls-help] How to substitute gnutls_record_check_corked Message-ID: <20200227100235.GH32545@jumper.schlittermann.de> Hi, Exim uses gnutls_record_cork() and ?_uncork(). After uncorking I'd like to wait until all data is flushed. Currently I do do { do outbytes = gnutls_record_uncork(state->session, 0); while (outbytes == GNUTLS_E_AGAIN); if (outbytes < 0) { ... /* return failure to the caller */ return -1; } } while (gnutls_record_check_corked(state->session) > 0); But GnuTLS < 3.2.8 does not have the gnutls_record_check_corked() function. My naive attempt to define it according to that what I found in the recent GnuTLS source failed, as it needs to access internal data structures (I believe). What is the proper way do wait until all data is flushed? Best regards from Dresden/Germany Viele Gr??e aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From john.sha.jiang at gmail.com Fri Feb 28 03:25:29 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Fri, 28 Feb 2020 10:25:29 +0800 Subject: [gnutls-help] Is X448 supported? Message-ID: Hi, Just want to confirm if X448 is supported by GnuTLS 3.6.10. Used the below OpenSSL command to try to connect a GnuTLS server, openssl s_client -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256 -groups X448 host:port The server raised handshake error: No supported cipher suites have been found. But if specified X25519, it worked fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Feb 28 12:57:00 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 Feb 2020 12:57:00 +0100 Subject: [gnutls-help] Is X448 supported? In-Reply-To: References: Message-ID: It was added in gnutls 3.6.12. regards, Nikos On Fri, Feb 28, 2020 at 3:26 AM John Jiang wrote: > > Hi, > Just want to confirm if X448 is supported by GnuTLS 3.6.10. > > Used the below OpenSSL command to try to connect a GnuTLS server, > openssl s_client -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256 -groups X448 host:port > The server raised handshake error: No supported cipher suites have been found. > > But if specified X25519, it worked fine. > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help