From shawn.hall at nag.com Tue Mar 5 19:39:56 2019 From: shawn.hall at nag.com (Shawn Hall) Date: Tue, 5 Mar 2019 18:39:56 +0000 Subject: [gnutls-help] GnuTLS performance on slower devices Message-ID: Hi, One of our customers uses TigerVNC for graphical connections to systems. There are more details here https://github.com/TigerVNC/tigervnc/issues/737, but we've found that on slower devices such as the Microsoft Surface Pro 4 that there was a noticeable slowdown when encryption is enabled. In talking to the TigerVNC developers, we've found that this slowdown is due to some fundamental parts of GnuTLS such a memory allocation and buffer management. Is there any work in progress or planned that would improve GnuTLS performance on slower devices? Thanks, Shawn This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Tue Mar 5 20:11:03 2019 From: dank at kegel.com (Dan Kegel) Date: Tue, 5 Mar 2019 11:11:03 -0800 Subject: [gnutls-help] GnuTLS performance on slower devices In-Reply-To: References: Message-ID: I added a question about the affected cpu type(s) at https://github.com/TigerVNC/tigervnc/issues/737 On Tue, Mar 5, 2019 at 10:55 AM Shawn Hall wrote: > > Hi, > > > > One of our customers uses TigerVNC for graphical connections to systems. There are more details here https://github.com/TigerVNC/tigervnc/issues/737, but we?ve found that on slower devices such as the Microsoft Surface Pro 4 that there was a noticeable slowdown when encryption is enabled. In talking to the TigerVNC developers, we?ve found that this slowdown is due to some fundamental parts of GnuTLS such a memory allocation and buffer management. > > > > Is there any work in progress or planned that would improve GnuTLS performance on slower devices? > > > > Thanks, > > Shawn > > > > Disclaimer > > Please see our Privacy Notice for information on how we process personal data. > > This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From mail at maciej.szmigiero.name Mon Mar 11 00:02:42 2019 From: mail at maciej.szmigiero.name (Maciej S. Szmigiero) Date: Mon, 11 Mar 2019 00:02:42 +0100 Subject: [gnutls-help] gnutls_memset: use explicit_bzero Message-ID: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name> > That is, use the glibc function when available and the second > parameter is zero. > > Resolves #230 > > Signed-off-by: Nikos Mavrogiannopoulos > ---(..) > --- a/lib/safe-memfuncs.c > +++ b/lib/safe-memfuncs.c > @@ -33,14 +30,18 @@ > * This function will operate similarly to memset(), but will > * not be optimized out by the compiler. > * > - * Returns: void. > - * > * Since: 3.4.0 > **/ > void gnutls_memset(void *data, int c, size_t size) > { > - volatile unsigned volatile_zero = 0; > + volatile unsigned volatile_zero; > volatile char *vdata = (volatile char*)data; > +#ifdef HAVE_EXPLICIT_BZERO > + if (c == 0) { > + explicit_bzero(data, size); Shouldn't the function return here? Because otherwise it is doing the zeroing twice: first time via explicit_bzero(), second time via a volatile trick below. > + } > +#endif > + volatile_zero = 0; > > /* This is based on a nice trick for safe memset, > * sent by David Jacobson in the openssl-dev mailing list. Maciej From a.dalbo at adbglobal.com Tue Mar 12 14:13:46 2019 From: a.dalbo at adbglobal.com (Andrea Dal Bo) Date: Tue, 12 Mar 2019 13:13:46 +0000 Subject: [gnutls-help] about ecnrypting pkts with lenght 0 Message-ID: Hi, recently we moved from gnults 2.13.23 to gnutls 3.6.5. By doing this I encountered an issue with applications using the library. In fact it happens that the our TR-069 agent is sending pkts over https by means of gnutls_record_send. It might happens that gnutls_record_send is called with data_size=0. This was accepted in the older gnutls 2.13.23. With gnutls 3.6.5 it is not. In fact gnutls_record_send calls gnutls_record_send2 with pad=0, and subsequently _gnutls_send_tlen_int that verifies that if both data_size and pad are 0 returns GNUTLS_E_INVALID_REQUEST (record.c line 492). I tried to modify the application to add a padding>=1 in case of data_size=0 by calling gnutls_record_can_use_length_hiding. In fact even if this function was returning 1, the subsequent call of gnutls_record_send2 was still returning GNUTLS_E_INVALID_REQUEST. In fact the discrimination was that tls1.3 handshake semantics was set to false. That is a bit misleading, IMHO. Can you explain the reason for that? Moreover why this restriction on the data_size length has been added to? Thanks Andrea [https://www.adbglobal.com/wp-content/uploads/adb.png] adbglobal.com This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is STRICTLY PROHIBITED. Please note that ADB protects your privacy. Any personal information we collect from you is used in accordance with our Privacy Policy and in compliance with applicable European data protection law (Regulation (EU) 2016/679, General Data Protection Regulation) and other statutory provisions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at openfortress.nl Tue Mar 26 21:19:02 2019 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 26 Mar 2019 21:19:02 +0100 Subject: [gnutls-help] Cert in DER, a pleasant surprise...? Message-ID: <5C9A8936.60800@openfortress.nl> Hi, I read in your docs on "gnutls_certificate_get_crt_raw ()" that it intends to "return the DER encoded certificate of the server". That raises a few questions. 1. Did you mean to return the _peer_ certificate, or always the _server_ certificate? 2. When the certificate is not DER-encoded, do you recode it? That would be quite useful! This is not a PEM-or-DER question but BER-or-DER. The TBSCertificate needs to be canonical so DER, but the Certificate around it may be BER, as specified in . Not sure everyone knows this... and having it repackaged would be pleasant to stop bugs caused by it. I'm going by RFC 3280/5280, and RFC 8446 details DER for every CertificateEntry, but I don't believe that RFC 5246 does the same? Sorry for the attention of detail, it might be a security thing... Cheers, -Rick From n.mavrogiannopoulos at gmail.com Wed Mar 27 08:13:05 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 27 Mar 2019 08:13:05 +0100 Subject: [gnutls-help] Cert in DER, a pleasant surprise...? In-Reply-To: <5C9A8936.60800@openfortress.nl> References: <5C9A8936.60800@openfortress.nl> Message-ID: On Tue, 2019-03-26 at 21:19 +0100, Rick van Rein wrote: > Hi, > > I read in your docs on "gnutls_certificate_get_crt_raw ()" that it > intends to "return the DER encoded certificate of the server". That > raises a few questions. > > 1. > Did you mean to return the _peer_ certificate, or always the _server_ > certificate? Hi, This returns the certificate as in the credentials structure. > 2. > When the certificate is not DER-encoded, do you recode it? That > would be quite useful! This is not a PEM-or-DER question but BER-or- > DER. The > TBSCertificate needs to be canonical so DER, but the Certificate > around > it may be BER, as specified in . Not sure everyone knows this... and > having it repackaged would be pleasant to stop bugs caused by it. I'd treat that as an implementation detail. We used to always DER-re- encode certificates, but that caused problems interoperating with golang applications which used to generate certificates not following DER very strictly, thus gnutls was breaking the signatures for them. regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Mar 27 08:23:10 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 27 Mar 2019 08:23:10 +0100 Subject: [gnutls-help] about ecnrypting pkts with lenght 0 In-Reply-To: References: Message-ID: <93536717e553a15866a6091942685a4bc1044193.camel@gmail.com> On Tue, 2019-03-12 at 13:13 +0000, Andrea Dal Bo wrote: > Hi, > recently we moved from gnults 2.13.23 to gnutls 3.6.5. > By doing this I encountered an issue with applications using the > library. In fact it happens that the our TR-069 agent is sending pkts > over https by means of gnutls_record_send. It might happens that > gnutls_record_send is called with data_size=0. This was accepted in > the older gnutls 2.13.23. > With gnutls 3.6.5 it is not. In fact gnutls_record_send calls > gnutls_record_send2 with pad=0, and subsequently > _gnutls_send_tlen_int that verifies that if both data_size and pad > are 0 returns GNUTLS_E_INVALID_REQUEST (record.c line 492). Hi, What is your goal with this behavior? The library tries to protect against incorrect use of it, and sending zero-byte packets was probably one of them (they are used for specific purposes in the protocol and can confuse the peer). > I tried to modify the application to add a padding>=1 in case of > data_size=0 by calling gnutls_record_can_use_length_hiding. In fact > even if this function was returning 1, the subsequent call of > gnutls_record_send2 was still returning GNUTLS_E_INVALID_REQUEST. In > fact the discrimination was that tls1.3 handshake semantics was set > to false. That is a bit misleading, IMHO. I am not sure I understand this, what do you mean here? btw. if you think that's a bug it is easier to bring on the issue tracker (I do not follow the help list much, and I think that's the same with other developers). regards, Nikos From nmav at gnutls.org Wed Mar 27 08:07:57 2019 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Mar 2019 08:07:57 +0100 Subject: [gnutls-help] gnutls 3.6.7 Message-ID: <9ced968063d37fa87631b69155a8fb2e911e149c.camel@gnutls.org> Hello, I've just released gnutls 3.6.7. This is a bug fix and security release on the stable 3.6.x branch. I'd like to thank everyone who contributed in this release: Alon Bar-Lev, Anderson Toshiyuki Sasaki, Andreas Metzler, Bas van Schaik, Daiki Ueno, Dmitry Eremin-Solenikov, Hugo Beauz?e-Luyssen, Ke Zhao, R. Andrew Bailey, Steve Lhomme, and Tim R?hsen. The applicable security advisory GNUTLS-SA-2019-03-27 will be made available at: https://www.gnutls.org/security-new.html The detailed list of changes follows; they can be seen in more detail in our milestone tracker: https://gitlab.com/gnutls/gnutls/milestones/19 Changes ======= * Version 3.6.7 (released 2019-03-27) ** libgnutls, gnutls tools: Every gnutls_free() will automatically set the free'd pointer to NULL. This prevents possible use-after-free and double free issues. Use-after-free will be turned into NULL dereference. The counter-measure does not extend to applications using gnutls_free(). ** libgnutls: Fixed a memory corruption (double free) vulnerability in the certificate verification API. Reported by Tavis Ormandy; addressed with the change above. [GNUTLS-SA-2019-03-27, #694] ** libgnutls: Fixed an invalid pointer access via malformed TLS1.3 async messages; Found using tlsfuzzer. [GNUTLS-SA-2019-03-27, #704] ** libgnutls: enforce key usage limitations on certificates more actively. Previously we would enforce it for TLS1.2 protocol, now we enforce it even when TLS1.3 is negotiated, or on client certificates as well. When an inappropriate for TLS1.3 certificate is seen on the credentials structure GnuTLS will disable TLS1.3 support for that session (#690). ** libgnutls: the default number of tickets sent under TLS 1.3 was increased to two. This makes it easier for clients which perform multiple connections to the server to use the tickets sent by a default server. ** libgnutls: enforce the equality of the two signature parameters fields in a certificate. We were already enforcing the signature algorithm, but there was a bug in parameter checking code. ** libgnutls: fixed issue preventing sending and receiving from different threads when false start was enabled (#713). ** libgnutls: the flag GNUTLS_PKCS11_OBJ_FLAG_LOGIN_SO now implies a writable session, as non-writeable security officer sessions are undefined in PKCS#11 (#721). ** libgnutls: no longer send downgrade sentinel in TLS 1.3. Previously the sentinel value was embedded to early in version negotiation and was sent even on TLS 1.3. It is now sent only when TLS 1.2 or earlier is negotiated (#689). ** gnutls-cli: Added option --logfile to redirect informational messages output. ** 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.7.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.7.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 n.mavrogiannopoulos at gmail.com Wed Mar 27 08:24:58 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 27 Mar 2019 08:24:58 +0100 Subject: [gnutls-help] gnutls_memset: use explicit_bzero In-Reply-To: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name> References: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name> Message-ID: <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com> On Mon, 2019-03-11 at 00:02 +0100, Maciej S. Szmigiero wrote: > > That is, use the glibc function when available and the second > > parameter is zero. > > > > Resolves #230 > > > > Signed-off-by: Nikos Mavrogiannopoulos > > ---(..) > > --- a/lib/safe-memfuncs.c > > +++ b/lib/safe-memfuncs.c > > @@ -33,14 +30,18 @@ > > * This function will operate similarly to memset(), but will > > * not be optimized out by the compiler. > > * > > - * Returns: void. > > - * > > * Since: 3.4.0 > > **/ > > void gnutls_memset(void *data, int c, size_t size) > > { > > - volatile unsigned volatile_zero = 0; > > + volatile unsigned volatile_zero; > > volatile char *vdata = (volatile char*)data; > > +#ifdef HAVE_EXPLICIT_BZERO > > + if (c == 0) { > > + explicit_bzero(data, size); > > Shouldn't the function return here? > > Because otherwise it is doing the zeroing twice: > first time via explicit_bzero(), > second time via a volatile trick below. You are right. Would you like to send a merge request fixing that? regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Mar 27 08:28:44 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 27 Mar 2019 08:28:44 +0100 Subject: [gnutls-help] GnuTLS performance on slower devices In-Reply-To: References: Message-ID: On Tue, 2019-03-05 at 18:39 +0000, Shawn Hall wrote: > Hi, > > One of our customers uses TigerVNC for graphical connections to > systems. There are more details here > https://github.com/TigerVNC/tigervnc/issues/737, but we?ve found that > on slower devices such as the Microsoft Surface Pro 4 that there was > a noticeable slowdown when encryption is enabled. In talking to the > TigerVNC developers, we?ve found that this slowdown is due to some > fundamental parts of GnuTLS such a memory allocation and buffer > management. > > Is there any work in progress or planned that would improve GnuTLS > performance on slower devices? I was never aware of any such problem with memory allocation and buffer management on slower devices. What I believe is more likely is that crypto in nettle library is not optimized for these platforms. There are certain improvements discussed on the nettle for specific platforms on its mailing list. regards, Nikos From rick at openfortress.nl Wed Mar 27 09:01:29 2019 From: rick at openfortress.nl (Rick van Rein) Date: Wed, 27 Mar 2019 09:01:29 +0100 Subject: [gnutls-help] Cert in DER, a pleasant surprise...? In-Reply-To: References: <5C9A8936.60800@openfortress.nl> Message-ID: <5C9B2DD9.1080007@openfortress.nl> Hi, > We used to always DER-re- > encode certificates, but that caused problems interoperating with > golang applications which used to generate certificates not following > DER very strictly, thus gnutls was breaking the signatures for them. Liberal in what you accept, I see. I took a similar approach with Quick DER, which accepts almost all BER forms as well. They are breaking standards however, and it has me concerned that this was not debugged in the Go code. Even though I can even read the RFCs to say that the TBSCertificate may be encoded differently (including JER) the signature itself must be computed over de DER form. Packing a certificate into JER might actually be useful to some use cases, but it would break on Go certificates, apparantly. I am wondering if this might create a single-language ecosystem that won't work with other applications. I would have stopped Google at this point. It is a good reason to not use Go, or at least its certificate "support" code. I would have started a debugging process in Go... and perhaps given them some leeway for a few upcoming releases. -Rick From n.mavrogiannopoulos at gmail.com Wed Mar 27 09:08:51 2019 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 27 Mar 2019 09:08:51 +0100 Subject: [gnutls-help] Cert in DER, a pleasant surprise...? In-Reply-To: <5C9B2DD9.1080007@openfortress.nl> References: <5C9A8936.60800@openfortress.nl> <5C9B2DD9.1080007@openfortress.nl> Message-ID: On Wed, 2019-03-27 at 09:01 +0100, Rick van Rein wrote: > Hi, > > > We used to always DER-re- > > encode certificates, but that caused problems interoperating with > > golang applications which used to generate certificates not > > following > > DER very strictly, thus gnutls was breaking the signatures for > > them. > > Liberal in what you accept, I see. I took a similar approach with > Quick DER, which accepts almost all BER forms as well. > > They are breaking standards however, and it has me concerned that > this was not debugged in the Go code. Even though I can even read > the RFCs to say that the TBSCertificate may be encoded differently > (including JER) the signature itself must be computed over de DER > form. Packing a certificate into JER might actually be useful to > some use cases, but it would break on Go certificates, apparantly. > > I am wondering if this might create a single-language ecosystem that > won't work with other applications. I would have stopped Google at > this point. It is a good reason to not use Go, or at least its > certificate "support" code. > > I would have started a debugging process in Go... and perhaps given > them some leeway for a few upcoming releases. The issue was not something complex, but with the SET ordering in DER rules; it was treated as bug: (though not yet resolved) https://github.com/golang/go/issues/24254 regards, Nikos From mail at maciej.szmigiero.name Thu Mar 28 23:08:07 2019 From: mail at maciej.szmigiero.name (Maciej S. Szmigiero) Date: Thu, 28 Mar 2019 23:08:07 +0100 Subject: [gnutls-help] gnutls_memset: use explicit_bzero In-Reply-To: <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com> References: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name> <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com> Message-ID: <158964ce-c6a8-1a16-b2a7-46bbeaba3fec@maciej.szmigiero.name> On 27.03.2019 08:24, Nikos Mavrogiannopoulos wrote: > On Mon, 2019-03-11 at 00:02 +0100, Maciej S. Szmigiero wrote: >>> That is, use the glibc function when available and the second >>> parameter is zero. >>> >>> Resolves #230 >>> >>> Signed-off-by: Nikos Mavrogiannopoulos >>> ---(..) >>> --- a/lib/safe-memfuncs.c >>> +++ b/lib/safe-memfuncs.c >>> @@ -33,14 +30,18 @@ >>> * This function will operate similarly to memset(), but will >>> * not be optimized out by the compiler. >>> * >>> - * Returns: void. >>> - * >>> * Since: 3.4.0 >>> **/ >>> void gnutls_memset(void *data, int c, size_t size) >>> { >>> - volatile unsigned volatile_zero = 0; >>> + volatile unsigned volatile_zero; >>> volatile char *vdata = (volatile char*)data; >>> +#ifdef HAVE_EXPLICIT_BZERO >>> + if (c == 0) { >>> + explicit_bzero(data, size); >> >> Shouldn't the function return here? >> >> Because otherwise it is doing the zeroing twice: >> first time via explicit_bzero(), >> second time via a volatile trick below. > > You are right. Would you like to send a merge request fixing that? While I don't have a gitlab account to open a merge request there I have attached a patch made by git-format-patch. Hope this way will work, too. > regards, > Nikos Thanks, Maciej -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gnutls_memset-calling-explicit_bzero-is-enough-to-ze.patch Type: text/x-patch Size: 868 bytes Desc: not available URL: