From Daniel.Heldt at cryptovision.com Mon Feb 3 14:00:15 2014 From: Daniel.Heldt at cryptovision.com (Heldt, Daniel) Date: Mon, 3 Feb 2014 13:00:15 +0000 Subject: [gnutls-devel] test suite fails one test on 3.2.10. + odd behavoir of gnutls-cli Message-ID: <5B23F33B7CE0FA45B95D6088B9F41E6997F3@daedalus> Hi there, today I built gnutls 3.2.10 on an ubuntu in a vm and one test failed (twice). I attached the testsuite.log and am willing to provide more information, if needed. Further, I observed, that Gnutls-cli announces the cipher suites ECDHE_PSK_WITH_AES_256_CBC_SHA384 and ECDHE_PSK_WITH_AES_128_CBC_SHA256 (if the priority string contains some +ECDHE_PSK),but if the server side chooses them, the handshake fails (I can post the network-traffic, if it is of interest) with the error message: *** Fatal error: Could not negotiate a supported cipher suite. *** Handshake has failed GnuTLS error: Could not negotiate a supported cipher suite. After the server has send the "hello done message"-packet. Still, with ECDHE_PSK_WITH_AES_128_CBC_SHA the handshake succeeds, which occurs slightly odd to me. So could somebody check if this is intended behavior, a bug, or somehow the server's fault? Thank you! With kind regards, Daniel heldt Ps: I am not on your Devel-List, so please cc me in your replies! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-suite.log Type: application/octet-stream Size: 609 bytes Desc: test-suite.log URL: From nmav at gnutls.org Mon Feb 3 19:56:34 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Feb 2014 19:56:34 +0100 Subject: [gnutls-devel] test suite fails one test on 3.2.10. + odd behavoir of gnutls-cli In-Reply-To: <5B23F33B7CE0FA45B95D6088B9F41E6997F3@daedalus> References: <5B23F33B7CE0FA45B95D6088B9F41E6997F3@daedalus> Message-ID: <52EFE662.8090509@gnutls.org> On 02/03/2014 02:00 PM, Heldt, Daniel wrote: > Hi there, > today I built gnutls 3.2.10 on an ubuntu in a vm and one test failed > (twice). > I attached the testsuite.log and am willing to provide more information, > if needed. Have you applied additional patches to the distributed tarball or used configure options to disable certain features? If not could you run the test that fails manually using the -v switch? > Further, I observed, that > Gnutls-cli announces the cipher suites ECDHE_PSK_WITH_AES_256_CBC_SHA384 > and ECDHE_PSK_WITH_AES_128_CBC_SHA256 (if the priority string contains > some +ECDHE_PSK),but if the server side chooses them, the handshake > fails (I can post the network-traffic, if it is of interest) with the > error message: > *** Fatal error: Could not negotiate a supported cipher suite. > *** Handshake has failed > GnuTLS error: Could not negotiate a supported cipher suite. Could it be that you have disabled TLS 1.2? These two ciphersuites are (mistakenly) enabled only in TLS 1.2. I noticed that few hours after the release and was fixed in the 8648c2da75e0db5f586627c70f2889a083462619 commit. regards, Nikos From nmav at gnutls.org Thu Feb 6 17:55:14 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 6 Feb 2014 17:55:14 +0100 Subject: [gnutls-devel] test suite fails one test on 3.2.10. + odd behavoir of gnutls-cli In-Reply-To: <5B23F33B7CE0FA45B95D6088B9F41E699849@daedalus> References: <5B23F33B7CE0FA45B95D6088B9F41E6997F3@daedalus> <52EFE662.8090509@gnutls.org> <5B23F33B7CE0FA45B95D6088B9F41E699849@daedalus> Message-ID: On Tue, Feb 4, 2014 at 8:42 AM, Heldt, Daniel wrote: > The tests failed after a straight ./configure; make; make check of 3.2.10. > I did run the test (mini-record-2) with the -v flag. The bziped2 output is attached. It seems that this test included a test on zlib which I suppose it was not used in your system. I've now added some ifdefs around the zlib test to avoid such issues. regards, Nikos From nmav at gnutls.org Fri Feb 7 08:51:43 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 07 Feb 2014 08:51:43 +0100 Subject: [gnutls-devel] what should be the actual security level of SECURE128? Message-ID: <52F4908F.40005@gnutls.org> Hello, In the 3.3.0 branch one of the new features is the enforcement of the security level in certificate verification. That would be that with the SECURE-128 priority string one would expect a minimum security level of 128-bits. However, that would mean that today one couldn't connect on any major website on the internet as their certificates are signed using SHA1 (that provides 80-bits of security in theory - less in practice). So the question is what should we do in gnutls. Make SECURE128 just a string that provides better security than NORMAL, or enforce the 128-bit level when this string is specified? The latter will have quite some implications as a lot of software seems to specify SECURE128 as the default priority string for no particular reason (and often with no way to change it). Any ideas? regards, Nikos From tim.ruehsen at gmx.de Fri Feb 7 15:50:50 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 07 Feb 2014 15:50:50 +0100 Subject: [gnutls-devel] what should be the actual security level of SECURE128? In-Reply-To: <52F4908F.40005@gnutls.org> References: <52F4908F.40005@gnutls.org> Message-ID: <1575096.09Zg4TpvVy@blitz-lx> On Friday 07 February 2014 08:51:43 Nikos Mavrogiannopoulos wrote: > Hello, > In the 3.3.0 branch one of the new features is the enforcement of the > security level in certificate verification. That would be that with the > SECURE-128 priority string one would expect a minimum security level of > 128-bits. However, that would mean that today one couldn't connect on > any major website on the internet as their certificates are signed using > SHA1 (that provides 80-bits of security in theory - less in practice). > > So the question is what should we do in gnutls. Make SECURE128 just a > string that provides better security than NORMAL, or enforce the 128-bit > level when this string is specified? The latter will have quite some > implications as a lot of software seems to specify SECURE128 as the > default priority string for no particular reason (and often with no way > to change it). Any ideas? As I understood, SECURE128 right now combines two different things, which in the docs (http://gnutls.org/manual/html_node/Priority-Strings.html) are named as 1) message authenticity security level 2) security level (i guess that means 'data encryption security level') You could add new keywords for 1) e.g. AUTH128 etc. Old software (recompiled or not) could still work with newer libraries. Adapted software will/can check for newer libraries available (at compile and/or run time) and may use the set of keywords at will. Another option would be to have a new function to enable the new behavior at run-time. Maybe with some kind of non-fatal warning during handshake if the function hasn't been called and SECURE128 has been given without AUTH...? Just enforcing the new security level sounds like breaking lot's of software (as you say). If you really want enforcement, there should at least be some kind of external control mechanism for users and packagers (maybe a ENV variable ?). Just ideas that popped up. Tim From wiz at NetBSD.org Sun Feb 9 12:52:36 2014 From: wiz at NetBSD.org (Thomas Klausner) Date: Sun, 9 Feb 2014 12:52:36 +0100 Subject: [gnutls-devel] test hangs in 3.2.8.1 In-Reply-To: <52DC0C76.4020805@gnutls.org> References: <20140116101819.GK16992@danbala.tuwien.ac.at> <52D8D541.2030109@gnutls.org> <20140117103102.GV16992@danbala.tuwien.ac.at> <52DC0C76.4020805@gnutls.org> Message-ID: <20140209115236.GI27673@danbala.tuwien.ac.at> On Sun, Jan 19, 2014 at 06:33:42PM +0100, Nikos Mavrogiannopoulos wrote: > 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? It seems so. Here's the output when run with bash: # bash ./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 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! > 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. And attached are the outputs when I set DEBUG="-d 9" in the script and remove all >/dev/null redirects, both with /bin/sh and bash, then run it with "... 2>&1 | tee output" In case it matters, openssl is at 1.0.1f, the NetBSD base system version. > > > 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. Let me know if you need further debugging information! Thanks, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: outputs.tar.gz Type: application/x-tar-gz Size: 15197 bytes Desc: not available URL: From wiz at NetBSD.org Sun Feb 9 13:01:29 2014 From: wiz at NetBSD.org (Thomas Klausner) Date: Sun, 9 Feb 2014 13:01:29 +0100 Subject: [gnutls-devel] Assembler problems in gnutls-3.2.8.1+ Message-ID: <20140209120129.GJ27673@danbala.tuwien.ac.at> Hi! Starting from gnutls-3.2.8.1 (we didn't have 3.2.8 in pkgsrc; reportedly still there in 3.2.9) there were problems with assembler files in pkgsrc, in particular on the SunOS and Mac OS X (built for 32bit) platforms. Here are the outputs for SunOS: 32bit: http://us-east.manta.joyent.com/pkgsrc/public/reports/upstream-trunk32/20140121.2027/gnutls-3.2.8.1/build.log 64bit: http://us-east.manta.joyent.com/pkgsrc/public/reports/upstream-trunk64/20140120.2248/gnutls-3.2.8.1/build.log For Mac OS X, I got this report: Mac OS X Lion: >uname -a Darwin example.com 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 i386 >gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The error message is: CCLD libgnutls.la nm: no name list nm: no name list nm: no name list nm: no name list nm: no name list nm: no name list nm: no name list duplicate symbol __gnutls_x86_cpuid_s in: accelerated/.libs/libaccelerated.a(aes-cbc-x86-aesni.o) accelerated/.libs/libaccelerated.a(aes-cbc-x86-ssse3.o) duplicate symbol __gnutls_x86_cpuid_s in: accelerated/.libs/libaccelerated.a(aes-cbc-x86-aesni.o) accelerated/.libs/libaccelerated.a(x86-common.o) ld: 2 duplicate symbols for architecture i386 collect2: ld returned 1 exit status gnumake[4]: *** [libgnutls.la] Error 1 gnumake[3]: *** [all-recursive] Error 1 gnumake[2]: *** [all] Error 2 gnumake[1]: *** [all-recursive] Error 1 gnumake: *** [all] Error 2 *** Error code 2 For this reason we're currently using --disable-hardware-acceleration on these platforms, but that's obviously just a workaround. Please advise! Thanks, Thomas From nmav at gnutls.org Mon Feb 10 10:07:11 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Feb 2014 10:07:11 +0100 Subject: [gnutls-devel] what should be the actual security level of SECURE128? In-Reply-To: <1575096.09Zg4TpvVy@blitz-lx> References: <52F4908F.40005@gnutls.org> <1575096.09Zg4TpvVy@blitz-lx> Message-ID: On Fri, Feb 7, 2014 at 3:50 PM, Tim Ruehsen wrote: >> So the question is what should we do in gnutls. Make SECURE128 just a >> string that provides better security than NORMAL, or enforce the 128-bit >> level when this string is specified? The latter will have quite some >> implications as a lot of software seems to specify SECURE128 as the >> default priority string for no particular reason (and often with no way >> to change it). Any ideas? > As I understood, SECURE128 right now combines two different things, which in > the docs (http://gnutls.org/manual/html_node/Priority-Strings.html) are named > as > 1) message authenticity security level > 2) security level (i guess that means 'data encryption security level') > You could add new keywords for 1) e.g. AUTH128 etc. > Old software (recompiled or not) could still work with newer libraries. > Adapted software will/can check for newer libraries available (at compile > and/or run time) and may use the set of keywords at will. Hello, The idea is to add a 3rd level as: 3) certificate verification level (i.e., signature check) Adding a new initial keyword with the additional level it would make it unaccessible to any of the software that use the SECURE128 and SECURE256 keywords. I'd like even old software to take advantage from new protection methods as time goes by and a new gnutls library is available. > Another option would be to have a new function to enable the new behavior at > run-time. > Maybe with some kind of non-fatal warning during handshake if the function > hasn't been called and SECURE128 has been given without AUTH...? As you suggest breaking old software isn't really reasonable, so what I am thinking is to set very conservative security levels for SECURE128 (the same as normal) for the 3rd option, and in a few years, when SHA256 or better are widely used in certificates, we could increase it. Of couse the ones who'd like to take advantage of the better verification profiles could set them directly using the %PROFILE additional keywords. regards, Nikos From nmav at gnutls.org Mon Feb 10 10:53:44 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Feb 2014 10:53:44 +0100 Subject: [gnutls-devel] Assembler problems in gnutls-3.2.8.1+ In-Reply-To: <20140209120129.GJ27673@danbala.tuwien.ac.at> References: <20140209120129.GJ27673@danbala.tuwien.ac.at> Message-ID: On Sun, Feb 9, 2014 at 1:01 PM, Thomas Klausner wrote: > Hi! > Starting from gnutls-3.2.8.1 (we didn't have 3.2.8 in pkgsrc; > reportedly still there in 3.2.9) there were problems with assembler > files in pkgsrc, in particular on the SunOS and Mac OS X (built for > 32bit) platforms. > Here are the outputs for SunOS: > 32bit: > http://us-east.manta.joyent.com/pkgsrc/public/reports/upstream-trunk32/20140121.2027/gnutls-3.2.8.1/build.log > 64bit: > http://us-east.manta.joyent.com/pkgsrc/public/reports/upstream-trunk64/20140120.2248/gnutls-3.2.8.1/build.log Could it be that the affected files aren't compiled with -fpic on this system? (I cannot check from the log, you need to compile with V=1). > For Mac OS X, I got this report: [...] > duplicate symbol __gnutls_x86_cpuid_s in: > accelerated/.libs/libaccelerated.a(aes-cbc-x86-aesni.o) > accelerated/.libs/libaccelerated.a(aes-cbc-x86-ssse3.o) It seems there is a symbol redefinition (I wonder why it is not detected in other systems). Could you try this patch? https://www.gitorious.org/gnutls/gnutls/commit/54768ca1cd9049bbd1c695696ef3c8595c6052db regards, Nikos From tim.ruehsen at gmx.de Tue Feb 11 09:18:02 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 11 Feb 2014 09:18:02 +0100 Subject: [gnutls-devel] what should be the actual security level of SECURE128? In-Reply-To: References: <52F4908F.40005@gnutls.org> <1575096.09Zg4TpvVy@blitz-lx> Message-ID: <13927099.vasaGonZQI@blitz-lx> On Monday 10 February 2014 10:07:11 Nikos Mavrogiannopoulos wrote: > On Fri, Feb 7, 2014 at 3:50 PM, Tim Ruehsen wrote: > >> So the question is what should we do in gnutls. Make SECURE128 just a > >> string that provides better security than NORMAL, or enforce the 128-bit > >> level when this string is specified? The latter will have quite some > >> implications as a lot of software seems to specify SECURE128 as the > >> default priority string for no particular reason (and often with no way > >> to change it). Any ideas? > > > > As I understood, SECURE128 right now combines two different things, which > > in the docs (http://gnutls.org/manual/html_node/Priority-Strings.html) > > are named as > > 1) message authenticity security level > > 2) security level (i guess that means 'data encryption security level') > > You could add new keywords for 1) e.g. AUTH128 etc. > > Old software (recompiled or not) could still work with newer libraries. > > Adapted software will/can check for newer libraries available (at compile > > and/or run time) and may use the set of keywords at will. > > Hello, > The idea is to add a 3rd level as: > 3) certificate verification level (i.e., signature check) > > Adding a new initial keyword with the additional level it would make > it unaccessible to any of the software that use the SECURE128 and > SECURE256 keywords. I'd like even old software to take advantage from > new protection methods as time goes by and a new gnutls library is > available. > > > Another option would be to have a new function to enable the new behavior > > at run-time. > > Maybe with some kind of non-fatal warning during handshake if the function > > hasn't been called and SECURE128 has been given without AUTH...? > > As you suggest breaking old software isn't really reasonable, so what > I am thinking is to set very conservative security levels for > SECURE128 (the same as normal) for the 3rd option, and in a few years, > when SHA256 or better are widely used in certificates, we could > increase it. Of couse the ones who'd like to take advantage of the > better verification profiles could set them directly using the > %PROFILE additional keywords. That seems nearly exactly what i tried to say in my first suggestion (the obvious, 'natural' choice). Maybe I just wanted to say that, but fucked it up somehow ;-) Regards, Tim From nmav at gnutls.org Wed Feb 12 09:48:10 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 09:48:10 +0100 Subject: [gnutls-devel] test hangs in 3.2.8.1 In-Reply-To: <20140209115236.GI27673@danbala.tuwien.ac.at> References: <20140116101819.GK16992@danbala.tuwien.ac.at> <52D8D541.2030109@gnutls.org> <20140117103102.GV16992@danbala.tuwien.ac.at> <52DC0C76.4020805@gnutls.org> <20140209115236.GI27673@danbala.tuwien.ac.at> Message-ID: On Sun, Feb 9, 2014 at 12:52 PM, Thomas Klausner wrote: > It seems so. Here's the output when run with bash: > # bash ./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 > 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 It seems that the executed programs are linked to a different gnutls version, which doesn't support TLS 1.2. Could that be the case? regards, Nikos From dennis.philipps at gmail.com Mon Feb 3 22:26:41 2014 From: dennis.philipps at gmail.com (Dennis Philipps) Date: Mon, 3 Feb 2014 22:26:41 +0100 Subject: [gnutls-devel] GnuTLS duplicate symbols Message-ID: Hello, the GnuTLS library since 3.2.x seems to have an issue on the X86 accelerated code-base. The files lib/accelerated/aes-cbc-x86-aesni.c lib/accelerated/aes-cbc-x86-ssse3.c both define the symbol unsigned int _gnutls_x86_cpuid_s[4]; which results in the duplicate symbols linker error. I assume this is a copy/paste/typo something bug. Linking works fine with 3.1.20 (latest 3.1.x version as it seems). I patched the files locally and the linking was okay. I built on Mac OS X 10.7 but this should probably be found on any x86 accelerated build as this is not an issue within the assembler code. Regards Dennis Philipps -------------- next part -------------- An HTML attachment was scrubbed... URL: From tron at zhadum.org.uk Mon Feb 10 13:52:26 2014 From: tron at zhadum.org.uk (Matthias Scheler) Date: Mon, 10 Feb 2014 12:52:26 +0000 Subject: [gnutls-devel] Assembler problems in gnutls-3.2.8.1+ In-Reply-To: References: <20140209120129.GJ27673@danbala.tuwien.ac.at> Message-ID: <20140210125225.GA22804@colwyn.zhadum.org.uk> On Mon, Feb 10, 2014 at 10:53:44AM +0100, Nikos Mavrogiannopoulos wrote: > > For Mac OS X, I got this report: > [...] > > duplicate symbol __gnutls_x86_cpuid_s in: > > accelerated/.libs/libaccelerated.a(aes-cbc-x86-aesni.o) > > accelerated/.libs/libaccelerated.a(aes-cbc-x86-ssse3.o) > > It seems there is a symbol redefinition (I wonder why it is not > detected in other systems). Could you try this patch? > https://www.gitorious.org/gnutls/gnutls/commit/54768ca1cd9049bbd1c695696ef3c8595c6052db I can confirm that this patch fixes the build under Mac OS 10.7 for me. Thanks a lot -- Matthias Scheler https://zhadum.org.uk/ From suman at cs.utexas.edu Tue Feb 11 11:35:19 2014 From: suman at cs.utexas.edu (Suman Jana) Date: Tue, 11 Feb 2014 02:35:19 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS Message-ID: <52F9FCE7.5080400@cs.utexas.edu> Hi, We are computer security researchers at UT Austin and UC Davis, currently testing several SSL/TLS implementations as part of a research project. When testing GnuTLS, we discovered the following security issues related to SSL/TLS certificate validation. Some of them may be deliberate violations of the X.509 standard, others appear to be bugs. As far as we know, none of them is documented. Please let us know how you intend to address these issues. The paper describing the results of our analysis will appear in the 2014 IEEE Symposium on Security and Privacy (?Oakland?), and we would like to include a report on the current status of all issues we discovered. 1. v1 CA certificates should be rejected by default unless validated by external means but GnuTLS accepts it. In GnuTLS, the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is set by default. So, in default settings, GnuTLS should accept only root v1 CAs but it accepts all v1 ca certs instead of only v1 root CA certs due to a bug in lib/x509/verify.c as described below. unsigned int _gnutls_x509_verify_certificate(...) { ... /* verify the certificate path (chain) */ for (i = clist_size - 1; i > 0; i--) { /* note that here we disable this V1 CA flag. So that no version 1 * certificates can exist in a supplied chain. */ if (!(flags & GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT)) flags &= ?(GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); if ((ret = _gnutls_verify_certificate2 (...)) ==0) { /* return error */ } } ... } int _gnutls_verify_certificate2(...) { ... if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) && ((flags & GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT) || issuer_version != 1)) { if (check_if_ca (cert, issuer, flags) == 0) { /*return error*/ ... } } /*perform other checks*/ ... } As shown in the code above, after a root v1 certi?cate has been accepted, to prevent any further v1 certi?cates from being accepted, GnuTLS clears the GNUTLS_VERIFY_ALLOW _X509_V1_CA_CRT ?ag before calling _gnutls_verify_certificate2. However, the _gnutls_ verify_certificate2 function accepts v1 certi?cates unless a different ?ag, GNUTLS_VERIFY_ DO_NOT_ALLOW_X509_V1_CA_CRT is set. But the caller (_gnutls_x509_verify_certificate) never sets that flag. 2. Path length constraints in CA certs should be enforced. GnuTLS ignores Path length constraints. 3. Name constraints in CA certs should be enforced. GnuTLS ignores name constraints. 4. keyUsage and extendedKeyUsage extensions in CA and leaf certificates should be checked correctly. GnuTLS does not check any of them. 5. Certificate validation must fail if unknown critical extensions are present in the certificate but GnuTLS accepts certificates with unknown critical extensions. Thanks, Suman From nmav at gnutls.org Wed Feb 12 16:38:53 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 16:38:53 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52F9FCE7.5080400@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> Message-ID: On Tue, Feb 11, 2014 at 11:35 AM, Suman Jana wrote: > Hi, > > We are computer security researchers at UT Austin and UC Davis, currently > testing > several SSL/TLS implementations as part of a research project. When testing > GnuTLS, > we discovered the following security issues related to SSL/TLS certificate > validation. > Some of them may be deliberate violations of the X.509 standard, others > appear to be > bugs. Hello, Thank you for the report. Comments inline; > As far as we know, none of them is documented. Please feel free to provide patches to improve documentation. That is the essence of free software. > 1. v1 CA certificates should be rejected by default unless validated by > external means but GnuTLS accepts it. You are correct. This is a bug in current code. > As shown in the code above, after a root v1 certi?cate has been accepted, to > prevent > any further v1 certi?cates from being accepted, GnuTLS clears the > GNUTLS_VERIFY_ALLOW > _X509_V1_CA_CRT ?ag before calling _gnutls_verify_certificate2. However, the > _gnutls_ > verify_certificate2 function accepts v1 certi?cates unless a different ?ag, > GNUTLS_VERIFY_ > DO_NOT_ALLOW_X509_V1_CA_CRT is set. But the caller > (_gnutls_x509_verify_certificate) > never sets that flag. Nice trace of the issue. I've now fixed it in the repository. > 2. Path length constraints in CA certs should be enforced. GnuTLS ignores > Path length constraints. Which version of gnutls did you use? GnuTLS supports path length constraints for quite some time now. > 3. Name constraints in CA certs should be enforced. GnuTLS ignores name > constraints. I believe that you haven't read RFC5280 :) GnuTLS will support name constraints when there is a reasonable profile defined. As it is now, the PKIX name constraints are a mess. > 4. keyUsage and extendedKeyUsage extensions in CA and leaf certificates > should be checked > correctly. GnuTLS does not check any of them. We used to check them (the keyUsage) and people were reporting it as a bug. See: http://www.gnutls.org/faq.html#key-usage-violation Since the keyusage is set by system administrators who have no idea what should go there, there is no much point in enforcing it (especially when no-else does and your software looks broken when it is strict). > 5. Certificate validation must fail if unknown critical extensions are > present in the certificate > but GnuTLS accepts certificates with unknown critical extensions. That is from the time when there was a single company that controlled most of the available software generating certificate. It would have been very easy for them to lock out gnutls if we have supported this rule. I may reconsider if there is any real issue. regards, Nikos From nmav at gnutls.org Wed Feb 12 19:58:46 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 19:58:46 +0100 Subject: [gnutls-devel] GnuTLS duplicate symbols In-Reply-To: References: Message-ID: <52FBC466.5060804@gnutls.org> On 02/03/2014 10:26 PM, Dennis Philipps wrote: > Hello, > > the GnuTLS library since 3.2.x seems to have an issue on the X86 > accelerated code-base. The files > > lib/accelerated/aes-cbc-x86-aesni.c > lib/accelerated/aes-cbc-x86-ssse3.c > > both define the symbol > > unsigned int _gnutls_x86_cpuid_s[4]; > > which results in the duplicate symbols linker error. I assume this is a > copy/paste/typo something bug. Linking works fine with 3.1.20 (latest > 3.1.x version as it seems). I patched the files locally and the linking > was okay. I built on Mac OS X 10.7 but this should probably be found on > any x86 accelerated build as this is not an issue within the assembler code. Thank you. This was reported few days ago and there is a fix in the repository that will be included in the next release. regards, Nikos From Jason at zx2c4.com Wed Feb 12 19:23:09 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 19:23:09 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? Message-ID: Hi folks, I'm getting a crash in weechat, and after some debugging, the maintainer of weechat told me to complain here. I've put all the info in this gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=501078 . Here are various backtraces: #0 0x0000744315fa2e8e in raise () from /lib64/libc.so.6 #1 0x0000744315fa45df in abort () from /lib64/libc.so.6 #2 0x0000744316de2324 in wrap_nettle_rnd () from /usr/lib64/libgnutls.so.28 #3 0x0000744316d28218 in _gnutls_tls_create_random () from /usr/lib64/libgnutls.so.28 #4 0x0000744316d2861a in _gnutls_set_client_random () from /usr/lib64/libgnutls.so.28 #5 0x0000744316d2a116 in _gnutls_send_hello () from /usr/lib64/libgnutls.so.28 #6 0x0000744316d2c928 in gnutls_handshake () from /usr/lib64/libgnutls.so.28 #7 0x000000c2d34924d1 in network_connect_child_read_cb () #8 0x000000c2d3489a46 in hook_fd_exec () #9 0x000000c2d34244fe in gui_main_loop () #10 0x000000c2d3419820 in main () (gdb) bt #0 0x00006448f718fad4 in __lll_lock_elision () from /lib64/libpthread.so.0 #1 0x00006448fa98e8be in ?? () from /usr/lib64/libgnutls.so.28 #2 0x00006448faa2c16e in ?? () from /usr/lib64/libgnutls.so.28 #3 0x00006448fa972218 in ?? () from /usr/lib64/libgnutls.so.28 #4 0x00006448fa97261a in ?? () from /usr/lib64/libgnutls.so.28 #5 0x00006448fa974116 in ?? () from /usr/lib64/libgnutls.so.28 #6 0x00006448fa976928 in gnutls_handshake () from /usr/lib64/libgnutls.so.28 #7 0x00000e43a73e14d1 in network_connect_child_read_cb () #8 0x00000e43a73d8a46 in hook_fd_exec () #9 0x00000e43a73734fe in gui_main_loop () #10 0x00000e43a7368820 in main () (gdb) bt #0 0x000074975344fe8e in raise () from /lib64/libc.so.6 #1 0x00007497534515df in abort () from /lib64/libc.so.6 #2 0x000074975428f324 in ?? () from /usr/lib64/libgnutls.so.28 #3 0x00007497541d5218 in ?? () from /usr/lib64/libgnutls.so.28 #4 0x00007497541d561a in ?? () from /usr/lib64/libgnutls.so.28 #5 0x00007497541d7116 in ?? () from /usr/lib64/libgnutls.so.28 #6 0x00007497541d9928 in gnutls_handshake () from /usr/lib64/libgnutls.so.28 #7 0x00000fbe153084d1 in network_connect_child_read_cb () #8 0x00000fbe152ffa46 in hook_fd_exec () #9 0x00000fbe1529a4fe in gui_main_loop () #10 0x00000fbe1528f820 in main () (gdb) bt #0 0x0000736ab354aad4 in __lll_lock_elision () from /lib64/libpthread.so.0 #1 0x0000736ab8c6d8be in ?? () from /usr/lib64/libgnutls.so.28 #2 0x0000736ab8d0b16e in ?? () from /usr/lib64/libgnutls.so.28 #3 0x0000736ab8c4c7ae in ?? () from /usr/lib64/libgnutls.so.28 #4 0x0000736ab8c477b8 in ?? () from /usr/lib64/libgnutls.so.28 #5 0x0000736ab8c49b92 in gnutls_record_send () from /usr/lib64/libgnutls.so.28 #6 0x0000736ab4c7e80c in irc_server_send () from /usr/lib64/weechat/plugins/irc.so #7 0x0000736ab4c7f130 in irc_server_send_one_msg () from /usr/lib64/weechat/plugins/irc.so #8 0x0000736ab4c7f953 in irc_server_sendf () from /usr/lib64/weechat/plugins/irc.so #9 0x0000736ab4c5cbfc in irc_input_send_user_message () from /usr/lib64/weechat/plugins/irc.so #10 0x0000736ab4c5cdfb in irc_input_data () from /usr/lib64/weechat/plugins/irc.so #11 0x00000909fff0eccd in input_data () #12 0x00000909ffec73ff in gui_input_return () #13 0x00000909ffee1f90 in command_input () #14 0x00000909fff06fc4 in hook_command_exec () #15 0x00000909fff0e951 in input_exec_command () #16 0x00000909fff0ed04 in input_data () #17 0x00000909ffecbb5f in gui_key_pressed () #18 0x00000909ffea1122 in gui_key_flush () #19 0x00000909ffea165e in gui_key_read_cb () #20 0x00000909fff07a46 in hook_fd_exec () #21 0x00000909ffea24fe in gui_main_loop () #22 0x00000909ffe97820 in main () Any help would be appreciated. Thanks, Jason From meissner at suse.de Wed Feb 12 20:58:43 2014 From: meissner at suse.de (Marcus Meissner) Date: Wed, 12 Feb 2014 20:58:43 +0100 Subject: [gnutls-devel] [PATCH] fixed socket existance checking Message-ID: <20140212195843.GH11227@suse.de> >From 970008c7706852b4703e7a2bed149fc94e897211 Mon Sep 17 00:00:00 2001 From: Marcus Meissner Date: Wed, 12 Feb 2014 20:56:17 +0100 Subject: [PATCH] fixed socket existance checking If getaddrinfo returns: ipv4 address, ipv6 address ... and socket() for the ipv6 address fails, this loop would fail and abort the socket listen code. --- src/serv.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/serv.c b/src/serv.c index 60d4e97..c3e33ae 100644 --- a/src/serv.c +++ b/src/serv.c @@ -712,7 +712,7 @@ int listen_socket(const char *name, int listen_port, int socktype) { struct addrinfo hints, *res, *ptr; char portname[6]; - int s; + int s = -1; int yes; listener_item *j = NULL; @@ -732,6 +732,7 @@ int listen_socket(const char *name, int listen_port, int socktype) } for (ptr = res; ptr != NULL; ptr = ptr->ai_next) { + int news; #ifndef HAVE_IPV6 if (ptr->ai_family != AF_INET) continue; @@ -747,11 +748,12 @@ int listen_socket(const char *name, int listen_port, int socktype) sizeof(topbuf))); } - if ((s = socket(ptr->ai_family, ptr->ai_socktype, + if ((news = socket(ptr->ai_family, ptr->ai_socktype, ptr->ai_protocol)) < 0) { perror("socket() failed"); continue; } + s = news; /* to not overwrite existing s from previous loops */ #if defined(HAVE_IPV6) && !defined(_WIN32) if (ptr->ai_family == AF_INET6) { yes = 1; -- 1.8.1.4 From nmav at gnutls.org Wed Feb 12 22:33:43 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 22:33:43 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: Message-ID: <52FBE8B7.3020900@gnutls.org> On 02/12/2014 07:23 PM, Jason A. Donenfeld wrote: > Hi folks, > > I'm getting a crash in weechat, and after some debugging, the > maintainer of weechat told me to complain here. I've put all the info > in this gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=501078 . > > Here are various backtraces: > #0 0x0000744315fa2e8e in raise () from /lib64/libc.so.6 > #1 0x0000744315fa45df in abort () from /lib64/libc.so.6 > #2 0x0000744316de2324 in wrap_nettle_rnd () from /usr/lib64/libgnutls.so.28 Hello Jason, Unfortunately these backtraces don't provide much information. You'll need debugging symbols (most probably included in your distribution as a separate package). Also the version of gnutls being used is important. It would be best to try with the latest released version. However, the only reason for a mutex call to fail is if the mutex isn't initialized. Is gnutls_global_init() executed successful in the program you use? regards, Nikos From nmav at gnutls.org Wed Feb 12 22:36:11 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 22:36:11 +0100 Subject: [gnutls-devel] [PATCH] fixed socket existance checking In-Reply-To: <20140212195843.GH11227@suse.de> References: <20140212195843.GH11227@suse.de> Message-ID: <52FBE94B.5070308@gnutls.org> On 02/12/2014 08:58 PM, Marcus Meissner wrote: > From 970008c7706852b4703e7a2bed149fc94e897211 Mon Sep 17 00:00:00 2001 > From: Marcus Meissner > Date: Wed, 12 Feb 2014 20:56:17 +0100 > Subject: [PATCH] fixed socket existance checking > > If getaddrinfo returns: ipv4 address, ipv6 address ... and socket() for > the ipv6 address fails, this loop would fail and abort the socket listen > code. Applied thank you. From Jason at zx2c4.com Wed Feb 12 23:21:41 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 23:21:41 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: <52FBE8B7.3020900@gnutls.org> References: <52FBE8B7.3020900@gnutls.org> Message-ID: On Wed, Feb 12, 2014 at 10:33 PM, Nikos Mavrogiannopoulos wrote: > Hello Jason, > Unfortunately these backtraces don't provide much information. You'll > need debugging symbols (most probably included in your distribution as a > separate package). Also the version of gnutls being used is important. > It would be best to try with the latest released version. This occurs with 3.2.10. I believe it also occurred with 3.2.9. I'll recompile with more debug granularity (I'm on gentoo hardened) and report back. > > However, the only reason for a mutex call to fail is if the mutex isn't > initialized. Is gnutls_global_init() executed successful in the program > you use? gnutls_global_init is executed. What's interesting is that the error only happens when weechat loads the python plugin. I'm not too familiar how the python plugin works internally, but I imagine it's possible it spawns a thread. Could there be some situation in which all new threads also need to call gnutls_global_init? I'm speculating here, but maybe it has something to do with this... From nmav at gnutls.org Wed Feb 12 23:29:09 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 23:29:09 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> Message-ID: <52FBF5B5.2020203@gnutls.org> On 02/12/2014 11:21 PM, Jason A. Donenfeld wrote: > On Wed, Feb 12, 2014 at 10:33 PM, Nikos Mavrogiannopoulos > wrote: >> Hello Jason, >> Unfortunately these backtraces don't provide much information. You'll >> need debugging symbols (most probably included in your distribution as a >> separate package). Also the version of gnutls being used is important. >> It would be best to try with the latest released version. > > This occurs with 3.2.10. I believe it also occurred with 3.2.9. I'll > recompile with more debug granularity (I'm on gentoo hardened) and > report back. It would be useful to know if there is a version of gnutls that this used to work well. >> However, the only reason for a mutex call to fail is if the mutex isn't >> initialized. Is gnutls_global_init() executed successful in the program >> you use? > gnutls_global_init is executed. > What's interesting is that the error only happens when weechat loads > the python plugin. I'm not too familiar how the python plugin works > internally, but I imagine it's possible it spawns a thread. Could > there be some situation in which all new threads also need to call > gnutls_global_init? I'm speculating here, but maybe it has something > to do with this... Not really. It only needs to be called once. However, could there be someone calling gnutls_global_deinit()? That would be another case where the mutex could be in an unstable state. regards, Nikos From Jason at zx2c4.com Wed Feb 12 23:29:29 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 23:29:29 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> Message-ID: Here's a better backtrace. 3.2.10 #0 0x000069ec221d0e8e in raise () from /lib64/libc.so.6 #1 0x000069ec221d25df in abort () from /lib64/libc.so.6 #2 0x000069ec230586c5 in wrap_nettle_rnd (_ctx=0x0, level=0, data=0x556db2fbeab, datasize=29) at rnd.c:441 #3 0x000069ec22f5c62d in _gnutls_rnd (level=GNUTLS_RND_NONCE, data=0x556db2fbeab, len=29) at ./random.h:37 #4 0x000069ec22f5cbdb in _gnutls_tls_create_random (dst=0x556db2fbea8 "R\373", ) at gnutls_handshake.c:206 #5 0x000069ec22f5cce2 in _gnutls_set_client_random (session=0x556db2fbe60, rnd=0x0) at gnutls_handshake.c:231 #6 0x000069ec22f62168 in _gnutls_send_client_hello (session=0x556db2fbe60, again=0) at gnutls_handshake.c:1990 #7 0x000069ec22f62b26 in _gnutls_send_hello (session=0x556db2fbe60, again=0) at gnutls_handshake.c:2203 #8 0x000069ec22f63892 in _gnutls_handshake_client (session=0x556db2fbe60) at gnutls_handshake.c:2656 #9 0x000069ec22f635ea in gnutls_handshake (session=0x556db2fbe60) at gnutls_handshake.c:2527 #10 0x00000556d7277581 in network_connect_child_read_cb (arg_hook_connect=0x556db2f9c90, fd=14) at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/core/wee-network.c:1484 #11 0x00000556d726966d in hook_fd_exec (read_fds=0x72851c083090, write_fds=0x72851c083110, exception_fds=0x72851c083190) at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/core/wee-hook.c:1329 #12 0x00000556d71eb0f2 in gui_main_loop () at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/gui/curses/gui-curses-main.c:501 #13 0x00000556d72358cf in main (argc=1, argv=0x72851c083358) at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/core/weechat.c:477 From Jason at zx2c4.com Wed Feb 12 23:33:06 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 23:33:06 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: <52FBF5B5.2020203@gnutls.org> References: <52FBE8B7.3020900@gnutls.org> <52FBF5B5.2020203@gnutls.org> Message-ID: >From reading the man page, apparently pthread_mutex_lock can fail for a variety of different reasons. I suppose I'll need to patch gnutls to print me the reason before crashing. Ugh. From Jason at zx2c4.com Wed Feb 12 23:43:36 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 23:43:36 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> <52FBF5B5.2020203@gnutls.org> Message-ID: Okay apparently it's failing with error 22 -- EINVAL. From the man page: EINVAL The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling. From Jason at zx2c4.com Wed Feb 12 23:44:13 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 23:44:13 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> <52FBF5B5.2020203@gnutls.org> Message-ID: Well this is interesting. Evidently sometimes it crashes in this error path instead: #0 0x00006cc0a1495e8e in raise () from /lib64/libc.so.6 #1 0x00006cc0a14975df in abort () from /lib64/libc.so.6 #2 0x00006cc0a148e2b2 in ?? () from /lib64/libc.so.6 #3 0x00006cc0a148e376 in __assert_fail () from /lib64/libc.so.6 #4 0x00006cc09ea2fec0 in __pthread_tpp_change_priority () from /lib64/libpthread.so.0 #5 0x00006cc09ea23ed8 in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #6 0x00006cc0a224ac8c in gnutls_system_mutex_lock (priv=0x6cc0a25583b8 ) at system.c:228 #7 0x00006cc0a231d6fc in wrap_nettle_rnd (_ctx=0x0, level=0, data=0xfc3f4a5207b, datasize=29) at rnd.c:441 #8 0x00006cc0a222162d in _gnutls_rnd (level=GNUTLS_RND_NONCE, data=0xfc3f4a5207b, len=29) at ./random.h:37 #9 0x00006cc0a2221bdb in _gnutls_tls_create_random (dst=0xfc3f4a52078 "R\373\370y") at gnutls_handshake.c:206 #10 0x00006cc0a2221ce2 in _gnutls_set_client_random (session=0xfc3f4a52030, rnd=0x0) at gnutls_handshake.c:231 #11 0x00006cc0a2227168 in _gnutls_send_client_hello (session=0xfc3f4a52030, again=0) at gnutls_handshake.c:1990 #12 0x00006cc0a2227b26 in _gnutls_send_hello (session=0xfc3f4a52030, again=0) at gnutls_handshake.c:2203 #13 0x00006cc0a2228892 in _gnutls_handshake_client (session=0xfc3f4a52030) at gnutls_handshake.c:2656 #14 0x00006cc0a22285ea in gnutls_handshake (session=0xfc3f4a52030) at gnutls_handshake.c:2527 #15 0x00000fc3f1c82581 in network_connect_child_read_cb (arg_hook_connect=0xfc3f4a51470, fd=12) at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/core/wee-network.c:1484 #16 0x00000fc3f1c7466d in hook_fd_exec (read_fds=0x724715d46df0, write_fds=0x724715d46e70, exception_fds=0x724715d46ef0) at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/core/wee-hook.c:1329 #17 0x00000fc3f1bf60f2 in gui_main_loop () at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/gui/curses/gui-curses-main.c:501 #18 0x00000fc3f1c408cf in main (argc=1, argv=0x724715d470b8) at /var/tmp/portage/net-irc/weechat-0.4.3/work/weechat-0.4.3/src/core/weechat.c:477 From Jason at zx2c4.com Wed Feb 12 23:57:05 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 12 Feb 2014 23:57:05 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> <52FBF5B5.2020203@gnutls.org> Message-ID: On Wed, Feb 12, 2014 at 11:43 PM, Jason A. Donenfeld wrote: > Okay apparently it's failing with error 22 -- EINVAL. From the man page: > > EINVAL The mutex was created with the protocol > attribute having the value > PTHREAD_PRIO_PROTECT and the calling > thread's priority is higher than the > mutex's current priority ceiling. I can't find any place PTHREAD_PRIO_PROTECT is set by gnutls nor weechat. Could there be some uninitialized data someplace? From Jason at zx2c4.com Thu Feb 13 00:04:30 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 13 Feb 2014 00:04:30 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> <52FBF5B5.2020203@gnutls.org> Message-ID: Okay, this awful awful patch "fixes" the weechat crashes. I'm sure this is crippling security, as it essentially destroys any proper respect for the locks, but... Anyway, I'll leave it to the gnutls and weechat devs to get to the bottom of this; I'm way over my head right now. My best guess right now would be that gnutls isn't properly initializing some sort of pthread struct, and it's an old bug, but one that is only triggered by the heap setup of recent versions of weechat. This would account for the PTHREAD_PRIO_PROTECT related error. stern ~ # cat /etc/portage/patches/net-libs/gnutls/rnd-mutex-crash-hack.patch Only in gnutls-3.2.10-modified: cscope.out diff -ru gnutls-3.2.10/lib/nettle/rnd.c gnutls-3.2.10-modified/lib/nettle/rnd.c --- gnutls-3.2.10/lib/nettle/rnd.c 2014-01-27 19:27:10.000000000 +0100 +++ gnutls-3.2.10-modified/lib/nettle/rnd.c 2014-02-12 23:54:34.926144545 +0100 @@ -42,8 +42,8 @@ #define SOURCES 2 -#define RND_LOCK if (gnutls_mutex_lock(&rnd_mutex)!=0) abort() -#define RND_UNLOCK if (gnutls_mutex_unlock(&rnd_mutex)!=0) abort() +#define RND_LOCK gnutls_mutex_lock(&rnd_mutex) +#define RND_UNLOCK gnutls_mutex_unlock(&rnd_mutex) enum { RANDOM_SOURCE_TRIVIA = 0, From nmav at gnutls.org Thu Feb 13 07:51:18 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 07:51:18 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: References: <52FBE8B7.3020900@gnutls.org> Message-ID: <52FC6B66.1010309@gnutls.org> On 02/12/2014 11:29 PM, Jason A. Donenfeld wrote: > Here's a better backtrace. 3.2.10 > > > #0 0x000069ec221d0e8e in raise () from /lib64/libc.so.6 > #1 0x000069ec221d25df in abort () from /lib64/libc.so.6 > #2 0x000069ec230586c5 in wrap_nettle_rnd (_ctx=0x0, level=0, > data=0x556db2fbeab, datasize=29) at rnd.c:441 > #3 0x000069ec22f5c62d in _gnutls_rnd (level=GNUTLS_RND_NONCE, > data=0x556db2fbeab, len=29) at ./random.h:37 Nothing suspicious in this backtrace. Could you try valgrind? It may provide more information on the issue. regards, Nikos From n.mavrogiannopoulos at gmail.com Thu Feb 13 08:57:39 2014 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 08:57:39 +0100 Subject: [gnutls-devel] access to win32 keys Message-ID: Hello, I am wondering whether we can simplify access to the keys in the win32 keystore. I believe that these keys can be accessed using gnutls_privkey_import_ext2() and a thin layer to convert the digestinfo in RSA keys. However, I'd like to know if there are already implementations of it, and whether there can be a layer in gnutls (e.g. similar to tpm key handling) that could ease that. regards, Nikos From pav5088 at internode.on.net Wed Feb 12 16:56:48 2014 From: pav5088 at internode.on.net (Mark Pavlichuk) Date: Thu, 13 Feb 2014 01:56:48 +1000 Subject: [gnutls-devel] isc dhcpd compiled with GNUTLS (Debian) In-Reply-To: <52FB92C8.4050300@internode.on.net> References: <52FB92C8.4050300@internode.on.net> Message-ID: <52FB99C0.1090807@internode.on.net> I am experiencing a bug (in isc-dhcp-server compiled with GNUTLS and LDAP support on Debian) which prevents TLS encryption between dhcpd and the LDAP server. I tried the versions in Wheezy and Jessie ie. 4.2.2 and 4.2.4. The problem is related to parsing the dhcpd.conf file: Internet Systems Consortium DHCP Server 4.2.4 Copyright 2004-2012 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ /etc/dhcp/dhcpd.conf line 113: semicolon expected. ldap-tls-crlfile "/etc/ssl/crl/ssl-cert-local-ca.crl" ^ ... ... a snippet from my config follows: ldap-server "fusion.strategicit.linuxoz.net"; ldap-port 389; ldap-ssl start_tls; ldap-tls-reqcert demand; ldap-tls-ca-file "/etc/ssl/certs/ssl-cert-local-ca.pem"; ldap-tls-crlfile "/etc/ssl/crl/ssl-cert-local-ca.crl"; ldap-tls-cert "/etc/dhcp/pki/dhcpd.pem"; ldap-tls-key "/etc/dhcp/pki/dhcpd.key"; As you can see the semicolon is there. Not sure if this is related to GNUTLS, but if it is I can provide additional debug output, access to test VMs and other assistance (limited by the fact I'm no dev) if required. A report with more output can be found here: Link to bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723773 -- Mark Pavlichuk From antoine at delignat-lavaud.fr Wed Feb 12 17:18:14 2014 From: antoine at delignat-lavaud.fr (Antoine Delignat-Lavaud) Date: Wed, 12 Feb 2014 17:18:14 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52F9FCE7.5080400@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> Message-ID: <52FB9EC6.1050807@delignat-lavaud.fr> Hi, I tried to report the exact same problems to GnuTLS last summer. You may find the following paper relevant: http://research.microsoft.com/pubs/206278/ndss.pdf Best, Antoine Delignat-Lavaud -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: S/MIME Cryptographic Signature URL: From nmav at gnutls.org Thu Feb 13 09:04:37 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 09:04:37 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FB9EC6.1050807@delignat-lavaud.fr> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> Message-ID: On Wed, Feb 12, 2014 at 5:18 PM, Antoine Delignat-Lavaud wrote: > Hi, > I tried to report the exact same problems to GnuTLS last summer. > You may find the following paper relevant: > http://research.microsoft.com/pubs/206278/ndss.pdf Hello, Publishing a paper in a conference isn't considered reporting. If you'd like to report something for gnutls, summarize it, and sent it to the appropriate e-mail address or the mailing list. Providing a fix, is even better. regards, Nikos From nmav at gnutls.org Thu Feb 13 09:05:55 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 09:05:55 +0100 Subject: [gnutls-devel] isc dhcpd compiled with GNUTLS (Debian) In-Reply-To: <52FB99C0.1090807@internode.on.net> References: <52FB92C8.4050300@internode.on.net> <52FB99C0.1090807@internode.on.net> Message-ID: On Wed, Feb 12, 2014 at 4:56 PM, Mark Pavlichuk wrote: > I am experiencing a bug (in isc-dhcp-server compiled with GNUTLS and > LDAP support on Debian) which prevents TLS encryption between dhcpd > and the LDAP server. I tried the versions in Wheezy and Jessie > ie. 4.2.2 and 4.2.4. The problem is related to parsing the dhcpd.conf > file: > Internet Systems Consortium DHCP Server 4.2.4 > Copyright 2004-2012 Internet Systems Consortium. > All rights reserved. > For info, please visit https://www.isc.org/software/dhcp/ > /etc/dhcp/dhcpd.conf line 113: semicolon expected. > ldap-tls-crlfile "/etc/ssl/crl/ssl-cert-local-ca.crl" > ^ Hello Mark, Gnutls doesn't parse files, it is simply the back-end for SSL or crypto. You'd better report the issue to the appropriate software that has the bug. regards, Nikos From suman at cs.utexas.edu Thu Feb 13 09:28:10 2014 From: suman at cs.utexas.edu (Suman Jana) Date: Thu, 13 Feb 2014 00:28:10 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> Message-ID: <52FC821A.6090801@cs.utexas.edu> Hi Nikos, Thanks for your response. Please find my inline comments. >> 2. Path length constraints in CA certs should be enforced. GnuTLS ignores >> Path length constraints. > Which version of gnutls did you use? GnuTLS supports path length > constraints for quite some time now. We found the bug in GnuTLS 3.1.9. As you mentioned, GnuTLS 3.1.9 indeed parses the path length constraints. However, it doesn't enforce them. During CA certificate verification, the function "check_if_ca" is called from verify.c. "check_if_ca" is defined in lib/x509/x509.c as follows - int gnutls_x509_crt_get_ca_status (gnutls_x509_crt_t cert, unsigned int *critical) { int pathlen; unsigned int ca; return gnutls_x509_crt_get_basic_constraints (cert, critical, &ca, &pathlen); } The problem is that the pathlen value is never checked. > GnuTLS will support name > constraints when there is a reasonable profile defined. As it is now, > the PKIX name constraints are a mess. While I do agree with you that name constraints are quite messy, I'll like to point out that several other open source SSL libraries that we tested (e.g., OpenSSL, PolarSSL, ,NSS, Bouncy Castle) support them. Thanks, Suman From suman at cs.utexas.edu Thu Feb 13 09:33:36 2014 From: suman at cs.utexas.edu (Suman Jana) Date: Thu, 13 Feb 2014 00:33:36 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FC821A.6090801@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> Message-ID: <52FC8360.9050707@cs.utexas.edu> Sorry, one small correction. The "check_if_ca" function is actually defined in lib/x509/verify.c and it calls "gnutls_x509_crt_get_ca_status". Suman >>> 2. Path length constraints in CA certs should be enforced. GnuTLS >>> ignores >>> Path length constraints. >> Which version of gnutls did you use? GnuTLS supports path length >> constraints for quite some time now. > We found the bug in GnuTLS 3.1.9. As you mentioned, GnuTLS 3.1.9 > indeed parses > the path length constraints. However, it doesn't enforce them. During > CA certificate > verification, the function "check_if_ca" is called from verify.c. > "check_if_ca" is defined in > lib/x509/x509.c as follows - > > int > gnutls_x509_crt_get_ca_status (gnutls_x509_crt_t cert, unsigned int > *critical) > { > int pathlen; > unsigned int ca; > return gnutls_x509_crt_get_basic_constraints (cert, critical, &ca, > &pathlen); > } > > The problem is that the pathlen value is never checked. > From nmav at gnutls.org Thu Feb 13 10:14:21 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 10:14:21 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FC821A.6090801@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> Message-ID: On Thu, Feb 13, 2014 at 9:28 AM, Suman Jana wrote: > Hi Nikos, > Thanks for your response. Please find my inline comments. >>> 2. Path length constraints in CA certs should be enforced. GnuTLS ignores >>> Path length constraints. >> Which version of gnutls did you use? GnuTLS supports path length >> constraints for quite some time now. > We found the bug in GnuTLS 3.1.9. As you mentioned, GnuTLS 3.1.9 indeed > parses > the path length constraints. However, it doesn't enforce them. During CA > certificate > verification, the function "check_if_ca" is called from verify.c. > "check_if_ca" is defined in > lib/x509/x509.c as follows - [...] > The problem is that the pathlen value is never checked. This is not the verification function. Pathlen constraints is correctly checked on the verification function as far as I can tell, and the test cases we include pass. I could be wrong though, but in that case please provide a certificate chain that succeeds verification whereas it should have failed. > While I do agree with you that name constraints are quite messy, I'll like > to point > out that several other open source SSL libraries that we tested (e.g., > OpenSSL, PolarSSL, > ,NSS, Bouncy Castle) support them. Do they support all the options for the name constraints or only the DNS? regards, Nikos From nmav at gnutls.org Thu Feb 13 10:20:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 10:20:50 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FC8360.9050707@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> <52FC8360.9050707@cs.utexas.edu> Message-ID: On Thu, Feb 13, 2014 at 9:33 AM, Suman Jana wrote: > Sorry, one small correction. The "check_if_ca" function is actually defined > in lib/x509/verify.c > and it calls "gnutls_x509_crt_get_ca_status". This is the place it is being used: https://www.gitorious.org/gnutls/gnutls/source/adab89f5c854ff0ac01e6db631df1eac86f1829f:lib/x509/verify.c#L189 Maybe you tried with an older version? regards, Nikos From nmav at gnutls.org Thu Feb 13 10:25:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 10:25:50 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> Message-ID: On Thu, Feb 13, 2014 at 9:48 AM, Andy Lutomirski wrote: > This should IMO have a CVE assigned and announcement made. If I understand > the issue correctly, this will be widely exploited. > If this affects verification of client certs, everyone is fscked. It should have a CVE as it has quite some implications. As of exploitability I think it depends on whether there are CAs that issue v1 certificates. I'll try to make a bug-fix release as soon. regards, Nikos From suman at cs.utexas.edu Thu Feb 13 09:54:30 2014 From: suman at cs.utexas.edu (Suman Jana) Date: Thu, 13 Feb 2014 00:54:30 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FB9EC6.1050807@delignat-lavaud.fr> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> Message-ID: <52FC8846.2010506@cs.utexas.edu> Hi Antoine, Thanks for sharing the link to the NDSS paper. The paper only seems to be talking about two issues (as you may have noticed we reported several others) - 1. GnuTLS ignores path length constraints for version <3.0. I think it's a different bug than the one we described even though the result is the same. We found the bug in GnuTLS 3.1.9 that (unlike older versions) has code for parsing path length constraints but does not enforce it correctly. Please see my earlier email to the gnutls-devel mailing list for more details. 2. GnuTLS accepts certificates with unknown critical extensions. This seems to be the same bug that you reported. Thanks, Suman On 02/12/2014 08:18 AM, Antoine Delignat-Lavaud wrote: > Hi, > > I tried to report the exact same problems to GnuTLS last summer. > You may find the following paper relevant: > http://research.microsoft.com/pubs/206278/ndss.pdf > > Best, > > Antoine Delignat-Lavaud > -------------- next part -------------- An HTML attachment was scrubbed... URL: From suman at cs.utexas.edu Thu Feb 13 10:26:58 2014 From: suman at cs.utexas.edu (Suman Jana) Date: Thu, 13 Feb 2014 01:26:58 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> Message-ID: <52FC8FE2.4050903@cs.utexas.edu> >> We found the bug in GnuTLS 3.1.9. As you mentioned, GnuTLS 3.1.9 indeed >> parses >> the path length constraints. However, it doesn't enforce them. During CA >> certificate >> verification, the function "check_if_ca" is called from verify.c. >> "check_if_ca" is defined in >> lib/x509/x509.c as follows - > [...] >> The problem is that the pathlen value is never checked. > This is not the verification function. Pathlen constraints is > correctly checked on the verification function as far as I can tell, > and the test cases we include pass. I could be wrong though, but in > that case please provide a certificate chain that succeeds > verification whereas it should have failed. I don't have the test certificate chain right now. I'll check and get back to you. >> While I do agree with you that name constraints are quite messy, I'll like >> to point >> out that several other open source SSL libraries that we tested (e.g., >> OpenSSL, PolarSSL, >> ,NSS, Bouncy Castle) support them. > Do they support all the options for the name constraints or only the DNS? We tested with DNS and all of them seemed to support that. Thanks, Suman From luto at amacapital.net Thu Feb 13 09:48:37 2014 From: luto at amacapital.net (Andy Lutomirski) Date: Thu, 13 Feb 2014 00:48:37 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> Message-ID: On Feb 12, 2014 7:40 AM, "Nikos Mavrogiannopoulos" wrote: > > On Tue, Feb 11, 2014 at 11:35 AM, Suman Jana wrote: > > Hi, > > > > We are computer security researchers at UT Austin and UC Davis, currently > > testing > > several SSL/TLS implementations as part of a research project. When testing > > GnuTLS, > > we discovered the following security issues related to SSL/TLS certificate > > validation. > > Some of them may be deliberate violations of the X.509 standard, others > > appear to be > > bugs. > > Hello, > Thank you for the report. Comments inline; > > > As far as we know, none of them is documented. > > Please feel free to provide patches to improve documentation. That is > the essence of free software. > > > 1. v1 CA certificates should be rejected by default unless validated by > > external means but GnuTLS accepts it. > > You are correct. This is a bug in current code. > > > As shown in the code above, after a root v1 certi?cate has been accepted, to > > prevent > > any further v1 certi?cates from being accepted, GnuTLS clears the > > GNUTLS_VERIFY_ALLOW > > _X509_V1_CA_CRT ?ag before calling _gnutls_verify_certificate2. However, the > > _gnutls_ > > verify_certificate2 function accepts v1 certi?cates unless a different ?ag, > > GNUTLS_VERIFY_ > > DO_NOT_ALLOW_X509_V1_CA_CRT is set. But the caller > > (_gnutls_x509_verify_certificate) > > never sets that flag. > > Nice trace of the issue. I've now fixed it in the repository. This should IMO have a CVE assigned and announcement made. If I understand the issue correctly, this will be widely exploited. If this affects verification of client certs, everyone is fscked. > > > 2. Path length constraints in CA certs should be enforced. GnuTLS ignores > > Path length constraints. > > Which version of gnutls did you use? GnuTLS supports path length > constraints for quite some time now. > > > 3. Name constraints in CA certs should be enforced. GnuTLS ignores name > > constraints. > > I believe that you haven't read RFC5280 :) GnuTLS will support name > constraints when there is a reasonable profile defined. As it is now, > the PKIX name constraints are a mess. > > > 4. keyUsage and extendedKeyUsage extensions in CA and leaf certificates > > should be checked > > correctly. GnuTLS does not check any of them. > > We used to check them (the keyUsage) and people were reporting it as a > bug. See: http://www.gnutls.org/faq.html#key-usage-violation > Since the keyusage is set by system administrators who have no idea > what should go there, there is no much point in enforcing it > (especially when no-else does and your software looks broken when it > is strict). > > > 5. Certificate validation must fail if unknown critical extensions are > > present in the certificate > > but GnuTLS accepts certificates with unknown critical extensions. > > That is from the time when there was a single company that controlled > most of the available software generating certificate. It would have > been very easy for them to lock out gnutls if we have supported this > rule. I may reconsider if there is any real issue. Of course there's an issue. It prevents anyone from *fixing* the disaster that is PKIX. Fortunately (?) issue #1 is sufficiently severe that, if you fix both issues together, old GnuTLS versions won't hold CAs back from issuing intermediate certs w/ critical constraints for GnuTLS's sake. --Andy > > regards, > Nikos > > _______________________________________________ > 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 Thu Feb 13 12:56:55 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 12:56:55 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FC8FE2.4050903@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> <52FC8FE2.4050903@cs.utexas.edu> Message-ID: On Thu, Feb 13, 2014 at 10:26 AM, Suman Jana wrote: >>> While I do agree with you that name constraints are quite messy, I'll >>> like >>> to point >>> out that several other open source SSL libraries that we tested (e.g., >>> OpenSSL, PolarSSL, >>> ,NSS, Bouncy Castle) support them. >> Do they support all the options for the name constraints or only the DNS? > We tested with DNS and all of them seemed to support that. So the fact that you only checked DNS constraints (directoryName is the only mandatory name constraint in rfc5280) means that there is already a de facto profile expected to work by people. regards, Nikos From antoine at delignat-lavaud.fr Thu Feb 13 13:07:38 2014 From: antoine at delignat-lavaud.fr (Antoine Delignat-Lavaud) Date: Thu, 13 Feb 2014 13:07:38 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> Message-ID: <52FCB58A.8060506@delignat-lavaud.fr> On 13/02/2014 09:04, Nikos Mavrogiannopoulos wrote: > Publishing a paper in a conference isn't considered reporting. If > you'd like to report something for gnutls, summarize it, and sent it > to the appropriate e-mail address or the mailing list. Providing a > fix, is even better. Hi Nikos, I was an intern at Microsoft at the time of writing, and was not allowed to disclose the issue myself, or even look at the GPL GnuTLS code at that time. That being said, it seems you answered to our report (through the Microsoft disclosure program) on September 13 last year pointing us to the following page: http://gnutls.org/manual/html_node/Verifying-X_002e509-certificate-paths.html where it says: "Limitation: Pathlen constraints or key usage flags are not consulted." on gnutls_x509_trust_list_verify_crt(). Thus, we considered it was a known issue and went ahead with the publication. That being said, there is no doubt that X509 validation leaves much to be desired in GnuTLS and I am volunteering to write a patch to strengthen some of the checks. On 13/02/2014 09:54, Suman Jana wrote: > 1. GnuTLS ignores path length constraints for version <3.0. I think > it's a different bug than the one we described even though the result > is the same. We found the bug in GnuTLS 3.1.9 that (unlike older > versions) has code for parsing path length constraints but does not > enforce it correctly. Please see my earlier email to the gnutls-devel > mailing list for more details. For newer versions we accepted Nikos' answer that the behavior is documented. We also reported the key usage issue, which is also documented on the page linked above. However, you are right that we didn't notice the issue with V1 certificates. Best, Antoine Delignat-Lavaud -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: S/MIME Cryptographic Signature URL: From nmav at gnutls.org Thu Feb 13 14:03:45 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 14:03:45 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FCB58A.8060506@delignat-lavaud.fr> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> Message-ID: On Thu, Feb 13, 2014 at 1:07 PM, Antoine Delignat-Lavaud wrote: > Publishing a paper in a conference isn't considered reporting. If > you'd like to report something for gnutls, summarize it, and sent it > to the appropriate e-mail address or the mailing list. Providing a > fix, is even better. > Hi Nikos, > I was an intern at Microsoft at the time of writing, and was not allowed to > disclose the issue myself, or even look at the GPL GnuTLS code at that time. > That being said, it seems you answered to our report (through the Microsoft > disclosure program) on September 13 last year pointing us to the following > page: > http://gnutls.org/manual/html_node/Verifying-X_002e509-certificate-paths.html > where it says: "Limitation: Pathlen constraints or key usage flags are > not consulted." on gnutls_x509_trust_list_verify_crt(). Ok, I remember that. Sorry for the attitude, but it is often that people from academia publish issues without reporting them back. > Thus, we considered it was a known issue and went ahead with the > publication. That being said, there is no doubt that X509 validation leaves > much to be desired in GnuTLS and I am volunteering to write a patch to > strengthen some of the checks. What do you have in mind? If you are interested some of the missing features are listed here: https://www.gitorious.org/gnutls/gnutls/source/2d1898608e451dabcff9b9ccb890f04a8f619ebc:doc/TODO#L14 Improving the test suite (suite/chain and chainverify.c) is also an important task. In any case you're welcome to contribute (but in that case please announce the topic so we avoid duplicate work). regards, Nikos From Jason at zx2c4.com Thu Feb 13 14:49:50 2014 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 13 Feb 2014 14:49:50 +0100 Subject: [gnutls-devel] crash inside of wrap_nettle_rnd? In-Reply-To: <52FC6B66.1010309@gnutls.org> References: <52FBE8B7.3020900@gnutls.org> <52FC6B66.1010309@gnutls.org> Message-ID: Fixed. Turned out that weechat wasn't linking against pthreads, so gnutls was using the stubbed out version in glibc. Then later, a plugin would load the non-stubbed version, which would mean the mutexes initialized prior by gnutls were uninitialized, but then put to use by libpthread. From antoine at delignat-lavaud.fr Thu Feb 13 17:45:37 2014 From: antoine at delignat-lavaud.fr (Antoine Delignat-Lavaud) Date: Thu, 13 Feb 2014 17:45:37 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> Message-ID: <52FCF6B1.3060906@delignat-lavaud.fr> On 13/02/2014 14:03, Nikos Mavrogiannopoulos wrote: > What do you have in mind? If you are interested some of the missing > features are listed here: > https://www.gitorious.org/gnutls/gnutls/source/2d1898608e451dabcff9b9ccb890f04a8f619ebc:doc/TODO#L14 > Improving the test suite (suite/chain and chainverify.c) is also an > important task. In any case you're welcome to contribute (but in that > case please announce the topic so we avoid duplicate work). regards, > Nikos I propose to implement the following changes (by order of priority): 1. check all basic constraints and key usage flags properly 2. (depends on 1) enforce critical extensions. According to our measurements, there are only two CA that have issued certificates with non-standard critical extensions in the past 2 years, for a total of 629 certificates. 3. enforce extended key usage 4. enforce name constraints Best, ADL -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: S/MIME Cryptographic Signature URL: From dkg at fifthhorseman.net Thu Feb 13 18:19:57 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Feb 2014 12:19:57 -0500 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FCF6B1.3060906@delignat-lavaud.fr> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> Message-ID: <52FCFEBD.3010601@fifthhorseman.net> On 02/13/2014 11:45 AM, Antoine Delignat-Lavaud wrote: > 1. check all basic constraints and key usage flags properly I think this should be split into two pieces: basic constraints and key usage flags. Do we have evidence that other TLS stacks are actually checking key usage flags and acting on the results? Nikos' concern that users or devs will think "GnuTLS is broken for site X" is a legitimate concern, unfortunately. It looks like key usage violations used to be permitted only when %COMPAT was specified in the priority string, and then commit id 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be tolerated by default. Perhaps this behavior could be added back in a way that could be controlled by a more specific priority string (i'm not sure what the default would be). In addition to knowing what other TLS libraries do, a survey of sites that are willing to offer ECDHE or DHE key exchange mechanisms without a digital signature key usage flag would be helpful in making an argument about what the default should be. I could produce this patch if people think that's a good approach. > 2. (depends on 1) enforce critical extensions. According to our > measurements, there are only two CA that have issued certificates with > non-standard critical extensions in the past 2 years, for a total of 629 > certificates. why does this depend on 1? enforcing criticality of extensions seems like it could be done independently. > 3. enforce extended key usage > 4. enforce name constraints it would be great to clarify which particular name constraints are the goal. DNS does seem like the right direction to start from, clearly, though it doesn't make as much sense when thinking about client-side certs. --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 Thu Feb 13 19:52:27 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 19:52:27 +0100 Subject: [gnutls-devel] gnutls 3.2.11 Message-ID: <52FD146B.1070100@gnutls.org> Hello, I've just released gnutls 3.2.11. This is a bugfix release on the current stable branch. This release addresses the security advisory GNUTLS-SA-2014-1 at: http://www.gnutls.org/security.html#GNUTLS-SA-2014-1 * Version 3.2.11 (released 2014-02-13) ** libgnutls: Tolerate servers that send the SUPPORTED ECC extension. ** libgnutls: Reduced the TLS and DTLS version requirements for all ciphersuites that are not GCM. ** libgnutls: When two initial keywords are specified then treat the second as having the '+' modifier. ** libgnutls: When using a PKCS #11 module for verification ensure that it has been marked a trusted policy module in p11-kit. Moreover, when an empty (i.e., "pkcs11:") URL is specified, then try all trusted modules in the system for verification. http://p11-glue.freedesktop.org/doc/p11-kit/pkcs11-conf.html ** libgnutls: Fixed bug that prevented the rejection of v1 intermediate CA certificates. Reported and investigated by Suman Jana. ** certtool: Added the --ask-pass option. ** API and ABI modifications: GNUTLS_PKCS11_TOKEN_TRUSTED: Added GNUTLS_PKCS11_OBJ_FLAG_PRESENT_IN_TRUSTED_MODULE: 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.11.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.11.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.11.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.11.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 Thu Feb 13 19:56:10 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 19:56:10 +0100 Subject: [gnutls-devel] gnutls 3.1.21 Message-ID: <52FD154A.8040907@gnutls.org> Hello, I've just released gnutls 3.1.21. This is a bug fix release on the old stable branch which addresses GNUTLS-SA-2014-1. * Version 3.1.21 (released 2014-02-13) ** libgnutls: Tolerate servers that sent the SUPPORTED ECC extension. ** libgnutls: Reduced the TLS and DTLS version requirements for all ciphersuites that are not GCM. ** libgnutls: When two initial keywords are specified then treat the second as having the '+' modifier. ** libgnutls: Fixed bug that prevented the rejection of v1 intermediate CA certificates. Reported and investigated by Suman Jana. ** 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.21.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.21.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.21.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.21.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 antoine at delignat-lavaud.fr Thu Feb 13 19:58:43 2014 From: antoine at delignat-lavaud.fr (Antoine Delignat-Lavaud) Date: Thu, 13 Feb 2014 19:58:43 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FCFEBD.3010601@fifthhorseman.net> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> Message-ID: <52FD15E3.1070909@delignat-lavaud.fr> Hi Daniel, Le 13/02/2014 18:19, Daniel Kahn Gillmor a ?crit : > On 02/13/2014 11:45 AM, Antoine Delignat-Lavaud wrote: > >> 1. check all basic constraints and key usage flags properly > > I think this should be split into two pieces: basic constraints and key > usage flags. > > Do we have evidence that other TLS stacks are actually checking key > usage flags and acting on the results? Nikos' concern that users or > devs will think "GnuTLS is broken for site X" is a legitimate concern, > unfortunately. I ran some tests with Ilya Mironov at MSR, and we found that browsers do in fact enforce the CertSign bit on CA certs. When a server certificate is used to sign the parameters in DH and ECDH ciphers, it is widely accepted that it requires the Signature bit, and this bit is in fact in all certificates issued recently. We tried to connect with an invalid certificate on Firefox, Chrome and IE, which indeed triggered errors. The consensus for RSA is to require the keyEncipherment bit, which is a bit controversial (the PMS is not a key, so it could fall under dataEncipherment or keyAgreement as well). In any case, the CA/B requires digitalSignature and keyEncipherment, and this is what is (almost) always found in certificates today. Enabling this check shouldn't break any recently issued publicly trusted certificate. We only found one instance of a server certificate that had the decipherOnly bit accidentally set. > It looks like key usage violations used to be permitted only when > %COMPAT was specified in the priority string, and then commit id > 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be > tolerated by default. Perhaps this behavior could be added back in a > way that could be controlled by a more specific priority string (i'm not > sure what the default would be). > In addition to knowing what other TLS libraries do, a survey of sites > that are willing to offer ECDHE or DHE key exchange mechanisms without a > digital signature key usage flag would be helpful in making an argument > about what the default should be. I will double check this but as far as I remember I don't think there was any certificate issued without the DigitalSignature flag recently, at least on the public PKI. >> 2. (depends on 1) enforce critical extensions. According to our >> measurements, there are only two CA that have issued certificates with >> non-standard critical extensions in the past 2 years, for a total of 629 >> certificates. > > why does this depend on 1? enforcing criticality of extensions seems > like it could be done independently. BC and Key Usage are typically critical extension, it wouldn't make sense to accept them if the checks in RFC 5280 are not enforced. >> 3. enforce extended key usage >> 4. enforce name constraints > > it would be great to clarify which particular name constraints are the > goal. DNS does seem like the right direction to start from, clearly, > though it doesn't make as much sense when thinking about client-side certs. DNS constraints are the one that are (admittedly, very rarely) used in practice. Best, ADL -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: Signature cryptographique S/MIME URL: From nmav at gnutls.org Thu Feb 13 20:14:31 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 20:14:31 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FD15E3.1070909@delignat-lavaud.fr> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD15E3.1070909@delignat-lavaud.fr> Message-ID: <52FD1997.1080906@gnutls.org> On 02/13/2014 07:58 PM, Antoine Delignat-Lavaud wrote: >> I think this should be split into two pieces: basic constraints and key >> usage flags. >> Do we have evidence that other TLS stacks are actually checking key >> usage flags and acting on the results? Nikos' concern that users or >> devs will think "GnuTLS is broken for site X" is a legitimate concern, >> unfortunately. > I ran some tests with Ilya Mironov at MSR, and we found that browsers do > in fact enforce the CertSign bit on CA certs. When a server certificate > is used to sign the parameters in DH and ECDH ciphers, it is widely > accepted that it requires the Signature bit, and this bit is in fact in > all certificates issued recently. We tried to connect with an invalid > certificate on Firefox, Chrome and IE, which indeed triggered errors. > The consensus for RSA is to require the keyEncipherment bit, which is a > bit controversial (the PMS is not a key, so it could fall under > dataEncipherment or keyAgreement as well). In any case, the CA/B > requires digitalSignature and keyEncipherment, and this is what is > (almost) always found in certificates today. > Enabling this check shouldn't break any recently issued publicly trusted > certificate. We only found one instance of a server certificate that had > the decipherOnly bit accidentally set. What we can do based on Daniel's suggestions is to have an additional verification flag STRICT_RFC5280 or so, that will incorporate the additional checks initially. Gradually we can move some of these tests to the default setting. It is important though, that when you add a new check to add two tests for it in chainverify.c for it (one that should succeed, and one that should violate the condition). >> It looks like key usage violations used to be permitted only when >> %COMPAT was specified in the priority string, and then commit id >> 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be >> tolerated by default. Perhaps this behavior could be added back in a >> way that could be controlled by a more specific priority string (i'm not >> sure what the default would be). >> In addition to knowing what other TLS libraries do, a survey of sites >> that are willing to offer ECDHE or DHE key exchange mechanisms without a >> digital signature key usage flag would be helpful in making an argument >> about what the default should be. > I will double check this but as far as I remember I don't think there > was any certificate issued without the DigitalSignature flag recently, > at least on the public PKI. You may want to check the SSL obvervatory's 2010 data (I couldn't find a later version). There you'll notice a whole madness with certificates. I even remember DSA certificates marked for key encipherment. >>> 4. enforce name constraints That would be nice to be enabled by default anyway. I have had hard time to find a CA that uses that though. Anyway I'm working on an API to get and set this extension's data so you could use that (not committed yet). regards, Nikos From nmav at gnutls.org Thu Feb 13 20:20:56 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 20:20:56 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FCFEBD.3010601@fifthhorseman.net> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> Message-ID: <52FD1B18.6060502@gnutls.org> On 02/13/2014 06:19 PM, Daniel Kahn Gillmor wrote: > It looks like key usage violations used to be permitted only when > %COMPAT was specified in the priority string, and then commit id > 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be > tolerated by default. Perhaps this behavior could be added back in a > way that could be controlled by a more specific priority string (i'm not > sure what the default would be). > In addition to knowing what other TLS libraries do, a survey of sites > that are willing to offer ECDHE or DHE key exchange mechanisms without a > digital signature key usage flag would be helpful in making an argument > about what the default should be. > I could produce this patch if people think that's a good approach. Maybe we can add back the check for 3.3.x when %COMPAT is not specified? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 534 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Thu Feb 13 20:29:22 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Feb 2014 14:29:22 -0500 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FD1997.1080906@gnutls.org> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD15E3.1070909@delignat-lavaud.fr> <52FD1997.1080906@gnutls.org> Message-ID: <52FD1D12.8070804@fifthhorseman.net> On 02/13/2014 02:14 PM, Nikos Mavrogiannopoulos wrote: > On 02/13/2014 07:58 PM, Antoine Delignat-Lavaud wrote: >> I will double check this but as far as I remember I don't think there >> was any certificate issued without the DigitalSignature flag recently, >> at least on the public PKI. > > You may want to check the SSL obvervatory's 2010 data (I couldn't find a > later version). There you'll notice a whole madness with certificates. I > even remember DSA certificates marked for key encipherment. there are some more modern scans provided at https://scans.io/, for folks interested in trawling large datasets of X.509 certificates. --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 dkg at fifthhorseman.net Thu Feb 13 20:41:25 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Feb 2014 14:41:25 -0500 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FD1B18.6060502@gnutls.org> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD1B18.6060502@gnutls.org> Message-ID: <52FD1FE5.7050002@fifthhorseman.net> On 02/13/2014 02:20 PM, Nikos Mavrogiannopoulos wrote: > On 02/13/2014 06:19 PM, Daniel Kahn Gillmor wrote: > >> It looks like key usage violations used to be permitted only when >> %COMPAT was specified in the priority string, and then commit id >> 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be >> tolerated by default. Perhaps this behavior could be added back in a >> way that could be controlled by a more specific priority string (i'm not >> sure what the default would be). >> In addition to knowing what other TLS libraries do, a survey of sites >> that are willing to offer ECDHE or DHE key exchange mechanisms without a >> digital signature key usage flag would be helpful in making an argument >> about what the default should be. >> I could produce this patch if people think that's a good approach. > > Maybe we can add back the check for 3.3.x when %COMPAT is not specified? is there a reason to only lump this in with %COMPAT and not have it be a distinct %PERMISSIVE_KEY_USAGE flag? %COMPAT could imply %PERMISSIVE_KEY_USAGE. It occurs to me: is there a way to *unset* a priority string flag? I'm thinking about a scenario where an administrator anticipates a change in the defaults for some setting, and wants to ensure that their preferred configuration setting works and is stable using the same priority string across versions. (another way to look at this is: how can someone write a HOWTO for a particular use case that has a single priority string that will work regardless of what the defaults are of the particular version the reader has deployed) --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 Thu Feb 13 21:42:21 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 21:42:21 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FD1FE5.7050002@fifthhorseman.net> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD1B18.6060502@gnutls.org> <52FD1FE5.7050002@fifthhorseman.net> Message-ID: <52FD2E2D.3010006@gnutls.org> On 02/13/2014 08:41 PM, Daniel Kahn Gillmor wrote: > On 02/13/2014 02:20 PM, Nikos Mavrogiannopoulos wrote: >> On 02/13/2014 06:19 PM, Daniel Kahn Gillmor wrote: >> >>> It looks like key usage violations used to be permitted only when >>> %COMPAT was specified in the priority string, and then commit id >>> 16d365ab359436651deb35a8ec6cdc0e76c077d9 that was changed to be >>> tolerated by default. Perhaps this behavior could be added back in a >>> way that could be controlled by a more specific priority string (i'm not >>> sure what the default would be). >>> In addition to knowing what other TLS libraries do, a survey of sites >>> that are willing to offer ECDHE or DHE key exchange mechanisms without a >>> digital signature key usage flag would be helpful in making an argument >>> about what the default should be. >>> I could produce this patch if people think that's a good approach. >> >> Maybe we can add back the check for 3.3.x when %COMPAT is not specified? > > is there a reason to only lump this in with %COMPAT and not have it be a > distinct %PERMISSIVE_KEY_USAGE flag? %COMPAT could imply > %PERMISSIVE_KEY_USAGE. It could be. In master I use a hash table so adding more flags wouldn't hurt. > It occurs to me: is there a way to *unset* a priority string flag? I'm > thinking about a scenario where an administrator anticipates a change in > the defaults for some setting, and wants to ensure that their preferred > configuration setting works and is stable using the same priority string > across versions. (another way to look at this is: how can someone write > a HOWTO for a particular use case that has a single priority string that > will work regardless of what the defaults are of the particular version > the reader has deployed) That could be done if we add individual priority string flags for all work arounds. Unsetting flags is not supported though, and I don't know if that additional complexity is needed. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 534 bytes Desc: OpenPGP digital signature URL: From kurt at roeckx.be Thu Feb 13 22:21:24 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 13 Feb 2014 22:21:24 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> Message-ID: <20140213212124.GA30642@roeckx.be> On Thu, Feb 13, 2014 at 10:25:50AM +0100, Nikos Mavrogiannopoulos wrote: > On Thu, Feb 13, 2014 at 9:48 AM, Andy Lutomirski wrote: > > > This should IMO have a CVE assigned and announcement made. If I understand > > the issue correctly, this will be widely exploited. > > If this affects verification of client certs, everyone is fscked. > > It should have a CVE as it has quite some implications. As of > exploitability I think it depends on whether there are CAs that issue > v1 certificates. I've checked 7.5M certificates that most browser should validate and found 71 such certificates, of which 44 are a CA, and so 27 are not. 24 of the 27 are from the CA for itself. Kurt From antoine at delignat-lavaud.fr Fri Feb 14 01:21:00 2014 From: antoine at delignat-lavaud.fr (Antoine Delignat-Lavaud) Date: Fri, 14 Feb 2014 01:21:00 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FD1997.1080906@gnutls.org> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD15E3.1070909@delignat-lavaud.fr> <52FD1997.1080906@gnutls.org> Message-ID: <52FD616C.1090707@delignat-lavaud.fr> Le 13/02/2014 20:14, Nikos Mavrogiannopoulos a ?crit : > You may want to check the SSL obvervatory's 2010 data (I couldn't find a > later version). There you'll notice a whole madness with certificates. I > even remember DSA certificates marked for key encipherment. I asked my colleagues to check the Microsoft database, which is a strict (and much larger, as well as up to date) superset of the EFF data. There have been 53 certificates issued in the past year without the Signature key usage (for instance: rubrica.poste.it, www.ha.org.hk, netbank.kdb.hu). They are on servers that only support the RSA key exchange (if such a certificate was used with (EC)DH, Chrome, Firefox and IE would trigger an error). In addition, there have been 101 certificates issued without the key usage extension at all, mostly by Google on their CA (this is allowed by RFC 5280 and the CA/B forum) Best, ADL -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: Signature cryptographique S/MIME URL: From suman at cs.utexas.edu Fri Feb 14 11:15:57 2014 From: suman at cs.utexas.edu (Suman Jana) Date: Fri, 14 Feb 2014 02:15:57 -0800 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> <52FC8360.9050707@cs.utexas.edu> Message-ID: <52FDECDD.3040605@cs.utexas.edu> Hi Nikos, You are right. It turns out that for this bug we were using v 3.1.0 from - ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.0.tar.lz. The source code listings I sent you were also from v 3.1.0. I confirmed that the pathlen constraints are indeed being checked correctly in v 3.1.9. Sorry about the confusion. BTW, is it a known bug for v 3.1.0? Thanks, Suman On 02/13/2014 01:20 AM, Nikos Mavrogiannopoulos wrote: > On Thu, Feb 13, 2014 at 9:33 AM, Suman Jana wrote: >> Sorry, one small correction. The "check_if_ca" function is actually defined >> in lib/x509/verify.c >> and it calls "gnutls_x509_crt_get_ca_status". > This is the place it is being used: > https://www.gitorious.org/gnutls/gnutls/source/adab89f5c854ff0ac01e6db631df1eac86f1829f:lib/x509/verify.c#L189 > > Maybe you tried with an older version? > > regards, > Nikos From nmav at gnutls.org Fri Feb 14 12:54:18 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 14 Feb 2014 12:54:18 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FDECDD.3040605@cs.utexas.edu> References: <52F9FCE7.5080400@cs.utexas.edu> <52FC821A.6090801@cs.utexas.edu> <52FC8360.9050707@cs.utexas.edu> <52FDECDD.3040605@cs.utexas.edu> Message-ID: On Fri, Feb 14, 2014 at 11:15 AM, Suman Jana wrote: > Hi Nikos, > You are right. It turns out that for this bug we were using v 3.1.0 > from - ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.0.tar.lz. > The source code listings I sent you were also from v 3.1.0. > I confirmed that the pathlen constraints are indeed being checked > correctly in v 3.1.9. > Sorry about the confusion. BTW, is it a known bug for v 3.1.0? It is expected then. Support for pathlen constraints was added in 3.1.4. regards, Nikos From anisimkov at ada-ru.org Sat Feb 15 07:14:04 2014 From: anisimkov at ada-ru.org (Dmitriy Anisimkov) Date: Sat, 15 Feb 2014 13:14:04 +0700 Subject: [gnutls-devel] Avoid segmentation fault on wrong crt files Message-ID: <52FF05AC.8080600@ada-ru.org> In gnutls_pcert_list_import_x509_raw call If data does not contain any certificate, the call gnutls_x509_crt_list_import returns error, and than failure happening inside gnutls_x509_crt_deinit, because the crt array was not zero initialized and looks like initialized by certificates. Do I need to create small test program demonstrating the faulure fixed by this patch ? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Avoid-segmentation-fail-on-file-without-certificates.patch Type: text/x-patch Size: 740 bytes Desc: not available URL: From nmav at gnutls.org Sat Feb 15 10:16:49 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 15 Feb 2014 10:16:49 +0100 Subject: [gnutls-devel] Avoid segmentation fault on wrong crt files In-Reply-To: <52FF05AC.8080600@ada-ru.org> References: <52FF05AC.8080600@ada-ru.org> Message-ID: <52FF3081.9010006@gnutls.org> On 02/15/2014 07:14 AM, Dmitriy Anisimkov wrote: > In gnutls_pcert_list_import_x509_raw call > If data does not contain any certificate, the call > gnutls_x509_crt_list_import returns error, > and than failure happening inside gnutls_x509_crt_deinit, because the > crt array was not > zero initialized and looks like initialized by certificates. Thank you. I've committed a little different fix in master. regards, Nikos From ametzler at bebt.de Sat Feb 15 16:15:56 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 15 Feb 2014 16:15:56 +0100 Subject: [gnutls-devel] GNUTLS-SA-2014-1 / CVE-2014-1959 only affexts 3.[12].x? Message-ID: <20140215151556.GA3355@downhill.g.la> Hello, http://www.gnutls.org/security.html#GNUTLS-SA-2014-1 says: "Suman Jana reported a vulnerability that affects the certificate verification functions of gnutls 3.1.x and gnutls 3.2.x." Is this correct, are 3.0.x and 2.x not affected? 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 mancha1 at hush.com Sat Feb 15 16:43:14 2014 From: mancha1 at hush.com (mancha) Date: Sat, 15 Feb 2014 15:43:14 +0000 Subject: [gnutls-devel] =?utf-8?q?GNUTLS-SA-2014-1_/_CVE-2014-1959_only_af?= =?utf-8?b?ZmV4dHMJMy5bMTJdLng/?= Message-ID: <20140215154314.7550D60161@smtp.hushmail.com> On Sat, 15 Feb 2014 15:16:55 +0000 "Andreas Metzler" wrote: >Hello, > >http://www.gnutls.org/security.html#GNUTLS-SA-2014-1 says: "Suman >Jana >reported a vulnerability that affects the certificate verification >functions of gnutls 3.1.x and gnutls 3.2.x." > >Is this correct, are 3.0.x and 2.x not affected? > >cu Andreas Hello. According to my code review the issue is introduced in 2.11.5 when V1 trusted CAs began getting allowed by default. Feel free to use my backport for 3.0.32: http://sf.net/projects/mancha/files/sec/gnutls-3.0.32_CVE-2014- 1959.diff --mancha From ametzler at bebt.de Sat Feb 15 18:00:22 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 15 Feb 2014 18:00:22 +0100 Subject: [gnutls-devel] gnutls 3.2.11 requires p11-kit >= 0.19.2 Message-ID: <20140215170022.GB3355@downhill.g.la> Hello, gnutls 3.2.11 FTBFS against 0.12: ------------------------- libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/share/locale\" -I./../gl -I./../gl -I./includes -I./x509 -I./includes -I./includes -I./x509 -I/usr/include/p11-kit-1 -I./opencdk -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -c pkcs11.c -fPIC -DPIC -o .libs/pkcs11.o pkcs11.c: In function 'pkcs11_add_module': pkcs11.c:226:2: warning: implicit declaration of function 'p11_kit_module_get_flags' [-Wimplicit-function-declaration] pkcs11.c:226:41: error: 'P11_KIT_MODULE_TRUSTED' undeclared (first use in this function) pkcs11.c:226:41: note: each undeclared identifier is reported only once for each function it appears in pkcs11.c: In function 'find_flags': pkcs11.c:2775:48: error: 'P11_KIT_MODULE_TRUSTED' undeclared (first use in this function) make[6]: *** [pkcs11.lo] Error 1 -------------------------- Afaict from p11-kit GIT P11_KIT_MODULE_TRUSTED was introduced early in the unstable 0.19.x series (0.19.1 or 0.19.2), therefore gnutls ./configure should test for the first stable release after, 0.20.0. 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 Sat Feb 15 18:16:01 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 15 Feb 2014 18:16:01 +0100 Subject: [gnutls-devel] gnutls 3.2.11 requires p11-kit >= 0.19.2 In-Reply-To: <20140215170022.GB3355@downhill.g.la> References: <20140215170022.GB3355@downhill.g.la> Message-ID: <52FFA0D1.7030206@gnutls.org> On 02/15/2014 06:00 PM, Andreas Metzler wrote: > Hello, > > gnutls 3.2.11 FTBFS against 0.12: > ------------------------- > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/share/locale\" -I./../gl -I./../gl -I./includes -I./x509 -I./includes -I./includes -I./x509 -I/usr/include/p11-kit-1 -I./opencdk -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -c pkcs11.c -fPIC -DPIC -o .libs/pkcs11.o > pkcs11.c: In function 'pkcs11_add_module': > pkcs11.c:226:2: warning: implicit declaration of function 'p11_kit_module_get_flags' [-Wimplicit-function-declaration] > pkcs11.c:226:41: error: 'P11_KIT_MODULE_TRUSTED' undeclared (first use in this function) > pkcs11.c:226:41: note: each undeclared identifier is reported only once for each function it appears in > pkcs11.c: In function 'find_flags': > pkcs11.c:2775:48: error: 'P11_KIT_MODULE_TRUSTED' undeclared (first use in this function) > make[6]: *** [pkcs11.lo] Error 1 > -------------------------- Nice catch. I didn't realize that this functionality didn't exist in the old branch. It the dependency has now been updated. regards, Nikos From nmav at gnutls.org Mon Feb 17 13:51:14 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 17 Feb 2014 13:51:14 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <52FD1997.1080906@gnutls.org> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD15E3.1070909@delignat-lavaud.fr> <52FD1997.1080906@gnutls.org> Message-ID: On Thu, Feb 13, 2014 at 8:14 PM, Nikos Mavrogiannopoulos wrote: >>>> 4. enforce name constraints > That would be nice to be enabled by default anyway. I have had hard time > to find a CA that uses that though. Anyway I'm working on an API to get > and set this extension's data so you could use that (not committed yet). I've implemented this functionality in master, but not added it in the verification process. The only certificate in my trusted root which contained this extension had: 1. Marked it as non-critical (RFC5280 requires this is critical) 2. DNSNames listed in the wrong format (e.g., '.com' instead of 'com'). So I'm still not sure whether this is something that should be checked by default. regards, Nikos From antoine at delignat-lavaud.fr Tue Feb 18 00:46:41 2014 From: antoine at delignat-lavaud.fr (Antoine Delignat-Lavaud) Date: Tue, 18 Feb 2014 00:46:41 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD15E3.1070909@delignat-lavaud.fr> <52FD1997.1080906@gnutls.org> Message-ID: <53029F61.8060303@delignat-lavaud.fr> Le 17/02/2014 13:51, Nikos Mavrogiannopoulos a ?crit : > On Thu, Feb 13, 2014 at 8:14 PM, Nikos Mavrogiannopoulos > wrote: > >>>>> 4. enforce name constraints >> That would be nice to be enabled by default anyway. I have had hard time >> to find a CA that uses that though. Anyway I'm working on an API to get >> and set this extension's data so you could use that (not committed yet). > > I've implemented this functionality in master, but not added it in the > verification process. > The only certificate in my trusted root which contained this extension had: > 1. Marked it as non-critical (RFC5280 requires this is critical) > 2. DNSNames listed in the wrong format (e.g., '.com' instead of 'com'). > > So I'm still not sure whether this is something that should be checked > by default. The CA/B forum has made an exception to allow the use of a non-critical name constraints extension because of poor implementation support in TLS libraries. This is also one of the reasons why CAs are reluctant to enable name constraints - thus if you are waiting for this feature to be widely used before implementing it, it will never see the light of day. Also, you'll find attached a list of CA certificates found in the wild that use name constraints. Best, ADL -------------- next part -------------- +---------+-----------------------------------------------------------------------------------------------------------------------------------+ | certID | subject | +---------+-----------------------------------------------------------------------------------------------------------------------------------+ | 263959 | CN=TEST RSA Signing CA1,OU=DEMO Certification Services,O=Carillon Information Security Inc.,C=CA | | 327706 | CN=Vonage Intermediate Corporate Server CA,OU=Vonage Networks,O=Vonage Holdings,C=US | | 327707 | CN=Vonage Intermediate Corporate Server CA,OU=Vonage Networks,O=Vonage Holdings,C=US | | 622705 | CN=Ashrpca001,OU=dpki,OU=r,O=mil,C=gb | | 663004 | CN=OpsCA,OU=PKI,OU=Ops,O=Red Condor | | 691866 | CN=SBGroup,DC=sbgroup,DC=sbstahl,DC=local | | 1254714 | CN=VeriSign Client External Certification Authority,OU=Certification Authorities,OU=ECA,O=U.S. Government,C=US | | 1295139 | CN=Omniscient Technologies Servers CA,OU=Omniscient Networks,O=Omniscient Technologies,C=US | | 1295140 | CN=Omniscient Technologies Core Server CA,OU=Omniscient Networks,O=Omniscient Technologies,C=US | | 1396482 | CN=U.S. Department of State AD High Assurance CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=state,DC=sbu | | 1581282 | CN=Multi Resolution Image Technology Certificate Authority,OU=Certificate Authority,O=Multi Resolution Image Technology,C=DE | | 2363493 | CN=DoD Interoperability Root CA 1,OU=PKI,OU=DoD,O=U.S. Government,C=US | | 2669148 | O=abox.el1t3.org,CN=ca | | 3348480 | CN=ORC ECA ITDev,OU=Certification Authorities,OU=ECA,O=U.S. Government,C=US | | 3494127 | CN=NPKIRootCA,O=NATO | | 3543819 | CN=Touring Club Suisse CA,O=Touring Club Suisse (TCS),L=Vernier,ST=Geneva,DC=tcsgroup,DC=ch,C=CH | | 3825106 | CN=Banka Slovenije CA Ent Sub,DC=bsi,DC=si | | 3888882 | CN=Banka Slovenije CA SA Sub,DC=bsi,DC=si | | 4877034 | CN=ICC-CPI Advanced G3 CA1,O=ICC-CPI,DC=ICC,DC=INT | | 4900138 | CN=ICC-CPI Advanced G2 CA1,O=ICC-CPI,DC=ICC,DC=INT | | 5017095 | CN=Ibridge Issuing CA01 | | 5022889 | CN=Ibridge Issuing CA01 | | 5303361 | E=asu at tyumbit.ru,CN=Asu-SubCA,O=Tyumbit-Asu,L=Tyumen,C=RU | | 5348564 | CN=Server Management,Description=Certificate Management,OU=Security & Identity Management,O=Cyssea,L=Paris,C=FR | | 5626019 | CN=DoD Interoperability Root CA 1,OU=PKI,OU=DoD,O=U.S. Government,C=US | | 5926615 | E=rd-adm at suse.de,CN=SUSE CA suse.de,OU=OPS Services,O=SUSE Linux Products GmbH,L=Nuremberg,ST=Franconia,C=DE | | 6199468 | C=US,ST=Michigan,L=Ann Arbor,O=Gizmo Labs Inc.,CN=Gizmo Labs Certificate Authority II | | 6291126 | CN=AppNexus Intermediate Server CA | | 6291127 | CN=AppNexus Root CA | | 6582872 | E=sysadmin at htl-leonding.ac.at,CN=HTL-Leonding internal servers CA,OU=EDVO,O=HTL-Leonding,ST=Upper Austria,C=AT | | 7310367 | CN=Technological Educational Institution of Thessaloniki CA R2,O=Hellenic Academic and Research Institutions Cert. Authority,C=GR | | 7310377 | CN=Hellenic Academic and Research Institutions RootCA 2011,O=Hellenic Academic and Research Institutions Cert. Authority,C=GR | | 7383682 | CN=U.S. Department of State AD Root CA,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=state,DC=sbu | | 7584472 | CN=AppNexus Intermediate Server CA | | 7761913 | CN=ATT Wi-Fi Services Root Certificate Authority G2,OU=ATT Wi-Fi Services,O=ATT Services Inc,ST=Texas,C=US | | 7763739 | CN=Intel External Basic Policy CA,O=Intel Corporation,C=US | | 8232412 | CN=DST ACES CA X6,OU=DST ACES,O=Digital Signature Trust,C=US | +---------+-----------------------------------------------------------------------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: Signature cryptographique S/MIME URL: From attilamolnar at hush.com Tue Feb 18 00:58:28 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Tue, 18 Feb 2014 00:58:28 +0100 Subject: [gnutls-devel] [RFC] srp: Add resistance against guessing usernames Message-ID: <20140217235829.09C9FA00E8@smtp.hushmail.com> Hello everyone, Currently, gnutls offers protection against attackers that attempt to guess valid SRP usernames. This functionality is desirable, but with the current implementation it is easy for a client to differentiate between valid and invalid usernames. The reason for this is that gnutls currently generates a random salt each time a user is not found, meaning that if a client attempts to authenticate with the same username multiple times and gets a different salt every time then it can assume the username is invalid. The provided patch aims to fix this by consistently generating the same salt for each invalid username based on the username and a secret seed. The seed can be set by the application, allowing it to supply a seed that it can store and reload later. The length of the generated fake salts can also be chosen by the application. The default is 16 bytes - the same as in srptool, and the limit is 20 bytes (output size of HMAC-SHA1). This can be lifted if necessary; I chose to go with it to keep the patch simple. Salts generated by applications that make use of the new API will be immune to this kind of valid username guessing. Applications not setting the seed explicitly (e.g. all old applications that are not aware of the new API) also benefit from this because an attacker has to wait until the credentials structure used is reallocated (which usually means wait until the application is restarted). Although the advantage is obviously limited in this case, it is still better than being able to connect a few times and compare the salts immediately. The patch is for master but I only managed to test it on top of 3.2. If accepted, I am going to submit another patch that adds the new functionality to gnutls-serv. Please let me know what you think. Regards, Attila From attilamolnar at hush.com Tue Feb 18 00:59:20 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Tue, 18 Feb 2014 00:59:20 +0100 Subject: [gnutls-devel] [PATCH] srp: Add resistance against guessing usernames Message-ID: <20140217235920.E1F59A00E8@smtp.hushmail.com> >From 3d05730d668d4dd5be31a93bf596be2ec1a8dcfe Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Mon, 17 Feb 2014 14:10:22 +0100 Subject: [PATCH] srp: Add resistance against guessing usernames When a client tries to authenticate using an unknown username, instead of generating a random salt every time, generate the salt based on the username and a secret seed. The seed is settable by the application, allowing servers to re-use the same seed after a restart. A random seed is generated for each newly allocated SRP server credentials structure, meaning that applications not using the new API to set the seed continue to work and gain limited advantage (because they use a different seed after every restart). For further information see section 2.5.1.3. in RFC 5054. Signed-off-by: Attila Molnar --- lib/auth/srp.h | 2 + lib/auth/srp_passwd.c | 52 ++++++++++++++++--------- lib/gnutls_srp.c | 84 +++++++++++++++++++++++++++++++++++++++-- lib/includes/gnutls/gnutls.h.in | 6 +++ lib/libgnutls.map | 1 + 5 files changed, 124 insertions(+), 21 deletions(-) diff --git a/lib/auth/srp.h b/lib/auth/srp.h index 2bfce81..c11aaac 100644 --- a/lib/auth/srp.h +++ b/lib/auth/srp.h @@ -38,6 +38,8 @@ typedef struct gnutls_srp_server_credentials_st { * password files. */ gnutls_srp_server_credentials_function *pwd_callback; + gnutls_datum_t fake_salt_seed; + unsigned int fake_salt_length; } srp_server_cred_st; /* these structures should not use allocated data */ diff --git a/lib/auth/srp_passwd.c b/lib/auth/srp_passwd.c index b25fe9f..61599ce 100644 --- a/lib/auth/srp_passwd.c +++ b/lib/auth/srp_passwd.c @@ -38,8 +38,11 @@ #include #include #include +#include -static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry); +static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry, + gnutls_srp_server_credentials_t cred, + const char * username); /* this function parses tpasswd.conf file. Format is: * string(username):base64(v):base64(salt):int(index) @@ -273,7 +276,7 @@ _gnutls_srp_pwd_read_entry(gnutls_session_t state, char *username, if (ret == 1) { /* the user does not exist */ if (entry->g.size != 0 && entry->n.size != 0) { - ret = _randomize_pwd_entry(entry); + ret = _randomize_pwd_entry(entry, cred, username); if (ret < 0) { gnutls_assert(); goto cleanup; @@ -348,7 +351,7 @@ _gnutls_srp_pwd_read_entry(gnutls_session_t state, char *username, * the last index found and randomize the entry. */ if (pwd_read_conf(cred->password_conf_file, entry, 1) == 0) { - ret = _randomize_pwd_entry(entry); + ret = _randomize_pwd_entry(entry, cred, username); if (ret < 0) { gnutls_assert(); goto cleanup; @@ -373,26 +376,23 @@ found: } /* Randomizes the given password entry. It actually sets the verifier - * and the salt. Returns 0 on success. + * to random data and sets the salt based on fake_salt_seed and + * username. Returns 0 on success. */ -static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry) +static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry, + gnutls_srp_server_credentials_t sc, + const char * username) { - unsigned char rnd; int ret; + const mac_entry_st *me = mac_to_entry(GNUTLS_MAC_SHA1); + mac_hd_st ctx; + size_t username_len = strlen(username); if (entry->g.size == 0 || entry->n.size == 0) { gnutls_assert(); return GNUTLS_E_INTERNAL_ERROR; } - ret = _gnutls_rnd(GNUTLS_RND_NONCE, &rnd, 1); - if (ret < 0) { - gnutls_assert(); - return ret; - } - - entry->salt.size = (rnd % 10) + 9; - entry->v.data = gnutls_malloc(20); entry->v.size = 20; if (entry->v.data == NULL) { @@ -406,20 +406,36 @@ static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry) return ret; } - entry->salt.data = gnutls_malloc(entry->salt.size); + /* Always allocate and work with 20 bytes even if they don't + * need salts that long, for convenience. + * + * In case an error occurs 'entry' (and the salt inside) + * is deallocated by our caller: _gnutls_srp_pwd_read_entry(). + */ + entry->salt.data = gnutls_malloc(20); if (entry->salt.data == NULL) { gnutls_assert(); return GNUTLS_E_MEMORY_ERROR; } - ret = - _gnutls_rnd(GNUTLS_RND_NONCE, entry->salt.data, - entry->salt.size); + ret = _gnutls_mac_init(&ctx, me, sc->fake_salt_seed.data, + sc->fake_salt_seed.size); + if (ret < 0) { gnutls_assert(); return ret; } + _gnutls_mac(&ctx, "salt", 4); + _gnutls_mac(&ctx, username, username_len); + _gnutls_mac_deinit(&ctx, entry->salt.data); + + /* Set length to the actual number of bytes they asked for. + * This is always <= 20 bytes, enforced by + * gnutls_srp_set_server_fake_salt_seed(). + */ + entry->salt.size = sc->fake_salt_length; + return 0; } diff --git a/lib/gnutls_srp.c b/lib/gnutls_srp.c index 1ee7473..b798898 100644 --- a/lib/gnutls_srp.c +++ b/lib/gnutls_srp.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "debug.h" @@ -489,10 +490,23 @@ void gnutls_srp_free_server_credentials(gnutls_srp_server_credentials_t sc) { gnutls_free(sc->password_file); gnutls_free(sc->password_conf_file); + _gnutls_free_datum(&sc->fake_salt_seed); gnutls_free(sc); } +/* Size of the default (random) seed if + * gnutls_srp_set_server_fake_salt_seed() is not called to set + * a seed. + */ +#define DEFAULT_FAKE_SALT_SEED_SIZE 20 + +/* Size of the fake salts generated if + * gnutls_srp_set_server_fake_salt_seed() is not called to set + * another size. + */ +#define DEFAULT_FAKE_SALT_SIZE 16 + /** * gnutls_srp_allocate_server_credentials: * @sc: is a pointer to a #gnutls_srp_server_credentials_t structure. @@ -507,12 +521,36 @@ int gnutls_srp_allocate_server_credentials(gnutls_srp_server_credentials_t * sc) { + int ret; *sc = gnutls_calloc(1, sizeof(srp_server_cred_st)); if (*sc == NULL) return GNUTLS_E_MEMORY_ERROR; + (*sc)->fake_salt_seed.size = DEFAULT_FAKE_SALT_SEED_SIZE; + (*sc)->fake_salt_seed.data = gnutls_malloc( + DEFAULT_FAKE_SALT_SEED_SIZE); + if ((*sc)->fake_salt_seed.data == NULL) { + ret = GNUTLS_E_MEMORY_ERROR; + gnutls_assert(); + goto cleanup; + } + + ret = _gnutls_rnd(GNUTLS_RND_RANDOM, (*sc)->fake_salt_seed.data, + DEFAULT_FAKE_SALT_SEED_SIZE); + + if (ret < 0) { + gnutls_assert(); + goto cleanup; + } + + (*sc)->fake_salt_length = DEFAULT_FAKE_SALT_SIZE; return 0; + +cleanup: + _gnutls_free_datum(&(*sc)->fake_salt_seed); + gnutls_free(*sc); + return ret; } /** @@ -586,13 +624,13 @@ gnutls_srp_set_server_credentials_file(gnutls_srp_server_credentials_t res, * in using the gnutls_malloc(). For convenience @prime and @generator * may also be one of the static parameters defined in gnutls.h. * - * In case the callback returned a negative number then gnutls will - * assume that the username does not exist. - * * In order to prevent attackers from guessing valid usernames, * if a user does not exist, g and n values should be filled in * using a random user's parameters. In that case the callback must * return the special value (1). + * See #gnutls_srp_set_server_fake_salt_seed too. + * If this is not required for your application, return a negative + * number from the callback to abort the handshake. * * The callback function will only be called once per handshake. * The callback function should return 0 on success, while @@ -745,4 +783,44 @@ void gnutls_srp_set_prime_bits(gnutls_session_t session, unsigned int bits) session->internals.srp_prime_bits = bits; } +/** + * gnutls_srp_set_server_fake_salt_seed: + * @cred: is a #gnutls_srp_server_credentials_t structure + * @seed: is the seed data, only needs to be valid until the function + * returns; size of the seed must be greater than zero + * @salt_length: is the length of the generated fake salts + * + * This function sets the seed that is used to generate salts for + * invalid (non-existent) usernames. + * + * In order to prevent attackers from guessing valid usernames, + * when a user does not exist gnutls generates a salt and a verifier + * and proceeds with the protocol as usual. + * The authentication will ultimately fail, but the client cannot tell + * whether the username is valid (exists) or invalid. + * + * If an attacker learns the seed, given a salt (which is part of the + * handshake) which was generated when the seed was in use, it can tell + * whether or not the authentication failed because of an unknown username. + * This seed cannot be used to reveal application data or passwords. + * + * @salt_length should represent the salt length your application uses. + * Generating fake salts longer than 20 bytes is not supported. + * + * By default the seed is a random value, different each time a + * #gnutls_srp_server_credentials_t is allocated and salts are 16 + * bytes long. + * + * Since: 3.3 + **/ +void +gnutls_srp_set_server_fake_salt_seed(gnutls_srp_server_credentials_t cred, + const gnutls_datum_t * seed, + unsigned int salt_length) +{ + _gnutls_free_datum(&cred->fake_salt_seed); + _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size); + cred->fake_salt_length = (salt_length < 20 ? salt_length : 20); +} + #endif /* ENABLE_SRP */ diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in index 485484d..151a31d 100644 --- a/lib/includes/gnutls/gnutls.h.in +++ b/lib/includes/gnutls/gnutls.h.in @@ -1679,6 +1679,12 @@ int gnutls_srp_base64_decode(const gnutls_datum_t * b64_data, char *result, int gnutls_srp_base64_decode_alloc(const gnutls_datum_t * b64_data, gnutls_datum_t * result); +void +gnutls_srp_set_server_fake_salt_seed(gnutls_srp_server_credentials_t + sc, + const gnutls_datum_t * seed, + unsigned int salt_length); + /* PSK stuff */ typedef struct gnutls_psk_server_credentials_st *gnutls_psk_server_credentials_t; diff --git a/lib/libgnutls.map b/lib/libgnutls.map index b4cdd3c..dd4bb53 100644 --- a/lib/libgnutls.map +++ b/lib/libgnutls.map @@ -952,6 +952,7 @@ GNUTLS_3_1_0 { gnutls_x509_name_constraints_get_permitted; gnutls_x509_name_constraints_get_excluded; gnutls_x509_name_constraints_check; + gnutls_srp_set_server_fake_salt_seed; } GNUTLS_3_0_0; GNUTLS_PRIVATE { -- From nmav at gnutls.org Tue Feb 18 13:30:27 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 Feb 2014 13:30:27 +0100 Subject: [gnutls-devel] SSL certificate validation bugs in GnuTLS In-Reply-To: <53029F61.8060303@delignat-lavaud.fr> References: <52F9FCE7.5080400@cs.utexas.edu> <52FB9EC6.1050807@delignat-lavaud.fr> <52FCB58A.8060506@delignat-lavaud.fr> <52FCF6B1.3060906@delignat-lavaud.fr> <52FCFEBD.3010601@fifthhorseman.net> <52FD15E3.1070909@delignat-lavaud.fr> <52FD1997.1080906@gnutls.org> <53029F61.8060303@delignat-lavaud.fr> Message-ID: On Tue, Feb 18, 2014 at 12:46 AM, Antoine Delignat-Lavaud wrote: >> I've implemented this functionality in master, but not added it in the >> verification process. >> The only certificate in my trusted root which contained this extension >> had: >> 1. Marked it as non-critical (RFC5280 requires this is critical) >> 2. DNSNames listed in the wrong format (e.g., '.com' instead of 'com'). > The CA/B forum has made an exception to allow the use of a non-critical name > constraints extension because of poor implementation support in TLS > libraries. This is also one of the reasons why CAs are reluctant to enable > name constraints - thus if you are waiting for this feature to be widely > used before implementing it, it will never see the light of day. Interesting document, but I see that they haven't restricted the profile to some reasonable options (e.g., only DNS and IP). They still allow pretty much anything to be present in such a constraint. > Also, you'll find attached a list of CA certificates found in the wild that > use name constraints. Could you send them to me? I'd be interested to see which options they support. regards, Nikos From nmav at gnutls.org Tue Feb 18 13:42:55 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 Feb 2014 13:42:55 +0100 Subject: [gnutls-devel] [RFC] srp: Add resistance against guessing usernames In-Reply-To: <20140217235829.09C9FA00E8@smtp.hushmail.com> References: <20140217235829.09C9FA00E8@smtp.hushmail.com> Message-ID: On Tue, Feb 18, 2014 at 12:58 AM, Attila Molnar wrote: > Hello everyone, > Currently, gnutls offers protection against attackers that attempt to > guess valid SRP usernames. This functionality is desirable, but with the > current implementation it is easy for a client to differentiate between > valid and invalid usernames. > The reason for this is that gnutls currently generates a random salt each > time a user is not found, meaning that if a client attempts to > authenticate with the same username multiple times and gets a different > salt every time then it can assume the username is invalid. > The provided patch aims to fix this by consistently generating the same > salt for each invalid username based on the username and a secret seed. > The seed can be set by the application, allowing it to supply a seed that > it can store and reload later. The length of the generated fake salts can > also be chosen by the application. The default is 16 bytes - the same as > in srptool, and the limit is 20 bytes (output size of HMAC-SHA1). This can > be lifted if necessary; I chose to go with it to keep the patch simple. Thanks, it's a nice feature. I wonder, whether we can avoid gnutls_srp_set_server_fake_salt_seed()... I believe most applications would not use an additional API for that. regards, Nikos From pav5088 at internode.on.net Tue Feb 18 15:49:44 2014 From: pav5088 at internode.on.net (Mark Pavlichuk) Date: Wed, 19 Feb 2014 00:49:44 +1000 Subject: [gnutls-devel] isc dhcpd compiled with GNUTLS (Debian) In-Reply-To: References: <52FB92C8.4050300@internode.on.net> <52FB99C0.1090807@internode.on.net> Message-ID: <53037308.2050309@internode.on.net> On 13/02/14 18:05, Nikos Mavrogiannopoulos wrote: > On Wed, Feb 12, 2014 at 4:56 PM, Mark Pavlichuk > wrote: >> I am experiencing a bug (in isc-dhcp-server compiled with GNUTLS and >> LDAP support on Debian) which prevents TLS encryption between dhcpd >> and the LDAP server. I tried the versions in Wheezy and Jessie >> ie. 4.2.2 and 4.2.4. The problem is related to parsing the dhcpd.conf >> file: >> Internet Systems Consortium DHCP Server 4.2.4 >> Copyright 2004-2012 Internet Systems Consortium. >> All rights reserved. >> For info, please visit https://www.isc.org/software/dhcp/ >> /etc/dhcp/dhcpd.conf line 113: semicolon expected. >> ldap-tls-crlfile "/etc/ssl/crl/ssl-cert-local-ca.crl" >> ^ > Hello Mark, > Gnutls doesn't parse files, it is simply the back-end for SSL or > crypto. You'd better report the issue to the appropriate software that > has the bug. > > regards, > Nikos > The problem seemed to be from mixing libraries (openssl /w GnuTLS) ie. the isc-dhcpd-ldap server code requires openssl, and the OpenLDAP libraries are compiled against GnuTLS. I got further by using openssl-formatted config options, but then dhcpd crashed calling a GnuTLS function. Detailed info is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723773 . I don't know enough to rewrite isc-dhcpd-ldap for GnuTLS, but I see there's a GNU/openssl compatibility layer... should I be using this? Is mixing libraries even a problem? The reason I'm asking here is the code is rather unloved, and my bug report is three months old with no upstream response. -- Mark Pavlichuk From attilamolnar at hush.com Tue Feb 18 19:02:38 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Tue, 18 Feb 2014 19:02:38 +0100 Subject: [gnutls-devel] [RFC] srp: Add resistance against guessing usernames In-Reply-To: References: <20140217235829.09C9FA00E8@smtp.hushmail.com> Message-ID: <20140218180238.F0340A00E8@smtp.hushmail.com> On Tue, Feb 18, 2014 at 1:42 PM, "Nikos Mavrogiannopoulos" wrote: >Thanks, it's a nice feature. I wonder, whether we can avoid >gnutls_srp_set_server_fake_salt_seed()... I believe most >applications would not use an additional API for that. Do you mean to avoid the new function and not have the ability to set the same seed after a restart, or to move this functionality somewhere else? If the latter, I checked the srp functions in gnutls and couldn't find one that could be modified in a way to include this feature. I have also taken a look at OpenSSL; it provides a way for programs to set the seed. Regards, Attila From nmav at gnutls.org Tue Feb 18 19:52:45 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 Feb 2014 19:52:45 +0100 Subject: [gnutls-devel] [PATCH] srp: Add resistance against guessing usernames In-Reply-To: <20140217235920.E1F59A00E8@smtp.hushmail.com> References: <20140217235920.E1F59A00E8@smtp.hushmail.com> Message-ID: <5303ABFD.1000606@gnutls.org> On 02/18/2014 12:59 AM, Attila Molnar wrote: >> Thanks, it's a nice feature. I wonder, whether we can avoid >> gnutls_srp_set_server_fake_salt_seed()... I believe most >> applications would not use an additional API for that. > > Do you mean to avoid the new function and not have the ability > to set the same seed after a restart, or to move this functionality > somewhere else? > > If the latter, I checked the srp functions in gnutls and couldn't > find one that could be modified in a way to include this feature. I couldn't think of anything better also. Anyway my only comments are: > entry->v.data = gnutls_malloc(20); > entry->v.size = 20; [...] > + _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size); > + cred->fake_salt_length = (salt_length < 20 ? salt_length : 20); Shouldn't they be DEFAULT_FAKE_SALT_SEED_SIZE? > + * Since: 3.3 s/3.3/3.3.0/ regards, Nikos From attilamolnar at hush.com Wed Feb 19 00:04:23 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Wed, 19 Feb 2014 00:04:23 +0100 Subject: [gnutls-devel] [PATCH] srp: Add resistance against guessing usernames In-Reply-To: <5303ABFD.1000606@gnutls.org> References: <20140217235920.E1F59A00E8@smtp.hushmail.com> <5303ABFD.1000606@gnutls.org> Message-ID: <20140218230424.12BEEA00E9@smtp.hushmail.com> On Tue, Feb 18, 2014 at 7:52 PM, "Nikos Mavrogiannopoulos" wrote: > >> entry->v.data = gnutls_malloc(20); >> entry->v.size = 20; > The verifier is always 20 bytes long regardless of the salt or the seed. > >> + _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed- >>size); >> + cred->fake_salt_length = (salt_length < 20 ? salt_length : 20); > >Shouldn't they be DEFAULT_FAKE_SALT_SEED_SIZE? > The 20 in this case refers to the output size of the hmac and is always the same unless hmac-sha1 is changed to something else with a different output size. Changing DEFAULT_FAKE_SALT_SEED_SIZE means changing the size of the default (random) seed that is generated for each srp server credentials upon allocation (which is used unless the program provides its own seed using gnutls_srp_set_server_fake_salt_seed()). If this is changed for some reason, we would still allow for the application to request up to 20 byte long fake salts because the hmac output size would stay the same regardless. Want me to change it anyway, or introduce a new #define for this? On a related note, we could allow applications to request longer fake salts than the output size of the hmac if we wanted to by doing more hashing: _gnutls_mac(&ctx, "salt", 4); This constant part can be modified and the operation repeated to generate arbitrarily long fake salts. >s/3.3/3.3.0/ Done. Regards, Attila From nmav at gnutls.org Wed Feb 19 07:19:18 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 19 Feb 2014 07:19:18 +0100 Subject: [gnutls-devel] [PATCH] srp: Add resistance against guessing usernames In-Reply-To: <20140218230424.12BEEA00E9@smtp.hushmail.com> References: <20140217235920.E1F59A00E8@smtp.hushmail.com> <5303ABFD.1000606@gnutls.org> <20140218230424.12BEEA00E9@smtp.hushmail.com> Message-ID: <53044CE6.8050202@gnutls.org> On 02/19/2014 12:04 AM, Attila Molnar wrote: > On Tue, Feb 18, 2014 at 7:52 PM, "Nikos Mavrogiannopoulos" wrote: >> >>> entry->v.data = gnutls_malloc(20); >>> entry->v.size = 20; > The verifier is always 20 bytes long regardless of the salt or > the seed. Ok, I see that this was set to 20 originally as well. Having a macro would be more readable though. >>> + _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed- >>> size); >>> + cred->fake_salt_length = (salt_length < 20 ? salt_length : 20); >> >> Shouldn't they be DEFAULT_FAKE_SALT_SEED_SIZE? > The 20 in this case refers to the output size of the hmac and is > always the same unless hmac-sha1 is changed to something > else with a different output size. You can get the used MAC's output size from mac_entry_st (as me->output_size). > Changing DEFAULT_FAKE_SALT_SEED_SIZE means changing the size > of the default (random) seed that is generated for each srp server > credentials upon allocation (which is used unless the program provides > its own seed using gnutls_srp_set_server_fake_salt_seed()). > If this is changed for some reason, we would still allow for the > application to request up to 20 byte long fake salts because the > hmac output size would stay the same regardless. > Want me to change it anyway, or introduce a new #define for this? I believe that adding some comment describing that would be sufficient. > On a related note, we could allow applications to request longer > fake salts than the output size of the hmac if we wanted to by > doing more hashing: > _gnutls_mac(&ctx, "salt", 4); > This constant part can be modified and the operation repeated > to generate arbitrarily long fake salts. Would there be any particular advantage on that? If not I think the best would be to keep it simple. regards, Nikos From attilamolnar at hush.com Wed Feb 19 18:45:34 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Wed, 19 Feb 2014 18:45:34 +0100 Subject: [gnutls-devel] [PATCH] srp: Add resistance against guessing usernames In-Reply-To: <53044CE6.8050202@gnutls.org> References: <20140217235920.E1F59A00E8@smtp.hushmail.com> <5303ABFD.1000606@gnutls.org> <20140218230424.12BEEA00E9@smtp.hushmail.com> <53044CE6.8050202@gnutls.org> Message-ID: <20140219174534.9708BA00E9@smtp.hushmail.com> On Wed, Feb 19 at 7:19 AM, "Nikos Mavrogiannopoulos" wrote: > >On 02/19/2014 12:04 AM, Attila Molnar wrote: >> On Tue, Feb 18, 2014 at 7:52 PM, "Nikos Mavrogiannopoulos" > wrote: >>> >>>> entry->v.data = gnutls_malloc(20); >>>> entry->v.size = 20; >> The verifier is always 20 bytes long regardless of the salt or >> the seed. > >Ok, I see that this was set to 20 originally as well. Having a >macro >would be more readable though. Agree, I will address this in a new patch. >>>> + _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed- >>>> size); >>>> + cred->fake_salt_length = (salt_length < 20 ? salt_length : >20); >>> >>> Shouldn't they be DEFAULT_FAKE_SALT_SEED_SIZE? >> The 20 in this case refers to the output size of the hmac and is >> always the same unless hmac-sha1 is changed to something >> else with a different output size. > >You can get the used MAC's output size from mac_entry_st (as >me->output_size). Makes sense, changed it. Also added a SRP_FAKE_SALT_MAC macro which is defined as GNUTLS_MAC_SHA1 and changed both places to use it. >> Changing DEFAULT_FAKE_SALT_SEED_SIZE means changing the size >> of the default (random) seed that is generated for each srp >server >> credentials upon allocation (which is used unless the program >provides >> its own seed using gnutls_srp_set_server_fake_salt_seed()). >> If this is changed for some reason, we would still allow for the >> application to request up to 20 byte long fake salts because the >> hmac output size would stay the same regardless. >> Want me to change it anyway, or introduce a new #define for this? > >I believe that adding some comment describing that would be >sufficient. Done. >> On a related note, we could allow applications to request longer >> fake salts than the output size of the hmac if we wanted to by >> doing more hashing: >> _gnutls_mac(&ctx, "salt", 4); >> This constant part can be modified and the operation repeated >> to generate arbitrarily long fake salts. > >Would there be any particular advantage on that? If not I think >the best >would be to keep it simple. Now programs are allowed to use long salts (e.g. 40 bytes) in gnutls_srp_verifier() etc. If a program happens to use salts longer than 20 bytes we won't generate credible fake salts - all fake salts will be 20 bytes; the real salts are longer, making it easy to differentiate between real and fake. This case would be solved by not limiting the fake salt length to the output size of the hmac. Programs would be able to use long real salts and get credible fake salts. In other words, gnutls would be more consistent: if programs are allowed to use 40 byte salts -> programs are also able to request 40 byte fake salts. Even though I do not see benefits in using salts that long, gnutls allows them and having a consensus among functions is generally a good thing. I agree that the best thing for now is to keep it simple, but I wanted to explain the "_gnutls_mac(&ctx, "salt", 4);" step anyway. I will submit the revised patch later today after I get a chance to test it with the changes applied. Regards, Attila From attilamolnar at hush.com Thu Feb 20 06:28:12 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Thu, 20 Feb 2014 06:28:12 +0100 Subject: [gnutls-devel] =?utf-8?q?=5BPATCH=5D_srp=3A_Add_resistance_agains?= =?utf-8?q?t_guessing=09usernames?= In-Reply-To: <20140219174534.9708BA00E9@smtp.hushmail.com> References: <20140217235920.E1F59A00E8@smtp.hushmail.com> <5303ABFD.1000606@gnutls.org> <20140218230424.12BEEA00E9@smtp.hushmail.com> <53044CE6.8050202@gnutls.org> <20140219174534.9708BA00E9@smtp.hushmail.com> Message-ID: <20140220052812.BFC69A00E9@smtp.hushmail.com> >From aa892147f5da4868613a6accf2a5f93a484b4d20 Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Mon, 17 Feb 2014 14:10:22 +0100 Subject: [PATCH] srp: Add resistance against guessing usernames When a client tries to authenticate using an unknown username, instead of generating a random salt every time, generate the salt based on the username and a secret seed. The seed is settable by the application, allowing servers to re-use the same seed after a restart. A random seed is generated for each newly allocated SRP server credentials structure, meaning that applications not using the new API to set the seed continue to work and gain limited advantage (because they use a different seed after every restart). For further information see section 2.5.1.3. in RFC 5054. Signed-off-by: Attila Molnar --- lib/auth/srp.h | 6 +++ lib/auth/srp_passwd.c | 52 +++++++++++++++-------- lib/gnutls_srp.c | 91 +++++++++++++++++++++++++++++++++++++++-- lib/includes/gnutls/gnutls.h.in | 6 +++ lib/libgnutls.map | 1 + 5 files changed, 135 insertions(+), 21 deletions(-) diff --git a/lib/auth/srp.h b/lib/auth/srp.h index 2bfce81..63b9de2 100644 --- a/lib/auth/srp.h +++ b/lib/auth/srp.h @@ -38,6 +38,8 @@ typedef struct gnutls_srp_server_credentials_st { * password files. */ gnutls_srp_server_credentials_function *pwd_callback; + gnutls_datum_t fake_salt_seed; + unsigned int fake_salt_length; } srp_server_cred_st; /* these structures should not use allocated data */ @@ -60,6 +62,10 @@ int _gnutls_proc_srp_client_kx(gnutls_session_t, uint8_t *, size_t); typedef struct srp_server_auth_info_st srp_server_auth_info_st; +/* MAC algorithm used to generate fake salts for unknown usernames + */ +#define SRP_FAKE_SALT_MAC GNUTLS_MAC_SHA1 + #endif /* ENABLE_SRP */ #endif diff --git a/lib/auth/srp_passwd.c b/lib/auth/srp_passwd.c index b25fe9f..5572dc9 100644 --- a/lib/auth/srp_passwd.c +++ b/lib/auth/srp_passwd.c @@ -38,8 +38,11 @@ #include #include #include +#include -static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry); +static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry, + gnutls_srp_server_credentials_t cred, + const char * username); /* this function parses tpasswd.conf file. Format is: * string(username):base64(v):base64(salt):int(index) @@ -273,7 +276,7 @@ _gnutls_srp_pwd_read_entry(gnutls_session_t state, char *username, if (ret == 1) { /* the user does not exist */ if (entry->g.size != 0 && entry->n.size != 0) { - ret = _randomize_pwd_entry(entry); + ret = _randomize_pwd_entry(entry, cred, username); if (ret < 0) { gnutls_assert(); goto cleanup; @@ -348,7 +351,7 @@ _gnutls_srp_pwd_read_entry(gnutls_session_t state, char *username, * the last index found and randomize the entry. */ if (pwd_read_conf(cred->password_conf_file, entry, 1) == 0) { - ret = _randomize_pwd_entry(entry); + ret = _randomize_pwd_entry(entry, cred, username); if (ret < 0) { gnutls_assert(); goto cleanup; @@ -373,26 +376,23 @@ found: } /* Randomizes the given password entry. It actually sets the verifier - * and the salt. Returns 0 on success. + * to random data and sets the salt based on fake_salt_seed and + * username. Returns 0 on success. */ -static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry) +static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry, + gnutls_srp_server_credentials_t sc, + const char * username) { - unsigned char rnd; int ret; + const mac_entry_st *me = mac_to_entry(SRP_FAKE_SALT_MAC); + mac_hd_st ctx; + size_t username_len = strlen(username); if (entry->g.size == 0 || entry->n.size == 0) { gnutls_assert(); return GNUTLS_E_INTERNAL_ERROR; } - ret = _gnutls_rnd(GNUTLS_RND_NONCE, &rnd, 1); - if (ret < 0) { - gnutls_assert(); - return ret; - } - - entry->salt.size = (rnd % 10) + 9; - entry->v.data = gnutls_malloc(20); entry->v.size = 20; if (entry->v.data == NULL) { @@ -406,20 +406,36 @@ static int _randomize_pwd_entry(SRP_PWD_ENTRY * entry) return ret; } - entry->salt.data = gnutls_malloc(entry->salt.size); + /* Always allocate and work with the output size of the MAC, + * even if they don't need salts that long, for convenience. + * + * In case an error occurs 'entry' (and the salt inside) + * is deallocated by our caller: _gnutls_srp_pwd_read_entry(). + */ + entry->salt.data = gnutls_malloc(me->output_size); if (entry->salt.data == NULL) { gnutls_assert(); return GNUTLS_E_MEMORY_ERROR; } - ret = - _gnutls_rnd(GNUTLS_RND_NONCE, entry->salt.data, - entry->salt.size); + ret = _gnutls_mac_init(&ctx, me, sc->fake_salt_seed.data, + sc->fake_salt_seed.size); + if (ret < 0) { gnutls_assert(); return ret; } + _gnutls_mac(&ctx, "salt", 4); + _gnutls_mac(&ctx, username, username_len); + _gnutls_mac_deinit(&ctx, entry->salt.data); + + /* Set length to the actual number of bytes they asked for. + * This is always less than or equal to the output size of + * the MAC, enforced by gnutls_srp_set_server_fake_salt_seed(). + */ + entry->salt.size = sc->fake_salt_length; + return 0; } diff --git a/lib/gnutls_srp.c b/lib/gnutls_srp.c index 1ee7473..8b5bbc3 100644 --- a/lib/gnutls_srp.c +++ b/lib/gnutls_srp.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "debug.h" @@ -489,10 +490,23 @@ void gnutls_srp_free_server_credentials(gnutls_srp_server_credentials_t sc) { gnutls_free(sc->password_file); gnutls_free(sc->password_conf_file); + _gnutls_free_datum(&sc->fake_salt_seed); gnutls_free(sc); } +/* Size of the default (random) seed if + * gnutls_srp_set_server_fake_salt_seed() is not called to set + * a seed. + */ +#define DEFAULT_FAKE_SALT_SEED_SIZE 20 + +/* Size of the fake salts generated if + * gnutls_srp_set_server_fake_salt_seed() is not called to set + * another size. + */ +#define DEFAULT_FAKE_SALT_SIZE 16 + /** * gnutls_srp_allocate_server_credentials: * @sc: is a pointer to a #gnutls_srp_server_credentials_t structure. @@ -507,12 +521,36 @@ int gnutls_srp_allocate_server_credentials(gnutls_srp_server_credentials_t * sc) { + int ret; *sc = gnutls_calloc(1, sizeof(srp_server_cred_st)); if (*sc == NULL) return GNUTLS_E_MEMORY_ERROR; + (*sc)->fake_salt_seed.size = DEFAULT_FAKE_SALT_SEED_SIZE; + (*sc)->fake_salt_seed.data = gnutls_malloc( + DEFAULT_FAKE_SALT_SEED_SIZE); + if ((*sc)->fake_salt_seed.data == NULL) { + ret = GNUTLS_E_MEMORY_ERROR; + gnutls_assert(); + goto cleanup; + } + + ret = _gnutls_rnd(GNUTLS_RND_RANDOM, (*sc)->fake_salt_seed.data, + DEFAULT_FAKE_SALT_SEED_SIZE); + + if (ret < 0) { + gnutls_assert(); + goto cleanup; + } + + (*sc)->fake_salt_length = DEFAULT_FAKE_SALT_SIZE; return 0; + +cleanup: + _gnutls_free_datum(&(*sc)->fake_salt_seed); + gnutls_free(*sc); + return ret; } /** @@ -586,13 +624,13 @@ gnutls_srp_set_server_credentials_file(gnutls_srp_server_credentials_t res, * in using the gnutls_malloc(). For convenience @prime and @generator * may also be one of the static parameters defined in gnutls.h. * - * In case the callback returned a negative number then gnutls will - * assume that the username does not exist. - * * In order to prevent attackers from guessing valid usernames, * if a user does not exist, g and n values should be filled in * using a random user's parameters. In that case the callback must * return the special value (1). + * See #gnutls_srp_set_server_fake_salt_seed too. + * If this is not required for your application, return a negative + * number from the callback to abort the handshake. * * The callback function will only be called once per handshake. * The callback function should return 0 on success, while @@ -745,4 +783,51 @@ void gnutls_srp_set_prime_bits(gnutls_session_t session, unsigned int bits) session->internals.srp_prime_bits = bits; } +/** + * gnutls_srp_set_server_fake_salt_seed: + * @cred: is a #gnutls_srp_server_credentials_t structure + * @seed: is the seed data, only needs to be valid until the function + * returns; size of the seed must be greater than zero + * @salt_length: is the length of the generated fake salts + * + * This function sets the seed that is used to generate salts for + * invalid (non-existent) usernames. + * + * In order to prevent attackers from guessing valid usernames, + * when a user does not exist gnutls generates a salt and a verifier + * and proceeds with the protocol as usual. + * The authentication will ultimately fail, but the client cannot tell + * whether the username is valid (exists) or invalid. + * + * If an attacker learns the seed, given a salt (which is part of the + * handshake) which was generated when the seed was in use, it can tell + * whether or not the authentication failed because of an unknown username. + * This seed cannot be used to reveal application data or passwords. + * + * @salt_length should represent the salt length your application uses. + * Generating fake salts longer than 20 bytes is not supported. + * + * By default the seed is a random value, different each time a + * #gnutls_srp_server_credentials_t is allocated and fake salts are + * 16 bytes long. + * + * Since: 3.3.0 + **/ +void +gnutls_srp_set_server_fake_salt_seed(gnutls_srp_server_credentials_t cred, + const gnutls_datum_t * seed, + unsigned int salt_length) +{ + _gnutls_free_datum(&cred->fake_salt_seed); + _gnutls_set_datum(&cred->fake_salt_seed, seed->data, seed->size); + + /* Cap the salt length at the output size of the MAC algorithm + * we are using to generate the fake salts. + */ + const mac_entry_st * me = mac_to_entry(SRP_FAKE_SALT_MAC); + const size_t mac_len = me->output_size; + + cred->fake_salt_length = (salt_length < mac_len ? salt_length : mac_len); +} + #endif /* ENABLE_SRP */ diff --git a/lib/includes/gnutls/gnutls.h.in b/lib/includes/gnutls/gnutls.h.in index 485484d..151a31d 100644 --- a/lib/includes/gnutls/gnutls.h.in +++ b/lib/includes/gnutls/gnutls.h.in @@ -1679,6 +1679,12 @@ int gnutls_srp_base64_decode(const gnutls_datum_t * b64_data, char *result, int gnutls_srp_base64_decode_alloc(const gnutls_datum_t * b64_data, gnutls_datum_t * result); +void +gnutls_srp_set_server_fake_salt_seed(gnutls_srp_server_credentials_t + sc, + const gnutls_datum_t * seed, + unsigned int salt_length); + /* PSK stuff */ typedef struct gnutls_psk_server_credentials_st *gnutls_psk_server_credentials_t; diff --git a/lib/libgnutls.map b/lib/libgnutls.map index c92d6db..9f24a6e 100644 --- a/lib/libgnutls.map +++ b/lib/libgnutls.map @@ -953,6 +953,7 @@ GNUTLS_3_1_0 { gnutls_x509_name_constraints_get_excluded; gnutls_x509_name_constraints_check; gnutls_x509_name_constraints_check_crt; + gnutls_srp_set_server_fake_salt_seed; } GNUTLS_3_0_0; GNUTLS_PRIVATE { -- 1.8.5.3 From nmav at gnutls.org Thu Feb 20 09:34:39 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 20 Feb 2014 09:34:39 +0100 Subject: [gnutls-devel] [PATCH] srp: Add resistance against guessing usernames In-Reply-To: <20140220052812.BFC69A00E9@smtp.hushmail.com> References: <20140217235920.E1F59A00E8@smtp.hushmail.com> <5303ABFD.1000606@gnutls.org> <20140218230424.12BEEA00E9@smtp.hushmail.com> <53044CE6.8050202@gnutls.org> <20140219174534.9708BA00E9@smtp.hushmail.com> <20140220052812.BFC69A00E9@smtp.hushmail.com> Message-ID: On Thu, Feb 20, 2014 at 6:28 AM, Attila Molnar wrote: > From aa892147f5da4868613a6accf2a5f93a484b4d20 Mon Sep 17 00:00:00 2001 > From: Attila Molnar > Date: Mon, 17 Feb 2014 14:10:22 +0100 > Subject: [PATCH] srp: Add resistance against guessing usernames > When a client tries to authenticate using an unknown username, instead of > generating a random salt every time, generate the salt based on the > username and a secret seed. Thank you, applied! From nmav at gnutls.org Fri Feb 21 10:24:38 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 21 Feb 2014 10:24:38 +0100 Subject: [gnutls-devel] isc dhcpd compiled with GNUTLS (Debian) In-Reply-To: <53037308.2050309@internode.on.net> References: <52FB92C8.4050300@internode.on.net> <52FB99C0.1090807@internode.on.net> <53037308.2050309@internode.on.net> Message-ID: On Tue, Feb 18, 2014 at 3:49 PM, Mark Pavlichuk wrote: > The problem seemed to be from mixing libraries (openssl /w GnuTLS) ie. the > isc-dhcpd-ldap server code requires openssl, and the OpenLDAP libraries are > compiled against GnuTLS. I got further by using openssl-formatted config > options, but then dhcpd crashed calling a GnuTLS function. Detailed info is > here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723773 . I don't know how isc-dhcpd-ldap and libldap interact, but in general there is no issue with mixing gnutls and openssl libraries. You'd better bring the bug up to the authors of these libraries as the issue doesn't seem to be in openssl or gnutls. regards, Nikos From dennis.philipps at gmail.com Fri Feb 21 19:01:00 2014 From: dennis.philipps at gmail.com (Dennis Philipps) Date: Fri, 21 Feb 2014 19:01:00 +0100 Subject: [gnutls-devel] GnuTLS duplicate symbols In-Reply-To: References: Message-ID: Hi Nikos, sorry for the late reply. I didn't have a chance to test the GIT version as up until now. But as I am now observing a SEGFAULT in the ASN1 parser during client handshake (communicating with a server that runs the same GnuTLS version and works fine with CURL, Chrome, etc....) I was considering to checkout the GIT version and to build GnuTLS to see if this fixes the broken situation. I observed: rnd-common.c:174: error: redefinition of typedef 'get_entropy_func' I removed the definition from the .c translation unit, as it redefined it from rnd-common.h. This worked. However: rm -f en at boldquot.gmo && /opt/local/bin/msgfmt -c --statistics --verbose -o en at boldquot.gmo en at boldquot.po en at boldquot.po:47: 'msgid' and 'msgstr' entries do not both end with '\n' (last line is repeated 228 times for like every third or fourth line in that file) - ends with: /opt/local/bin/msgfmt: found 228 fatal errors Well, this is no wonder if you look at it (including the en at quot.po). Some automation thing has obviously broken these files. I just removed every \n from the strings to get further. But not very much: /bin/true no such file or directory (I am using OS X 10.7.5)... but I just placed a bash script "return 0" there with a chmod+x No rule to make target `srptool-args.h', needed by `all'. I followed the steps from the GnuTLS web page: http://gnutls.org/devel.html using 'make autoreconf' No luck :( If I was more versed with the autotools suite I would look into that aswell but I can't invest that much time into autotools atm ;) Well. So much for testing whether your previous bugfix worked. I hope this report helps you a bit. // Dennis 2014-02-03 22:26 GMT+01:00 Dennis Philipps : > Hello, > > the GnuTLS library since 3.2.x seems to have an issue on the X86 > accelerated code-base. The files > > lib/accelerated/aes-cbc-x86-aesni.c > lib/accelerated/aes-cbc-x86-ssse3.c > > both define the symbol > > unsigned int _gnutls_x86_cpuid_s[4]; > > which results in the duplicate symbols linker error. I assume this is a > copy/paste/typo something bug. Linking works fine with 3.1.20 (latest 3.1.x > version as it seems). I patched the files locally and the linking was okay. > I built on Mac OS X 10.7 but this should probably be found on any x86 > accelerated build as this is not an issue within the assembler code. > > > Regards > > Dennis Philipps > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Feb 21 22:01:54 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 21 Feb 2014 22:01:54 +0100 Subject: [gnutls-devel] GnuTLS duplicate symbols In-Reply-To: References: Message-ID: <5307BEC2.1020309@gnutls.org> On 02/21/2014 07:01 PM, Dennis Philipps wrote: > Hi Nikos, > > sorry for the late reply. I didn't have a chance to test the GIT version > as up until now. But as I am now observing a SEGFAULT in the ASN1 parser > during client handshake (communicating with a server that runs the same > GnuTLS version and works fine with CURL, Chrome, etc....) I was > considering to checkout the GIT version and to build GnuTLS to see if > this fixes the broken situation. I'd suggest to provide some traces of the crash with valgrind (or some way for me to reproduce it). > I observed > rnd-common.c:174: error: redefinition of typedef 'get_entropy_func' Thanks. I've committed a fix. > rm -f en at boldquot.gmo && /opt/local/bin/msgfmt -c --statistics --verbose > -o en at boldquot.gmo en at boldquot.po > en at boldquot.po:47: 'msgid' and 'msgstr' entries do not both end with '\n' > (last line is repeated 228 times for like every third or fourth line in > that file) - ends with: > /opt/local/bin/msgfmt: found 228 fatal errors No idea what could be there. It may be some old gettext or anything. > /bin/true > no such file or directory (I am using OS X 10.7.5)... but I just placed > a bash script "return 0" there with a chmod+x > No rule to make target `srptool-args.h', needed by `all'. You'll need to have autogen (and libopts) to build from git unfortunately. > No luck :( If I was more versed with the autotools suite I would look > into that aswell but I can't invest that much time into autotools atm ;) > Well. So much for testing whether your previous bugfix worked. I hope > this report helps you a bit. Maybe the best would be to get the latest release and replace the files you'd be interested at? (or apply the patches that you think they fix the issue). regards, Nikos From jens.lechtenboerger at fsfe.org Sat Feb 22 18:43:17 2014 From: jens.lechtenboerger at fsfe.org (Jens Lechtenboerger) Date: Sat, 22 Feb 2014 18:43:17 +0100 Subject: [gnutls-devel] [PATCH] New option --stricttofu for gnutls-cli Message-ID: <86eh2voxfu.fsf@PC.i-did-not-set--mail-host-address--so-tickle-me> With option --tofu, gnutls-cli waits with a yes-no-question upon certificate changes. I added the option --stricttofu that omits the question and fails instead. The contribution is in accordance to the "Developer's Certificate of Origin" as found in the file doc/DCO.txt. Best wishes Jens Signed-off-by: Jens Lechtenb?rger --- src/cli-args.def | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/src/cli-args.def b/src/cli-args.def index 6f9c722..db69a0d 100644 --- a/src/cli-args.def +++ b/src/cli-args.def @@ -21,6 +21,14 @@ flag = { }; flag = { + name = stricttofu; + descrip = "Fail to connect if a known certificate has changed"; + disabled; + disable = "no"; + doc = "This option will perform authentication as with option --tofu; however, while --tofu asks whether to trust a changed certificate, this option will fail in case of certificate changes."; +}; + +flag = { name = dane; descrip = "Enable DANE certificate verification (DNSSEC)"; disabled; @@ -421,4 +429,3 @@ $ gnutls-cli www.example.com --x509keyfile $MYKEY --x509certfile MYCERT Notice that the private key only differs from the certificate in the object-type. _EOF_; }; - -- 1.7.1 Signed-off-by: Jens Lechtenb?rger --- src/cli.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/src/cli.c b/src/cli.c index 68004aa..2c78e93 100644 --- a/src/cli.c +++ b/src/cli.c @@ -421,6 +421,11 @@ static int cert_verify_callback(gnutls_session_t session) int rc; unsigned int status = 0; int ssh = ENABLED_OPT(TOFU); + int strictssh = ENABLED_OPT(STRICTTOFU); + if (strictssh) { + ssh = strictssh; + } + #ifdef HAVE_DANE int dane = ENABLED_OPT(DANE); #endif @@ -490,10 +495,13 @@ static int cert_verify_callback(gnutls_session_t session) "Its certificate is valid for %s.\n", hostname); - rc = read_yesno - ("Do you trust the received key? (y/N): "); - if (rc == 0) - return -1; + if (strictssh == 0) { + rc = read_yesno + ("Do you trust the received key? (y/N): "); + if (rc == 0) + return -1; + } else return -1; + } else if (rc < 0) { fprintf(stderr, "gnutls_verify_stored_pubkey: %s\n", -- 1.7.1 From nmav at gnutls.org Sun Feb 23 08:30:57 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 23 Feb 2014 08:30:57 +0100 Subject: [gnutls-devel] [PATCH] New option --stricttofu for gnutls-cli In-Reply-To: <86eh2voxfu.fsf@PC.i-did-not-set--mail-host-address--so-tickle-me> References: <86eh2voxfu.fsf@PC.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <5309A3B1.9090805@gnutls.org> On 02/22/2014 06:43 PM, Jens Lechtenboerger wrote: > With option --tofu, gnutls-cli waits with a yes-no-question upon > certificate changes. I added the option --stricttofu that omits the > question and fails instead. > > The contribution is in accordance to the "Developer's Certificate of > Origin" as found in the file doc/DCO.txt. Applied, thank you. I've only tweaked the name to strict-tofu. regards, Nikos From nmav at gnutls.org Fri Feb 28 21:32:14 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 Feb 2014 21:32:14 +0100 Subject: [gnutls-devel] dane - limited usability die to (indirect) OpenSSL dependency In-Reply-To: <1388241258.14170.10.camel@aspire.lan> References: <20131228135512.GB3225@downhill.g.la> <1388241258.14170.10.camel@aspire.lan> Message-ID: <5310F24E.4010900@gnutls.org> On 12/28/2013 03:34 PM, Nikos Mavrogiannopoulos wrote: >> [1] I am aware that there are divided opinions on this subject. e.g. >> Fedora uses the system library exeption clause for OpenSSL. >> >> But e.g. Debian has always tried to not ship GPL software linked >> against OpenSSL and although this might change would not count on it. > I understand Debian's approach but I cannot think of anything I could do > in gnutls-dane to solve that. While I'd be happy to drop unbound and use > another library for dnssec resolving, I know of no other alternatives. I realized that dnsmasq uses nettle to provide dnssec support. If someone could make a small library out of it, we could simply switch to it from unbound. regards, Nikos