From nmav at gnutls.org Fri Jun 1 13:28:23 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 1 Jun 2012 13:28:23 +0200 Subject: LDAP over SSL does not work with Ubuntu Prolonged Pain In-Reply-To: References: <4FAC0892.3040600@gnutls.org>

<4FBBA78B.1000900@gnutls.org> <4FBBC6FF.1070700@gnutls.org> <4FBC966F.4040607@gnutls.org> <4FBD33A0.7070501@gnutls.org> Message-ID: On Thu, May 31, 2012 at 2:24 PM, Thorsten Glaser wrote: > In the meanwhile, I tested this patch on Debian squeeze (exemplarily; > lenny is also affected), *buntu hardy, lucid, oneiric and precise, > and it works (turns out the older versions are also affected). I only > had thought it to be a regression since we used to have > ? ? ? ?TLS_CACERT ? ? ?/etc/ssl/certs/dc.lan.tarent.de.cer > in our /etc/ldap/ldap.conf, and my coworker?s new setup places the > whole ca-certificates.crt file there, instead of just the certificate > of the CA who signed the LDAP servers? certs. Thanks. > There?s a comment typo (isser instead of issuer) and a few occurences of > trailing whitespace in the patch. I'll correct it. regards, Nikos From nmav at gnutls.org Tue Jun 5 19:36:42 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 05 Jun 2012 19:36:42 +0200 Subject: gnutls 3.0.20 Message-ID: <4FCE43AA.60806@gnutls.org> Hello, I've just released gnutls 3.0.20. This is a minor feature update and bug-fix release on the current stable branch. * Version 3.0.20 (released 2012-06-05) ** libgnutls: Corrected bug which prevented the parsing of handshake packets spanning multiple records. ** libgnutls: Check key identifiers when checking for an issuer. ** libgnutls: Added gnutls_pubkey_verify_hash2() ** libgnutls: Added gnutls_certificate_set_x509_system_trust() that loads the trusted CA certificates from system locations (e.g. trusted storage in windows and CA bundle files in other systems). ** certtool: Added support for the URI subject alternative name type in certtool. ** certtool: Increase to 128 the maximum number of distinct options (e.g. dns_names) allowed. ** gnutls-cli: If --print-cert is given, print the certificate, even on verification failure. ** API and ABI modifications: gnutls_pk_to_sign: Added gnutls_pubkey_verify_hash2: Added gnutls_certificate_set_x509_system_trust: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.20.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.20.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.20.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.20.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.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 From latze at angry-red-pla.net Sat Jun 9 12:36:09 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sat, 09 Jun 2012 12:36:09 +0200 Subject: how to use gnutls_privkey_import_ext Message-ID: <4FD32719.6010102@angry-red-pla.net> Hi all I tried to port some of my really old code to a new version of GnuTLS. I used a signing callback in order to let the TPM sign data. However since gnutls_sign_callback_set is deprecated now I tried to move to gnutls_privkey_import_ext. Here is what I did: I defined an empty privkey structure (since the privkey is stored within the TPM): const gnutls_datum_t key = { NULL, 0 }; I took my old sign callback and assigned it to that structure: gnutls_privkey_import_ext(&key,NULL,NULL,gnutls_tpm_sign,NULL,0); gnutls_certificate_set_x509_key_mem(xcred, &ccert, &key, GNUTLS_X509_FMT_PEM); But now when I try to run the handshake, I get: GnuTLS error: Insufficient credentials for that request. Segmentation fault (core dumped) Since I have debug messages in my sign function I know that it does never execute that function Are there any examples on how to use privkey_import_ext? I did not find any so far :-/ PKCS#11 is not really an option since that comes with some limitations on the TPM... Regards Carolin From nmav at gnutls.org Sun Jun 10 02:47:29 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 02:47:29 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD32719.6010102@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> Message-ID: <4FD3EEA1.8070507@gnutls.org> On 06/09/2012 12:36 PM, Carolin Latze wrote: > Hi all > > I tried to port some of my really old code to a new version of GnuTLS. I > used a signing callback in order to let the TPM sign data. However since > gnutls_sign_callback_set is deprecated now I tried to move to > gnutls_privkey_import_ext. Here is what I did: > > I defined an empty privkey structure (since the privkey is stored within > the TPM): > const gnutls_datum_t key = { NULL, 0 }; > > I took my old sign callback and assigned it to that structure: > gnutls_privkey_import_ext(&key,NULL,NULL,gnutls_tpm_sign,NULL,0); Hello, Did you check the error code from this function? It should have failed because it requires a sign function and a decryption function. You also do not set the public key algorithm to be used and put a NULL there. If you do not want to use decryption, then put a dummy function that always returns an error code and then make sure you use ciphersuites that require signing (DHE-RSA/ECDHE-RSA). > PKCS#11 is not really an option since that comes with some limitations > on the TPM... I see that trousers comes with a PKCS #11 module (or they claim to). I've never tried it, but doesn't it work? regards, Nikos From latze at angry-red-pla.net Sun Jun 10 11:37:28 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 11:37:28 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD3EEA1.8070507@gnutls.org> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> Message-ID: <4FD46AD8.3090703@angry-red-pla.net> Hi Nikos, On 06/10/2012 02:47 AM, Nikos Mavrogiannopoulos wrote: > On 06/09/2012 12:36 PM, Carolin Latze wrote: > > >> Hi all >> >> I tried to port some of my really old code to a new version of GnuTLS. I >> used a signing callback in order to let the TPM sign data. However since >> gnutls_sign_callback_set is deprecated now I tried to move to >> gnutls_privkey_import_ext. Here is what I did: >> >> I defined an empty privkey structure (since the privkey is stored within >> the TPM): >> const gnutls_datum_t key = { NULL, 0 }; >> >> I took my old sign callback and assigned it to that structure: >> gnutls_privkey_import_ext(&key,NULL,NULL,gnutls_tpm_sign,NULL,0); >> > > Hello, > Did you check the error code from this function? It should have failed > because it requires a sign function and a decryption function. You also > do not set the public key algorithm to be used and put a NULL there. > I also tried with GNUTLS_PK_RSA, but that did not help. And yeah I also switched on logging with a level of 15, but did not really see what the problem could. Well I thought it would be the pk algorithm, but as I said, that did not solve the problem. > If you do not want to use decryption, then put a dummy function that > always returns an error code and then make sure you use ciphersuites > that require signing (DHE-RSA/ECDHE-RSA). > Ok, I will try that. > > >> PKCS#11 is not really an option since that comes with some limitations >> on the TPM... >> > > I see that trousers comes with a PKCS #11 module (or they claim to). > I've never tried it, but doesn't it work? > It does. But the TPM has never been designed to meet the PKCS#11 spec, so it requires for instance to set some keys to NULL. I could do that but I need to clear and reset my TPM to do that and I was hoping that I could prevent that. Maybe that is the next thing I try if I don't manage to get the other function to work. Regards Carolin From nmav at gnutls.org Sun Jun 10 11:55:29 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 11:55:29 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD46AD8.3090703@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> Message-ID: <4FD46F11.9000009@gnutls.org> On 06/10/2012 11:37 AM, Carolin Latze wrote: >> Hello, >> Did you check the error code from this function? It should have failed >> because it requires a sign function and a decryption function. You also >> do not set the public key algorithm to be used and put a NULL there. > I also tried with GNUTLS_PK_RSA, but that did not help. And yeah I also > switched on logging with a level of 15, but did not really see what the > problem could. Well I thought it would be the pk algorithm, but as I > said, that did not solve the problem. Note that I didn't refer to logging but to checking the error code returned by the function. If such a function fails the results are inpredictable (like the crash you see). If possible send me an output of valgrind with the crash to see whether an error code can be returned instead of crash. >> I see that trousers comes with a PKCS #11 module (or they claim to). >> I've never tried it, but doesn't it work? > It does. But the TPM has never been designed to meet the PKCS#11 spec, > so it requires for instance to set some keys to NULL. I could do that > but I need to clear and reset my TPM to do that and I was hoping that I > could prevent that. Maybe that is the next thing I try if I don't manage > to get the other function to work. This function works (I know it is used in windows which usually has no pkcs #11), so if you have more issues let me know. Just make sure you provide functions of the correct type (note that the parameters in gnutls_privkey_sign_func are different than the old gnutls_sign_func). btw. If you manage to use the TPM with this, would be nice if you point me to your code (if it is lgpl). Would be nice to have some code to use TPM. regards, Nikos From latze at angry-red-pla.net Sun Jun 10 11:58:31 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 11:58:31 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD46F11.9000009@gnutls.org> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> Message-ID: <4FD46FC7.3060808@angry-red-pla.net> On 06/10/2012 11:55 AM, Nikos Mavrogiannopoulos wrote: > On 06/10/2012 11:37 AM, Carolin Latze wrote: > > > >>> Hello, >>> Did you check the error code from this function? It should have failed >>> because it requires a sign function and a decryption function. You also >>> do not set the public key algorithm to be used and put a NULL there. >>> > > >> I also tried with GNUTLS_PK_RSA, but that did not help. And yeah I also >> switched on logging with a level of 15, but did not really see what the >> problem could. Well I thought it would be the pk algorithm, but as I >> said, that did not solve the problem. >> > > Note that I didn't refer to logging but to checking the error code > returned by the function. If such a function fails the results are > inpredictable (like the crash you see). If possible send me an output of > valgrind with the crash to see whether an error code can be returned > instead of crash. > I will try that. > >>> I see that trousers comes with a PKCS #11 module (or they claim to). >>> I've never tried it, but doesn't it work? >>> >> It does. But the TPM has never been designed to meet the PKCS#11 spec, >> so it requires for instance to set some keys to NULL. I could do that >> but I need to clear and reset my TPM to do that and I was hoping that I >> could prevent that. Maybe that is the next thing I try if I don't manage >> to get the other function to work. >> > > This function works (I know it is used in windows which usually has no > pkcs #11), so if you have more issues let me know. Just make sure you > provide functions of the correct type (note that the parameters in > gnutls_privkey_sign_func are different than the old gnutls_sign_func). > Aha, ok, that helps :) I will rewrite the sign callback then. > btw. If you manage to use the TPM with this, would be nice if you point > me to your code (if it is lgpl). Would be nice to have some code to use TPM. > Yeah sure. > regards, > Nikos > From latze at angry-red-pla.net Sun Jun 10 12:56:02 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 12:56:02 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD46FC7.3060808@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> Message-ID: <4FD47D42.7090100@angry-red-pla.net> Ok, this is what I did now: I defined a sign_func and a decrypt_func based on the type found in abstract.h: int gnutls_tpm_sign_func (gnutls_privkey_t key, void *userdata, const gnutls_datum_t * raw_data, gnutls_datum_t * signature); int gnutls_tpm_decrypt_func (gnutls_privkey_t key, void *userdata, const gnutls_datum_t * ciphertext, gnutls_datum_t * plaintext); The decrypt func will just return -1, whereas the sign func will call the TPM. Furthermore I create a NULL privkey: gnutls_privkey_t key; gnutls_privkey_init(&key); and assigned a NULL privkey to the credentials of this session: (even if I assign the &key here, it does not help) gnutls_certificate_set_x509_key_mem(xcred, &ccert, NULL, GNUTLS_X509_FMT_PEM); Later, after gnutls_init, I tried to import the key callbacks: gnutls_privkey_import_ext(key,GNUTLS_PK_RSA,NULL,gnutls_tpm_sign_func,gnutls_tpm_decrypt_func,0); Now I see that gnutls_privkey_import_ext is executed without problems (no errors, no segfault, valgrind just silent), but none of the callbacks will be called. I guess I miss something during the initialization. Do you have an idea what I miss here? Regards Carolin On 06/10/2012 11:58 AM, Carolin Latze wrote: > On 06/10/2012 11:55 AM, Nikos Mavrogiannopoulos wrote: >> On 06/10/2012 11:37 AM, Carolin Latze wrote: >> >> >>>> Hello, >>>> Did you check the error code from this function? It should have >>>> failed >>>> because it requires a sign function and a decryption function. You >>>> also >>>> do not set the public key algorithm to be used and put a NULL there. >> >>> I also tried with GNUTLS_PK_RSA, but that did not help. And yeah I also >>> switched on logging with a level of 15, but did not really see what the >>> problem could. Well I thought it would be the pk algorithm, but as I >>> said, that did not solve the problem. >> >> Note that I didn't refer to logging but to checking the error code >> returned by the function. If such a function fails the results are >> inpredictable (like the crash you see). If possible send me an output of >> valgrind with the crash to see whether an error code can be returned >> instead of crash. > I will try that. >>>> I see that trousers comes with a PKCS #11 module (or they claim to). >>>> I've never tried it, but doesn't it work? >>> It does. But the TPM has never been designed to meet the PKCS#11 spec, >>> so it requires for instance to set some keys to NULL. I could do that >>> but I need to clear and reset my TPM to do that and I was hoping that I >>> could prevent that. Maybe that is the next thing I try if I don't >>> manage >>> to get the other function to work. >> >> This function works (I know it is used in windows which usually has no >> pkcs #11), so if you have more issues let me know. Just make sure you >> provide functions of the correct type (note that the parameters in >> gnutls_privkey_sign_func are different than the old gnutls_sign_func). > Aha, ok, that helps :) I will rewrite the sign callback then. >> btw. If you manage to use the TPM with this, would be nice if you point >> me to your code (if it is lgpl). Would be nice to have some code to >> use TPM. > Yeah sure. >> regards, >> Nikos > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls From nmav at gnutls.org Sun Jun 10 13:07:17 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 13:07:17 +0200 Subject: gnutls 2.12.20 Message-ID: <4FD47FE5.6030806@gnutls.org> Hello, I've just released gnutls 2.12.19. It includes few bug fixes. Version 2.12.20 (released 2012-06-10) ** libgnutls: Fixed memory leak in PKCS #8 key import. ** libgnutls: Check key identifiers when checking for an issuer. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.20.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.20.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.20.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.20.tar.bz2.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 Sun Jun 10 13:18:39 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 13:18:39 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD47D42.7090100@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> Message-ID: <4FD4828F.6030904@gnutls.org> On 06/10/2012 12:56 PM, Carolin Latze wrote: > gnutls_privkey_t key; > gnutls_privkey_init(&key); > > and assigned a NULL privkey to the credentials of this session: (even if > I assign the &key here, it does not help) > > gnutls_certificate_set_x509_key_mem(xcred, &ccert, NULL, > GNUTLS_X509_FMT_PEM); Unfortunately you cannot call this. If you have a gnutls_privkey_t you need to use gnutls_certificate_set_key(). That means that you'll have to import the certificate and convert it to gnutls_pcert_st. A helper function is indeed needed in that case. regards, Nikos From latze at angry-red-pla.net Sun Jun 10 14:51:14 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 14:51:14 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD4828F.6030904@gnutls.org> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> Message-ID: <4FD49842.4060101@angry-red-pla.net> yay, that works ( I do it with a cert_callback now). I just need to restrict the hash algorithms to SHA-1 since the TPM refuses to sign an SHA256 hash :-/ need to figure out how to do this. If all is running fine I need to clean up the code and will send it to you. On 06/10/2012 01:18 PM, Nikos Mavrogiannopoulos wrote: > On 06/10/2012 12:56 PM, Carolin Latze wrote: > > > >> gnutls_privkey_t key; >> gnutls_privkey_init(&key); >> >> and assigned a NULL privkey to the credentials of this session: (even if >> I assign the&key here, it does not help) >> >> gnutls_certificate_set_x509_key_mem(xcred,&ccert, NULL, >> GNUTLS_X509_FMT_PEM); >> > > Unfortunately you cannot call this. If you have a gnutls_privkey_t you > need to use gnutls_certificate_set_key(). That means that you'll have to > import the certificate and convert it to gnutls_pcert_st. A helper > function is indeed needed in that case. > > regards, > Nikos > From nmav at gnutls.org Sun Jun 10 15:26:16 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 15:26:16 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD49842.4060101@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> <4FD49842.4060101@angry-red-pla.net> Message-ID: <4FD4A078.4030804@gnutls.org> On 06/10/2012 02:51 PM, Carolin Latze wrote: > yay, that works ( I do it with a cert_callback now). I just need to > restrict the hash algorithms to SHA-1 since the TPM refuses to sign an > SHA256 hash :-/ > need to figure out how to do this. If all is running fine I need to > clean up the code and will send it to you. This you can control using the priority string. Add "-SIGN-ALL:+SIGN-SHA1". regards, Nikos From latze at angry-red-pla.net Sun Jun 10 17:08:18 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 17:08:18 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD4A078.4030804@gnutls.org> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> <4FD49842.4060101@angry-red-pla.net> <4FD4A078.4030804@gnutls.org> Message-ID: <4FD4B862.9010703@angry-red-pla.net> shy question: what type of hashes will be delivered with RSA-SHA1? I get a hash of 35 bytes length, which is a bit too long for a standard SHA1. And it is too short for the old SHA1+MD5 hash that used to used in TLS. On 06/10/2012 03:26 PM, Nikos Mavrogiannopoulos wrote: > On 06/10/2012 02:51 PM, Carolin Latze wrote: > > >> yay, that works ( I do it with a cert_callback now). I just need to >> restrict the hash algorithms to SHA-1 since the TPM refuses to sign an >> SHA256 hash :-/ >> > >> need to figure out how to do this. If all is running fine I need to >> > >> clean up the code and will send it to you. >> > > This you can control using the priority string. Add "-SIGN-ALL:+SIGN-SHA1". > > regards, > Nikos > From nmav at gnutls.org Sun Jun 10 17:25:23 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 17:25:23 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD4B862.9010703@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> <4FD49842.4060101@angry-red-pla.net> <4FD4A078.4030804@gnutls.org> <4FD4B862.9010703@angry-red-pla.net> Message-ID: <4FD4BC63.9000501@gnutls.org> On 06/10/2012 05:08 PM, Carolin Latze wrote: > shy question: what type of hashes will be delivered with RSA-SHA1? I get > a hash of 35 bytes length, which is a bit too long for a standard SHA1. > And it is too short for the old SHA1+MD5 hash that used to used in TLS. It should be the PKCS #1 encoding applied after hashing. It includes an algorithm identifier. From latze at angry-red-pla.net Sun Jun 10 19:36:58 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 19:36:58 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD4BC63.9000501@gnutls.org> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> <4FD49842.4060101@angry-red-pla.net> <4FD4A078.4030804@gnutls.org> <4FD4B862.9010703@angry-red-pla.net> <4FD4BC63.9000501@gnutls.org> Message-ID: <4FD4DB3A.5020508@angry-red-pla.net> I am sorry, but this still causes me some troubles. As far as I understand it, the hash in PKCS#1 is: bytes 00 - 14: algorithm identifier + some more bytes bytes 15 - 20: the hash So I thought it might be sufficient do define a new gnutls_datum_t vdata with vdata.data = &raw_data->data[15] vdata.size = raw_data->size-15 Did not work :) The TPM was happy, but the TLS handshake ended with "Public key signature verification has failed." Next try: r=asn1_der_decoding(&dinfo,raw_data->data,raw_data->size,NULL); if (r!=ASN1_SUCCESS) printf("ERROR: asn1_der_decoding: %s\n",asn2err(r)); r=asn1_read_value(dinfo,"digest",&vdata.data,&vdata.size); if (r!=ASN1_SUCCESS) printf("ERROR: asn1_read_value: %s\n",asn2err(r)); However, this (=both functions) ends with GNUTLS_E_ASN1_ELEMENT_NOT_FOUND. When I check decode_ber_digest_info in the GnuTLS code I see that you initialize it first, probably with the GnuTLS ASN.1 type. So this is probably the reason for this error, however I see no easy way to initialize it in my code. Is there any function that does that already? On 06/10/2012 05:25 PM, Nikos Mavrogiannopoulos wrote: > On 06/10/2012 05:08 PM, Carolin Latze wrote: > > >> shy question: what type of hashes will be delivered with RSA-SHA1? I get >> a hash of 35 bytes length, which is a bit too long for a standard SHA1. >> And it is too short for the old SHA1+MD5 hash that used to used in TLS. >> > > It should be the PKCS #1 encoding applied after hashing. It includes an > algorithm identifier. > > > From nmav at gnutls.org Sun Jun 10 20:45:46 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Jun 2012 20:45:46 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD4DB3A.5020508@angry-red-pla.net> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> <4FD49842.4060101@angry-red-pla.net> <4FD4A078.4030804@gnutls.org> <4FD4B862.9010703@angry-red-pla.net> <4FD4BC63.9000501@gnutls.org> <4FD4DB3A.5020508@angry-red-pla.net> Message-ID: <4FD4EB5A.8030701@gnutls.org> On 06/10/2012 07:36 PM, Carolin Latze wrote: > I am sorry, but this still causes me some troubles. > > As far as I understand it, the hash in PKCS#1 is: > > bytes 00 - 14: algorithm identifier + some more bytes > bytes 15 - 20: the hash > So I thought it might be sufficient do define a new gnutls_datum_t vdata > with > vdata.data = &raw_data->data[15] > vdata.size = raw_data->size-15 Why do you do that? You're not supposed to interpret that data, just sign it using raw RSA. You should treat it the same way you treated the MD5+SHA1 combo in TLS 1.0. regards, Nikos From latze at angry-red-pla.net Sun Jun 10 21:15:35 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Sun, 10 Jun 2012 21:15:35 +0200 Subject: how to use gnutls_privkey_import_ext In-Reply-To: <4FD4EB5A.8030701@gnutls.org> References: <4FD32719.6010102@angry-red-pla.net> <4FD3EEA1.8070507@gnutls.org> <4FD46AD8.3090703@angry-red-pla.net> <4FD46F11.9000009@gnutls.org> <4FD46FC7.3060808@angry-red-pla.net> <4FD47D42.7090100@angry-red-pla.net> <4FD4828F.6030904@gnutls.org> <4FD49842.4060101@angry-red-pla.net> <4FD4A078.4030804@gnutls.org> <4FD4B862.9010703@angry-red-pla.net> <4FD4BC63.9000501@gnutls.org> <4FD4DB3A.5020508@angry-red-pla.net> <4FD4EB5A.8030701@gnutls.org> Message-ID: <4FD4F257.2090304@angry-red-pla.net> On 06/10/2012 08:45 PM, Nikos Mavrogiannopoulos wrote: > On 06/10/2012 07:36 PM, Carolin Latze wrote: > > >> I am sorry, but this still causes me some troubles. >> >> As far as I understand it, the hash in PKCS#1 is: >> >> bytes 00 - 14: algorithm identifier + some more bytes >> bytes 15 - 20: the hash >> So I thought it might be sufficient do define a new gnutls_datum_t vdata >> with >> vdata.data =&raw_data->data[15] >> vdata.size = raw_data->size-15 >> > > Why do you do that? You're not supposed to interpret that data, just > sign it using raw RSA. You should treat it the same way you treated the > MD5+SHA1 combo in TLS 1.0. > > Hm. I cannot send more than 20 bytes to the TPM sign function, so I would need to encrypt. As far as I remember the TLS 1.2 RFC, the goal was to have 20 bytes and be able to use standard signature functions instead of encryption as it was in TLS <1.2. So maybe other cryptographic modules are able to handle the complete PKCS#1 structure, but unfortunately, the TPM is not. From mike at cchtml.com Fri Jun 15 00:17:39 2012 From: mike at cchtml.com (Michael Cronenworth) Date: Thu, 14 Jun 2012 17:17:39 -0500 Subject: network transfer performance Message-ID: <4FDA6303.8040807@cchtml.com> Hello, I have developed a GnuTLS client/server app. The server and client live on the same machine and are using the system loopback for talking to each other. It takes about 10 seconds to transfer 100MB (byte) of data from the server to the client. If I use SSH (SCP/SFTP) to transfer files through localhost, I see about 14MB per second speeds. This speed seems low, too, but shows my app is doing about as good as it can. Running iperf reports my loopback can get about 30 gigabits per second so there is no bottleneck there. Yes, I realize SSL connections have overhead, but with my system[1] I feel like data transfer should be faster than 10MB/second. Is what I am seeing normal (AES processing) or is there anything I can do to speed any of this up? Thanks, Michael [1] Core i5 750 (quad core 2.6ghz) 8GB RAM Fedora 17 x86_64 GnuTLS 2.12.17 Priorities: "NONE:+VERS-TLS1.1:+AES-256-CBC:+RSA:+SHA1:+COMP-NULL" From nmav at gnutls.org Fri Jun 15 08:31:51 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 15 Jun 2012 08:31:51 +0200 Subject: network transfer performance In-Reply-To: <4FDA6303.8040807@cchtml.com> References: <4FDA6303.8040807@cchtml.com> Message-ID: On Fri, Jun 15, 2012 at 12:17 AM, Michael Cronenworth wrote: > Yes, I realize SSL connections have overhead, but with my system[1] I > feel like data transfer should be faster than 10MB/second. > Is what I am seeing normal (AES processing) or is there anything I can > do to speed any of this up? > Core i5 750 (quad core 2.6ghz) > 8GB RAM > Fedora 17 x86_64 > GnuTLS 2.12.17 > Priorities: "NONE:+VERS-TLS1.1:+AES-256-CBC:+RSA:+SHA1:+COMP-NULL" Hello Michael, There are few things you can do to speed a connection up. But first a question, is gnutls linked in your system with libgcrypt or libnettle? The latter provides a 2x performance boost in most algorithms. Now about your selection of algorithms. Why AES-256 and not 128? If transfer speed is your only concern ARCFOUR-128 is the cipher with best performance. You may also use HMAC-MD5 instead of HMAC-SHA1 to boost speed at the cost of using a borderline algorithm. regards, Nikos From mike at cchtml.com Fri Jun 15 09:12:04 2012 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 15 Jun 2012 02:12:04 -0500 Subject: network transfer performance In-Reply-To: References: <4FDA6303.8040807@cchtml.com> Message-ID: <4FDAE044.2010009@cchtml.com> On 06/15/2012 01:31 AM, Nikos Mavrogiannopoulos wrote: > There are few things you can do to speed a connection up. But first a > question, is gnutls linked in your system with libgcrypt or libnettle? > The latter provides a 2x performance boost in most algorithms. Now > about your selection of algorithms. Why AES-256 and not 128? If > transfer speed is your only concern ARCFOUR-128 is the cipher with > best performance. You may also use HMAC-MD5 instead of HMAC-SHA1 to > boost speed at the cost of using a borderline algorithm. Fedora uses libgcrypt. 128-bit vs 256-bit didn't provide any tangible difference in my testing. I'll give all those ciphers a shot and look into using libnettle. Thanks! From scott.mcgillivray at gmail.com Sun Jun 17 11:58:01 2012 From: scott.mcgillivray at gmail.com (Scott McGillivray) Date: Sun, 17 Jun 2012 10:58:01 +0100 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers Message-ID: Hi, On my older Debian server running gnutls-cli (GnuTLS) 2.8.5 if i test various websites located behind a Cisco CSS load balancer that does the SSL offload with command "gnutls-cli accounts.codemasters.com" it works OK but with a newer install of Debian server running gnutls-cli 3.0.20 if i issue the same command then i get the below error. Processed 153 CA certificate(s). Resolving 'accounts.codemasters.com'... Connecting to '94.75.196.190:443'... |<1>| Note that the security level of the Diffie-Hellman key exchange has been lowered to 512 bits and this may allow decryption of the session data *** Fatal error: The TLS connection was non-properly terminated. No certificates found! *** Handshake has failed GnuTLS error: The TLS connection was non-properly terminated. If i try to connect to https://accounts.codemasters.com using Firefox, Chrome or openssl s_client then it works fine. So it seems that GnuTLS 3.0.x has a bug maybe? On the server running gnuTLS 3.0.20 i am able to run gnutls-cli against other sites such as google.com, hotmail.com etc.. and it works fine so i know that it works, just not against the sites where the SSL offload is performed by these Cisco CSS load balancers. On the gnuTLS 2.8.5 install i noticed that the client/server hello is processed ok as seen in the debug output below |<3>| HSK[0x9342d78]: CLIENT HELLO was send [136 bytes] |<2>| ASSERT: gnutls_cipher.c:204 |<2>| ASSERT: gnutls_cipher.c:204 |<3>| HSK[0x9342d78]: SERVER HELLO was received [74 bytes] |<3>| HSK[0x9342d78]: Server's version: 3.1 |<3>| HSK[0x9342d78]: SessionID length: 32 |<3>| HSK[0x9342d78]: SessionID: a32ec5fb0f2fef86bbc660747ee3cd49f0d68483ced53f116f451a96a2ad97d0 |<3>| HSK[0x9342d78]: Selected cipher suite: RSA_ARCFOUR_MD5 |<2>| ASSERT: gnutls_extensions.c:124 |<2>| ASSERT: gnutls_cipher.c:204 |<3>| HSK[0x9342d78]: CERTIFICATE was received [3602 bytes] but on the 3.2.20 install i get |<3>| HSK[0x1b5c550]: CLIENT HELLO was queued [217 bytes] |<7>| HWRITE: enqueued [CLIENT HELLO] 217. Total 217 bytes. |<7>| HWRITE FLUSH: 217 bytes in buffer. |<4>| REC[0x1b5c550]: Preparing Packet Handshake(22) with length: 217 |<9>| ENC[0x1b5c550]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<7>| WRITE: enqueued 222 bytes for 0x4. Total 222 bytes. |<4>| REC[0x1b5c550]: Sent Packet[1] Handshake(22) in epoch 0 and length: 222 |<7>| HWRITE: wrote 1 bytes, 0 bytes left. |<7>| WRITE FLUSH: 222 bytes in buffer. |<7>| WRITE: wrote 222 bytes, 0 bytes left. |<2>| ASSERT: gnutls_buffers.c:974 |<7>| READ: Got 0 bytes from 0x4 |<7>| READ: read 0 bytes from 0x4 |<2>| ASSERT: gnutls_buffers.c:482 |<2>| ASSERT: gnutls_record.c:876 |<2>| ASSERT: gnutls_record.c:986 |<2>| ASSERT: gnutls_buffers.c:1175 |<2>| ASSERT: gnutls_handshake.c:1269 |<2>| ASSERT: gnutls_handshake.c:2484 *** Fatal error: The TLS connection was non-properly terminated. |<2>| ASSERT: gnutls_ui.c:544 No certificates found! |<4>| REC: Sending Alert[2|10] - Unexpected message |<4>| REC[0x1b5c550]: Preparing Packet Alert(21) with length: 2 |<9>| ENC[0x1b5c550]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes. |<7>| WRITE FLUSH: 7 bytes in buffer. |<2>| errno: 32 |<2>| ASSERT: gnutls_buffers.c:374 |<7>| WRITE error: code -53, 7 bytes left. |<2>| ASSERT: gnutls_buffers.c:599 |<2>| ASSERT: gnutls_record.c:456 *** Handshake has failed GnuTLS error: The TLS connection was non-properly terminated. Can anyone suggest how i can fix this ? I'm trying to to use a program that needs gnuTLS 3.x libs so i can't just use gnuTLS 2.x that works. Also the Cisco devices are running the latest and greatest firmware from Cisco circa Dec 2011. many thanks Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at kde.org Sun Jun 17 16:15:58 2012 From: rich at kde.org (Richard Moore) Date: Sun, 17 Jun 2012 15:15:58 +0100 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: References: Message-ID: On 17 June 2012 10:58, Scott McGillivray wrote: > Can anyone suggest how i can fix this ? I'm trying to to use a program that > needs gnuTLS 3.x libs so i can't just use gnuTLS 2.x that works. Also the > Cisco devices are running the latest and greatest firmware from Cisco circa > Dec 2011. I'd try disabling TLS extensions using --disable-extensions and see if that makes a difference. I've found with some cisco devices that compression causes them to drop the connection. Cheers Rich. From scott.mcgillivray at gmail.com Sun Jun 17 18:30:47 2012 From: scott.mcgillivray at gmail.com (Scott McGillivray) Date: Sun, 17 Jun 2012 17:30:47 +0100 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: References:

Message-ID: On 17 June 2012 15:15, Richard Moore wrote: > On 17 June 2012 10:58, Scott McGillivray > wrote: > > Can anyone suggest how i can fix this ? I'm trying to to use a program > that > > needs gnuTLS 3.x libs so i can't just use gnuTLS 2.x that works. Also the > > Cisco devices are running the latest and greatest firmware from Cisco > circa > > Dec 2011. > > I'd try disabling TLS extensions using --disable-extensions and see if > that makes a difference. I've found with some cisco devices that > compression causes them to drop the connection. > > Cheers > > Rich. > Thanks for the suggestion. I tried that option as well as many of the other options from the gnutls-cli man page and none of them made any difference. -------------- next part -------------- An HTML attachment was scrubbed... URL: From help-gnutls-phil at spodhuis.org Mon Jun 18 01:23:20 2012 From: help-gnutls-phil at spodhuis.org (Phil Pennock) Date: Sun, 17 Jun 2012 16:23:20 -0700 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: References: Message-ID: <20120617232320.GA65479@redoubt.spodhuis.org> On 2012-06-17 at 10:58 +0100, Scott McGillivray wrote: > If i try to connect to https://accounts.codemasters.com using Firefox, > Chrome or openssl s_client then it works fine. Failed for me with openssl s_client, 1.0.1c. Succeeded with 0.9.8r. Succeeded with OpenSSL 1.0.1c once I added -no_tls1_2 to the command-line. Looks as though the site breaks with TLS 1.2. -Phil From scott.mcgillivray at gmail.com Mon Jun 18 10:50:27 2012 From: scott.mcgillivray at gmail.com (Scott McGillivray) Date: Mon, 18 Jun 2012 09:50:27 +0100 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: <20120617232320.GA65479@redoubt.spodhuis.org> References: <20120617232320.GA65479@redoubt.spodhuis.org> Message-ID: I've tried with OpenSSL 0.9.8k and OpenSSL 1.0.1 which both work ok with no special options. The Cisco CSS is quite an old load balancer and doesn't support TLS 1.1 let alone TLS 1.2 so I'm not sure why openssl 1.0.1c would fail until you specifically told it to ignore TLS 1.2. I thought as part of the negotiation, openssl would have detected that TLS 1.0 was only supported. I had a quick look through the openssl changelog ( http://www.openssl.org/news/changelog.html) to see if there was any obvious changes between 1.0.1 and 1.0.1c that might cause the problem but nothing jumped out to me. I don't know if the problem see in openssl 1.0.1c might be related to the problem I'm seeing in gnutls 3.0.20? I couldn't see a similar option for gnutls-cli to force TLS 1.0 or ignore TLS 1.2 for me to test. Thanks for the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott.mcgillivray at gmail.com Mon Jun 18 11:36:08 2012 From: scott.mcgillivray at gmail.com (Scott McGillivray) Date: Mon, 18 Jun 2012 10:36:08 +0100 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: References: <20120617232320.GA65479@redoubt.spodhuis.org> Message-ID: On 18 June 2012 10:03, Richard Moore wrote: > On 18 June 2012 09:50, Scott McGillivray > wrote: > > I don't know if the problem see in openssl 1.0.1c might be related to the > > problem I'm seeing in gnutls 3.0.20? I couldn't see a similar option for > > gnutls-cli to force TLS 1.0 or ignore TLS 1.2 for me to test. > > --protocols > > Rich. > Many thanks, that allowed me to connect. i think the --protocols option is deprecated, i couldn't find it in in man pages, but i was able to successfully connect to the site using the below command which does the same thing. gnutls-cli --priority NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT accounts.codemasters.com Info on the command found at http://www.gnu.org/software/gnutls/manual/gnutls.html#Interoperability I wonder what has changed in gnutls and openssl in recent versions that prevents them from gratefully downgrading to a supported TLS version when connecting to these Cisco CSS units. Thanks again for your help. Scott. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich at kde.org Mon Jun 18 11:03:18 2012 From: rich at kde.org (Richard Moore) Date: Mon, 18 Jun 2012 10:03:18 +0100 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: References: <20120617232320.GA65479@redoubt.spodhuis.org> Message-ID: On 18 June 2012 09:50, Scott McGillivray wrote: > I don't know if the problem see in openssl 1.0.1c might be related to the > problem I'm seeing in gnutls 3.0.20? I couldn't see a similar option for > gnutls-cli to force TLS 1.0 or ignore TLS 1.2 for me to test. --protocols Rich. From nmav at gnutls.org Tue Jun 19 00:28:11 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 19 Jun 2012 00:28:11 +0200 Subject: gnuTLS 3.0.20 - 'Fatal error: The TLS connection was non-properly terminated' against Cisco load balancers In-Reply-To: References: <20120617232320.GA65479@redoubt.spodhuis.org>

