From tzz at lifelogs.com Fri Jan 3 21:29:23 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Fri, 03 Jan 2014 15:29:23 -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> Message-ID: <87zjncg670.fsf@flea.lifelogs.com> 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). 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. Ted From nmav at gnutls.org Fri Jan 3 21:45:15 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 03 Jan 2014 21:45:15 +0100 Subject: [gnutls-help] Problem Using gnutls_openpgp_crt_verify_ring .. cdk_pk_check_sigs In-Reply-To: <6D9A2D35-69CA-41E1-BB8F-6F995B563A30@usf.edu> References: <6D9A2D35-69CA-41E1-BB8F-6F995B563A30@usf.edu> Message-ID: <52C7215B.6030207@gnutls.org> On 12/23/2013 11:53 PM, Rogers, David wrote: > Hello! > > I'm trying to write server code to verify a client's OpenPGP key > inside gnutls. The key exchange works fine, but the server's call > to gnutls_openpgp_crt_verify_ring always returns CDK_KEY_NOSIGNER. (on > GNUTLS_DEBUG_LEVEL=9) [...] > gnutls_certificate_verification_status_print --> > The certificate is NOT trusted. The certificate is not trusted. Could > not find a signer of the certificate. [...] > I think the trouble is that it has some impossible requirements on the > signers (line 509): > verification must be ok AND the signature must not be a self-sig. Hello David, In short the idea is to only accept a signature if it is made by someone else than the owner of the key. > But the self-sigs have to be good, or else the algo. fails. So, the > self-sigs it adds to the "uid_list" make the final "uid_list_all_signed" > check (on line 522) fail, resulting in CDK_KEY_NOSIGNER. For the algo > to be correct, the self-sigs should not be added to the final list > check. I'm not even sure what the uid_list check is for... I have not checked the details, but could you describe the scenario you want it to succeed and it doesn't? > FWIW, I would rather see a "int > gnutls_openpgp_crt_verify_signer(gnutls_openpgp_crt_t key, > gnutls_openpgp_crt_t signer, unsigned int *verify)" test that would take > an gnutls_openpgp_crt_t 'cert' from the client and > an gnutls_openpgp_crt_t 'signer' holding the signer's public key and > check that > 1) the client cert's self-signs are valid > 2) the client cert has at least one valid signature from the provided > 'signer' pubkey That's what the existing gnutls_openpgp_crt_verify_ring() is supposed to do. There is indeed quite some functionality missing for pgp support but I don't plan in working on it any time soon. However, if you submit patches to improve or fix the openpgp functionality I'll includ them. regards, Nikos From nmav at gnutls.org Fri Jan 3 21:54:39 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 03 Jan 2014 21:54:39 +0100 Subject: [gnutls-help] gnutls_dh_set_prime_bits question In-Reply-To: <87zjncg670.fsf@flea.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> Message-ID: <52C7238F.7020100@gnutls.org> 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). > > 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. Indeed, I noticed that confusion too on various forums. For that topic it may be nice to have an answer in: http://www.gnutls.org/faq.html For modifying that you may want to check the web-pages branch of the gnutls repository. regards, Nikos From davidrogers at usf.edu Fri Jan 3 21:56:20 2014 From: davidrogers at usf.edu (Rogers, David) Date: Fri, 3 Jan 2014 15:56:20 -0500 Subject: [gnutls-help] Problem Using gnutls_openpgp_crt_verify_ring .. cdk_pk_check_sigs In-Reply-To: <52C7215B.6030207@gnutls.org> References: <6D9A2D35-69CA-41E1-BB8F-6F995B563A30@usf.edu> <52C7215B.6030207@gnutls.org> Message-ID: <26118161-DDC2-4A4D-BA26-EAE20E963656@usf.edu> On Jan 3, 2014, at 3:45 PM, Nikos Mavrogiannopoulos wrote: > On 12/23/2013 11:53 PM, Rogers, David wrote: >> Hello! >> >> I'm trying to write server code to verify a client's OpenPGP key >> inside gnutls. The key exchange works fine, but the server's call >> to gnutls_openpgp_crt_verify_ring always returns CDK_KEY_NOSIGNER. (on >> GNUTLS_DEBUG_LEVEL=9) > [...] >> gnutls_certificate_verification_status_print --> >> The certificate is NOT trusted. The certificate is not trusted. Could >> not find a signer of the certificate. > [...] >> I think the trouble is that it has some impossible requirements on the >> signers (line 509): >> verification must be ok AND the signature must not be a self-sig. > > Hello David, > In short the idea is to only accept a signature if it is made by > someone else than the owner of the key. > >> But the self-sigs have to be good, or else the algo. fails. So, the >> self-sigs it adds to the "uid_list" make the final "uid_list_all_signed" >> check (on line 522) fail, resulting in CDK_KEY_NOSIGNER. For the algo >> to be correct, the self-sigs should not be added to the final list >> check. I'm not even sure what the uid_list check is for... > > I have not checked the details, but could you describe the scenario you > want it to succeed and it doesn't? > >> FWIW, I would rather see a "int >> gnutls_openpgp_crt_verify_signer(gnutls_openpgp_crt_t key, >> gnutls_openpgp_crt_t signer, unsigned int *verify)" test that would take >> an gnutls_openpgp_crt_t 'cert' from the client and >> an gnutls_openpgp_crt_t 'signer' holding the signer's public key and >> check that >> 1) the client cert's self-signs are valid >> 2) the client cert has at least one valid signature from the provided >> 'signer' pubkey > > That's what the existing gnutls_openpgp_crt_verify_ring() is supposed to > do. There is indeed quite some functionality missing for pgp support but > I don't plan in working on it any time soon. However, if you submit > patches to improve or fix the openpgp functionality I'll includ them. > > regards, > Nikos > > Actually, I realized my problem was caused by reading the PGP keyring (gnutls_openpgp_keyring_import) using ASCII mode, when the file (.gpg extension) was binary. No error occurred on read, but no signers could be found because the public keys didn't actually load. So I would re-classify this as an issue with gnutls_openpgp_keyring_import. What I wanted to do was verify that the peer's certificate had a valid signature from a particular signer. This is covered by the present code if I create a keyring containing only the public key I want to check against. Thanks! ~ David. From mail at lenzw.de Fri Jan 10 03:20:38 2014 From: mail at lenzw.de (Lenz Weber) Date: Fri, 10 Jan 2014 03:20:38 +0100 Subject: [gnutls-help] gnutls + courier-imap => very slow Message-ID: <52CF58F6.4070504@lenzw.de> Hello, I'm currently investigating some serious performance problems when using courier-0.66.1ubuntu4 in combination with gnutls-3.0.11+really2.12.14-5ubuntu3.5, which would be the usual combination if one were to compile courier using the --with-gnutls config flag in the lastest Ubuntu LTS version 12.04. I'm already in contact with the courier-mta mailing list and if you want to read the complete history, you can do this here: http://sourceforge.net/mailarchive/forum.php?forum_name=courier-imap&max_rows=25&style=nested&viewmonth=201401 TL;DR: using GnuTLS slows courier down. A lot. I did some benchmarking and while downloading a 10MB attachment through courier-OpenSSL takes 1.6 seconds, with GnuTLS, it takes about 60 seconds. Listing large directories will just time out because it takes too long. Funny thing is: the couriertls process takes <1% CPU usage while on GnuTLS. If I attach strace to that process, CPU usage goes up to 40% and the test download finishes after ~4 seconds. Still not as fast as OpenSSL, but something I could work with. I'm suspecting that this might be some kind of timing problem, maybe even in the GnuTLS library, so maybe someone here has an idea of how to address the problem? Regards, Lenz Weber From mrsam at courier-mta.com Fri Jan 10 05:46:51 2014 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 09 Jan 2014 23:46:51 -0500 Subject: [gnutls-help] =?utf-8?q?gnutls_+_courier-imap_=3D=3E_very_slow?= References: <52CF58F6.4070504@lenzw.de> Message-ID: Lenz Weber writes: > Hello, > I'm currently investigating some serious performance problems when using > courier-0.66.1ubuntu4 in combination with > gnutls-3.0.11+really2.12.14-5ubuntu3.5, which would be the usual > combination if one were to compile courier using the --with-gnutls > config flag in the lastest Ubuntu LTS version 12.04. The key part in the strace, here, http://paste.ubuntu.com/6724497/ starting around line 500. What should be happening there is nothing more than a read()ing a nicely-sized chunk from a pipe, file descriptor 6, and then tossing the whole thing to gnutls_record_send() which writes it to a socket on file descriptor 0. Between each call to read(), and a subsequent writev() of the encrypted chunk, there are two sets of calls gettimeofday(), getrusage(), and times(). I can't see why that alone would be enough to grind things to a halt; however it's hard to see the actual timings here. However, I happened to have sources of 3.2.7 handy, and from poking around, those syscalls appear to be coming out of wrap_nettle_rnd_refresh() in lib/nettle/rnd.c, which appears to have something to do with reseeding an internal random number pool. It looks like there's a lot of work happening here; and I don't quite follow why that needs to be done for each call to gnutls_record_send(); but that's as far as I could go, with what I know. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Jan 10 06:37:35 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jan 2014 00:37:35 -0500 Subject: [gnutls-help] gnutls + courier-imap => very slow In-Reply-To: References: <52CF58F6.4070504@lenzw.de> Message-ID: <52CF871F.6050708@fifthhorseman.net> On 01/09/2014 11:46 PM, Sam Varshavchik wrote: > Lenz Weber writes: > >> I'm currently investigating some serious performance problems when using >> courier-0.66.1ubuntu4 in combination with >> gnutls-3.0.11+really2.12.14-5ubuntu3.5, which would be the usual >> combination if one were to compile courier using the --with-gnutls >> config flag in the lastest Ubuntu LTS version 12.04. [...] > However, I happened to have sources of 3.2.7 handy, and from poking > around, those syscalls appear to be coming out of > wrap_nettle_rnd_refresh() in lib/nettle/rnd.c, which appears to have > something to do with reseeding an internal random number pool. It looks > like there's a lot of work happening here; and I don't quite follow why > that needs to be done for each call to gnutls_record_send(); but that's > as far as I could go, with what I know. the ubuntu version Lenz mentioned is "really2.12.14", which means it's built against gcrypt, not nettle, iiuc. sorry i don't have more help to offer on this at the moment, but just wanted to avoid anyone doing a goose chase down into the nettle code for this situation. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Fri Jan 10 08:11:26 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Jan 2014 08:11:26 +0100 Subject: [gnutls-help] gnutls + courier-imap => very slow In-Reply-To: <52CF58F6.4070504@lenzw.de> References: <52CF58F6.4070504@lenzw.de> Message-ID: <52CF9D1E.4070602@gnutls.org> On 01/10/2014 03:20 AM, Lenz Weber wrote: > Hello, > I'm currently investigating some serious performance problems when using > courier-0.66.1ubuntu4 in combination with > gnutls-3.0.11+really2.12.14-5ubuntu3.5, which would be the usual > combination if one were to compile courier using the --with-gnutls > config flag in the lastest Ubuntu LTS version 12.04. Please try with an "official" gnutls version before reporting here any issue. The ubuntu packages may contain bugs that don't exist in the released versions. Try 3.1.18 or better 3.2.8. The latter should be faster than openssl not slower. regards, Nikos From mail at lenzw.de Fri Jan 10 13:43:38 2014 From: mail at lenzw.de (Lenz Weber) Date: Fri, 10 Jan 2014 13:43:38 +0100 Subject: [gnutls-help] gnutls + courier-imap => very slow In-Reply-To: <52CF9D1E.4070602@gnutls.org> References: <52CF58F6.4070504@lenzw.de> <52CF9D1E.4070602@gnutls.org> Message-ID: <52CFEAFA.4020106@lenzw.de> Thanks for the input, I found it: It's a bug that apparently was fixed somewhere between libgnutls26_2.12.14 (which the ubuntu deb is based on) and libgnutls26_2.12.23 (the latest release in the 2.12 branch). The newer version takes 1.5 seconds, acually using ~80% cpu, which looks promising. Is the 2.12 branch still safe to use? Compiling 3.* has dependencies that Ubuntu LTS cannot fullfill. Regards, Lenz On 10.01.2014 08:11, Nikos Mavrogiannopoulos wrote: > On 01/10/2014 03:20 AM, Lenz Weber wrote: >> Hello, >> I'm currently investigating some serious performance problems when using >> courier-0.66.1ubuntu4 in combination with >> gnutls-3.0.11+really2.12.14-5ubuntu3.5, which would be the usual >> combination if one were to compile courier using the --with-gnutls >> config flag in the lastest Ubuntu LTS version 12.04. > > Please try with an "official" gnutls version before reporting here > any issue. The ubuntu packages may contain bugs that don't exist in > the released versions. Try 3.1.18 or better 3.2.8. The latter should be > faster than openssl not slower. > > regards, > Nikos > From nmav at gnutls.org Fri Jan 10 14:27:10 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Jan 2014 14:27:10 +0100 Subject: [gnutls-help] gnutls + courier-imap => very slow In-Reply-To: <52CFEAFA.4020106@lenzw.de> References: <52CF58F6.4070504@lenzw.de> <52CF9D1E.4070602@gnutls.org> <52CFEAFA.4020106@lenzw.de> Message-ID: On Fri, Jan 10, 2014 at 1:43 PM, Lenz Weber wrote: > Thanks for the input, > I found it: > It's a bug that apparently was fixed somewhere between > libgnutls26_2.12.14 (which the ubuntu deb is based on) and > libgnutls26_2.12.23 (the latest release in the 2.12 branch). > Please report the issue to the ubuntu package maintainers. The newer version takes 1.5 seconds, acually using ~80% cpu, which looks > promising. > Is the 2.12 branch still safe to use? > No, it is no longer supported (by me at least, I guess ubuntu have their own support). However if you really need to stick with 2.12.23 make sure you apply the fix at: http://www.gnutls.org/security.html#GNUTLS-SA-2013-2 regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuelharmer at gmail.com Sun Jan 5 11:24:23 2014 From: samuelharmer at gmail.com (Samuel Harmer) Date: Sun, 5 Jan 2014 10:24:23 +0000 Subject: [gnutls-help] Is it possible to invoke certtool to create a self signed certificate using a pkcs #8 key and a template file? Message-ID: Dear GnuTLS mailing list, I have posted this to ubuntu.stackexchange.com already but have a feeling this mailing list might know a bit more. Alternative solutions welcome although I'm deliberately trying to avoid OpenSSL, which I'm pretty sure is capable of handling this. I'm struggling with certtool from the gnutls package on Ubuntu server 12.04.3. I'm trying to follow this guide ( https://help.ubuntu.com/community/GnuTLS) but with an encrypted key. I've created my encrypted private key like so. # certtool \ > --generate-privkey \ > --pkcs8 \ > --sec-param low \ > --pkcs-cipher aes-256 \ > --outfile ca_key.pkcs8 Generating a 1248 bit RSA private key... Enter password: Confirm password: Now I would like to create a self signed certificate using this key with the following command. Instead of prompting me for the password for the private key though, I get the following error. # certtool \ > --generate-self-signed \ > --load-privkey ca_key.pkcs8 \ > --pkcs8 \ > --pkcs-cipher aes-256 \ > --template ca_template Generating a self signed certificate... Segmentation fault (core dumped) If I attempt this with the same template and an unencrypted private key it works. Or if I use the encrypted key without a template, it also works. # certtool --generate-privkey --sec-param low --outfile ca_key Generating a 1248 bit RSA private key... # certtool --generate-self-signed --load-privkey ca_key --template ca_template Generating a self signed certificate... X.509 Certificate Information: Version: 3 ... # certtool --generate-self-signed --load-privkey ca_key.pkcs8 --pkcs8 --pkcs-cipher aes-256 Generating a self signed certificate... Enter password: Please enter the details of the certificate's distinguished name. Just press enter to ignore a field. Country name (2 chars): GB ... Is there a way to make certtool accept both a template file and an encrypted private key? Or do I need to script the decryption of the private key to a temporary key file to pass to certtool? Thanks and regards, Samuel H. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lavr at ncbi.nlm.nih.gov Fri Jan 10 20:32:17 2014 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Fri, 10 Jan 2014 19:32:17 +0000 Subject: [gnutls-help] pkcs12 format not understood by GNUTLS 3.1.18 Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C45C097@MLBXv04.nih.gov> Hi, There is an issue reported to me that GNUTLS 3.1.18 fails to load a certificate / public key, from a PKCS#12 file in DER format created by the following command: openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt When the "certificate.pfx" file is then read with the following GNUTLS call, an error -60 gets returned: err = gnutls_certificate_set_x509_simple_pkcs12_file(cred, "certificate.pfx", GNUTLS_X509_FMT_DER, pass); Yet that works perfectly with an older GNUTLS version (e.g. 2.4.2). If CACert.crt is not included in the .pfx file, the code above begins to work with the current GNUTLS release (3.1.18). Is this the expected behavior? Thanks, Anton Lavrentiev Contractor NIH/NLM/NCBI From dkg at fifthhorseman.net Fri Jan 10 23:16:46 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 10 Jan 2014 17:16:46 -0500 Subject: [gnutls-help] pkcs12 format not understood by GNUTLS 3.1.18 In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D0C45C097@MLBXv04.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D0C45C097@MLBXv04.nih.gov> Message-ID: <52D0714E.7090801@fifthhorseman.net> On 01/10/2014 02:32 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > There is an issue reported to me that GNUTLS 3.1.18 fails to load > a certificate / public key, from a PKCS#12 file in DER format > created by the following command: > > openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt > > When the "certificate.pfx" file is then read with the following GNUTLS call, > an error -60 gets returned: > > err = gnutls_certificate_set_x509_simple_pkcs12_file(cred, "certificate.pfx", GNUTLS_X509_FMT_DER, pass); -60 is GNUTLS_E_CERTIFICATE_KEY_MISMATCH. > Yet that works perfectly with an older GNUTLS version (e.g. 2.4.2). yow, that is a much older version of GnuTLS. I'm unaware of anyone who is supporting it right now. > If CACert.crt is not included in the .pfx file, the code above begins > to work with the current GNUTLS release (3.1.18). > > Is this the expected behavior? in lib/gnutls_x509.c, in version 3.1.18, in the comments above gnutls_certificate_set_x509_simple_pkcs12_file, it says: * PKCS#12 file may contain many keys and/or certificates, and there * is no way to identify which key/certificate pair you want. You * should make sure the PKCS#12 file only contain one key/certificate * pair and/or one CRL. the same paragraph is present on the latest version, 3.2.8: http://gnutls.org/manual/html_node/Core-TLS-API.html#index-gnutls_005fcertificate_005fset_005fx509_005fsimple_005fpkcs12_005ffile so i'd say this is expected behavior -- based on the way the certs are place into the bag emitted by openssl pkcs12, gnutls doesn't know which cert to use when your .pfx file contains both the EE's cert and the CA's cert. I'm unsure why it loaded the complex .pfx file loads at all in 2.4.2. perhaps 2.4.2 will offer the wrong certificate to the TLS peer it communicates with if it loads the generated .pfx file? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sat Jan 11 11:34:43 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 11 Jan 2014 11:34:43 +0100 Subject: [gnutls-help] pkcs12 format not understood by GNUTLS 3.1.18 In-Reply-To: <52D0714E.7090801@fifthhorseman.net> References: <5F8AAC04F9616747BC4CC0E803D5907D0C45C097@MLBXv04.nih.gov> <52D0714E.7090801@fifthhorseman.net> Message-ID: <52D11E43.4050403@gnutls.org> On 01/10/2014 11:16 PM, Daniel Kahn Gillmor wrote: >> If CACert.crt is not included in the .pfx file, the code above >> begins to work with the current GNUTLS release (3.1.18). Is this >> the expected behavior? > in lib/gnutls_x509.c, in version 3.1.18, in the comments above [...] > so i'd say this is expected behavior -- based on the way the certs are > place into the bag emitted by openssl pkcs12, gnutls doesn't know > which cert to use when your .pfx file contains both the EE's cert and > the CA's cert. I'm unsure why it loaded the complex .pfx file loads > at all in 2.4.2. perhaps 2.4.2 will offer the wrong certificate to > the TLS peer it communicates with if it loads the generated .pfx > file? Hello, Most probably the old version returned the first certificate and key found, and those happened to be the correct ones in that case. However, in gnutls 3.1.18 gnutls_certificate_set_x509_simple_pkcs12_file() uses gnutls_pkcs12_simple_parse() which does try to detect the proper cert key pair based on the key ID which should be the same on certificate and key. I've updated the documentation, but I'm quite surprised that the mismatch error is returned in that case. In fact if I understand well that error should be returned after the PKCS#12 file is parsed and loaded, by another sanity check that verifies that the added key has the same public key algorithm as the certificate. I added an additional test in tests/set_pkcs12_cred.c and Anton I cannot reproduce the failure you see. Could you provide the certificates and keys you use, or try to debug the failure case yourself? regards, Nikos From nmav at gnutls.org Sat Jan 11 11:39:26 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 11 Jan 2014 11:39:26 +0100 Subject: [gnutls-help] Is it possible to invoke certtool to create a self signed certificate using a pkcs #8 key and a template file? In-Reply-To: References: Message-ID: <52D11F5E.3030302@gnutls.org> On 01/05/2014 11:24 AM, Samuel Harmer wrote: > Dear GnuTLS mailing list, > > I have posted this to ubuntu.stackexchange.com > already but have a feeling this > mailing list might know a bit more. Alternative solutions welcome > although I'm deliberately trying to avoid OpenSSL, which I'm pretty sure > is capable of handling this. > > I'm struggling with certtool from the gnutls package on Ubuntu server > 12.04.3. I'm trying to follow this guide > (https://help.ubuntu.com/community/GnuTLS) but with an encrypted key. > > I've created my encrypted private key like so. [...] > Is there a way to make certtool accept both a template file and an > encrypted private key? Or do I need to script the decryption of the > private key to a temporary key file to pass to certtool? Hello Samuel, I'd suggest to try with a more recent certtool from 3.1 or 3.2 branches of gnutls. There are several changes in the handling of password protected keys. regards, Nikos From mail at lenzw.de Sat Jan 11 21:29:26 2014 From: mail at lenzw.de (Lenz Weber) Date: Sat, 11 Jan 2014 21:29:26 +0100 Subject: [gnutls-help] gnutls + courier-imap => very slow In-Reply-To: References: <52CF58F6.4070504@lenzw.de> <52CF9D1E.4070602@gnutls.org> <52CFEAFA.4020106@lenzw.de> Message-ID: <52D1A9A6.3090005@lenzw.de> I identified the fix - it's the patch from 2.12.15 to 2.12.16. On 10.01.2014 14:27, Nikos Mavrogiannopoulos wrote: > > Please report the issue to the ubuntu package maintainers. I reported the bug here https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1268193 Is someone here using debian who can confirm if this bug consists there, too? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4231 bytes Desc: S/MIME Cryptographic Signature URL: From dkg at fifthhorseman.net Sat Jan 11 21:47:04 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 11 Jan 2014 15:47:04 -0500 Subject: [gnutls-help] gnutls + courier-imap => very slow In-Reply-To: <52D1A9A6.3090005@lenzw.de> References: <52CF58F6.4070504@lenzw.de> <52CF9D1E.4070602@gnutls.org> <52CFEAFA.4020106@lenzw.de> <52D1A9A6.3090005@lenzw.de> Message-ID: <52D1ADC8.2080707@fifthhorseman.net> On 01/11/2014 03:29 PM, Lenz Weber wrote: > I identified the fix - it's the patch from 2.12.15 to 2.12.16. > > On 10.01.2014 14:27, Nikos Mavrogiannopoulos wrote: >> >> Please report the issue to the ubuntu package maintainers. > > I reported the bug here > https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1268193 > > Is someone here using debian who can confirm if this bug consists there, > too? debian stable (wheezy) ships 2.12.20, so i don't believe it should have that problem, but i haven't tested it myself. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From bann at arcor.de Sun Jan 12 11:34:30 2014 From: bann at arcor.de (Gadget) Date: Sun, 12 Jan 2014 10:34:30 +0000 (UTC) Subject: [gnutls-help] Source code is hard to decompress on Windows Message-ID: Why have you chosen so rarely used compression format (.lz and .xz) for the source code tarball? This is really hard for windows users to decompress. No normal tool does support it. From dkg at fifthhorseman.net Sun Jan 12 15:19:49 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 12 Jan 2014 09:19:49 -0500 Subject: [gnutls-help] Source code is hard to decompress on Windows In-Reply-To: References: Message-ID: <52D2A485.8010805@fifthhorseman.net> On 01/12/2014 05:34 AM, Gadget wrote: > Why have you chosen so rarely used compression format (.lz and .xz) for the > source code tarball? > > This is really hard for windows users to decompress. No normal tool does > support it. If you're stuck on Windows and you need an archive decompressor, 7-zip should be able to work for this purpose: http://www.7-zip.org/ Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From lavr at ncbi.nlm.nih.gov Mon Jan 13 22:36:21 2014 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Mon, 13 Jan 2014 21:36:21 +0000 Subject: [gnutls-help] pkcs12 format not understood by GNUTLS 3.1.18 In-Reply-To: <52D11E43.4050403@gnutls.org> References: <5F8AAC04F9616747BC4CC0E803D5907D0C45C097@MLBXv04.nih.gov> <52D0714E.7090801@fifthhorseman.net> <52D11E43.4050403@gnutls.org> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C45CDAC@MLBXv04.nih.gov> Nikos, > Anton I cannot reproduce the failure you see. Could you > provide the certificates and keys you use, or try to debug the > failure case yourself? Unfortunately, I cannot send you the cert / key(s) (as I do not have them either, which also makes it impossible for me to do any debugging on my own, sorry), but the developer asserts he has got an error (-60) at this very line of code when he tried to load up a .pfx file that he created with the openssl command shown in my previous post: err = gnutls_certificate_set_x509_simple_pkcs12_file(cred, file, type, pass); But thanks to dkg's patient help, we're not going to use a .pfx file with anything more than a pair of cert / key from now on; so we're all set. Thanks again! Anton Lavrentiev Contractor NIH/NLM/NCBI From stephen.nightingale at nist.gov Wed Jan 22 17:42:33 2014 From: stephen.nightingale at nist.gov (Nightingale, J. Stephen) Date: Wed, 22 Jan 2014 16:42:33 +0000 Subject: [gnutls-help] GnuTLS HTTP server Message-ID: So when I start gnutls-serv as an http server, where is it serving pages from? I have an index.html in the local directory. When I connect with the tlslite client and request a page, gnutls-serv completes the handshake, then serves up the negotiation parameters wrapped in html, as a canned response. Can I get gnutls to server a specific requested page, from an identifiable directory? I note also that when requesting 'disable-client-cert', gnutls-serv still complains that no client certificate was furnished. Cheers, Stephen Nightingale, NIST. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Jan 23 18:15:45 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 23 Jan 2014 18:15:45 +0100 Subject: [gnutls-help] GnuTLS HTTP server In-Reply-To: References: Message-ID: <52E14E41.1010407@gnutls.org> On 01/22/2014 05:42 PM, Nightingale, J. Stephen wrote: > So when I start gnutls-serv as an http server, where is it serving pages > from? I have an index.html in the local directory. When I connect with > the tlslite client and request a page, gnutls-serv completes the > handshake, then serves up the negotiation parameters wrapped in html, as > a canned response. Can I get gnutls to server a specific requested > page, from an identifiable directory? gnutls-serv is a debugging server, not a proper web server. For a web server that uses gnutls you may want to check mod_gnutls and nxweb. > I note also that when requesting 'disable-client-cert', gnutls-serv > still complains that no client certificate was furnished. Could you elaborate on the issue? regards, Nikos From Venkata.Chaitanya at GainSpan.com Fri Jan 24 06:26:52 2014 From: Venkata.Chaitanya at GainSpan.com (Venkata Chaitanya) Date: Thu, 23 Jan 2014 21:26:52 -0800 Subject: [gnutls-help] gnutls server Message-ID: <3582894D7E3C1141A7D0D3132B8EC38B36E436C5C4@GS-EX01.GainSpan.LAN> Hi, I was new to gnutls ,when I start a server it always listens on ip 0.0.0.0 .Is there any way to make it listen on my machine ip address.Help is badly required.Please help me. Regards Chaitanya -------------- next part -------------- An HTML attachment was scrubbed... URL: From lavr at ncbi.nlm.nih.gov Fri Jan 24 16:01:01 2014 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Fri, 24 Jan 2014 15:01:01 +0000 Subject: [gnutls-help] gnutls server In-Reply-To: <3582894D7E3C1141A7D0D3132B8EC38B36E436C5C4@GS-EX01.GainSpan.LAN> References: <3582894D7E3C1141A7D0D3132B8EC38B36E436C5C4@GS-EX01.GainSpan.LAN> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C46BA87@MLBXv04.nih.gov> IP 0.0.0.0 is a special wildcard, which allows the listening socket to accept connections from any network interface (if the host has many). Binding to an IP will only allow connections coming from that very IP (interface) - i.e. local to the host, but not from outside of it. HTH, Anton Lavrentiev Contractor NIH/NLM/NCBI From: Venkata Chaitanya [mailto:Venkata.Chaitanya at GainSpan.com] Sent: Friday, January 24, 2014 12:27 AM To: gnutls-help at gnutls.org; proj-had Subject: [gnutls-help] gnutls server Hi, I was new to gnutls ,when I start a server it always listens on ip 0.0.0.0 .Is there any way to make it listen on my machine ip address.Help is badly required.Please help me. Regards Chaitanya -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.nightingale at nist.gov Fri Jan 24 16:12:00 2014 From: stephen.nightingale at nist.gov (Stephen Nightingale) Date: Fri, 24 Jan 2014 10:12:00 -0500 Subject: [gnutls-help] GnuTLS HTTP server In-Reply-To: <52E14E41.1010407@gnutls.org> References: <52E14E41.1010407@gnutls.org> Message-ID: <52E282C0.6040907@nist.gov> On 1/23/2014 12:15 PM, Nikos Mavrogiannopoulos wrote: >> So when I start gnutls-serv as an http server, where is it serving pages >> from? > gnutls-serv is a debugging server, not a proper web server. For a web > server that uses gnutls you may want to check mod_gnutls and nxweb. Okay. I'm thinking to run the pygnutls twisted-server, and add the http callback instead, so as to get more programmatic control than Apache allows. > >> I note also that when requesting 'disable-client-cert', gnutls-serv >> still complains that no client certificate was furnished. > Could you elaborate on the issue? I have gnutls-serv set up as shown below: had4.antd [72]{.../tlslite-0.4.6/tests}-> more gnutlsserv.sh #3 /bin/sh gnutls-serv --port 4461 --disable-client-cert --http --x509keyfile fourkey.pem -- x509certfile fourcert.pem When connecting from the peer, the server spits out the following: had4.antd [73]{.../tlslite-0.4.6/tests}-> * connection from 10.0.20.22, port 50551 - Certificate type: X.509 No certificates found! - Could not verify certificate (err: The peer did not send any certificate.) - Version: TLS1.1 - Key Exchange: RSA - Cipher: 3DES-CBC - MAC: SHA1 - Compression: NULL So it complains about 'no certificates found' and gives a Could not verify error message, even though I have the --disable-client-cert option enabled. This is identical to the behavior experienced when no client cert flag is set. Ah! but when the --require-cert flag is set, this is what happens: had4.antd [82]{.../tlslite-0.4.6/tests}-> more ./gnutlsserv.sh #3 /bin/sh gnutls-serv --port 4461 --require-cert --http --x509keyfile fourkey.pem --x509cer tfile fourcert.pem had4.antd [83]{.../tlslite-0.4.6/tests}-> Error in handshake Error: The peer did not send any certificate. So it looks like in the disable and no flag cases, the server complains but completes the connection, however in the require-cert case, no connection is made. So I guess the message is just spurious noise. Regards, Stephen Nightingale. From nmav at gnutls.org Fri Jan 24 19:09:15 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 19:09:15 +0100 Subject: [gnutls-help] gnutls 3.2.9 Message-ID: <52E2AC4B.5040809@gnutls.org> Hello, I've just released gnutls 3.2.9. This is a bugfix release which also marks the gnutls 3.2 branch is as the current stable. * Version 3.2.9 (released 2014-01-24) ** libgnutls: The %DUMBFW option in priority string only appends data to client hello if the expected size is in the "black hole" range. ** libgnutls: %COMPAT implies %DUMBFW. ** libgnutls: gnutls_session_get_desc() returns a more compact ciphersuite description. * libgnutls: In PKCS #11 allow deleting multiple non-certificate data. ** libgnutls: When a PKCS #11 trust store is specified (e.g. using the configure option --with-default-trust-store-pkcs11), then the PKCS #11 token is used on demand to obtain the trusted anchors, rather than preloading all trusted certificates. That delegates CA certificate management and blacklist checking to the PKCS #11 module. ** libgnutls: When a PKCS #11 trust store is specified in configure option or in gnutls_x509_trust_list_add_trust_file(), then the module is used to obtain the verification anchors and any required blacklists as in http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html ** libgnutls: Fix in OCSP certificate status extension handling in non-blocking servers. Patch by Nils Maier. ** p11tool: Added --so-login option to force login as security officer (admin). ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.9.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Jan 24 19:23:38 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 24 Jan 2014 19:23:38 +0100 Subject: [gnutls-help] gnutls 3.1.19 Message-ID: <52E2AFAA.80806@gnutls.org> Hello, I've just released gnutls 3.1.19. This is a bug fix release on the previous stable branch. * Version 3.1.19 (released 2014-01-24) ** libgnutls: Fix in OCSP certificate status extension handling in non-blocking servers. Patch by Nils Maier. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.19.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From jonathan.roudiere at gmail.com Mon Jan 27 11:38:29 2014 From: jonathan.roudiere at gmail.com (Jonathan Roudiere) Date: Mon, 27 Jan 2014 11:38:29 +0100 Subject: [gnutls-help] Session resumption/unpack error while getting timestamp, expired sessions/db clean questions Message-ID: Hello Nikos, On GnuTLS 3.2.x stable release, when session db cache is used, timestamp can't be got through gnutls_db_check_entry_time(). - When session are packed into _gnutls_session_pack() magic number (PACKED_SESSION_MAGIC) - and security_parameters.timestamp - are copied in big endian order (through BUFFER_APPEND_NUM(), ... _gnutls_write_uint32() ... _gnutls_buffer_append_data()) but when they are unpacked in gnutls_db_check_entry_time() they are memcopied without any treatment thus on x86 they are badly unpacked and this forbid to get timestamp. The following patch solve the problem. diff --git a/lib/gnutls_db.c b/lib/gnutls_db.c index 2d9b744..faa158c 100644 --- a/lib/gnutls_db.c +++ b/lib/gnutls_db.c @@ -164,12 +164,12 @@ time_t gnutls_db_check_entry_time(gnutls_datum_t * entry) if (entry->size < 8) return gnutls_assert_val(0); - memcpy(&magic, entry->data, 4); + magic = _gnutls_read_uint32(entry->data); if (magic != PACKED_SESSION_MAGIC) return gnutls_assert_val(0); - memcpy(&t, &entry->data[4], 4); + t = _gnutls_read_uint32(&entry->data[4]); return t; } - Else, db remove function is never called internally by GnuTLS even if timestamp is checked against expire_time when a session is unpacked through _gnutls_session_unpack(). In _gnutls_server_restore_session() a comment specifies "expiration check is performed inside" but no action are taken in order to remove expired session from the cache/db. Is GnuTLS should not remove session from cache/db in this case ? I have patched GnuTLS in order to call the db_remove_func function from _gnutls_server_restore_session(), I don't know if this hurt GnuTLS design and should be done in another place or not at all (initially patch was against _gnutls_session_unpack()). diff --git a/lib/gnutls_db.c b/lib/gnutls_db.c index 2d9b744..6d860a4 100644 --- a/lib/gnutls_db.c +++ b/lib/gnutls_db.c @@ -285,6 +285,9 @@ _gnutls_server_restore_session(gnutls_session_t session, /* expiration check is performed inside */ ret = gnutls_session_set_data(session, data.data, data.size); + if (ret == GNUTLS_E_EXPIRED) + session->internals.db_remove_func(session->internals.db_ptr, key); + gnutls_free(data.data); if (ret < 0) { - Last question, expire_time is set on session itself so why it is not packed with the session data in order to check it when session is unpacked ? and to provide a function like gnutls_db_check_entry_time() which will return remaining time or GNUTLS_E_EXPIRED. Thanks, Joe From nmav at gnutls.org Mon Jan 27 16:14:19 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 27 Jan 2014 16:14:19 +0100 Subject: [gnutls-help] Session resumption/unpack error while getting timestamp, expired sessions/db clean questions In-Reply-To: References: Message-ID: On Mon, Jan 27, 2014 at 11:38 AM, Jonathan Roudiere wrote: > Hello Nikos, > On GnuTLS 3.2.x stable release, when session db cache is used, > timestamp can't be got through gnutls_db_check_entry_time(). > - When session are packed into _gnutls_session_pack() magic number > (PACKED_SESSION_MAGIC) - and security_parameters.timestamp - are > copied in big endian order (through BUFFER_APPEND_NUM(), ... > _gnutls_write_uint32() ... _gnutls_buffer_append_data()) but when they > are unpacked in gnutls_db_check_entry_time() they are memcopied > without any treatment thus on x86 they are badly unpacked and this > forbid to get timestamp. Hello Jonathan, Thank you for reporting that. I've committed a fix and a test program to allow detecting similar issues. > - Else, db remove function is never called internally by GnuTLS even > if timestamp is checked against expire_time when a session is unpacked > through _gnutls_session_unpack(). In _gnutls_server_restore_session() > a comment specifies "expiration check is performed inside" but no > action are taken in order to remove expired session from the cache/db. Indeed. The time check is in unpack_security_parameters() so resumption will be prevented. > Is GnuTLS should not remove session from cache/db in this case ? I > have patched GnuTLS in order to call the db_remove_func function from > _gnutls_server_restore_session(), I don't know if this hurt GnuTLS > design and should be done in another place or not at all (initially > patch was against _gnutls_session_unpack()). The idea is for the one having control of the DB to do periodical purges independently of gnutls' usage. That is why gnutls_db_check_entry_time() is provided (at least that was the idea). Now about removing a session from _gnutls_server_restore_session(). I don't think this is good, a session may be resumed multiple times (e.g., a browser downloading different images from a server in several resumed sessions from the initial one). > - Last question, expire_time is set on session itself so why it is not > packed with the session data in order to check it when session is > unpacked ? and to provide a function like gnutls_db_check_entry_time() > which will return remaining time or GNUTLS_E_EXPIRED. For simplicity. The idea of gnutls_db_check_entry_time() is to be called periodically for all stored sessions, so it would have to quickly determine the time of the session without any significant parsing. regards, Nikos From jonathan.roudiere at gmail.com Mon Jan 27 23:05:02 2014 From: jonathan.roudiere at gmail.com (Jonathan Roudiere) Date: Mon, 27 Jan 2014 23:05:02 +0100 Subject: [gnutls-help] Session resumption/unpack error while getting timestamp, expired sessions/db clean questions In-Reply-To: References: Message-ID: re Nikos, >> Is GnuTLS should not remove session from cache/db in this case ? I >> have patched GnuTLS in order to call the db_remove_func function from >> _gnutls_server_restore_session(), I don't know if this hurt GnuTLS >> design and should be done in another place or not at all (initially >> patch was against _gnutls_session_unpack()). > > The idea is for the one having control of the DB to do periodical > purges independently of > gnutls' usage. That is why gnutls_db_check_entry_time() is provided > (at least that was the idea). > Now about removing a session from _gnutls_server_restore_session(). I > don't think this is good, > a session may be resumed multiple times (e.g., a browser downloading > different images from > a server in several resumed sessions from the initial one). Ok, but the module which has in charge to store sessions -- has to set a lock if it is running in a multithread env and -- if a session isn't useful anymore then why not removing it instead of waiting for looking another time in the db, load the session, unpack it and to finally don't resume session (in handshake). Of course, callback used to retrieve sessions can do that itself (using gnutls_db_check_entry_time()) but that (in my case) the expected behaviour when callbacks are provided to remove session. >> - Last question, expire_time is set on session itself so why it is not >> packed with the session data in order to check it when session is >> unpacked ? and to provide a function like gnutls_db_check_entry_time() >> which will return remaining time or GNUTLS_E_EXPIRED. > > For simplicity. The idea of gnutls_db_check_entry_time() is to be > called periodically for all > stored sessions, so it would have to quickly determine the time of the > session without any > significant parsing. > Ok, in fact I speak about that because as expire_time is set on session and in many case the module in charge of purging session from cache db hasn't any idea of which lifetime time has been set (especially in case of different expire_time per session characteristics/purpose) else it's required to kept a global to known expire_time. Of course maybe I'm wrong that's just ideas. Thank for your time, regards, Joe > regards, > Nikos From nmav at gnutls.org Tue Jan 28 15:14:10 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 28 Jan 2014 15:14:10 +0100 Subject: [gnutls-help] Session resumption/unpack error while getting timestamp, expired sessions/db clean questions In-Reply-To: References: Message-ID: On Mon, Jan 27, 2014 at 11:05 PM, Jonathan Roudiere wrote: > re Nikos, >>> Is GnuTLS should not remove session from cache/db in this case ? I >>> have patched GnuTLS in order to call the db_remove_func function from >>> _gnutls_server_restore_session(), I don't know if this hurt GnuTLS >>> design and should be done in another place or not at all (initially >>> patch was against _gnutls_session_unpack()). >> The idea is for the one having control of the DB to do periodical >> purges independently of >> gnutls' usage. That is why gnutls_db_check_entry_time() is provided >> (at least that was the idea). >> Now about removing a session from _gnutls_server_restore_session(). I >> don't think this is good, >> a session may be resumed multiple times (e.g., a browser downloading >> different images from >> a server in several resumed sessions from the initial one). > Ok, but the module which has in charge to store sessions -- has to set > a lock if it is running in a multithread env and -- if a session isn't > useful anymore then why not removing it instead of waiting for looking > another time in the db, load the session, unpack it and to finally > don't resume session (in handshake). Of course, callback used to > retrieve sessions can do that itself (using > gnutls_db_check_entry_time()) but that (in my case) the expected > behaviour when callbacks are provided to remove session. Well, I think the locks are unavoidable in both cases. I'm not sure I understand correctly what you propose, so I'll try to expand on it. My understanding is that you propose to remove a session from the DB by the time it is resumed. That cannot be done, as a session can be resumed multiple times and not only once. >>> - Last question, expire_time is set on session itself so why it is not >>> packed with the session data in order to check it when session is >>> unpacked ? and to provide a function like gnutls_db_check_entry_time() >>> which will return remaining time or GNUTLS_E_EXPIRED. >> For simplicity. The idea of gnutls_db_check_entry_time() is to be >> called periodically for all >> stored sessions, so it would have to quickly determine the time of the >> session without any >> significant parsing. > Ok, in fact I speak about that because as expire_time is set on > session and in many case the module in charge of purging session from > cache db hasn't any idea of which lifetime time has been set > (especially in case of different expire_time per session > characteristics/purpose) else it's required to kept a global to known > expire_time. You're right here, and I need to add a function to return the default expiration time. For the versions that this doesn't exist you can assume it is 3600 secs. regards, Nikos From nmav at gnutls.org Fri Jan 31 17:30:23 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 Jan 2014 17:30:23 +0100 Subject: [gnutls-help] gnutls 3.2.10 Message-ID: <52EBCF9F.7090104@gnutls.org> Hello, I've just released gnutls 3.2.10. This is a bugfix release on the current stable branch. * Version 3.2.10 (released 2014-01-31) ** libgnutls: fixed null pointer derefence when printing a certificate DN and an LDAP description isn't present. ** libgnutls: When obtaining usage statistics for the random generator use system calls outside the mutex locks to prevent them from becoming bottleneck. ** libgnutls: gnutls_db_check_entry_time will correctly report the time; report and patch by Jonathan Roudiere. ** API and ABI modifications: gnutls_x509_policy_release: Exported gnutls_pubkey_set_key_usage: Exported gnutls_x509_privkey_import_rsa_raw2: Exported gnutls_pkcs11_token_get_flags: Exported gnutls_pubkey_get_pk_ecc_x962: Exported gnutls_pubkey_import_ecc_x962: Exported gnutls_rnd_refresh: Exported gnutls_mac_get_nonce_size: Exported gnutls_x509_crl_get_raw_issuer_dn: Exported gnutls_certificate_get_crt_raw: Exported gnutls_db_get_default_cache_expiration: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.10.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Jan 31 17:44:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 Jan 2014 17:44:50 +0100 Subject: [gnutls-help] gnutls 3.1.20 Message-ID: <52EBD302.50407@gnutls.org> Hello, I've just released gnutls 3.1.20. This is a bug-fix release on the previous stable branch. * Version 3.1.20 (released 2014-01-31) ** libgnutls: fixed null pointer derefence when printing a certificate DN and an LDAP description isn't present. ** libgnutls: gnutls_db_check_entry_time will correctly report the time; report and patch by Jonathan Roudiere. ** API and ABI modifications: gnutls_x509_policy_release: Exported gnutls_pubkey_set_key_usage: Exported gnutls_x509_privkey_import_rsa_raw2: Exported gnutls_pkcs11_token_get_flags: Exported gnutls_pubkey_get_pk_ecc_x962: Exported gnutls_pubkey_import_ecc_x962: Exported gnutls_rnd_refresh: Exported gnutls_x509_crl_get_raw_issuer_dn: Exported Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.20.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos