From mail at lechevalier.se Mon Feb 3 23:56:12 2014 From: mail at lechevalier.se (A L) Date: Mon, 03 Feb 2014 23:56:12 +0100 Subject: [gnutls-help] No password prompt with csr generation when input is an encrypted pkcs8 key Message-ID: <52F01E8C.4050409@lechevalier.se> I am trying to automate some of the key generation and request operations with certtool (gnutls 3.2.9). Normally omitting the --password from command line makes certtool prompt the user for a password, which is perfect in my shell scripts. --- # certtool --generate-privkey --rsa --pkcs8 --outfile example.com-privkey.pk8 Generating a 2432 bit RSA private key... Enter password: --- It seems that when generating a CSR from an encrypted key, this does not happen. --- #certtool --generate-request --load-privkey example.com-privkey.pk8 \ --template example.com.cfg --outfile example.com-pubkey.csr Generating a PKCS #10 certificate request... importing --load-privkey: example.com-privkey.pk8: Decryption has failed. --- Is it possible to make certtool prompt for the password to decrypt the pkcs8 file? Or is it possible to have certtool reading the password from a file descriptor or a named pipe? If not, it presents some problems. I can either add the password=secret to template.cfg or use the --password command line. Both seems very insecure. Third option is to store the plaintext key as example.com-privkey.pem, which can't be a good alternative either. ~A From swbrown at variadic.org Wed Feb 5 08:15:55 2014 From: swbrown at variadic.org (Steven Brown) Date: Tue, 04 Feb 2014 23:15:55 -0800 Subject: [gnutls-help] Lightweight authentication of worker connections Message-ID: <52F1E52B.7090902@variadic.org> I'm building a program where I have a control connection to a remote service that establishes a form of session and manages it and then several other worker connections for that session over its lifetime. I'd like to use a lightweight authentication scheme on the worker connections if possible as they frequently come and go and there can be many of them. I figure it should be possible for the control connection to establish the authentication information necessary for the workers but I'm not sure how best to go about it, hence this question. >From what I've read, I'm planning on SRP for the control connection and PSK for the worker connections. If I'm understanding things correctly, PSK should be lightweight. I can generate a random key when I create the client's session and share it over SRP for use with PSK, but doesn't SRP generate a session key as part of its negotiation? If so, is there a way (and does it make sense) to use SRP's session key to do PSK authentication of the workers? From nmav at gnutls.org Wed Feb 5 09:59:55 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Feb 2014 09:59:55 +0100 Subject: [gnutls-help] Lightweight authentication of worker connections In-Reply-To: <52F1E52B.7090902@variadic.org> References: <52F1E52B.7090902@variadic.org> Message-ID: On Wed, Feb 5, 2014 at 8:15 AM, Steven Brown wrote: > I'm building a program where I have a control connection to a remote > service that establishes a form of session and manages it and then > several other worker connections for that session over its lifetime. > I'd like to use a lightweight authentication scheme on the worker > connections if possible as they frequently come and go and there can be > many of them. I figure it should be possible for the control connection > to establish the authentication information necessary for the workers > but I'm not sure how best to go about it, hence this question. > From what I've read, I'm planning on SRP for the control connection and > PSK for the worker connections. If I'm understanding things correctly, > PSK should be lightweight. I can generate a random key when I create > the client's session and share it over SRP for use with PSK, but doesn't > SRP generate a session key as part of its negotiation? If so, is there > a way (and does it make sense) to use SRP's session key to do PSK > authentication of the workers? The best is to use a different key that can be derived from the initial session parameters. You can do that using the gnutls_prf() function. http://gnutls.org/manual/html_node/Deriving-keys-for-other-applications_002fprotocols.html#Deriving-keys-for-other-applications_002fprotocols regards, Nikos From nmav at gnutls.org Wed Feb 5 10:16:34 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Feb 2014 10:16:34 +0100 Subject: [gnutls-help] No password prompt with csr generation when input is an encrypted pkcs8 key In-Reply-To: <52F01E8C.4050409@lechevalier.se> References: <52F01E8C.4050409@lechevalier.se> Message-ID: On Mon, Feb 3, 2014 at 11:56 PM, A L wrote: > I am trying to automate some of the key generation and request > operations with certtool (gnutls 3.2.9). > Normally omitting the --password from command line makes certtool prompt > the user for a password, which is perfect in my shell scripts. > It seems that when generating a CSR from an encrypted key, this does not > happen. Indeed, when the --template option is specified certtool goes to non-interactive mode and will not ask for anything. There could be some option --ask-pass to allow interaction for passwords during key generation. I'll try adding that. regards, Nikos From mail at lechevalier.se Wed Feb 5 18:02:45 2014 From: mail at lechevalier.se (A L) Date: Wed, 05 Feb 2014 18:02:45 +0100 Subject: [gnutls-help] No password prompt with csr generation when input is an encrypted pkcs8 key In-Reply-To: References: <52F01E8C.4050409@lechevalier.se> Message-ID: <52F26EB5.6010505@lechevalier.se> On 2014-02-05 10:16, Nikos Mavrogiannopoulos wrote: > On Mon, Feb 3, 2014 at 11:56 PM, A L wrote: >> I am trying to automate some of the key generation and request >> operations with certtool (gnutls 3.2.9). >> Normally omitting the --password from command line makes certtool prompt >> the user for a password, which is perfect in my shell scripts. >> It seems that when generating a CSR from an encrypted key, this does not >> happen. > Indeed, when the --template option is specified certtool goes to > non-interactive mode and will not ask for anything. There could be > some option --ask-pass to allow interaction for passwords during key > generation. I'll try adding that. This sounds like a good option. Dealing with passwords in shell scripting is not very secure in any circomstance. Perhaps some option to use 'pinentry' might be useful. I will double check later, but I thought I tested supplying password inside the template.cfg, but the 'password' option was not used for CSR tasks. Thanks. ~A From lxr1234 at hotmail.com Mon Feb 3 10:30:29 2014 From: lxr1234 at hotmail.com (Randy Li) Date: Mon, 3 Feb 2014 17:30:29 +0800 Subject: [gnutls-help] use certtool to manage a own CA Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I use openssl to create and verify the certificate before, now I want to switch to gnutls. I find that it seems that certtool won't record the verified certificats and update the serial number or crl number like openssl. So I have to do that in hand? ayaka -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJS72G0AAoJEPb4VsMIzTziebwH/3IUHodCtaVC6H4DELnFqN6a kvGDi9EjSwzLa18p14PqlSKifab+qeDiQnXV69Vf5xkeOTwM8rL75etdp19jjt3N Bm4bJxqXywgpNSN76Q26LGeT7mm2+iT7eJiT3XxCWtEUOS8Nh+7JkLaRoMTs485k SWS4eoGJcu0v2S35Bd+OYQHmLGE7i1tF9qoC6q2d8E/CSB4TnWp/lGKISwNlFKv2 mImXSGRo+wc6AfVd9AVcj2oVWi9tXdMMyUdgKgNQFZhm9wiM57YkXq17GQ/Bh2WX 6cQHFIUPLWIab51ay8MswF8O3AgcFqURC9Pbx9sM8p/Tmwdi/bzvqMqa9fp2iY0= =KtBB -----END PGP SIGNATURE----- From tzz at lifelogs.com Mon Feb 10 00:22:26 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Sun, 09 Feb 2014 18:22:26 -0500 Subject: [gnutls-help] gnutls_dh_set_prime_bits question References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> Message-ID: <87sirran2l.fsf@lifelogs.com> On Fri, 03 Jan 2014 21:54:39 +0100 Nikos Mavrogiannopoulos wrote: NM> On 01/03/2014 09:29 PM, Ted Zlatanov wrote: >> On Sun, 22 Dec 2013 09:05:12 +0100 Nikos Mavrogiannopoulos wrote: >> >>>> I was about to submit a patch against the manual based on this e-mail >>>> from July and wanted to quickly check if the answers to (1), (2), (3) >>>> have changed (since I know there have been some issues with EC since >>>> then). I wrote a patch that tries to list all the things enabled for each level and mentions how to disable DHE. It could use a thorough check. I did a lot of text editing by hand because the command `gnutls-cli -l --priority NORMAL' doesn't seem to differ from `gnutls-cli -l', so there's no way to tell what a priority string triggers AFAICT except by looking at the code. NM> What issues are you referring to? >> >> I did not mean "some issues with EC" to mean GnuTLS specifically, >> sorry if that was unclear. >> >> I meant the backdoor in http://en.wikipedia.org/wiki/Dual_EC_DRBG and >> AFAIK it doesn't affect GnuTLS, but I would expect users to be somewhat >> paranoid about anything with "EC" in the name. So we could amend the >> answers to preempt the possible EC-related questions. It's up to you if >> you feel that's necessary. NM> Indeed, I noticed that confusion too on various forums. For that topic NM> it may be nice to have an answer in: NM> http://www.gnutls.org/faq.html NM> For modifying that you may want to check the web-pages branch of the NM> gnutls repository. I hope the answer in the patch attached here is not *too* brief :) Thanks, and sorry for the delay with this... Ted -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-doc.patch Type: text/x-diff Size: 66623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-faq.patch Type: text/x-diff Size: 488 bytes Desc: not available URL: From tzz at lifelogs.com Mon Feb 10 17:51:29 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Mon, 10 Feb 2014 11:51:29 -0500 Subject: [gnutls-help] gnutls_dh_set_prime_bits question References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> <87sirran2l.fsf@lifelogs.com> Message-ID: <87bnye7vxq.fsf@lifelogs.com> I didn't see that somehow build-aux/config.rpath got included in the patch, which was already pretty long. Sorry about that. Ted From mail at lechevalier.se Mon Feb 10 19:47:30 2014 From: mail at lechevalier.se (A L) Date: Mon, 10 Feb 2014 19:47:30 +0100 Subject: [gnutls-help] use certtool to manage a own CA In-Reply-To: References: Message-ID: <52F91EC2.2090508@lechevalier.se> I believe you specify this in the template.cfg (http://gnutls.org/manual/html_node/certtool-Invocation.html at the bottom of the page) serial = 001 crl_number = 1 If you omit the serial option, a time based serial will be generated. Do you need anything else than a random number? For CRLs, it should be easy enough to script or handle manually. Doesn't OpenSSL handle this in a psuedo-scripted way anyway with CA.pl or CA.sh ? Anyway you can use -set_serial or -CAcreateserial ~A On 2014-02-03 10:30, Randy Li wrote: > > Hello, > I use openssl to create and verify the certificate before, now I want to > switch to gnutls. > I find that it seems that certtool won't record the verified certificats > and update the serial number or > crl number like openssl. So I have to do that in hand? > > ayaka -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Feb 11 14:06:55 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 11 Feb 2014 14:06:55 +0100 Subject: [gnutls-help] gnutls_dh_set_prime_bits question In-Reply-To: <87bnye7vxq.fsf@lifelogs.com> References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> <87sirran2l.fsf@lifelogs.com> <87bnye7vxq.fsf@lifelogs.com> Message-ID: On Mon, Feb 10, 2014 at 5:51 PM, Ted Zlatanov wrote: > I didn't see that somehow build-aux/config.rpath got included in the > patch, which was already pretty long. Sorry about that. There seems to be something wrong with the patch for documentation. There are duplicate sections (e.g. "Introduction to the library"), and it seems like it duplicates existing documention. Is that intentional? regards, Nikos From tzz at lifelogs.com Tue Feb 11 15:33:57 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Tue, 11 Feb 2014 09:33:57 -0500 Subject: [gnutls-help] gnutls_dh_set_prime_bits question In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 11 Feb 2014 14:06:55 +0100") References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> <87sirran2l.fsf@lifelogs.com> <87bnye7vxq.fsf@lifelogs.com> Message-ID: <87iosl67my.fsf@lifelogs.com> On Tue, 11 Feb 2014 14:06:55 +0100 Nikos Mavrogiannopoulos wrote: NM> On Mon, Feb 10, 2014 at 5:51 PM, Ted Zlatanov wrote: >> I didn't see that somehow build-aux/config.rpath got included in the >> patch, which was already pretty long. Sorry about that. NM> There seems to be something wrong with the patch for documentation. NM> There are duplicate sections (e.g. "Introduction to the library"), and NM> it seems like it duplicates existing documention. Is that intentional? Ugh. I was editing the document and everything looked OK with `git diff' but when I redirected it I caught some garbage in the patch. I'm sorry about that, no idea what happened[1]. See attached. Should I mention for each priority string (I only did for "NORMAL") if it enables or disabled DHE? The FAQ patch stands. Ted [1] Emacs has started losing the transient mark on Shift+PageDown and I keep missing that, and forgetting to ask how to fix it... I think it was the reason for that large erroneous block of text. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-doc.patch Type: text/x-diff Size: 10592 bytes Desc: not available URL: From nmav at gnutls.org Wed Feb 12 19:57:43 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Feb 2014 19:57:43 +0100 Subject: [gnutls-help] gnutls_dh_set_prime_bits question In-Reply-To: <87iosl67my.fsf@lifelogs.com> References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> <87sirran2l.fsf@lifelogs.com> <87bnye7vxq.fsf@lifelogs.com> <87iosl67my.fsf@lifelogs.com> Message-ID: <52FBC427.1040102@gnutls.org> On 02/11/2014 03:33 PM, Ted Zlatanov wrote: > NM> On Mon, Feb 10, 2014 at 5:51 PM, Ted Zlatanov wrote: >>> I didn't see that somehow build-aux/config.rpath got included in the >>> patch, which was already pretty long. Sorry about that. > > NM> There seems to be something wrong with the patch for documentation. > NM> There are duplicate sections (e.g. "Introduction to the library"), and > NM> it seems like it duplicates existing documention. Is that intentional? > > Ugh. I was editing the document and everything looked OK with `git > diff' but when I redirected it I caught some garbage in the patch. I'm > sorry about that, no idea what happened[1]. See attached. > Should I mention for each priority string (I only did for "NORMAL") if > it enables or disabled DHE? Thanks. I've committed only part of it. I think mentioning the detailed mappings to ciphersuites or algorithms should be done in an appendix (or one can obtain the list in real-time by using gnutls-cli -l --priority NORMAL). I'd prefer not to have such mappings in the main documentation so that there is freedom to rearrange algorithms and orders, as new attacks are being found without being bound to strict documented behavior. regards, Nikos From tzz at lifelogs.com Thu Feb 13 15:02:25 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Thu, 13 Feb 2014 09:02:25 -0500 Subject: [gnutls-help] gnutls_dh_set_prime_bits question References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> <87sirran2l.fsf@lifelogs.com> <87bnye7vxq.fsf@lifelogs.com> <87iosl67my.fsf@lifelogs.com> <52FBC427.1040102@gnutls.org> Message-ID: <87d2irglfy.fsf@lifelogs.com> On Wed, 12 Feb 2014 19:57:43 +0100 Nikos Mavrogiannopoulos wrote: NM> On 02/11/2014 03:33 PM, Ted Zlatanov wrote: NM> On Mon, Feb 10, 2014 at 5:51 PM, Ted Zlatanov wrote: >>>> I didn't see that somehow build-aux/config.rpath got included in the >>>> patch, which was already pretty long. Sorry about that. >> NM> There seems to be something wrong with the patch for documentation. NM> There are duplicate sections (e.g. "Introduction to the library"), and NM> it seems like it duplicates existing documention. Is that intentional? >> >> Ugh. I was editing the document and everything looked OK with `git >> diff' but when I redirected it I caught some garbage in the patch. I'm >> sorry about that, no idea what happened[1]. See attached. NM> Thanks. I've committed only part of it. I think mentioning the detailed NM> mappings to ciphersuites or algorithms should be done in an appendix (or NM> one can obtain the list in real-time by using gnutls-cli -l --priority NM> NORMAL). Maybe we should mention that method at the beginning of the list of priority strings? I think an auto-generated appendix would be terrific as a reference, so you don't have to run gnutls-cli to find out what "NORMAL" means. For instance, if you're setting up priority strings in Emacs, it would be really nice :) It sounds reasonably easy with some scripting. As text it would be very convenient for grepping and diffing. The meaning of e.g. "NORMAL" for a particular release is particularly important, both to look for behavior changes as a diff and for users stuck on that release. NM> I'd prefer not to have such mappings in the main documentation so that NM> there is freedom to rearrange algorithms and orders, as new attacks are NM> being found without being bound to strict documented behavior. Understood, it's a hassle certainly. >> Should I mention for each priority string (I only did for "NORMAL") if >> it enables or disabled DHE? What do you think about this? Thanks Ted From nmav at gnutls.org Thu Feb 13 17:23:01 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Feb 2014 17:23:01 +0100 Subject: [gnutls-help] gnutls_dh_set_prime_bits question In-Reply-To: <87d2irglfy.fsf@lifelogs.com> References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> <1387699512.3650.2.camel@aspire.lan> <87zjncg670.fsf@flea.lifelogs.com> <52C7238F.7020100@gnutls.org> <87sirran2l.fsf@lifelogs.com> <87bnye7vxq.fsf@lifelogs.com> <87iosl67my.fsf@lifelogs.com> <52FBC427.1040102@gnutls.org> <87d2irglfy.fsf@lifelogs.com> Message-ID: On Thu, Feb 13, 2014 at 3:02 PM, Ted Zlatanov wrote: > NM> Thanks. I've committed only part of it. I think mentioning the detailed > NM> mappings to ciphersuites or algorithms should be done in an appendix (or > NM> one can obtain the list in real-time by using gnutls-cli -l --priority > NM> NORMAL). > Maybe we should mention that method at the beginning of the list of > priority strings? Could be nice. > I think an auto-generated appendix would be terrific as a reference, so > you don't have to run gnutls-cli to find out what "NORMAL" means. For > instance, if you're setting up priority strings in Emacs, it would be > really nice :) It sounds reasonably easy with some scripting. As text > it would be very convenient for grepping and diffing. I agree. It may need some tweaking of printlist.c to use gnutls_priority_get_cipher_suite_index, and some changes in the makefiles. >>> Should I mention for each priority string (I only did for "NORMAL") if >>> it enables or disabled DHE? > What do you think about this? It is nice. Maybe say "it enables perfect forward secrecy (DHE, ECDHE)" instead? I think that more people will understand the purpose of this text if PFS is explicit. regards, Nikos 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-help] 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-help] 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 Venkata.Chaitanya at GainSpan.com Wed Feb 19 11:35:55 2014 From: Venkata.Chaitanya at GainSpan.com (Venkata Chaitanya) Date: Wed, 19 Feb 2014 02:35:55 -0800 Subject: [gnutls-help] querry Message-ID: <3582894D7E3C1141A7D0D3132B8EC38B36E453FE93@GS-EX01.GainSpan.LAN> Hi, I have one more query I started gnutls server but I get this error "ERROR Code:Sec_error_pkcs11_device_error" when I try to connect using browser. Thanks, Chaitanya -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Feb 19 23:16:13 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 19 Feb 2014 17:16:13 -0500 Subject: [gnutls-help] querry In-Reply-To: <3582894D7E3C1141A7D0D3132B8EC38B36E453FE93@GS-EX01.GainSpan.LAN> References: <3582894D7E3C1141A7D0D3132B8EC38B36E453FE93@GS-EX01.GainSpan.LAN> Message-ID: <53052D2D.4080406@fifthhorseman.net> On 02/19/2014 05:35 AM, Venkata Chaitanya wrote: > I have one more query I started gnutls server but I get this error "ERROR Code:Sec_error_pkcs11_device_error" when I try to connect using browser. What version of gnutls are you using? On what platform? How are you starting the server? How are you connecting to the server with your browser? Do you see any other error or diagnostic information? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From pav5088 at internode.on.net Thu Feb 20 17:32:46 2014 From: pav5088 at internode.on.net (Mark Pavlichuk) Date: Fri, 21 Feb 2014 02:32:46 +1000 Subject: [gnutls-help] GnuTLS/openssl compatibility bug? Message-ID: <53062E2E.2050902@internode.on.net> I'm a sysadmin out of his depth. I'm having a crash in GnuTLS code linked to isc-dhcpd-server-ldap (Debian Wheezy). Full bug report : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723773 I normally wouldn't beg for help this desperately, but this issue is preventing me from helping the FusionDirectory(FD) developers, and from finishing a years long project to document FD. FD is a fork of GOsa which is the backbone of the Munich Linux project. My "docs" are only scripts right now... but once everything is working the scripts will be the skeleton for proper docs : http://sourceforge.net/p/wfstt/code/ci/master/tree/ . The FusionDirectory developers have also asked me to help test some PXE based deployment technology (related to the above), but because this requires dhcpd+ldap this bug is preventing me here also. -- Mark Pavlichuk From mpg at polarssl.org Fri Feb 28 16:38:31 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Fri, 28 Feb 2014 16:38:31 +0100 Subject: [gnutls-help] gnutls-serv, PSK and documentation Message-ID: <5310AD77.5000808@polarssl.org> Hi, The man page for gnutls-serv (3.2.11) says: Let's also start a server with support for PSK. This would require a password file created with psktool. gnutls-serv --http --pskpasswd psk-passwd.txt When I tried exactly that, I was unable to connect with a client offering only PSK ciphersuites. To make it work, I had to explicitly enable the PSK key exchange(s) using the --priority option. It's no big deal, but I feel like the Examples section in the man page should mention this, so that running exactly the command as printed works as expected. I didn't test with anything else than PSK, but this may hold for other key exchanges that aren't in NORMAL too, like SRP. Also, though it's probably obvious, the description of the --priority option could mention that the default value is NORMAL when the option is not used. Another detail while at it: table 6.3 of http://www.gnutls.org/manual/html_node/Priority-Strings.html doesn't mention SHA384 as an option for MAC, though it seems to be supported. Manuel. From mpg at polarssl.org Fri Feb 28 16:38:11 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Fri, 28 Feb 2014 16:38:11 +0100 Subject: [gnutls-help] Ciphersuite minimal version inconsistency? Message-ID: <5310AD63.8070308@polarssl.org> Hi, % gnutls-cli --version | head -n1 gnutls-cli 3.2.11 % gnutls-cli --list | grep DHE_PSK_ARC TLS_ECDHE_PSK_ARCFOUR_128_SHA1 0xc0, 0x33 SSL3.0 TLS_DHE_PSK_ARCFOUR_128_SHA1 0x00, 0x8e TLS1.0 I have trouble getting why the DHE_PSK suite would require TLS 1.0 while the ECDHE_PSK one would work with SSL 3.0. AFAICS, neither RFC 4279 nor 5489, which define these suites, say anything about a minimum version for them. Am I missing something? Thanks, Manuel. From mpg at polarssl.org Fri Feb 28 16:38:23 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Fri, 28 Feb 2014 16:38:23 +0100 Subject: [gnutls-help] Some "missing" ciphersuites Message-ID: <5310AD6F.6050700@polarssl.org> Hi, In GnuTLS 3.2.11, the following ciphersuites do not seem to be available, according to the output of 'gnutls-cli --list', though, unless I'm mistaken, all the necessary components (key exchange etc) are available, and similar ciphersuites are available. TLS_DHE_PSK_NULL_SHA1 TLS_DHE_PSK_RC4_128_SHA1 TLS_ECDHE_PSK_NULL_SHA1 TLS_ECDHE_PSK_RC4_128_SHA1 TLS_PSK_NULL_SHA1 TLS_RSA_PSK_RC4_128_SHA1 Is that an oversight, or is there a particular reason? Thanks, Manuel. From nmav at gnutls.org Fri Feb 28 19:39:00 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 Feb 2014 19:39:00 +0100 Subject: [gnutls-help] gnutls-serv, PSK and documentation In-Reply-To: <5310AD77.5000808@polarssl.org> References: <5310AD77.5000808@polarssl.org> Message-ID: <5310D7C4.5080602@gnutls.org> On 02/28/2014 04:38 PM, Manuel P?gouri?-Gonnard wrote: > Hi, > > The man page for gnutls-serv (3.2.11) says: > > Let's also start a server with support for PSK. This would require a > password file created with psktool. > > gnutls-serv --http --pskpasswd psk-passwd.txt > > When I tried exactly that, I was unable to connect with a client offering only > PSK ciphersuites. To make it work, I had to explicitly enable the PSK key > exchange(s) using the --priority option. > It's no big deal, but I feel like the Examples section in the man page should > mention this, so that running exactly the command as printed works as expected. > I didn't test with anything else than PSK, but this may hold for other key > exchanges that aren't in NORMAL too, like SRP. Thanks, I've updated the documentation. It was much older than the implementation. regards, Nikos From nmav at gnutls.org Fri Feb 28 19:43:18 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 Feb 2014 19:43:18 +0100 Subject: [gnutls-help] Ciphersuite minimal version inconsistency? In-Reply-To: <5310AD63.8070308@polarssl.org> References: <5310AD63.8070308@polarssl.org> Message-ID: <5310D8C6.2090807@gnutls.org> On 02/28/2014 04:38 PM, Manuel P?gouri?-Gonnard wrote: > Hi, > > % gnutls-cli --version | head -n1 > gnutls-cli 3.2.11 > % gnutls-cli --list | grep DHE_PSK_ARC > TLS_ECDHE_PSK_ARCFOUR_128_SHA1 0xc0, 0x33 SSL3.0 > TLS_DHE_PSK_ARCFOUR_128_SHA1 0x00, 0x8e TLS1.0 > > I have trouble getting why the DHE_PSK suite would require TLS 1.0 while the > ECDHE_PSK one would work with SSL 3.0. AFAICS, neither RFC 4279 nor 5489, which > define these suites, say anything about a minimum version for them. > Am I missing something? Hello Manuel, The RFCs you refer to don't mention SSL 3.0 at all, so my approach was to allow these algorithms for TLS 1.0 or later. Unfortunately openssl was negotiating these algorithms on SSL 3.0 as well, so I allowed some of them in SSL 3.0 as well. I asked the TLS WG at the time, and there was no real answer. Anyway maybe it makes sense to allow all the TLS 1.0 ciphersuites in SSL 3.0 as well to prevent any incompatibilities. regards, Nikos From nmav at gnutls.org Fri Feb 28 19:54:20 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 Feb 2014 19:54:20 +0100 Subject: [gnutls-help] Some "missing" ciphersuites In-Reply-To: <5310AD6F.6050700@polarssl.org> References: <5310AD6F.6050700@polarssl.org> Message-ID: <5310DB5C.70105@gnutls.org> On 02/28/2014 04:38 PM, Manuel P?gouri?-Gonnard wrote: > Hi, > > In GnuTLS 3.2.11, the following ciphersuites do not seem to be available, > according to the output of 'gnutls-cli --list', though, unless I'm mistaken, all > the necessary components (key exchange etc) are available, and similar > ciphersuites are available. > > TLS_DHE_PSK_NULL_SHA1 > TLS_DHE_PSK_RC4_128_SHA1 > TLS_ECDHE_PSK_NULL_SHA1 > TLS_ECDHE_PSK_RC4_128_SHA1 > TLS_PSK_NULL_SHA1 > TLS_RSA_PSK_RC4_128_SHA1 > Is that an oversight, or is there a particular reason? No particular reason. Probably it was an oversight and no-one asked for them. Do you think there is some good reason to add them? regards, Nikos