Message-ID: <4FDFAB7B.2060109@gnutls.org> On 06/18/2012 11:36 AM, Scott McGillivray wrote: > gnutls-cli --priority > NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT > accounts.codemasters.com > > Info on the command found at > http://www.gnu.org/software/gnutls/manual/gnutls.html#Interoperability > > I wonder what has changed in gnutls and openssl in recent versions that > prevents them from gratefully downgrading to a supported TLS version when > connecting to these Cisco CSS units. The downgrade occurs on the server side. In the case you describe most probably it's a broken server. regards, Nikos From mike at cchtml.com Fri Jun 22 17:15:10 2012 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 22 Jun 2012 10:15:10 -0500 Subject: network transfer performance In-Reply-To: <4FDAE044.2010009@cchtml.com> References: <4FDA6303.8040807@cchtml.com> <4FDAE044.2010009@cchtml.com> Message-ID: <4FE48BFE.3060006@cchtml.com> Michael Cronenworth wrote: > Fedora uses libgcrypt. 128-bit vs 256-bit didn't provide any tangible > difference in my testing. I'll give all those ciphers a shot and look > into using libnettle. Thanks! Using libnettle with ARCFOUR-128 and MD5 nets me about a 2 second improvement. (8 seconds down from 10 seconds for 100MB) Perf shows all the processing is happening in libnettle on both the client and server side so none of my code should be holding up the transfer. client (top two lines): 25.76% foo libnettle.so.4.3 [.] nettle_arcfour_crypt 18.61% foo libnettle.so.4.3 [.] _nettle_md5_compress server (top two lines): 16.17% bar libnettle.so.4.3 [.] nettle_arcfour_crypt 13.19% bar libnettle.so.4.3 [.] _nettle_md5_compress When I run "top" during the transfer the client and server process take ~30% of a CPU core each, so it still seems like something is bottlenecking the processes, but I have exhausted my knowledge on profiling. Anything else I can look at?