From r.korthaus at sirrix.com Thu Jan 2 11:13:09 2014 From: r.korthaus at sirrix.com (=?ISO-8859-15?Q?Ren=E9_Korthaus?=) Date: Thu, 2 Jan 2014 11:13:09 +0100 Subject: [gnutls-devel] gnutls-announce Message-ID: <52C53BB5.7050408@sirrix.com> Hi, we are using GnuTLS in some of our projects and sure want to keep up-to-date with the latest GnuTLS releases. Most open source projects, such as Qt, Boost, OpenSSL, Gentoo, and numerous others have a separate mailing list for announcing security bugs and new releases. Keeping up-to-date with these projects is as easy as subscribing to their xxx-announce mailing lists and waiting for announcements, whereas GnuTLS does not have an announcement mailing list. For us this means subscribing to the gnutls-devel mailing list and filtering for release announcements, which is not so comfortable, especially when you're not interested in regular development of GnuTLS. Is there anything that speaks against having a gnutls-announce mailing list? If not, can you please set up this list in addition to gnutls-help and gnutls-devel? Best regards, Ren? Korthaus -- Sirrix AG security technologies - http://www.sirrix.com Ren? Korthaus eMail: r.korthaus at sirrix.com Tel +49(681) 959 86-163 Fax +49(681) 959 86-5163 PGP Key ID 0x688EF9C8 Fingerprint 1FB6 2405 51C4 79DB C008 D1D2 C2E0 1A14 688E F9C8 Vorstand: Ammar Alkassar (Vors.), Christian St?ble, Markus Bernhammer Vorsitzender des Aufsichtsrates: Harald St?ber Sitz der Gesellschaft: Homburg/Saar, HRB 3857 Amtsgericht Saarbr?cken This message may contain confidential and/or privileged information. If you are not the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. From nmav at gnutls.org Thu Jan 2 18:01:24 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 02 Jan 2014 18:01:24 +0100 Subject: [gnutls-devel] gnutls-announce In-Reply-To: <52C53BB5.7050408@sirrix.com> References: <52C53BB5.7050408@sirrix.com> Message-ID: <52C59B64.7080200@gnutls.org> On 01/02/2014 11:13 AM, Ren? Korthaus wrote: > Hi, > > we are using GnuTLS in some of our projects and sure want to keep > up-to-date with the latest GnuTLS releases. Most open source projects, > such as Qt, Boost, OpenSSL, Gentoo, and numerous others have a separate > mailing list for announcing security bugs and new releases. Keeping > up-to-date with these projects is as easy as subscribing to their > xxx-announce mailing lists and waiting for announcements, whereas GnuTLS > does not have an announcement mailing list. For us this means > subscribing to the gnutls-devel mailing list and filtering for release > announcements, which is not so comfortable, especially when you're not > interested in regular development of GnuTLS. Is there anything that > speaks against having a gnutls-announce mailing list? If not, can you > please set up this list in addition to gnutls-help and gnutls-devel? Hello, There is quite an overhead for maintaining another mailing list. Why not use the atom or even twitter feeds from gnutls.org? regards, Nikos From nmav at gnutls.org Fri Jan 3 22:03:54 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 03 Jan 2014 22:03:54 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52C20757.2020902@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> <52C1E7B2.7000200@fifthhorseman.net> <52C20757.2020902@mirix.org> Message-ID: <52C725BA.6090601@gnutls.org> On 12/31/2013 12:52 AM, Matthias-Christian Ott wrote: > It required me to find, read and translate their documents into an OpenSSL > cipher list and to choose the key lengths accordingly. When new > recommendations are available, I would have to repeat this procedure. I > would prefer it if GnuTLS had a keyword BSI or something similar to > always conform to the latest recommendation (other systems > administrators I know who run TLS protected web sites don't even know > what a key length or a certain cipher is (sic!) and probably wouldn't > make any efforts to comply with the recommendations). keylength.com > lists other recommendations of other institutions that might be > relevant. Also GnuTLS already has some Suite B support. Hello, I don't know how practical it is to have priority strings for every possible jurisdiction. We can have though options for the major ones. Despite the latest revelations with NSA, NIST has been leading on making sensible recommendations and that's why I added the suiteB priority string options. EU on the other hand has ENISA which I don't even know if it has any recommendations or if anyone follows them. So in case you have any suggestion for improvement on that matter please express it. regards, Nikos From ott at mirix.org Sun Jan 5 17:57:57 2014 From: ott at mirix.org (Matthias-Christian Ott) Date: Sun, 05 Jan 2014 17:57:57 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52C725BA.6090601@gnutls.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> <52C1E7B2.7000200@fifthhorseman.net> <52C20757.2020902@mirix.org> <52C725BA.6090601@gnutls.org> Message-ID: <52C98F15.1080804@mirix.org> On 01/03/14 22:03, Nikos Mavrogiannopoulos wrote: > On 12/31/2013 12:52 AM, Matthias-Christian Ott wrote: >> It required me to find, read and translate their documents into an OpenSSL >> cipher list and to choose the key lengths accordingly. When new >> recommendations are available, I would have to repeat this procedure. I >> would prefer it if GnuTLS had a keyword BSI or something similar to >> always conform to the latest recommendation (other systems >> administrators I know who run TLS protected web sites don't even know >> what a key length or a certain cipher is (sic!) and probably wouldn't >> make any efforts to comply with the recommendations). keylength.com >> lists other recommendations of other institutions that might be >> relevant. Also GnuTLS already has some Suite B support. > > Hello, > I don't know how practical it is to have priority strings for every > possible jurisdiction. We can have though options for the major ones. If I'm not mistaken, cipher suites only specify key lengths or symmetric ciphers and GnuTLS security parameters are only used for key generation not for connections. As Daniel correctly suggested, this is not enough. At 30C3 BetterCrypto.org was presented and received some press attention in Germany. Looking at their ?Applied Crypto Hardening? document, which targets system administrators, configuring TLS implementations is still too hard and requires too much effort. Most administrators will never bother. I think we need security profiles for GnuTLS. A security profile covers all parameters that are relevant for security including cipher suites, key lengths and TLS extensions. GnuTLS could include some default profiles, such as profiles based on recommendations of institutions like NIST or ENISA. Security profiles are by default loaded from a system-wide security profile registry (some directory consists of security profile files) according to a system-wide security policy which specifies the default profile. If the system administrator or application software configures nothing else, GnuTLS uses the default profile specified in the system-wide security policy. Configuring all software thus in general reduces to changing a single profile name in the system-wide security policy. All paths for the registry, profiles and policy are of course changeable and there will be an API to specify them programmatically instead of loading them from files. What you you think? Regards, Matthias-Christian From home_pw at msn.com Sun Jan 5 18:23:36 2014 From: home_pw at msn.com (peter williams) Date: Sun, 5 Jan 2014 09:23:36 -0800 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? Message-ID: Use an old idea. Ssl handshake contains basic policy negotiation apparatus (lists of ciphersuite names). Let x509 extensions convey lists of such names, too. Implement class based discovery, which directs selection of suite. Do the unthinkable (ignore 25 years of stupid cypherpunks advice about hierarhical cert models, built on failed religion): implement discovery based cert chaining, in which receiving party finds "best" cert chain to user cert's public key - where multiple ca may issue (policy annotated) user cert for a given public key. Policy based discovery of chain delivers negotiation of ciphersuite classes, which constrains ssl handshakes selection of suite from list offered. Matthias-Christian Ott wrote: > > >On 01/03/14 22:03, Nikos Mavrogiannopoulos wrote: >> On 12/31/2013 12:52 AM, Matthias-Christian Ott wrote: >>> It required me to find, read and translate their documents into an OpenSSL >>> cipher list and to choose the key lengths accordingly. When new >>> recommendations are available, I would have to repeat this procedure. I >>> would prefer it if GnuTLS had a keyword BSI or something similar to >>> always conform to the latest recommendation (other systems >>> administrators I know who run TLS protected web sites don't even know >>> what a key length or a certain cipher is (sic!) and probably wouldn't >>> make any efforts to comply with the recommendations). keylength.com >>> lists other recommendations of other institutions that might be >>> relevant. Also GnuTLS already has some Suite B support. >> >> Hello, >>? I don't know how practical it is to have priority strings for every >> possible jurisdiction. We can have though options for the major ones. > >If I'm not mistaken, cipher suites only specify key lengths or symmetric >ciphers and GnuTLS security parameters are only used for key generation >not for connections. As Daniel correctly suggested, this is not enough. > >At 30C3 BetterCrypto.org was presented and received some press attention >in Germany. Looking at their ?Applied Crypto Hardening? document, which >targets system administrators, configuring TLS implementations is still >too hard and requires too much effort. Most administrators will never >bother. > >I think we need security profiles for GnuTLS. A security profile covers >all parameters that are relevant for security including cipher suites, >key lengths and TLS extensions. GnuTLS could include some default >profiles, such as profiles based on recommendations of institutions like >NIST or ENISA. Security profiles are by default loaded from a >system-wide security profile registry (some directory consists of >security profile files) according to a system-wide security policy which >specifies the default profile. If the system administrator or >application software configures nothing else, GnuTLS uses the default >profile specified in the system-wide security policy. Configuring all >software thus in general reduces to changing a single profile name in >the system-wide security policy. > >All paths for the registry, profiles and policy are of course changeable >and there will be an API to specify them programmatically instead of >loading them from files. > >What you you think? > >Regards, >Matthias-Christian > >_______________________________________________ >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 Sun Jan 5 21:38:29 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 05 Jan 2014 21:38:29 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52C98F15.1080804@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> <52C1E7B2.7000200@fifthhorseman.net> <52C20757.2020902@mirix.org> <52C725BA.6090601@gnutls.org> <52C98F15.1080804@mirix.org> Message-ID: <52C9C2C5.3090702@gnutls.org> On 01/05/2014 05:57 PM, Matthias-Christian Ott wrote: >> Hello, >> I don't know how practical it is to have priority strings for every >> possible jurisdiction. We can have though options for the major ones. > If I'm not mistaken, cipher suites only specify key lengths or symmetric > ciphers and GnuTLS security parameters are only used for key generation > not for connections. That's partially true. Security parameters are also used to enforce certain connection parameters as well. > As Daniel correctly suggested, this is not enough. Indeed. > At 30C3 BetterCrypto.org was presented and received some press attention > in Germany. Looking at their ?Applied Crypto Hardening? document, which > targets system administrators, configuring TLS implementations is still > too hard and requires too much effort. Most administrators will never > bother. > I think we need security profiles for GnuTLS. A security profile covers > all parameters that are relevant for security including cipher suites, We have already. This is what the common keywords like NORMAL, SECURE128, and SECURE192 are. What we don't have is to actively enforce the certificate verification to the profile level (i.e., make sure the certificates use algorithms of adequate strength). The reason to keep it that way was until now that there was no website offering an RSA certificate with strength equivalent to 128-bits or better. We could nevertheless, add new security levels such as SECURE80 and SECURE96 and see how that works out in practice when the levels are enforced. I don't know whether I'll have time for that. Anyone wanting to work on it? Most probably it would require the certificate verification process to be aware of the security level. > key lengths and TLS extensions. GnuTLS could include some default > profiles, such as profiles based on recommendations of institutions like > NIST or ENISA. Are you aware of any such profiles? The only one I know is suiteb from NSA. > Security profiles are by default loaded from a > system-wide security profile registry (some directory consists of > security profile files) according to a system-wide security policy which > specifies the default profile. That sounds like a good idea. We could have a priority string like "SYSTEM:NORMAL" that will use the system profile or NORMAL if nothing was provided by the system. regards, Nikos From nmav at gnutls.org Mon Jan 6 09:54:04 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 6 Jan 2014 09:54:04 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52C9C2C5.3090702@gnutls.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> <52C1E7B2.7000200@fifthhorseman.net> <52C20757.2020902@mirix.org> <52C725BA.6090601@gnutls.org> <52C98F15.1080804@mirix.org> <52C9C2C5.3090702@gnutls.org> Message-ID: On Sun, Jan 5, 2014 at 9:38 PM, Nikos Mavrogiannopoulos wrote: > > key lengths and TLS extensions. GnuTLS could include some default > > profiles, such as profiles based on recommendations of institutions like > > NIST or ENISA. > > Are you aware of any such profiles? The only one I know is suiteb from NSA. > I've just realized that ENISA has quite good and practical recommendations: http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report There is also a "best practices" paper, but I don't know whether we can get much from that: https://bettercrypto.org/static/applied-crypto-hardening.pdf regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From testnutzer123 at gmail.com Mon Jan 6 15:30:26 2014 From: testnutzer123 at gmail.com (Nils Maier) Date: Mon, 06 Jan 2014 15:30:26 +0100 Subject: [gnutls-devel] BUG: Cannot connect with non-blocking OS to OCSP stapling-enabled (CERTIFICATE STATUS) server Message-ID: <52CABE02.4010809@gmail.com> Affected: Likely all GnuTLS versions supporting OCSP stapling. Tested with 3.1.18 and 3.2.8. STR: - Program client using non-blocking sockets. Or if you're lazy, use aria2, where we discovered this. http://aria2.sourceforge.net/ https://github.com/tatsuhiro-t/aria2/issues/179 Or wget master, which is affected as well, or something like that. - Try to connect to a TLS server that uses stapling. E.g. https://tn123.org/ - The connection will fail (more often than not), right after the full CERTIFICATE STATUS packet is received, with: "An unexpected TLS handshake packet was received." - It fails in STATE8 of the handshake (kx) not STATE6 (CERTIFICATE STATUS). Reasons: https://gitorious.org/gnutls/gnutls/source/1b5fce89c569e4abf9784e6a2944b3ccf9dd61f8:lib/ext/status_request.c#L581 _gnutls_recv_server_certificate_status() does not handle incomplete packets (EGAIN) correctly. It sets |priv->expect_cstatus = 0;| before actually checking if there was already a full packet received. If there wasn't (and this is likely with non-blocking I/O), the method will later exit, to be called again when additional data is received. However, in that subsequent call the function will bail without further processing as |priv->expect_cstatus| was already set in the first call, leaving the unprocessed CERTIFICATE STATUS packet in the buffers. After bailing, the STATE in _gnutls_recv_server_certificate_status() transitions from STATE6 -> STATE7 -> STATE8. In STATE8, _gnutls_recv_server_kx_message() is called, with the CERTIFICATE STATUS still in the buffer, and therefore fails as it rightfully didn't expect that packet, aborting the connection attempt entirely. Fix: A preliminary test indicates the attached patch (against 3_1_x, because I'm to lazy to build a nettle-2.7 right now) fixes the problem, by moving |priv->expect_cstatus = 0;| after the |_gnutls_recv_handshake| call. I'm not a GnuTLS expert, so I have no idea what it might break in turn. Cheers Nils PS: Please CC me if you need something, as I'm not watching the lists. -------------- next part -------------- >From d6d4a177e9e705c4bbac0eaa689fa80025f52f71 Mon Sep 17 00:00:00 2001 From: Nils Maier Date: Mon, 6 Jan 2014 15:15:58 +0100 Subject: [PATCH] Fix CERTIFICATE STATUS processing when using non-blocking I/O _gnutls_recv_server_certificate_status() must wait for the first full packet before setting priv->expect_cstatus = 0, or else CERTIFCATE STATUS packets won't be processed in subsequent calls at all, leaving them in the buffer and therefore causing later connection aborts. --- lib/ext/status_request.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/ext/status_request.c b/lib/ext/status_request.c index ac512c2..267ba5d 100644 --- a/lib/ext/status_request.c +++ b/lib/ext/status_request.c @@ -574,28 +574,28 @@ _gnutls_recv_server_certificate_status (gnutls_session_t session) _gnutls_ext_get_session_data (session, GNUTLS_EXTENSION_STATUS_REQUEST, &epriv); if (ret < 0) return 0; priv = epriv.ptr; if (!priv->expect_cstatus) return 0; - priv->expect_cstatus = 0; - ret = _gnutls_recv_handshake (session, GNUTLS_HANDSHAKE_CERTIFICATE_STATUS, 0, &buf); if (ret < 0) return gnutls_assert_val_fatal(ret); + priv->expect_cstatus = 0; + data = buf.data; data_size = buf.length; /* minimum message is type (1) + response (3) + data */ if (data_size == 0) return 0; else if (data_size < 4) return gnutls_assert_val (GNUTLS_E_UNEXPECTED_PACKET_LENGTH); if (data[0] != 0x01) -- 1.8.5.2 From nmav at gnutls.org Tue Jan 7 09:30:46 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 7 Jan 2014 09:30:46 +0100 Subject: [gnutls-devel] BUG: Cannot connect with non-blocking OS to OCSP stapling-enabled (CERTIFICATE STATUS) server In-Reply-To: <52CABE02.4010809@gmail.com> References: <52CABE02.4010809@gmail.com> Message-ID: On Mon, Jan 6, 2014 at 3:30 PM, Nils Maier wrote: > Affected: Likely all GnuTLS versions supporting OCSP stapling. Tested > with 3.1.18 and 3.2.8. > > STR: > - Program client using non-blocking sockets. Or if you're lazy, use > aria2, where we discovered this. > http://aria2.sourceforge.net/ > https://github.com/tatsuhiro-t/aria2/issues/179 > Or wget master, which is affected as well, or something like that. > Thank you. The fix seems correct and I'll apply it. As a work-around you may call gnutls_init() with the GNUTLS_NO_EXTENSIONS flag (when defined). The side effect would be to disable the OCSP status extension and the session ticket extension being enabled by default. regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Jan 8 21:57:59 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 8 Jan 2014 15:57:59 -0500 Subject: [gnutls-devel] [PATCH] gnutls-cli-debug should accept TLS 1.2-only servers Message-ID: <1389214679-27918-1-git-send-email-dkg@fifthhorseman.net> Without this patch, a TLS 1.2-only server will not be properly investigated by gnutls-cli-debug. e.g. a server like: gnutls-serv --x509keyfile=server/secret.key --x509certfile=server/x509.pem --priority 'NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2' gets this failed analysis: 0 dkg at alice:~$ gnutls-cli-debug --port 5556 localhostrt 5556 localhost Resolving 'localhost'... Connecting to '::1:5556'... Checking for SSL 3.0 support... no Checking whether %COMPAT is required... yes Checking for TLS 1.0 support... no Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... failed Checking for TLS 1.2 support... yes Checking whether we need to disable TLS 1.2... N/A Checking whether we need to disable TLS 1.1... no Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 0 dkg at alice:~$ --- src/cli-debug.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/cli-debug.c b/src/cli-debug.c index 6110184..f6e4c16 100644 --- a/src/cli-debug.c +++ b/src/cli-debug.c @@ -63,6 +63,7 @@ unsigned int verbose = 0; extern int tls1_ok; extern int tls1_1_ok; +extern int tls1_2_ok; extern int ssl3_ok; static void tls_log_func(int level, const char *str) @@ -248,10 +249,10 @@ int main(int argc, char **argv) /* if neither of SSL3 and TLSv1 are supported, exit */ - if (i > 6 && tls1_1_ok == 0 && tls1_ok == 0 + if (i > 6 && tls1_2_ok == 0 && tls1_1_ok == 0 && tls1_ok == 0 && ssl3_ok == 0) { fprintf(stderr, - "\nServer does not support any of SSL 3.0, TLS 1.0 and TLS 1.1\n"); + "\nServer does not support any of SSL 3.0, TLS 1.0 and TLS 1.1 and TLS 1.2\n"); break; } -- 1.8.5.2 From nmav at gnutls.org Thu Jan 9 08:52:02 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 09 Jan 2014 08:52:02 +0100 Subject: [gnutls-devel] [PATCH] gnutls-cli-debug should accept TLS 1.2-only servers In-Reply-To: <1389214679-27918-1-git-send-email-dkg@fifthhorseman.net> References: <1389214679-27918-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <52CE5522.5020808@gnutls.org> On 01/08/2014 09:57 PM, Daniel Kahn Gillmor wrote: > Without this patch, a TLS 1.2-only server will not be properly > investigated by gnutls-cli-debug. Applied. Thank you. Nikos From wiz at NetBSD.org Thu Jan 16 11:18:19 2014 From: wiz at NetBSD.org (Thomas Klausner) Date: Thu, 16 Jan 2014 11:18:19 +0100 Subject: [gnutls-devel] test hangs in 3.2.8.1 Message-ID: <20140116101819.GK16992@danbala.tuwien.ac.at> Hi! I've updated gnutls in pkgsrc to 3.2.8.1 and ran the self tests on NetBSD-6.99.28/amd64. Two of the tests hung for minutes until I gave up on them. I'm not sure if that's a bug or if I'm too impatient. I've disabled them in pkgsrc for now (the dsa/ test and the testcerts test in openpgp-certs). Does anyone else have problems with these tests? Do you have suggestions how to debug this, if it's a local problem? Thanks, Thomas -------------- next part -------------- $NetBSD: patch-tests_Makefile.in,v 1.1 2014/01/16 10:14:09 wiz Exp $ Disable dsa test. Hangs on NetBSD-6.99.28/amd64 in gnutls-3.8.2.1. Please retest during updates. --- tests/Makefile.in.orig 2013-12-20 18:30:47.000000000 +0000 +++ tests/Makefile.in @@ -2063,7 +2063,7 @@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ SUBDIRS = . rsa-md5-collision pkcs1-padding pkcs8-decode pkcs12-decode \ - userid cert-tests key-id sha2 safe-renegotiation dsa scripts \ + userid cert-tests key-id sha2 safe-renegotiation scripts \ ecdsa slow dtls srp $(am__append_1) $(am__append_2) EXTRA_DIST = suppressions.valgrind eagain-common.h AM_CFLAGS = $(WARN_CFLAGS) $(WERROR_CFLAGS) -------------- next part -------------- $NetBSD: patch-tests_openpgp-certs_Makefile.in,v 1.1 2014/01/16 10:14:09 wiz Exp $ Disable testcerts test. Hangs on NetBSD-6.99.28/amd64 with gnutls-3.8.2.1. Please retest during updates. --- tests/openpgp-certs/Makefile.in.orig 2014-01-16 09:45:13.000000000 +0000 +++ tests/openpgp-certs/Makefile.in @@ -1417,7 +1417,7 @@ dist_check_SCRIPTS = testselfsigs testce # The selftest is disabled until we can make it work under Wine and # under Debian buildds (problem with 127.0.0.2?). - at ENABLE_OPENPGP_TRUE@TESTS = testselfsigs $(am__append_1) + at ENABLE_OPENPGP_TRUE@TESTS = testselfsigs # $(am__append_1) TESTS_ENVIRONMENT = EXEEXT=$(EXEEXT) \ LC_ALL="C" \ top_builddir="$(top_builddir)" \ From nmav at gnutls.org Fri Jan 17 08:01:21 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 17 Jan 2014 08:01:21 +0100 Subject: [gnutls-devel] test hangs in 3.2.8.1 In-Reply-To: <20140116101819.GK16992@danbala.tuwien.ac.at> References: <20140116101819.GK16992@danbala.tuwien.ac.at> Message-ID: <52D8D541.2030109@gnutls.org> On 01/16/2014 11:18 AM, Thomas Klausner wrote: > Hi! > > I've updated gnutls in pkgsrc to 3.2.8.1 and ran the self tests on > NetBSD-6.99.28/amd64. > > Two of the tests hung for minutes until I gave up on them. I'm not > sure if that's a bug or if I'm too impatient. I've disabled them in > pkgsrc for now (the dsa/ test and the testcerts test in > openpgp-certs). > > Does anyone else have problems with these tests? > Do you have suggestions how to debug this, if it's a local problem? Hello, The tests you disabled are simply scripts. Could you try running them and see where their failure is? regards, Nikos From wiz at NetBSD.org Fri Jan 17 11:31:02 2014 From: wiz at NetBSD.org (Thomas Klausner) Date: Fri, 17 Jan 2014 11:31:02 +0100 Subject: [gnutls-devel] test hangs in 3.2.8.1 In-Reply-To: <52D8D541.2030109@gnutls.org> References: <20140116101819.GK16992@danbala.tuwien.ac.at> <52D8D541.2030109@gnutls.org> Message-ID: <20140117103102.GV16992@danbala.tuwien.ac.at> On Fri, Jan 17, 2014 at 08:01:21AM +0100, Nikos Mavrogiannopoulos wrote: > The tests you disabled are simply scripts. Could you try running them > and see where their failure is? $ ./testdsa Checking various DSA key sizes Checking DSA-1024 with TLS 1.0 Error setting the x509 trust file Checking server DSA-1024 with client DSA-1024 and TLS 1.0 Error setting the x509 trust file Checking server DSA-1024 with client DSA-2048 and TLS 1.0 Checking server DSA-1024 with client DSA-3072 and TLS 1.0 (nothing happens for a long time) (when I press CTRL-C it continues with) Checking DSA-1024 with TLS 1.2 Error setting the x509 trust file Checking server DSA-1024 with client DSA-1024 and TLS 1.2 Error setting the x509 trust file Checking server DSA-1024 with client DSA-2048 and TLS 1.2 Error setting the x509 trust file *** Fatal error: The given DSA key is incompatible with the selected TLS protocol. *** Handshake has failed GnuTLS error: The given DSA key is incompatible with the selected TLS protocol. Failure: Failed connection to a server with a client DSA 2048 key and TLS 1.2! and I have two processes left: user 29304 99.0 0.0 26504 2700 pts/2 O 10:13AM 7:53.90 /scratch/security/gnutls/work/gnutls-3.2.8/src/.libs/gnutls-serv -q -p 5559 --priority NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0 --x509certfile ./cert.dsa.1024.pem --x509keyfile ./dsa.1024.pem user 18836 0.0 0.0 25480 2112 pts/2 I 10:20AM 0:00.01 /scratch/security/gnutls/work/gnutls-3.2.8/src/.libs/gnutls-serv -q -p 5559 --priority NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2 --x509certfile ./cert.dsa.1024.pem --x509keyfile ./dsa.1024.pem After killing them both, I tried the other test: $ ./testcerts Checking OpenPGP certificate verification (nothing happens) (after I press CTRL-C a few times, I see) Error setting the x509 trust file *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate. Failure: Connection to signed PGP certificate should have succeeded! (error code 1) and I have three processes left: user 603 0.0 0.0 27532 2676 pts/2 I 10:23AM 0:00.01 /scratch/security/gnutls/work/gnutls-3.2.8/src/.libs/gnutls-serv -q -p 5557 --priority NORMAL:+CTYPE-OPENPGP --pgpcertfile ./srv-public-127.0.0.1-signed.gpg --pgpkeyfile ./srv-secret.gpg user 15030 0.0 0.0 25484 2112 pts/2 I 10:28AM 0:00.01 /scratch/security/gnutls/work/gnutls-3.2.8/src/.libs/gnutls-serv -q -p 5557 --priority NORMAL:+CTYPE-OPENPGP --pgpcertfile ./srv-public-localhost-signed.gpg --pgpkeyfile ./srv-secret.gpg user 28391 0.0 0.0 25484 2112 pts/2 I 10:28AM 0:00.01 /scratch/security/gnutls/work/gnutls-3.2.8/src/.libs/gnutls-serv -q -p 5557 --priority NORMAL:+CTYPE-OPENPGP --pgpcertfile ./srv-public-all-signed.gpg --pgpkeyfile ./srv-secret.gpg Why are there left-over processes? Are they perhaps emptying out the entropy pool and blocking for that reason, or do you have another explanation? Thomas From ametzler at bebt.de Sun Jan 19 13:34:22 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 19 Jan 2014 13:34:22 +0100 Subject: [gnutls-devel] gnutls 3.2.6+: connection to api.dreamhost.com hangs Message-ID: <20140119123422.GE3230@downhill.g.la> Hello, this is http://bugs.debian.org/733039 reported by Neil Roeth. Recent versions of gnutls fail at connecting to api.dreamhost.com, they just hang. Git bisect shows that breakage started with this commit: ------- 3ff8313d3eb53eed1a509e45d5f5103c87c1900d is the first bad commit commit 3ff8313d3eb53eed1a509e45d5f5103c87c1900d Author: Nikos Mavrogiannopoulos Date: Wed Oct 23 18:53:45 2013 +0200 Added camellia-gcm into the default priority levels, and prioritized GCM over CBC everywhere. ------- Daniel Kahn Gillmor added these interesting pieces of information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733039#22 |------------------------------------------------------ | I can confirm that 3.2.7 seems to hang for me, when i do: | | gnutls-cli --priority NORMAL api.dreamhost.com | | However, i can connect cleanly with: | | gnutls-cli --priority NORMAL:-DHE-DSS api.dreamhost.com | | I can avoid the same hang if i substitute any large-ish class of ciphers | anywhere i put DHE-DSS above. | | Looking at the traffic on the wire, it looks like the non-hanging | connections offer a ClientHello of size < 256 bytes, while the hanging | connections have size >= 256 bytes. | | this smells a lot like the F5 bug with certain sizes of TLS handshakes, | being misinterpreted as SSLv2, as reported by Xiaoyong Wu: | | http://thread.gmane.org/gmane.ietf.tls/11187/focus=11227 | | The way to resolve this would be: if the client hello is >= 256 byees, | but < 512 bytes, add a meaningless extension to push the size of the | client hello above 512 bytes. | | I haven't tested this yet, unfortunately. | | --dkg |------------------------------------------------------ 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 Sun Jan 19 14:23:24 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 19 Jan 2014 14:23:24 +0100 Subject: [gnutls-devel] gnutls 3.2.6+: connection to api.dreamhost.com hangs In-Reply-To: <20140119123422.GE3230@downhill.g.la> References: <20140119123422.GE3230@downhill.g.la> Message-ID: <52DBD1CC.6030104@gnutls.org> On 01/19/2014 01:34 PM, Andreas Metzler wrote: > Hello, > > this is http://bugs.debian.org/733039 reported by Neil Roeth. > > Recent versions of gnutls fail at connecting to api.dreamhost.com, > they just hang. Git bisect shows that breakage started with this commit: Hello, It looks like that this site is behind the problematic firewall the %DUMBFW priority string option was added. Does adding the %DUMBFW option fix the connection? This firewall drops TLS client hello messages that are between 256 and 512 bytes. regards, Nikos From nmav at gnutls.org Sun Jan 19 14:56:26 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 19 Jan 2014 14:56:26 +0100 Subject: [gnutls-devel] gnutls 3.2.6+: connection to api.dreamhost.com hangs In-Reply-To: <52DBD1CC.6030104@gnutls.org> References: <20140119123422.GE3230@downhill.g.la> <52DBD1CC.6030104@gnutls.org> Message-ID: <52DBD98A.7050000@gnutls.org> On 01/19/2014 02:23 PM, Nikos Mavrogiannopoulos wrote: > On 01/19/2014 01:34 PM, Andreas Metzler wrote: >> Hello, >> >> this is http://bugs.debian.org/733039 reported by Neil Roeth. >> >> Recent versions of gnutls fail at connecting to api.dreamhost.com, >> they just hang. Git bisect shows that breakage started with this commit: > > Hello, > It looks like that this site is behind the problematic firewall the > %DUMBFW priority string option was added. Does adding the %DUMBFW option > fix the connection? This firewall drops TLS client hello messages that > are between 256 and 512 bytes. And indeed that's the case. When removing DHE-DSS the client hello size drops to 247 bytes. If it is a widespread issue maybe we can add enable the %DUMBFW extension to clients by default. There is even an internet draft for this extension: http://tools.ietf.org/html/draft-agl-tls-padding-03 regards, Nikos From nmav at gnutls.org Sun Jan 19 18:33:42 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 19 Jan 2014 18:33:42 +0100 Subject: [gnutls-devel] test hangs in 3.2.8.1 In-Reply-To: <20140117103102.GV16992@danbala.tuwien.ac.at> References: <20140116101819.GK16992@danbala.tuwien.ac.at> <52D8D541.2030109@gnutls.org> <20140117103102.GV16992@danbala.tuwien.ac.at> Message-ID: <52DC0C76.4020805@gnutls.org> On 01/17/2014 11:31 AM, Thomas Klausner wrote: > On Fri, Jan 17, 2014 at 08:01:21AM +0100, Nikos Mavrogiannopoulos wrote: >> The tests you disabled are simply scripts. Could you try running them >> and see where their failure is? > > $ ./testdsa > Checking various DSA key sizes > Checking DSA-1024 with TLS 1.0 > Error setting the x509 trust file > Checking server DSA-1024 with client DSA-1024 and TLS 1.0 > Error setting the x509 trust file > Checking server DSA-1024 with client DSA-2048 and TLS 1.0 > Checking server DSA-1024 with client DSA-3072 and TLS 1.0 > (nothing happens for a long time) > (when I press CTRL-C it continues with) Could there be some bashism in the script that makes it hang? You could also remove the redirections to /dev/null of stderr in that command to see the actual error. It's better first to check the script with /bin/bash to see if it succeeds. > Why are there left-over processes? > Are they perhaps emptying out the entropy pool and blocking for that > reason, or do you have another explanation? I have no explanation yet, though it cannot be the entropy pool issue as /dev/urandom is used. However to identify the issue I'll need some debug data from you, e.g., by running the instance that fails without redirection of stderr and using -d 9, both on the client and server. regards, Nikos From user100 at lisec.com Tue Jan 21 15:06:50 2014 From: user100 at lisec.com (user100) Date: Tue, 21 Jan 2014 15:06:50 +0100 Subject: [gnutls-devel] Handshake issue with windows-version of GnuTLS with GnuTLS 3.2.7 / 3.2.8 Message-ID: <52DE7EFA.2050003@lisec.com> Handshake does not work anymore on Win8 64bit with GnuTLS 3.2.7 or GnuTLS 3.2.8 - binaries from ftp://ftp.gnutls.org/gcrypt/gnutls/w32/ (app is 32bit too). Previous versions (including 3.2.6) worked pretty well. Following is the gnutls log at a missing handshake with 3.2.8 (WSA did not report an error ... and as already written 3.2.6 worked well): EXT[04B35BF0]: Sending extension SIGNATURE ALGORITHMS (28 bytes) HSK[04B35BF0]: CLIENT HELLO was queued [249 bytes] HWRITE: enqueued [CLIENT HELLO] 249. Total 249 bytes. HWRITE FLUSH: 249 bytes in buffer. REC[04B35BF0]: Preparing Packet Handshake(22) with length: 249 and min pad: 0 ENC[04B35BF0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 WRITE: enqueued 254 bytes for 000002D0. Total 254 bytes. REC[04B35BF0]: Sent Packet[1] Handshake(22) in epoch 0 and length: 254 HWRITE: wrote 1 bytes, 0 bytes left. WRITE FLUSH: 254 bytes in buffer. ASSERT: gnutls_buffers.c:408 errno: 5 ASSERT: gnutls_buffers.c:192 WRITE error: code -53, 254 bytes left. ASSERT: gnutls_buffers.c:650 ASSERT: gnutls_handshake.c:2675 Error is fatal: Error in the push function. From nmav at gnutls.org Thu Jan 23 18:13:34 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 23 Jan 2014 18:13:34 +0100 Subject: [gnutls-devel] Handshake issue with windows-version of GnuTLS with GnuTLS 3.2.7 / 3.2.8 In-Reply-To: <52DE7EFA.2050003@lisec.com> References: <52DE7EFA.2050003@lisec.com> Message-ID: <52E14DBE.3070103@gnutls.org> On 01/21/2014 03:06 PM, user100 wrote: > Handshake does not work anymore on Win8 64bit with GnuTLS 3.2.7 or > GnuTLS 3.2.8 - binaries from ftp://ftp.gnutls.org/gcrypt/gnutls/w32/ > (app is 32bit too). Previous versions (including 3.2.6) worked pretty > well. Following is the gnutls log at a missing handshake with 3.2.8 (WSA > did not report an error ... and as already written 3.2.6 worked well): The current version of gnutls uses by default the gnulib's recv and send functions that are incompatible (didn't realize until very recently). A work-around until the next release is to make some dummy push and pull functions using windows' recv() and send() and use gnutls_transport_set_push_function and gnutls_transport_set_pull_function to set them. regards, Nikos From kurt at roeckx.be Fri Jan 24 00:14:19 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Jan 2014 00:14:19 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences Message-ID: <20140123231419.GA4316@roeckx.be> Hi, I'm using gnutls_x509_dn_get_rdn_ava() to iterate over the over all the fields. One of the fields (irdn 3, iava 0) I get back a value_tag of 16, and the length is 72. 16 seems to mean that it's a sequence. The OID is 2.5.4.16 (PostalAddress). certtool prints it like: 2.5.4.16=#30480c46[...] openssl's x509 prints it as: postalAddress=0H\x0CF[...] The first 2 bytes of the data I see is 0x0C (12), 0x46 (70, 'F'), so I'm confused why both certtool and openssl put 0x30 ('0'), 0x48 ('H') in front of it. A hex dump of the file at least shows a "10 30 48 0c 46". Anyway, the 12, 70 seem to mean that it's an UTF8String of size 70 to me, and I can actually parse it like that succesfully. I understand that the Postal Address is a sequence since it's supposed to be a sequence of DirectoryString. But I'm little confused why gnutls is showing me the data like that. I was expecting to just get a type 12 (UTF8String) from the gnutls_x509_dn_get_rdn_ava() since it says it's supposed to model the sequence of sequences. This was tested with 3.2.8.1 The certificate is attached. Kurt -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDwDCCA22gAwIBAgIQAcxbS/CxBrAAAAAAGqIADDAKBgYqhQMCAgMFADCCAS0x CzAJBgNVBAYTAlJVMRUwEwYDVQQHDAzQodCw0LzQsNGA0LAxGzAZBgNVBAgMEtCh 0LDQvNCw0YDRgdC60LDRjzFRME8GA1UEEDBIDEY0NDMwMTMsINCh0LDQvNCw0YDQ sCwg0JzQvtGB0LrQvtCy0YHQutC+0LUg0YjQvtGB0YHQtSwgMywg0L7RhNC40YEg MzAyMR0wGwYJKoZIhvcNAQkBFg5jYUBjcnlwdGV4LnBybzEgMB4GA1UECgwX0J7Q ntCeINCa0YDQuNC/0YLRjdC60YExRDBCBgNVBAsMO9Cj0LTQvtGB0YLQvtCy0LXR gNGP0Y7RidC40Lkg0Lgg0LrQu9GO0YfQtdCy0L7QuSDRhtC10L3RgtGAMRAwDgYD VQQDDAdDUllQVEVYMB4XDTExMDgxNTEzMTI0N1oXDTE2MDgxNTEzMDUwMFowgaMx CzAJBgNVBAYTAlJVMRUwEwYDVQQHDAzQodCw0LzQsNGA0LAxHjAcBgNVBAgMFTYz INCh0LDQvNCw0YDRgdC60LDRjzEiMCAGCSqGSIb3DQEJARYTc2VydmljZUBjcnlw dGV4LnBybzEgMB4GA1UECgwX0J7QntCeINCa0YDQuNC/0YLRjdC60YExFzAVBgNV BAMMDnRzLmNyeXB0ZXgucHJvMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDD C4h7O2jnyFzCUCvi1bepEvYlpPqy9tcC1/yfT0DcAmnDr7sYRksRar1Yi5Y6/Em4 WD0tP/8HuKfSei0nQKo2vI1x2KqMR3dldb4j64Vo/ba307owZY5iWYvrAka7gbGU zZ6/tYR+66nTeLTny5DV2oljBV+OAl/4XLXjz6hfswIDAQABgQkAMUFBMjAwMDKj gaMwgaAwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1Ud EwEB/wQCMAAwHQYDVR0OBBYEFDx3LnKjcPemvfwjvIsm+WoY3M0HMCsGA1UdEAQk MCKADzIwMTEwODE1MTMxMjQ3WoEPMjAxMjA4MTUxMzEyNDdaMB8GA1UdIwQYMBaA FOy7IUu+JmatNcWB0YRK0/zZgXozMAoGBiqFAwICAwUAA0EA5oqy7oPaCL12ka6r gdVCH4J7h5Wv60kjwUkPKGFF8UoPNR3IolfxBEWfq7PPGKcJpxVY1J3z/CvdZ24H ihpoZA== -----END CERTIFICATE----- From nmav at gnutls.org Fri Jan 24 07:39:32 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 07:39:32 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences In-Reply-To: <20140123231419.GA4316@roeckx.be> References: <20140123231419.GA4316@roeckx.be> Message-ID: <52E20AA4.70408@gnutls.org> On 01/24/2014 12:14 AM, Kurt Roeckx wrote: > I understand that the Postal Address is a sequence since it's > supposed to be a sequence of DirectoryString. > > But I'm little confused why gnutls is showing me the data like that. > I was expecting to just get a type 12 (UTF8String) from the > gnutls_x509_dn_get_rdn_ava() since it says it's supposed to model > the sequence of sequences. It models the sequence of sequences in the DN itself, not any possible sequence within the individual fields. The postalAddress field as you notice is a sequence as well. That's why you see that difference and that's the reason it is not being decoded by default. regards, Nikos From kurt at roeckx.be Fri Jan 24 09:18:32 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Jan 2014 09:18:32 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences In-Reply-To: <52E20AA4.70408@gnutls.org> References: <20140123231419.GA4316@roeckx.be> <52E20AA4.70408@gnutls.org> Message-ID: <20140124081832.GA15326@roeckx.be> On Fri, Jan 24, 2014 at 07:39:32AM +0100, Nikos Mavrogiannopoulos wrote: > On 01/24/2014 12:14 AM, Kurt Roeckx wrote: > > > I understand that the Postal Address is a sequence since it's > > supposed to be a sequence of DirectoryString. > > > > But I'm little confused why gnutls is showing me the data like that. > > I was expecting to just get a type 12 (UTF8String) from the > > gnutls_x509_dn_get_rdn_ava() since it says it's supposed to model > > the sequence of sequences. > > It models the sequence of sequences in the DN itself, not any possible > sequence within the individual fields. The postalAddress field as you > notice is a sequence as well. That's why you see that difference and > that's the reason it is not being decoded by default. So are there some functions I can use that to go over that sequence, or do I need to write my own parser? Kurt From nmav at gnutls.org Fri Jan 24 10:16:38 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 10:16:38 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences In-Reply-To: <20140124081832.GA15326@roeckx.be> References: <20140123231419.GA4316@roeckx.be> <52E20AA4.70408@gnutls.org> <20140124081832.GA15326@roeckx.be> Message-ID: On Fri, Jan 24, 2014 at 9:18 AM, Kurt Roeckx wrote: >> > But I'm little confused why gnutls is showing me the data like that. >> > I was expecting to just get a type 12 (UTF8String) from the >> > gnutls_x509_dn_get_rdn_ava() since it says it's supposed to model >> > the sequence of sequences. >> It models the sequence of sequences in the DN itself, not any possible >> sequence within the individual fields. The postalAddress field as you >> notice is a sequence as well. That's why you see that difference and >> that's the reason it is not being decoded by default. > So are there some functions I can use that to go over that > sequence, or do I need to write my own parser? You can decode it using libtasn1 or even a custom parser. If you do a patch for gnutls to decode it would also be appreciated. regards, Nikos From kurt at roeckx.be Fri Jan 24 18:31:39 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Jan 2014 18:31:39 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences In-Reply-To: References: <20140123231419.GA4316@roeckx.be> <52E20AA4.70408@gnutls.org> <20140124081832.GA15326@roeckx.be> Message-ID: <20140124173139.GA23596@roeckx.be> On Fri, Jan 24, 2014 at 10:16:38AM +0100, Nikos Mavrogiannopoulos wrote: > On Fri, Jan 24, 2014 at 9:18 AM, Kurt Roeckx wrote: > >> > But I'm little confused why gnutls is showing me the data like that. > >> > I was expecting to just get a type 12 (UTF8String) from the > >> > gnutls_x509_dn_get_rdn_ava() since it says it's supposed to model > >> > the sequence of sequences. > >> It models the sequence of sequences in the DN itself, not any possible > >> sequence within the individual fields. The postalAddress field as you > >> notice is a sequence as well. That's why you see that difference and > >> that's the reason it is not being decoded by default. > > So are there some functions I can use that to go over that > > sequence, or do I need to write my own parser? > > You can decode it using libtasn1 or even a custom parser. If you do a > patch for gnutls to decode it would also be appreciated. What did you have in mind for patching in gnutls? That certtool can handle it? That there is an API other than using libtasn1 to do it? Kurt From nmav at gnutls.org Fri Jan 24 19:09:15 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 19:09:15 +0100 Subject: [gnutls-devel] gnutls 3.2.9 Message-ID: <52E2AC4B.5040809@gnutls.org> Hello, I've just released gnutls 3.2.9. This is a bugfix release which also marks the gnutls 3.2 branch is as the current stable. * Version 3.2.9 (released 2014-01-24) ** libgnutls: The %DUMBFW option in priority string only appends data to client hello if the expected size is in the "black hole" range. ** libgnutls: %COMPAT implies %DUMBFW. ** libgnutls: gnutls_session_get_desc() returns a more compact ciphersuite description. * libgnutls: In PKCS #11 allow deleting multiple non-certificate data. ** libgnutls: When a PKCS #11 trust store is specified (e.g. using the configure option --with-default-trust-store-pkcs11), then the PKCS #11 token is used on demand to obtain the trusted anchors, rather than preloading all trusted certificates. That delegates CA certificate management and blacklist checking to the PKCS #11 module. ** libgnutls: When a PKCS #11 trust store is specified in configure option or in gnutls_x509_trust_list_add_trust_file(), then the module is used to obtain the verification anchors and any required blacklists as in http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html ** libgnutls: Fix in OCSP certificate status extension handling in non-blocking servers. Patch by Nils Maier. ** p11tool: Added --so-login option to force login as security officer (admin). ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.lz.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 Fri Jan 24 19:23:38 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 19:23:38 +0100 Subject: [gnutls-devel] gnutls 3.1.19 Message-ID: <52E2AFAA.80806@gnutls.org> Hello, I've just released gnutls 3.1.19. This is a bug fix release on the previous stable branch. * Version 3.1.19 (released 2014-01-24) ** libgnutls: Fix in OCSP certificate status extension handling in non-blocking servers. Patch by Nils Maier. ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.lz.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 Fri Jan 24 20:03:04 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 20:03:04 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences In-Reply-To: <20140124173139.GA23596@roeckx.be> References: <20140123231419.GA4316@roeckx.be> <52E20AA4.70408@gnutls.org> <20140124081832.GA15326@roeckx.be> <20140124173139.GA23596@roeckx.be> Message-ID: <52E2B8E8.8040406@gnutls.org> On 01/24/2014 06:31 PM, Kurt Roeckx wrote: >>>> It models the sequence of sequences in the DN itself, not any possible >>>> sequence within the individual fields. The postalAddress field as you >>>> notice is a sequence as well. That's why you see that difference and >>>> that's the reason it is not being decoded by default. >>> So are there some functions I can use that to go over that >>> sequence, or do I need to write my own parser? >> >> You can decode it using libtasn1 or even a custom parser. If you do a >> patch for gnutls to decode it would also be appreciated. > > What did you have in mind for patching in gnutls? That certtool > can handle it? That there is an API other than using libtasn1 to > do it? For more complex encoding than octet strings libtasn1 is the easiest to use (although the complexity of PostalString is really borderline and making a custom parser may be actually faster). I was thinking about gnutls_x509_crt_get_dn() (under the hood is gnutls_x509_crt_get_dn()) that decodes DNs to plain LDAP strings. regards, Nikos From kurt at roeckx.be Sun Jan 26 17:32:45 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Jan 2014 17:32:45 +0100 Subject: [gnutls-devel] gnutls_x509_policy_release not available Message-ID: <20140126163245.GA20070@roeckx.be> Hi, When using trying to use I get: undefined reference to `gnutls_x509_policy_release' Not using that function I of course end up with a memory leak. Kurt From kurt at roeckx.be Sun Jan 26 18:27:30 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 26 Jan 2014 18:27:30 +0100 Subject: [gnutls-devel] gnutls_x509_crt_get_extension_by_oid and NULL buf Message-ID: <20140126172730.GA20803@roeckx.be> Hi, The documentation for gnutls_x509_crt_get_extension_by_oid says that buf can be NULL. But looking at the code I see this: if (output.size > (unsigned int) *buf_size) { *buf_size = output.size; _gnutls_free_datum(&output); return GNUTLS_E_SHORT_MEMORY_BUFFER; } *buf_size = output.size; if (buf) memcpy(buf, output.data, output.size); That is, if buf is NULL, it's still going to check the size of the buffer and if it's too small update the size and return GNUTLS_E_SHORT_MEMORY_BUFFER. At this point I was only interested in checking the existence of the extension, and so was expecting to get GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE back, and if it's not present it works properly, but if it is present I currently get GNUTLS_E_SHORT_MEMORY_BUFFER back, unless I set buf_size to some arbitrary high value. So my question is if this is intentional or not. Wouldn't it make more sense to only give this error in case buf is not NULL? Kurt From nmav at gnutls.org Sun Jan 26 19:38:32 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 26 Jan 2014 19:38:32 +0100 Subject: [gnutls-devel] gnutls_x509_policy_release not available In-Reply-To: <20140126163245.GA20070@roeckx.be> References: <20140126163245.GA20070@roeckx.be> Message-ID: <52E55628.1030008@gnutls.org> On 01/26/2014 05:32 PM, Kurt Roeckx wrote: > Hi, > When using trying to use I get: > undefined reference to `gnutls_x509_policy_release' > > Not using that function I of course end up with a memory leak. Hello, Unfortunately that function wasn't listed in the exported list. I've now made a script to compare the exported functions with the headers to avoid missing such issues. It seems there were more functions that were not exported while present, so a new release should be expected soon. regards, Nikos From nmav at gnutls.org Sun Jan 26 19:45:52 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 26 Jan 2014 19:45:52 +0100 Subject: [gnutls-devel] gnutls_x509_crt_get_extension_by_oid and NULL buf In-Reply-To: <20140126172730.GA20803@roeckx.be> References: <20140126172730.GA20803@roeckx.be> Message-ID: <52E557E0.7080004@gnutls.org> On 01/26/2014 06:27 PM, Kurt Roeckx wrote: > Hi, > > The documentation for gnutls_x509_crt_get_extension_by_oid says > that buf can be NULL. But looking at the code I see this: > > if (output.size > (unsigned int) *buf_size) { > *buf_size = output.size; > _gnutls_free_datum(&output); > return GNUTLS_E_SHORT_MEMORY_BUFFER; > } > > *buf_size = output.size; > > if (buf) > memcpy(buf, output.data, output.size); > > That is, if buf is NULL, it's still going to check the size of the > buffer and if it's too small update the size and return > GNUTLS_E_SHORT_MEMORY_BUFFER. That seems correct. > At this point I was only interested in checking the existence of > the extension, and so was expecting to get > GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE back, and if it's not > present it works properly, but if it is present I currently > get GNUTLS_E_SHORT_MEMORY_BUFFER back, unless I set buf_size > to some arbitrary high value. > So my question is if this is intentional or not. Wouldn't it make > more sense to only give this error in case buf is not NULL? This was intentional. Most of the functions in gnutls that accept a buffer work pretty much that way. When a null buffer and/or zero buffer_size is passed then the required size is returned along with GNUTLS_E_SHORT_MEMORY_BUFFER. Success is only returned when the data are actually returned. I think that logic is sufficient to check the presence or not as GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is always returned if the extension is not there. regards, Nikos From nmav at gnutls.org Mon Jan 27 14:31:01 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 27 Jan 2014 14:31:01 +0100 Subject: [gnutls-devel] gnutls_x509_dn_get_rdn_ava and sequences In-Reply-To: <52E2B8E8.8040406@gnutls.org> References: <20140123231419.GA4316@roeckx.be> <52E20AA4.70408@gnutls.org> <20140124081832.GA15326@roeckx.be> <20140124173139.GA23596@roeckx.be> <52E2B8E8.8040406@gnutls.org> Message-ID: On Fri, Jan 24, 2014 at 8:03 PM, Nikos Mavrogiannopoulos wrote: >> What did you have in mind for patching in gnutls? That certtool >> can handle it? That there is an API other than using libtasn1 to >> do it? > For more complex encoding than octet strings libtasn1 is the easiest to > use (although the complexity of PostalString is really borderline and > making a custom parser may be actually faster). btw. nettle in its asn1.h has a very primitive decoding method based on an iterator that suits that case. Maybe that should be part of libtasn1. regards, Nikos From dkg at fifthhorseman.net Tue Jan 28 22:17:22 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 Jan 2014 16:17:22 -0500 Subject: [gnutls-devel] libgmp re-licensing and its effect on GnuTLS Message-ID: <52E81E62.9060705@fifthhorseman.net> Hi GnuTLS folks-- It looks like libgmp is re-licensing to use LGPL3+ and GPL2+: https://gmplib.org/repo/gmp/rev/02634effbd4e This suggests that the licensing requirements for works derived from gnutls now have a different bar to meet. in particular, i think it means that GPLv2-only applications linked against modern versions of GnuTLS should now be redistributable again. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Fri Jan 31 17:30:23 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 Jan 2014 17:30:23 +0100 Subject: [gnutls-devel] gnutls 3.2.10 Message-ID: <52EBCF9F.7090104@gnutls.org> Hello, I've just released gnutls 3.2.10. This is a bugfix release on the current stable branch. * Version 3.2.10 (released 2014-01-31) ** libgnutls: fixed null pointer derefence when printing a certificate DN and an LDAP description isn't present. ** libgnutls: When obtaining usage statistics for the random generator use system calls outside the mutex locks to prevent them from becoming bottleneck. ** libgnutls: gnutls_db_check_entry_time will correctly report the time; report and patch by Jonathan Roudiere. ** API and ABI modifications: gnutls_x509_policy_release: Exported gnutls_pubkey_set_key_usage: Exported gnutls_x509_privkey_import_rsa_raw2: Exported gnutls_pkcs11_token_get_flags: Exported gnutls_pubkey_get_pk_ecc_x962: Exported gnutls_pubkey_import_ecc_x962: Exported gnutls_rnd_refresh: Exported gnutls_mac_get_nonce_size: Exported gnutls_x509_crl_get_raw_issuer_dn: Exported gnutls_certificate_get_crt_raw: Exported gnutls_db_get_default_cache_expiration: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.lz.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 Fri Jan 31 17:44:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 Jan 2014 17:44:50 +0100 Subject: [gnutls-devel] gnutls 3.1.20 Message-ID: <52EBD302.50407@gnutls.org> Hello, I've just released gnutls 3.1.20. This is a bug-fix release on the previous stable branch. * Version 3.1.20 (released 2014-01-31) ** libgnutls: fixed null pointer derefence when printing a certificate DN and an LDAP description isn't present. ** libgnutls: gnutls_db_check_entry_time will correctly report the time; report and patch by Jonathan Roudiere. ** API and ABI modifications: gnutls_x509_policy_release: Exported gnutls_pubkey_set_key_usage: Exported gnutls_x509_privkey_import_rsa_raw2: Exported gnutls_pkcs11_token_get_flags: Exported gnutls_pubkey_get_pk_ecc_x962: Exported gnutls_pubkey_import_ecc_x962: Exported gnutls_rnd_refresh: Exported gnutls_x509_crl_get_raw_issuer_dn: Exported Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.lz.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