From nmav at gnutls.org Tue Jul 4 07:59:08 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Jul 2017 07:59:08 +0200 Subject: [gnutls-devel] gnutls 3.3.28 Message-ID: <1499147948.26324.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.3.28. This is a bug-fix release on the previous stable branch. * Version 3.3.28 (released 2017-07-04) ** libgnutls: Fixed issue when rehandshaking without a client certificate in ???a session which initially used one. Reported by Frantisek Sumsal. ** libgnutls: fix issue in RSA-PSK client callback which resulted in no username ???being sent to the peer. Patch by Nicolas Dufresne. ** libgnutls: no longer parse the ResponseID field of the status response ???TLS extension. The field is not used by GnuTLS nor is made available to ???calling applications. That addresses a null pointer dereference on server ???side caused by packets containing the ResponseID field. Reported ???by Hubert Kario. [GNUTLS-SA-2017-4] ** libgnutls: Handle specially HSMs which request explicit authentication. ???There are HSMs which return CKR_USER_NOT_LOGGED_IN on the first private key ???operation. Detect that state and try to login. ** libgnutls: the GNUTLS_PKCS11_OBJ_FLAG_LOGIN will force a login on HSMs. ???That is, even in tokens which do not have a CKF_LOGIN_REQUIRED flag ???a login will be forced. This improves operation on certain Safenet HSMs. ** libgnutls: do not set leading zeros when copying integers on HSMs. ???PKCS#11 defines integers as unsigned having most significant byte ???first, e.g., 32768 = 0x80 0x00. This is interpreted literraly by ???some HSMs which do not accept an integer with a leading zero. This ???improves operation with certain Atos HSMs. ** libgnutls: Backported PKCS#11 key generation functionality for DSA keys. ** libgnutls: Improve check for /dev/urandom uniqueness. Ensure that when ???gnutls_global_init() is called for a second time that /dev/urandom is ???re-opened when the inode or device ID has changed. ** 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.3/gnutls-3.3.28.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.28.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 Tue Jul 4 08:00:59 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Jul 2017 08:00:59 +0200 Subject: [gnutls-devel] gnutls 3.5.14 Message-ID: <1499148059.26324.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.14. This is a bug fix release on the 3.5.x branch. * Version 3.5.14 (released 2017-07-04) ** libgnutls: Handle specially HSMs which request explicit authentication. ???There are HSMs which return CKR_USER_NOT_LOGGED_IN on the first private key ???operation. Detect that state and try to login. ** libgnutls: the GNUTLS_PKCS11_OBJ_FLAG_LOGIN will force a login on HSMs. ???That is, even in tokens which do not have a CKF_LOGIN_REQUIRED flag ???a login will be forced. This improves operation on certain Safenet HSMs. ** libgnutls: do not set leading zeros when copying integers on HSMs. ???PKCS#11 defines integers as unsigned having most significant byte ???first, e.g., 32768 = 0x80 0x00. This is interpreted literraly by ???some HSMs which do not accept an integer with a leading zero. This ???improves operation with certain Atos HSMs. ** libgnutls: Fixed issue discovering certain OCSP signers, and improved the ???discovery of OCSP signer in the case where the Subject Public Key ???identifier field matches. Resolves gitlab issue #223. ** gnutls-cli: ensure OCSP responses are saved with --save-ocsp even if ???certificate verification fails. ** 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.14.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.14.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 pitchum at gramaton.org Thu Jul 6 16:31:43 2017 From: pitchum at gramaton.org (pitchum) Date: Thu, 6 Jul 2017 16:31:43 +0200 Subject: [gnutls-devel] [PATCH] gnutls-cli won't work with ejabberd Message-ID: <38b6e7b5-c904-df7c-359c-f06de642959c@gramaton.org> Hi, I'm currently trying to debug XMPP federation problems involving TLS negociation between prosody and ejabberd. gnutls-cli works fine with prosody but not with ejabberd. I've patched gnutls to workaround this and now my local gnutls-cli is able to communicate successfully with ejabberd (and prosody of course). My patch fixes 2 different problems. 1. ejabberd requires a different XML namespace whether you want to establish a c2s or an s2s connection while prosody is not so demanding. xmls='jabber:client' or xmlns='jabber:server' respectively. 2. ejabberd seems slow to answer to the first request. On initial request, prosody replies both and in one shot. ejabberd immediatly replies only and gnutls-cli would have to perform another socket read to fetch . But I found out that waiting a little (200ms+) before reading the socket gives ejabberd enough time to reply both and in one shot, then making the next socket read return what is expected. I decided to modify the possible values for --starttls-proto option: xmpp is replaced with xmpp-client or xmpp-server to avoid confusion. If you ask, I can make a merge request on gitlab too. But I'm not a C programmer and I'm sure my patch can be improved. Maybe there's a better solution than waiting 200ms for instance. Feel free to rewrite it as needed. Thanks. -- pitchum -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-gnutls-cli-ejabberd.patch Type: text/x-patch Size: 1917 bytes Desc: not available URL: From nmav at gnutls.org Sat Jul 8 09:30:33 2017 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 8 Jul 2017 09:30:33 +0200 Subject: [gnutls-devel] [PATCH] gnutls-cli won't work with ejabberd In-Reply-To: <38b6e7b5-c904-df7c-359c-f06de642959c@gramaton.org> References: <38b6e7b5-c904-df7c-359c-f06de642959c@gramaton.org> Message-ID: On Thu, Jul 6, 2017 at 4:31 PM, pitchum wrote: > Hi, > > I'm currently trying to debug XMPP federation problems involving TLS > negociation between prosody and ejabberd. gnutls-cli works fine with > prosody but not with ejabberd. > I've patched gnutls to workaround this and now my local gnutls-cli is > able to communicate successfully with ejabberd (and prosody of course). > > My patch fixes 2 different problems. > > 1. ejabberd requires a different XML namespace whether you want to > establish a c2s or an s2s connection while prosody is not so demanding. > xmls='jabber:client' or xmlns='jabber:server' respectively. > > 2. ejabberd seems slow to answer to the first request. On initial > request, prosody replies both and in one shot. > ejabberd immediatly replies only and gnutls-cli would have to > perform another socket read to fetch . Thank you for the patch. I no longer remember the details of the protocol, but my question here would be why not wait for the text? > But I found out that > waiting a little (200ms+) before reading the socket gives ejabberd > enough time to reply both and in one shot, then > making the next socket read return what is expected. > > I decided to modify the possible values for --starttls-proto option: > xmpp is replaced with xmpp-client or xmpp-server to avoid confusion. We would have to keep 'xmpp' for backwards compatibility (most likely to the most common variant). The CANON_SERVICE() macro should be updated as well. > If you ask, I can make a merge request on gitlab too. But I'm not a C > programmer and I'm sure my patch can be improved. Maybe there's a better > solution than waiting 200ms for instance. Feel free to rewrite it as needed. I'd really appreciate a merge request, ideally with a testsuite similarly to tests/starttls-smtp.sh and friends. regards, Nikos From pitchum at gramaton.org Sat Jul 8 13:13:07 2017 From: pitchum at gramaton.org (pitchum) Date: Sat, 8 Jul 2017 13:13:07 +0200 Subject: [gnutls-devel] [PATCH] gnutls-cli won't work with ejabberd In-Reply-To: References: <38b6e7b5-c904-df7c-359c-f06de642959c@gramaton.org> Message-ID: Le 08/07/2017 ? 09:30, Nikos Mavrogiannopoulos a ?crit : > On Thu, Jul 6, 2017 at 4:31 PM, pitchum wrote: >> My patch fixes 2 different problems. > > Thank you for the patch. I no longer remember the details of the protocol, but > my question here would be why not wait for the text? That's what I tried at first but then it broke support for prosody. Maybe I didn't implement it the right way. As I said, I'm not a C programmer. Then I found the solution based on usleep() and I was happy because it introduces very few changes in the code and it worked like a charm with both prosody and ejabberd. I'll try to find a better solution though. >> I decided to modify the possible values for --starttls-proto option: >> xmpp is replaced with xmpp-client or xmpp-server to avoid confusion. > > We would have to keep 'xmpp' for backwards compatibility (most likely > to the most common variant). The CANON_SERVICE() macro should be > updated as well. Oh, I didn't see this macro. Ok then I'll try to make it clear in the man page that xmpp is an alias for xmpp-server. > I'd really appreciate a merge request, ideally with a testsuite > similarly to tests/starttls-smtp.sh and friends. I'll do that. But it'll take some time, don't be impatient :) -- pitchum From alon.barlev at gmail.com Sun Jul 16 19:40:42 2017 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 16 Jul 2017 20:40:42 +0300 Subject: [gnutls-devel] [TESTS] gnutls-3.5 key exchange fails in sparc for ecdhe x25519 rsa In-Reply-To: References: Message-ID: On 27 March 2017 at 12:32, Nikos Mavrogiannopoulos wrote: > On Sun, Mar 26, 2017 at 10:29 AM, Alon Bar-Lev wrote: >> Hi, >> Can anyone please assist in determine why sparc tests fails? >> Logs are available here[1] >> It seems that the ecdhe x25519 rsa is an issue. > > Does nettle's test suite succeed? Which version of nettle is it being used with? Hi, With help we found the issue, see[1], it will be nice if you review this as well. Thanks, Alon [1] http://lists.lysator.liu.se/pipermail/nettle-bugs/2017/003287.html From n.mavrogiannopoulos at gmail.com Mon Jul 17 12:51:21 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 17 Jul 2017 12:51:21 +0200 Subject: [gnutls-devel] moving out from SHA1 In-Reply-To: References: Message-ID: On Fri, Feb 24, 2017 at 10:23 AM, Nikos Mavrogiannopoulos wrote: > Hi, > Given the first found collision for SHA1, I think it is time to plan > removing it from the trusted set. I do not believe we can do that > today in existing releases, as there is simply too much stuff relying > SHA1. Even for the web PKI which the transition from SHA1 was already > in place, major sites like amazon.com today provide an OCSP response > signed with RSA-SHA1. > > So what I propose, is remove sha1 from the trusted set in gnutls 3.6.0 > (to be released the second half of this year). That release will > forbid SHA1 from any operation unless special flags to indicate that > broken algorithms are allowed are set. My intention is not to > introduce a new flag to allow SHA1, but utilize the catch-all allow > broken algorithms flag. > > In 3.5.x we forbid SHA1 for certificate verification in TLS, for the > NORMAL and above levels, in one of the next few releases (3.5.10 or > 3.5.11), but still allow it for TLS handshake signatures. That is, we > take advantage of the verifcation PROFILEs associated with a priority > string keyword, and even though SHA1 is in general acceptable, it will > be refused for certificate verification. At the same time it will > allow applications which rely on SHA1 to continue function, as well as > connection to old servers which use TLS signatures with SHA1 (maybe > even treat OCSP differently to avoid breaking examples with amazon as > above). I think, that the gradual phasing out, firstly for certificates and then for everything else makes sense also for the 3.6.0 release. SHA1 is still actively used for OCSP, DNS and possibly many other protocols. As such I've opened the issue: https://gitlab.com/gnutls/gnutls/issues/229 and I believe we should move more conservatively in this deprecation. Make it happen on 3.6.0 releases only for certificates, and postpone full phasing out few years from now. regards, Nikos