From dev.admin at ntlworld.com Tue Jun 1 01:53:52 2010 From: dev.admin at ntlworld.com (dev.admin at ntlworld.com) Date: Tue, 1 Jun 2010 00:53:52 +0100 Subject: [2.8.6] build time symbol not found error. In-Reply-To: <87mxvghqo2.fsf@mocca.josefsson.org> References: <87mxvghqo2.fsf@mocca.josefsson.org> Message-ID: <0EC5D802-627A-4E0B-AA36-178DE9D7D913@ntlworld.com> Simon, It's being build on an iMac in 64bit. I've just rebuilt all the dependencies using only dynamic libraries and gnuTLS build OK as dynamic. I'll try and find the offending library and get back to you. It'll take some time to eliminate. Andrew. From carolin.latze at unifr.ch Tue Jun 1 16:45:21 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Tue, 1 Jun 2010 16:45:21 +0200 Subject: how to send arbitrary data in supplemental data message In-Reply-To: <4C03D925.70200@gnutls.org> References: <4C024695.4090809@gnutls.org> <4C03D280.7020203@unifr.ch> <4C03D925.70200@gnutls.org> Message-ID: <4C051D01.5020903@unifr.ch> Thanks a lot!!!! Works now. Carolin On 05/31/2010 05:43 PM, Nikos Mavrogiannopoulos wrote: > Carolin Latze wrote: > > Here is the trouble maker: > _gnutls_buffer_append(buf, > session->security_parameters.extensions.aik_sent->data, > (uint8_t) > session->security_parameters.extensions.aik_sent->size); > > Remove the cast (uint8_t) to solve the issue. You're are effectively > doing a (mod 256) to the data size. > > > regards, > Nikos > > > >> Hi Nikos, >> >> On 05/30/2010 01:05 PM, Nikos Mavrogiannopoulos wrote: >> >>> LATZE Carolin wrote: >>> >>> >>>> Hi everybody, >>>> >>>> I ran again into problems with the supplemental data messages. I >>>> tried to copy a certificate into the buffer of type gnutls_buffer and >>>> do not manage to send all 1314 bytes of the certificate. Instead it >>>> sends only 41 bytes. I tried it with another certificate which >>>> resulted in 65 bytes sent. This is pretty strange. I expected the >>>> buffer to stop at a \0 character in the signature, but that does not >>>> seem to be the case since strlen of the original data results in the >>>> correct length of 1314. Any ideas? >>>> >>>> In order to simplify debugging, I copied my gnutls version including >>>> the tls-tpm extension (not finished yet, but does not cause crashes >>>> :-)) onto a server: >>>> http://diuf.unifr.ch/people/latzec/gnutls-CL-28052010.tar.gz >>>> >>>> Furthermore, I uploaded my little sample program as well: >>>> http://diuf.unifr.ch/people/latzec/sample.tar.gz >>>> >>>> I would be happy for any hints or ideas since I am clueless at the >>>> moment. >>>> >>>> >>> Could you use debugging output with >>> gnutls_global_set_log_function (tls_log_func); >>> gnutls_global_set_log_level (level); >>> ? >>> >>> >>> >> Oh sorry, I did that already (with level 3), but forgot to add the file. >> You find it here: >> >> http://diuf.unifr.ch/people/latzec/out >> >> Thats the output of the client who is supposed to send the supplemental >> data. >> >> Carolin >> >> >>> Level 2 should be sufficient. >>> >>> regards, >>> Nikos >>> >>> >>> >>> >>> >> > From mwd at cert.org Wed Jun 2 16:59:42 2010 From: mwd at cert.org (Michael Welsh Duggan) Date: Wed, 02 Jun 2010 10:59:42 -0400 Subject: Checking expiry of my own certificates Message-ID: I work on a project where we have written a client and server that use GnuTLS to communicate. Specifically, the client and server use gnutls_certificate_set_x509_trust_file() to load a CA and gnutls_certificate_set_x509_simple_pkcs12_file() to load a password protected certificate/key pair. Recently we have had an experience attempting to communicate using certificates that have expired. When using certs that have expired, the call to gnutls_certificate_verify_peers2() will set the GNUTLS_CERT_EXPIRED flag in the 'status' variable (assuming GnuTLS 2.6.6 or later---thanks for adding this check). What we would rather have happen is that when the client or server start, they check the expiration times on the certificates they read, and exit if they find no valid certificates. This saves us from attempting a connection that is going to be rejected because of the expired certificates. Once we've loaded the CA into the gnutls_certificate_credentials_t structure, we can use gnutls_certificate_get_x509_cas() to loop over the CAs and check their activation and expiration times (using gnutls_x509_crt_get_activation_time()). However, we don't see a way to do that with the certificate/key pair that we load. gnutls_x509_crt_list_verify() looks close, however it does not check the activation/expiration times, and we haven't found a function that lets me get a certificate list from a gnutls_certificate_credentials_t structure. Are we missing something? Are there other suggestions on how to perform this check? -- Michael Welsh Duggan (mwd at cert.org) From fweimer at bfk.de Fri Jun 4 10:32:24 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 04 Jun 2010 08:32:24 +0000 Subject: Purpose of gnutls_credentials_set Message-ID: <82r5knkxk7.fsf@mid.bfk.de> I'm somewhat mystified what this function (and the surrounding constructs) is supposed to do. I'm calling gnutls_certificate_set_x509_trust_mem and gnutls_certificate_set_x509_key in the client, but in itself, that does not cause failures when connecting to a server which presents the wrong certificate, nor does it cause the client to send along a certificate (for that, I've found that I have to install a callback using gnutls_certificate_client_set_retrieve_function). For certificate verification to happen, it seems that I need to call gnutls_certificate_verify_peers2 (or implement some sort of verification manually). Perhaps this could be clarified in the documentation? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Fri Jun 4 10:49:51 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 04 Jun 2010 08:49:51 +0000 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: <200606220130.53330.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu\, 22 Jun 2006 01\:30\:53 +0200") References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> <200606220130.53330.nmav@gnutls.org> Message-ID: <82bpbrkwr4.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: >> May I assume that the first certificate returned by >> gnutls_certifcate_get_peers contains public key material which >> actually corresponds to the private key material which was used to >> establish the ssession? > No. That would be the last certificate in the chain. But the documentation says: Get the peer's raw certificate (chain) as sent by the peer. These certificates are in raw format (DER encoded for X.509). In case of a X.509 then a certificate list may be present. The first certificate in the list is the peer's certificate, following the issuer's certificate, then the issuer's issuer etc. So which one is correct? 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nmav at gnutls.org Fri Jun 4 13:40:25 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Jun 2010 13:40:25 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: <82bpbrkwr4.fsf@mid.bfk.de> References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> <200606220130.53330.nmav@gnutls.org> <82bpbrkwr4.fsf@mid.bfk.de> Message-ID: On Fri, Jun 4, 2010 at 10:49 AM, Florian Weimer wrote: > * Nikos Mavrogiannopoulos: > >>> May I assume that the first certificate returned by >>> gnutls_certifcate_get_peers contains public key material which >>> actually corresponds to the private key material which was used to >>> establish the ssession? > >> No. That would be the last certificate in the chain. > > But the documentation says: > > ? ? Get the peer's raw certificate (chain) as sent by the peer. ?These > ? ? certificates are in raw format (DER encoded for X.509). ?In case of > ? ? a X.509 then a certificate list may be present. ?The first > ? ? certificate in the list is the peer's certificate, following the > ? ? issuer's certificate, then the issuer's issuer etc. > So which one is correct? 8-) The documentation is correct. Did I really say the thing above? :) regards, Nikos From nmav at gnutls.org Fri Jun 4 13:42:56 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Jun 2010 13:42:56 +0200 Subject: Purpose of gnutls_credentials_set In-Reply-To: <82r5knkxk7.fsf@mid.bfk.de> References: <82r5knkxk7.fsf@mid.bfk.de> Message-ID: After or during the handshake (with a callback that I don't remember its name) you should verify the certificate chain received by peer. For that you can use gnutls_certificate_verify_peers2(). Could you suggest the points in documentation that were not clear for you, so we can correct them? The problem when I read the documentation is that I know everything :) that needs to be done thus such things are easy to miss. regards, Nikos On Fri, Jun 4, 2010 at 10:32 AM, Florian Weimer wrote: > I'm somewhat mystified what this function (and the surrounding > constructs) is supposed to do. ?I'm calling > gnutls_certificate_set_x509_trust_mem and > gnutls_certificate_set_x509_key in the client, but in itself, that > does not cause failures when connecting to a server which presents the > wrong certificate, nor does it cause the client to send along a > certificate (for that, I've found that I have to install a callback > using gnutls_certificate_client_set_retrieve_function). ?For > certificate verification to happen, it seems that I need to call > gnutls_certificate_verify_peers2 (or implement some sort of > verification manually). > > Perhaps this could be clarified in the documentation? > > -- > Florian Weimer ? ? ? ? ? ? ? ? > BFK edv-consulting GmbH ? ? ? http://www.bfk.de/ > Kriegsstra?e 100 ? ? ? ? ? ? ?tel: +49-721-96201-1 > D-76133 Karlsruhe ? ? ? ? ? ? fax: +49-721-96201-99 > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From fweimer at bfk.de Fri Jun 4 17:10:17 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 04 Jun 2010 15:10:17 +0000 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri\, 4 Jun 2010 13\:40\:25 +0200") References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> <200606220130.53330.nmav@gnutls.org> <82bpbrkwr4.fsf@mid.bfk.de> Message-ID: <82zkzaj0km.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > On Fri, Jun 4, 2010 at 10:49 AM, Florian Weimer wrote: >> * Nikos Mavrogiannopoulos: >> >>>> May I assume that the first certificate returned by >>>> gnutls_certifcate_get_peers contains public key material which >>>> actually corresponds to the private key material which was used to >>>> establish the ssession? >> >>> No. That would be the last certificate in the chain. >> >> But the documentation says: >> >> ? ? Get the peer's raw certificate (chain) as sent by the peer. ?These >> ? ? certificates are in raw format (DER encoded for X.509). ?In case of >> ? ? a X.509 then a certificate list may be present. ?The first >> ? ? certificate in the list is the peer's certificate, following the >> ? ? issuer's certificate, then the issuer's issuer etc. >> So which one is correct? 8-) > > The documentation is correct. Did I really say the thing above? :) Yes, but that was a long time ago. 8-) Thanks for the clarification. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Fri Jun 4 18:23:45 2010 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 04 Jun 2010 16:23:45 +0000 Subject: Purpose of gnutls_credentials_set In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri\, 4 Jun 2010 13\:42\:56 +0200") References: <82r5knkxk7.fsf@mid.bfk.de> Message-ID: <82631yhilq.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > After or during the handshake (with a callback that I don't remember > its name) you should verify the certificate chain received by peer. > For that you can use gnutls_certificate_verify_peers2(). Could you > suggest the points in documentation that were not clear for you, so we > can correct them? The problem when I read the documentation is that I > know everything :) that needs to be done thus such things are easy to > miss. gnutls_certificate_set_x509_key, gnutls_certificate_set_x509_key_mem, gnutls_certificate_set_x509_key_file should mention that they are only relevant to the server side, and that on the client side, gnutls_certificate_client_set_retrieve_function has to be used to install a callback which provides the certificate to send to the server. Splitting the "Core functions" section in the manual might also make sense (into certificate, session, session credentials functions, etc.). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Mon Jun 7 17:37:11 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Jun 2010 17:37:11 +0200 Subject: Checking expiry of my own certificates In-Reply-To: (Michael Welsh Duggan's message of "Wed, 02 Jun 2010 10:59:42 -0400") References: Message-ID: <87ocfm26s8.fsf@mocca.josefsson.org> Michael Welsh Duggan writes: > I work on a project where we have written a client and server that use > GnuTLS to communicate. Specifically, the client and server use > gnutls_certificate_set_x509_trust_file() to load a CA and > gnutls_certificate_set_x509_simple_pkcs12_file() to load a password > protected certificate/key pair. > > Recently we have had an experience attempting to communicate using > certificates that have expired. When using certs that have expired, > the call to gnutls_certificate_verify_peers2() will set the > GNUTLS_CERT_EXPIRED flag in the 'status' variable (assuming GnuTLS > 2.6.6 or later---thanks for adding this check). > > What we would rather have happen is that when the client or server > start, they check the expiration times on the certificates they read, > and exit if they find no valid certificates. This saves us from > attempting a connection that is going to be rejected because of the > expired certificates. > > Once we've loaded the CA into the gnutls_certificate_credentials_t > structure, we can use gnutls_certificate_get_x509_cas() to loop over > the CAs and check their activation and expiration times (using > gnutls_x509_crt_get_activation_time()). > > However, we don't see a way to do that with the certificate/key pair > that we load. gnutls_x509_crt_list_verify() looks close, however it > does not check the activation/expiration times, and we haven't found a > function that lets me get a certificate list from a > gnutls_certificate_credentials_t structure. > > Are we missing something? Are there other suggestions on how to perform > this check? Doesn't gnutls_x509_crt_list_verify check times? If I read the code for gnutls_certificate_verify_peers2, it calls _gnutls_x509_cert_verify_peers which calls gnutls_x509_crt_list_verify. I can't find any time checks outside of that function. Note that the function trims trusted certificates from the list of certificates to check expiration dates on. It could be a bug, see if you can create a small test case that calls gnutls_x509_crt_list_verify on a chain which doesn't fail but should. /Simon From mwd at cert.org Mon Jun 7 19:42:57 2010 From: mwd at cert.org (Michael Welsh Duggan) Date: Mon, 7 Jun 2010 13:42:57 -0400 Subject: Checking expiry of my own certificates Message-ID: On Mon, 7 Jun 2010 11:37:11 -0400, Simon Josefsson wrote: > Michael Welsh Duggan writes: > >> However, we don't see a way to do that with the certificate/key >> pair that we load. gnutls_x509_crt_list_verify() looks close, >> however it does not check the activation/expiration times, and we >> haven't found a function that lets me get a certificate list from >> a gnutls_certificate_credentials_t structure. > > Doesn't gnutls_x509_crt_list_verify check times? If I read the code for > gnutls_certificate_verify_peers2, it calls > _gnutls_x509_cert_verify_peers which calls gnutls_x509_crt_list_verify. > I can't find any time checks outside of that function. Yes, you are correct. gnutls_x509_crt_list_verify() does verify the times. I meant to write that gnutls_x509_crt_verify() does not the times. However, we are still confused on how to get from a gnutls_certificate_credentials_t struct to the list of certificates that we can pass to gnutls_x509_crt_list_verify(). Thanks. -- Michael Welsh Duggan (mwd at cert.org) From mwd at cert.org Mon Jun 7 19:56:30 2010 From: mwd at cert.org (Michael Welsh Duggan) Date: Mon, 07 Jun 2010 13:56:30 -0400 Subject: Checking expiry of my own certificates In-Reply-To: (Michael Welsh Duggan's message of "Mon, 7 Jun 2010 13:42:57 -0400") References: Message-ID: Michael Welsh Duggan writes: > On Mon, 7 Jun 2010 11:37:11 -0400, Simon Josefsson wrote: > >> Michael Welsh Duggan writes: >> >>> However, we don't see a way to do that with the certificate/key >>> pair that we load. gnutls_x509_crt_list_verify() looks close, >>> however it does not check the activation/expiration times, and we >>> haven't found a function that lets me get a certificate list from >>> a gnutls_certificate_credentials_t structure. >> >> Doesn't gnutls_x509_crt_list_verify check times? If I read the code for >> gnutls_certificate_verify_peers2, it calls >> _gnutls_x509_cert_verify_peers which calls gnutls_x509_crt_list_verify. >> I can't find any time checks outside of that function. > > Yes, you are correct. gnutls_x509_crt_list_verify() does verify the > times. > > I meant to write that gnutls_x509_crt_verify() does not the times. Sorry, I meant: I meant to write that gnutls_x509_crt_verify() does not verify the times. > However, we are still confused on how to get from a > gnutls_certificate_credentials_t struct to the list of certificates > that we can pass to gnutls_x509_crt_list_verify(). > > Thanks. -- Michael Welsh Duggan (mwd at cert.org) From nmav at gnutls.org Mon Jun 7 20:08:36 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 07 Jun 2010 20:08:36 +0200 Subject: Checking expiry of my own certificates In-Reply-To: References: Message-ID: <4C0D35A4.9000601@gnutls.org> Michael Welsh Duggan wrote: > On Mon, 7 Jun 2010 11:37:11 -0400, Simon Josefsson wrote: > >> Michael Welsh Duggan writes: >> >>> However, we don't see a way to do that with the certificate/key >>> pair that we load. gnutls_x509_crt_list_verify() looks close, >>> however it does not check the activation/expiration times, and we >>> haven't found a function that lets me get a certificate list from >>> a gnutls_certificate_credentials_t structure. >> Doesn't gnutls_x509_crt_list_verify check times? If I read the code for >> gnutls_certificate_verify_peers2, it calls >> _gnutls_x509_cert_verify_peers which calls gnutls_x509_crt_list_verify. >> I can't find any time checks outside of that function. > > Yes, you are correct. gnutls_x509_crt_list_verify() does verify the > times. > > I meant to write that gnutls_x509_crt_verify() does not the times. > > However, we are still confused on how to get from a > gnutls_certificate_credentials_t struct to the list of certificates > that we can pass to gnutls_x509_crt_list_verify(). You cannot. You can use gnutls_certificate_verify_peers2() to use that list for verification, or you can load the trusted certificates independently using gnutls_x509_crt_list_import(). regards, Nikos From simon at josefsson.org Fri Jun 11 16:28:17 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 11 Jun 2010 16:28:17 +0200 Subject: Getting keys for my own crtypto functions (opencdk) In-Reply-To: <4C124433.8080507@iri.com> (Kahnan Patel's message of "Fri, 11 Jun 2010 10:12:03 -0400") References: <4C124433.8080507@iri.com> Message-ID: <87mxv14pa6.fsf@mocca.josefsson.org> Kahnan Patel writes: > Hi Sir, > > My name is Kahnan Patel and I need some help regarding: > > cdk_error_t cdk_pubkey_to_sexp (cdk_pkt_pubkey_t pk, char **sexp, size_t * len); > cdk_error_t cdk_seckey_to_sexp (cdk_pkt_seckey_t sk, char **sexp, size_t * len); > > > > I just implement my code using this function and everything worked > fine, but as you mention that you have already tested this function > with libgcrypt to get key from key ring by it's id and use that key in > this sexp and encrypt and decrypt. > > So if you can sent me that code or if you can just guid me how to > convert ascii armor to "cdk_pkt_pubkey_t pk" object then I will > really appreciate this. The OpenCDK library is (alas) no longer available as a separate package, so you should first try to map the above APIs to GnuTLS functions. /Simon From zhirkow at yahoo.com Mon Jun 14 07:07:52 2010 From: zhirkow at yahoo.com (Artem Zhirkow) Date: Sun, 13 Jun 2010 22:07:52 -0700 (PDT) Subject: Apache crashes when mod_php uses curl that build with gnutls Message-ID: <465314.77946.qm@web63707.mail.re1.yahoo.com> Hi, I got many problems with my apache webserver when I tried to use php configured with curl support. Curl was build with gnutls-2.8.6 and openssl-0.9.8n. Apache crashed with apache2: ath.c:213: _gcry_ath_mutex_unlock: Assertion `*lock == ((ath_mutex_t) 1)' failed. message in error_log. Isnt it gnutls problem? Since I rebuild curl without gnutls support everything means to be ok. I using non-threaded apache 2.2.15 (with mpm-itk)? and php 5.2.13 and curl 7.20.0-r2 on gentoo x86_64. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Jun 14 09:34:22 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Jun 2010 09:34:22 +0200 Subject: Apache crashes when mod_php uses curl that build with gnutls In-Reply-To: <465314.77946.qm@web63707.mail.re1.yahoo.com> References: <465314.77946.qm@web63707.mail.re1.yahoo.com> Message-ID: It should be some locking issue in curl. You'd better report it to the authors of the programs you're using directly. 2010/6/14 Artem Zhirkow > Hi, > I got many problems with my apache webserver when I tried to use php > configured with curl support. Curl was build with gnutls-2.8.6 and > openssl-0.9.8n. Apache crashed with > > apache2: ath.c:213: _gcry_ath_mutex_unlock: Assertion `*lock == > ((ath_mutex_t) 1)' failed. > > message in error_log. Isnt it gnutls problem? Since I rebuild curl without > gnutls support everything means to be ok. I using non-threaded apache 2.2.15 > (with mpm-itk) and php 5.2.13 and curl 7.20.0-r2 on gentoo x86_64. > Thanks > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sun Jun 20 21:13:02 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 20 Jun 2010 21:13:02 +0200 Subject: Purpose of gnutls_credentials_set In-Reply-To: <82631yhilq.fsf@mid.bfk.de> References: <82r5knkxk7.fsf@mid.bfk.de> <82631yhilq.fsf@mid.bfk.de> Message-ID: <4C1E683E.5050703@gnutls.org> Florian Weimer wrote: > * Nikos Mavrogiannopoulos: > >> After or during the handshake (with a callback that I don't remember >> its name) you should verify the certificate chain received by peer. >> For that you can use gnutls_certificate_verify_peers2(). Could you >> suggest the points in documentation that were not clear for you, so we >> can correct them? The problem when I read the documentation is that I >> know everything :) that needs to be done thus such things are easy to >> miss. > gnutls_certificate_set_x509_key, gnutls_certificate_set_x509_key_mem, > gnutls_certificate_set_x509_key_file should mention that they are only > relevant to the server side, and that on the client side, > gnutls_certificate_client_set_retrieve_function has to be used to > install a callback which provides the certificate to send to the > server. Hi, Actually those functions you mention are valid for both client and server side. The callback is optional and suitable for the case where you might not initially know which certificate to load. regards, Nikos From fweimer at bfk.de Mon Jun 21 09:06:15 2010 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 21 Jun 2010 07:06:15 +0000 Subject: Purpose of gnutls_credentials_set In-Reply-To: <4C1E683E.5050703@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun\, 20 Jun 2010 21\:13\:02 +0200") References: <82r5knkxk7.fsf@mid.bfk.de> <82631yhilq.fsf@mid.bfk.de> <4C1E683E.5050703@gnutls.org> Message-ID: <82631c50go.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > Florian Weimer wrote: >> * Nikos Mavrogiannopoulos: >> >>> After or during the handshake (with a callback that I don't remember >>> its name) you should verify the certificate chain received by peer. >>> For that you can use gnutls_certificate_verify_peers2(). Could you >>> suggest the points in documentation that were not clear for you, so we >>> can correct them? The problem when I read the documentation is that I >>> know everything :) that needs to be done thus such things are easy to >>> miss. >> gnutls_certificate_set_x509_key, gnutls_certificate_set_x509_key_mem, >> gnutls_certificate_set_x509_key_file should mention that they are only >> relevant to the server side, and that on the client side, >> gnutls_certificate_client_set_retrieve_function has to be used to >> install a callback which provides the certificate to send to the >> server. > > Hi, > Actually those functions you mention are valid for both client and > server side. The callback is optional and suitable for the case where > you might not initially know which certificate to load. But if I don't use the callback, the client does not actually send the certificate, so I'm now totally confused. 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nmav at gnutls.org Mon Jun 21 10:20:26 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Jun 2010 10:20:26 +0200 Subject: Purpose of gnutls_credentials_set In-Reply-To: <82631c50go.fsf@mid.bfk.de> References: <82r5knkxk7.fsf@mid.bfk.de> <82631yhilq.fsf@mid.bfk.de> <4C1E683E.5050703@gnutls.org> <82631c50go.fsf@mid.bfk.de> Message-ID: The client sends the certificate if the server requests a certificate signed with its CA. Does the server request for such a certificate? (you can check with wireshark, or you can print in the callback the DNs of the CAs that the server supports). regards, Nikos On Mon, Jun 21, 2010 at 9:06 AM, Florian Weimer wrote: > * Nikos Mavrogiannopoulos: > >> Florian Weimer wrote: >>> * Nikos Mavrogiannopoulos: >>> >>>> After or during the handshake (with a callback that I don't remember >>>> its name) you should verify the certificate chain received by peer. >>>> For that you can use gnutls_certificate_verify_peers2(). Could you >>>> suggest the points in documentation that were not clear for you, so we >>>> can correct them? The problem when I read the documentation is that I >>>> know everything :) that needs to be done thus such things are easy to >>>> miss. >>> gnutls_certificate_set_x509_key, gnutls_certificate_set_x509_key_mem, >>> gnutls_certificate_set_x509_key_file should mention that they are only >>> relevant to the server side, and that on the client side, >>> gnutls_certificate_client_set_retrieve_function has to be used to >>> install a callback which provides the certificate to send to the >>> server. >> >> ?Hi, >> Actually those functions you mention are valid for both client and >> server side. The callback is optional and suitable for the case where >> you might not initially know which certificate to load. > > But if I don't use the callback, the client does not actually send the > certificate, so I'm now totally confused. 8-) > > -- > Florian Weimer ? ? ? ? ? ? ? ? > BFK edv-consulting GmbH ? ? ? http://www.bfk.de/ > Kriegsstra?e 100 ? ? ? ? ? ? ?tel: +49-721-96201-1 > D-76133 Karlsruhe ? ? ? ? ? ? fax: +49-721-96201-99 > From fweimer at bfk.de Mon Jun 21 10:34:53 2010 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 21 Jun 2010 08:34:53 +0000 Subject: Purpose of gnutls_credentials_set In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon\, 21 Jun 2010 10\:20\:26 +0200") References: <82r5knkxk7.fsf@mid.bfk.de> <82631yhilq.fsf@mid.bfk.de> <4C1E683E.5050703@gnutls.org> <82631c50go.fsf@mid.bfk.de> Message-ID: <82lja8zsuq.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > The client sends the certificate if the server requests a certificate > signed with its CA. Aha! This is somewhat non-obvious and certainly not a typical application. > Does the server request for such a certificate? (you can check with > wireshark, or you can print in the callback the DNs of the CAs that > the server supports). No, all certificates are self-signed. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From lars at public.noschinski.de Mon Jun 21 10:58:38 2010 From: lars at public.noschinski.de (Lars Noschinski) Date: Mon, 21 Jun 2010 10:58:38 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME Message-ID: <20100621085837.GA5689@lars.home.noschinski.de> Hi, I am wondering when the flag GNUTLS_VERIFY_DO_NOT_ALLOW_SAME should be used. I've seen it in use in the Wocky library[0], which is used by the instant messenger client empathy. This flag seems to prevent connections to servers using certificates from CAcert.org, as their root and class3 certificates[1] use MD5 and are hence deemed insecure by gnutls; i.e. $ gnutls-cli jabberd.jabber.ccc.de --x509cafile /tmp/cacert.crt succeeds (where cacert.crt is the concatenation of both the cacert.org certificates), but if I patch gnutls-cli to set GNUTLS_VERIFY_DO_NOT_ALLOW_SAME, it fails. Now, this is probably intended behaviour for GnuTLS, but I wonder whether this flag is a sensible choice for such a client application? -- Lars [0] , in particular [1] From simon at josefsson.org Mon Jun 21 11:32:19 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 21 Jun 2010 11:32:19 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: <20100621085837.GA5689@lars.home.noschinski.de> (Lars Noschinski's message of "Mon, 21 Jun 2010 10:58:38 +0200") References: <20100621085837.GA5689@lars.home.noschinski.de> Message-ID: <87y6e8ybmk.fsf@mocca.josefsson.org> Lars Noschinski writes: > Hi, > > I am wondering when the flag GNUTLS_VERIFY_DO_NOT_ALLOW_SAME should be > used. I've seen it in use in the Wocky library[0], which is used by the > instant messenger client empathy. > > This flag seems to prevent connections to servers using certificates > from CAcert.org, as their root and class3 certificates[1] use MD5 and are > hence deemed insecure by gnutls; i.e. > > $ gnutls-cli jabberd.jabber.ccc.de --x509cafile /tmp/cacert.crt > > succeeds (where cacert.crt is the concatenation of both the cacert.org > certificates), but if I patch gnutls-cli to set > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME, it fails. > > Now, this is probably intended behaviour for GnuTLS, but I wonder > whether this flag is a sensible choice for such a client application? I don't see any normal situation where this flag is useful. I'm not sure the behaviour you see is actually intended, I don't see why it should reject the chain here. So it may be a bug... The flag _may_ be useful if you have a X.509 Version 1 certificate as a trust anchor. You may want to trust a X.509v1 CA for verifying server certificates signed by the X.509v1 CA, but you definitely do not want to accept that certificate as the server certificate (because there are no name restriction extensions). On the other hand, you shouldn't use X.509v1 certificates anyway... /Simon From lars at public.noschinski.de Mon Jun 21 12:43:43 2010 From: lars at public.noschinski.de (Lars Noschinski) Date: Mon, 21 Jun 2010 12:43:43 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: <87y6e8ybmk.fsf@mocca.josefsson.org> References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> Message-ID: <20100621104343.GA11713@lars.home.noschinski.de> * Simon Josefsson [10-06-21 11:32]: > > I am wondering when the flag GNUTLS_VERIFY_DO_NOT_ALLOW_SAME should be > > used. I've seen it in use in the Wocky library[0], which is used by the > > instant messenger client empathy. [...] > I don't see any normal situation where this flag is useful. > > I'm not sure the behaviour you see is actually intended, I don't see why > it should reject the chain here. So it may be a bug... > > The flag _may_ be useful if you have a X.509 Version 1 certificate as a > trust anchor. You may want to trust a X.509v1 CA for verifying server > certificates signed by the X.509v1 CA, but you definitely do not want to > accept that certificate as the server certificate (because there are no > name restriction extensions). On the other hand, you shouldn't use > X.509v1 certificates anyway... Just to clarify: Using GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT without GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a sane choice (if one stills needs to deal with X.509v1 certificates). -- Lars From nmav at gnutls.org Mon Jun 21 13:06:13 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Jun 2010 13:06:13 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: <20100621104343.GA11713@lars.home.noschinski.de> References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> <20100621104343.GA11713@lars.home.noschinski.de> Message-ID: On Mon, Jun 21, 2010 at 12:43 PM, Lars Noschinski wrote: >> I don't see any normal situation where this flag is useful. >> >> I'm not sure the behaviour you see is actually intended, I don't see why >> it should reject the chain here. ?So it may be a bug... >> >> The flag _may_ be useful if you have a X.509 Version 1 certificate as a >> trust anchor. ?You may want to trust a X.509v1 CA for verifying server >> certificates signed by the X.509v1 CA, but you definitely do not want to >> accept that certificate as the server certificate (because there are no >> name restriction extensions). ?On the other hand, you shouldn't use >> X.509v1 certificates anyway... > > Just to clarify: Using GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT without > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a sane choice (if one stills needs to > deal with X.509v1 certificates). The GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a flag, to make the trusted certificate list, a list that can only certify other keys. That is it will not allow a certificate from this list to be used as a server certificate. So how it works it depends on your usage of this list. If you add end server certificates there maybe GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is not a good option for you. But for other uses it is quite sensible. regards, Nikos From lars at public.noschinski.de Mon Jun 21 13:23:07 2010 From: lars at public.noschinski.de (Lars Noschinski) Date: Mon, 21 Jun 2010 13:23:07 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> <20100621104343.GA11713@lars.home.noschinski.de> Message-ID: <20100621112307.GA12100@lars.home.noschinski.de> * Nikos Mavrogiannopoulos [10-06-21 13:06]: > On Mon, Jun 21, 2010 at 12:43 PM, Lars Noschinski > wrote: > > >> I don't see any normal situation where this flag is useful. > >> > >> I'm not sure the behaviour you see is actually intended, I don't see why > >> it should reject the chain here. ?So it may be a bug... > >> > >> The flag _may_ be useful if you have a X.509 Version 1 certificate as a > >> trust anchor. ?You may want to trust a X.509v1 CA for verifying server > >> certificates signed by the X.509v1 CA, but you definitely do not want to > >> accept that certificate as the server certificate (because there are no > >> name restriction extensions). ?On the other hand, you shouldn't use > >> X.509v1 certificates anyway... > > > > Just to clarify: Using GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT without > > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a sane choice (if one stills needs to > > deal with X.509v1 certificates). > > The GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a flag, to make the trusted > certificate list, a list that can only certify other keys. That is it > will not allow a certificate from this list to be used as a server > certificate. So how it works it depends on your usage of this list. If > you add end server certificates there maybe > GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is not a good option for you. But for > other uses it is quite sensible. Ok. But in this case, the behaviour I observed seems to be indeed a bug in gnutls, as my certificate list did not contain the server's certificate, but only the CA certificates. From nmav at gnutls.org Mon Jun 21 13:46:40 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Jun 2010 13:46:40 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> <20100621104343.GA11713@lars.home.noschinski.de> <20100621112307.GA12100@lars.home.noschinski.de> Message-ID: On Mon, Jun 21, 2010 at 1:45 PM, Nikos Mavrogiannopoulos wrote: >> Ok. But in this case, the behaviour I observed seems to be indeed a bug >> in gnutls, as my certificate list did not contain the server's >> certificate, but only the CA certificates. > Then please send me something I can reproduce (such as the smallest > possible list that I can use to verify the problem and how I can > verify it). And of course the version of gnutls you are using. If you are not using 1.8.x please reproduce with it. regards. Nikos From nmav at gnutls.org Mon Jun 21 13:45:41 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Jun 2010 13:45:41 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: <20100621112307.GA12100@lars.home.noschinski.de> References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> <20100621104343.GA11713@lars.home.noschinski.de> <20100621112307.GA12100@lars.home.noschinski.de> Message-ID: On Mon, Jun 21, 2010 at 1:23 PM, Lars Noschinski wrote: >> The GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is a flag, to make the trusted >> certificate list, a list that can only certify other keys. That is it >> will not allow a certificate from this list to be used as a server >> certificate. So how it works it depends on your usage of this list. If >> you add end server certificates there maybe >> GNUTLS_VERIFY_DO_NOT_ALLOW_SAME is not a good option for you. But for >> other uses it is quite sensible. > Ok. But in this case, the behaviour I observed seems to be indeed a bug > in gnutls, as my certificate list did not contain the server's > certificate, but only the CA certificates. Then please send me something I can reproduce (such as the smallest possible list that I can use to verify the problem and how I can verify it). regards, Nikos From lars at public.noschinski.de Mon Jun 21 14:58:21 2010 From: lars at public.noschinski.de (Lars Noschinski) Date: Mon, 21 Jun 2010 14:58:21 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> <20100621104343.GA11713@lars.home.noschinski.de> <20100621112307.GA12100@lars.home.noschinski.de> Message-ID: <20100621125821.GA14320@lars.home.noschinski.de> * Nikos Mavrogiannopoulos [10-06-21 13:46]: > On Mon, Jun 21, 2010 at 1:45 PM, Nikos Mavrogiannopoulos > wrote: > > >> Ok. But in this case, the behaviour I observed seems to be indeed a bug > >> in gnutls, as my certificate list did not contain the server's > >> certificate, but only the CA certificates. > > Then please send me something I can reproduce (such as the smallest > > possible list that I can use to verify the problem and how I can > > verify it). For the certificate list, see http://avalon.hoffentlich.net/~cebewee/debug/gnutls/cacert.crt (containing the CAcert.org root certificates). Now, $ gnutls-cli jabberd.jabber.ccc.de --x509cafile cacert.crt trusts the server certificate [0]. Now apply the patch [1] to cli.c and run the patched binary. Now $ gnutls-cli.patched jabberd.jabber.ccc.de --x509cafile cacert.crt fails to establish a trusted chain [2]. > And of course the version of gnutls you are using. If you are not > using 1.8.x please reproduce with it. You mean 2.8.x, correct? Reproduced using libgnutls26, 2.8.6-1 package from debian (the package does not contain code patches, only the patches in the debian/patches subdirectory of http://ftp.de.debian.org/debian/pool/main/g/gnutls26/gnutls26_2.8.6-1.debian.tar.gz ). -- Lars. [0] http://avalon.hoffentlich.net/~cebewee/debug/gnutls/gnutls-ok.log [1] http://avalon.hoffentlich.net/~cebewee/debug/gnutls/gnutls-cli.patch [2] http://avalon.hoffentlich.net/~cebewee/debug/gnutls/gnutls-fail.log From nmav at gnutls.org Mon Jun 21 18:51:29 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Jun 2010 18:51:29 +0200 Subject: Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME In-Reply-To: <20100621125821.GA14320@lars.home.noschinski.de> References: <20100621085837.GA5689@lars.home.noschinski.de> <87y6e8ybmk.fsf@mocca.josefsson.org> <20100621104343.GA11713@lars.home.noschinski.de> <20100621112307.GA12100@lars.home.noschinski.de> <20100621125821.GA14320@lars.home.noschinski.de> Message-ID: <4C1F9891.8050007@gnutls.org> Lars Noschinski wrote: >>>> Ok. But in this case, the behaviour I observed seems to be indeed a bug >>>> in gnutls, as my certificate list did not contain the server's >>>> certificate, but only the CA certificates. >>> Then please send me something I can reproduce (such as the smallest >>> possible list that I can use to verify the problem and how I can >>> verify it). > > For the certificate list, see > > http://avalon.hoffentlich.net/~cebewee/debug/gnutls/cacert.crt > > (containing the CAcert.org root certificates). > > Now, > > $ gnutls-cli jabberd.jabber.ccc.de --x509cafile cacert.crt > > trusts the server certificate [0]. Now apply the patch [1] to cli.c > and run the patched binary. Now Hi, Thank you. I've checked the issue and although it sounds strange this quirk of the flag has some logic here. Check what is the output of certtool -e to the list sent by jabberd: > Certificate[0]: C=DE,ST=Hamburg,L=Hamburg,O=Chaos Computer Club e.V.,CN=jabber.ccc.de > Issued by: O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root > Verifying against certificate[1]. > Verification output: Verified. > > Certificate[1]: O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root > Issued by: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org > Verifying against certificate[2]. > Verification output: Not verified, Insecure algorithm. > > Certificate[2]: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org > Issued by: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org > Verification output: Verified. > > Chain verification output: Not verified, Insecure algorithm. The Certificate[1] is signed using an insecure algorithm. Here you can see that normally gnutls should reject that certificate list. However if the DO_NOT_ALLOW_SAME flag is not set (default), gnutls will keep for verification only Certificate[0] and will verify it against the trusted list and thus passes. However if you set the flag then the list is verified as is and the last certificate in the list is checked against the trusted list. That is the reason for the different result. I have commited a fix in master to have the same result for both methods by allowing the shortening of the list even if the DO_NOT_ALLOW_SAME flag is set except for the 1st certificate (which is the certificate that the flag refers to). You can avoid the problem by having the server only send the first certificate. Sending the whole chain does not help any client who must anyway trust Certificate[1] explicitly since it is signed with insecure algorithm. regards, Nikos From simon at josefsson.org Fri Jun 25 09:57:04 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 25 Jun 2010 09:57:04 +0200 Subject: GnuTLS 2.10.0 released Message-ID: <8763171r5b.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.10.0. GnuTLS is a modern C library that implements the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnu.org/software/gnutls/ What's New ========== Version 2.10.0 is the first stable release on the 2.10.x branch and is the result of over 12 months of work on the experimental 2.9.x branch. The GnuTLS 2.10.x branch replaces the GnuTLS 2.8.x branch as the supported stable branch, although we will continue to support GnuTLS 2.8.x for some time. ** libgnutls: Added Steve Dispensa's patch for safe renegotiation (RFC 5746) Solves the issue discussed in: and . Note that to allow connecting to unpatched servers the full protection is only enabled if the priority string %SAFE_RENEGOTIATION is specified. You can check whether protection is in place by querying gnutls_safe_renegotiation_status(). New error codes GNUTLS_E_SAFE_RENEGOTIATION_FAILED and GNUTLS_E_UNSAFE_RENEGOTIATION_DENIED added. ** libgnutls: Time verification extended to trusted certificate list. Unless new constant GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS flag is specified. ** certtool: Display postalCode and Name X.509 DN attributes correctly. Based on patch by Pavan Konjarla. Adds new constant GNUTLS_OID_X520_POSTALCODE and GNUTLS_OID_X520_NAME. ** libgnutls: When checking openpgp self signature also check the signatures ** of all subkeys. Ilari Liusvaara noticed and reported the issue and provided test vectors as well. ** libgnutls: Added cryptodev support (/dev/crypto). Tested with http://home.gna.org/cryptodev-linux/. Added benchmark utility for AES. Adds new error codes GNUTLS_E_CRYPTODEV_IOCTL_ERROR and GNUTLS_E_CRYPTODEV_DEVICE_ERROR. ** libgnutls: Exported API to access encryption and hash algorithms. The new API functions are gnutls_cipher_decrypt, gnutls_cipher_deinit, gnutls_cipher_encrypt, gnutls_cipher_get_block_size, gnutls_cipher_init, gnutls_hash, gnutls_hash_deinit, gnutls_hash_fast, gnutls_hash_get_len, gnutls_hash_init, gnutls_hash_output, gnutls_hmac, gnutls_hmac_deinit, gnutls_hmac_fast, gnutls_hmac_get_len, gnutls_hmac_init, gnutls_hmac_output. New API constants are GNUTLS_MAC_SHA224 and GNUTLS_DIG_SHA224. ** libgnutls: Added gnutls_certificate_set_verify_function() to allow verification of certificate upon receipt rather than waiting until the end of the handshake. ** libgnutls: Don't send alerts during handshake. Instead new error code GNUTLS_E_UNKNOWN_SRP_USERNAME is added. ** certtool: Corrected two issues that affected certificate request generation. (1) Null padding is added on integers (found thanks to Wilankar Trupti), (2) In optional SignatureAlgorithm parameters field for DSA keys the DSA parameters were added. Those were rejected by Verisign. Gnutls no longer adds those parameters there since other implementations don't do either and having them does not seem to offer anything (anyway you need the signer's certificate to verify thus public key will be available). Found thanks to Boyan Kasarov. This however has the side-effect that public key IDs shown by certtool are now different than previous gnutls releases. (3) the option --pgp-certificate-info will verify self signatures ** certtool: Allow exporting of Certificate requests on DER format. ** certtool: New option --no-crq-extensions to avoid extensions in CSRs. ** gnutls-cli: Handle reading binary data from server. Reported by and tiny patch from Vitaly Mayatskikh in . ** minitasn1: Upgraded to libtasn1 version 2.6. ** doc: The GTK-DOC manual is significantly improved. ** doc: a PDF version of the API reference manual (GTK-DOC) is now built. ** doc: Terms 'GNUTLS' and 'GNU TLS' were changed to 'GnuTLS' for consistency. ** libgnutls: Cleanups and several bug fixes. Found by Steve Grubb and Tomas Mraz. ** Link libgcrypt explicitly to certtool, gnutls-cli, gnutls-serv. ** Fix --disable-valgrind-tests. Reported by Ingmar Vanhassel in . ** libgnutls: Fix for memory leaks on interrupted handshake. Reported by Tang Tong. ** libgnutls: Addition of support for TLS 1.2 signature algorithms ** extension and certificate verify field. This requires changes for TLS 1.2 servers and clients that use callbacks for certificate retrieval. They are now required to check with gnutls_sign_algorithm_get_requested() whether the certificate they send complies with the peer's preferences in signature algorithms. ** libgnutls: In server side when resuming a session do not overwrite the ** initial session data with the resumed session data. ** libgnutls: Added support for AES-128, AES-192 and AES-256 in PKCS #8 ** encryption. This affects also PKCS #12 encoded files. This adds the following new enums: GNUTLS_CIPHER_AES_192_CBC, GNUTLS_PKCS_USE_PBES2_AES_128, GNUTLS_PKCS_USE_PBES2_AES_192, GNUTLS_PKCS_USE_PBES2_AES_256. ** libgnutls: Fix PKCS#12 encoding. The error you would get was "The OID is not supported.". Problem introduced for the v2.8.x branch in 2.7.6. ** certtool: Added the --pkcs-cipher option. To explicitely specify the encryption algorithm to use. ** tests: Added "pkcs12_encode" self-test to check PKCS#12 functions. ** tests: Fix time bomb in chainverify self-test. Reported by Andreas Metzler in . ** tests: Fix expired cert in chainverify self-test. ** libgnutls: TLS 1.2 server mode fixes. Now interoperates against Opera. Contributed by Daiki Ueno. ** libgnutlsxx: Fix link problems. Tiny patch from Boyan Kasarov . ** guile: Compatibility with guile 2.x. By Ludovic Courtes . ** libgnutls: Enable Camellia ciphers by default. ** libgnutls: Add new functions to extract X.509 Issuer Alternative Names. The new functions are gnutls_x509_crt_get_issuer_alt_name2, gnutls_x509_crt_get_issuer_alt_name, and gnutls_x509_crt_get_issuer_alt_othername_oid. Contributed by Brad Hards . ** libgnutls: Client-side TLS 1.2 and SHA-256 ciphersuites now works. The new supported ciphersuites are AES-128/256 in CBC mode with ANON-DH/RSA/DHE-DSS/DHE-RSA. Contributed by Daiki Ueno. Further, SHA-256 is now the preferred default MAC (however it is only used with TLS 1.2). ** libgnutls: Make OpenPGP hostname checking work again. The patch to resolve the X.509 CN/SAN issue accidentally broken OpenPGP hostname comparison. ** libgnutls: When printing X.509 certificates, handle XMPP SANs better. Reported by Howard Chu in . ** Fix use of deprecated types internally. Use of deprecated types in GnuTLS from now on will lead to a compile error, to prevent this from happening again. ** libgnutls: Support for TLS tickets was contributed by Daiki Ueno. The new APIs are gnutls_session_ticket_enable_client, gnutls_session_ticket_enable_server, and gnutls_session_ticket_key_generate. ** gnutls-cli, gnutls-serv: New parameter --noticket to disable TLS tickets. ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields. By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS into 1) not printing the entire CN/SAN field value when printing a certificate and 2) cause incorrect positive matches when matching a hostname against a certificate. Some CAs apparently have poor checking of CN/SAN values and issue these (arguable invalid) certificates. Combined, this can be used by attackers to become a MITM on server-authenticated TLS sessions. The problem is mitigated since attackers needs to get one certificate per site they want to attack, and the attacker reveals his tracks by applying for a certificate at the CA. It does not apply to client authenticated TLS sessions. Research presented independently by Dan Kaminsky and Moxie Marlinspike at BlackHat09. Thanks to Tomas Hoger for providing one part of the patch. [GNUTLS-SA-2009-4] [CVE-2009-2730]. ** libgnutls: Fix rare failure in gnutls_x509_crt_import. The function may fail incorrectly when an earlier certificate was imported to the same gnutls_x509_crt_t structure. ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status. Before it always returned false. Reported by Peter Hendrickson in . ** libgnutls: Fix off-by-one size computation error in unknown DN printing. The error resulted in truncated strings when printing unknown OIDs in X.509 certificate DNs. Reported by Tim Kosse in . ** libgnutls: Fix PKCS#12 decryption from password. The encryption key derived from the password was incorrect for (on average) 1 in every 128 input for random inputs. Reported by "Kukosa, Tomas" in . ** libgnutls: Return correct bit lengths of some MPIs. gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and gnutls_dh_get_peers_public_bits. Before the reported value was overestimated. Reported by Peter Hendrickson in . ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN. Report and patch by Tim Kosse in and . ** libgnutls: Relax checking of required libtasn1/libgcrypt versions. Before we required that the runtime library used the same (or more recent) libgcrypt/libtasn1 as it was compiled with. Now we just check that the runtime usage is above the minimum required. Reported by Marco d'Itri via Andreas Metzler in . ** tests: Added new self-test pkcs12_s2k_pem to detect MPI bit length error. ** tests: Improved test vectors in self-test pkcs12_s2k. ** tests: Added new self-test dn2 to detect off-by-one size error. ** tests: Fix failure in "chainverify" because a certificate have expired. ** libgnutls: Fix crash in gnutls_global_init after earlier init/deinit cycle. Forwarded by Martin von Gagern from . ** Reduce stack usage for some CRQ functions. ** Doc fixes for CRQ functions. TLS Renegotiation Attack ======================== Some application protocols and implementations uses the TLS renegotiation feature in a manner that enables attackers to insert content of his choice in the beginning of a TLS session. One easy to understand vulnerability is HTTPS when servers request client certificates optionally for certain parts of a web site. The attack works by having the attacker simulate a client and connect to a server, with server-only authentication, and send some data intended to cause harm. When the proper client attempts to contact the server, the attacker hijacks that connection and uses the TLS renegotiation feature with the server and splices in the client connection to the already established connection between the attacker and server. The attacker will not be able to read the data exchanged between the client and the server. However, the server will (incorrectly) assume that the data sent by the attacker was sent by the now authenticated client. The result is a prefix plain-text injection attack. The above is just one example. Other vulnerabilities exists that do not rely on the TLS renegotiation to change the client's authenticated status (either TLS or application layer). While fixing these application protocols and implementations would be one natural reaction, an extension to TLS has been designed that cryptographically binds together any renegotiated handshakes with the initial negotiation. When the extension is used, the attack is detected and the session can be terminated. The extension is specified in RFC5746. GnuTLS supports the safe renegotiation extension. The default behavior is as follows. Clients will attempt to negotiate the safe renegotiation extension when talking to servers. Servers will accept the extension when presented by clients. Clients and servers will permit an initial handshake to complete even when the other side does not support the safe renegotiation extension. Clients and servers will refuse renegotiation attempts when the extension has not been negotiated. Note that permitting clients to connect to servers even when the safe renegotiation extension is not negotiated open up for some attacks. Changing this default behaviour would prevent interoperability against the majority of deployed servers out there. We will reconsider this default behaviour in the future when more servers have been upgraded. Note that it is easy to configure clients to always require the safe renegotiation extension from servers (see below on the `%SAFE_RENEGOTIATION' priority string). To modify the default behaviour, we have introduced some new priority strings. The priority strings can be used by applications (see gnutls_priority_set) and end users (e.g., `--priority' parameter to `gnutls-cli' and `gnutls-serv'). The `%UNSAFE_RENEGOTIATION' priority string permits (re-)handshakes even when the safe renegotiation extension was not negotiated. The default behavior is `%PARTIAL_RENEGOTIATION' that will prevent renegotiation with clients and servers not supporting the extension. This is secure for servers but leaves clients vulnerable to some attacks, but this is a tradeoff between security and compatibility with old servers. The `%SAFE_RENEGOTIATION' priority string makes clients and servers require the extension for every handshake. The latter is the most secure option for clients, at the cost of not being able to connect to legacy servers. Servers will also deny clients that do not support the extension from connecting. It is possible to disable use of the extension completely, in both clients and servers, by using the `%DISABLE_SAFE_RENEGOTIATION' priority string however we strongly recommend you to only do this for debugging and test purposes. The default values if the flags above are not specified are: `Server:' %PARTIAL_RENEGOTIATION `Client:' %PARTIAL_RENEGOTIATION For applications we have introduced a new API related to safe renegotiation. The gnutls_safe_renegotiation_status function is used to check if the extension has been negotiated on a session, and can be used both by clients and servers. Call to application authors =========================== Please use the priority string interface, and make it possible for users to supply a priority string! Several parts of GnuTLS, including the new safe renegotiation behaviour, can be configured through priority strings. However, if the application do not publish this interface to users, it will not be possible to configure GnuTLS the way a user wants. The new defaults for GnuTLS with regard to the safe renegotiation bug is to be insecure by default. This is something we reluctantly and after carefuly consideration decided to do, for interoperability reasons. We'd like to close this security gap as soon as possible, hopefully even for the GnuTLS 2.12.x branch. For this transition to be as smooth as possible, users of GnuTLS applications needs to be able to provide a priority string when a TLS session is initialized. Preferrably it should be possible to do on a domain name or IP basis, to only modify the defaults for a particular server and not generally. Once the GnuTLS defaults have changed to be secure by default, users may want to be able to provide a %PARTIAL_RENEGOTIATION or even an %UNSAFE_RENEGOTIATION priority string, to be able to talk with certain clients or servers. This will not be possible unless you, as application author, export this ability to your users. Technically, you would replace a call like this: gnutls_set_default_priority (session) with a call like this: gnutls_priority_set_direct (session, string, NULL); where 'string' is a character string read from your configuration files, and the default should be 'NORMAL'. It is fine for string to be NULL if you didn't read any configuration from the user, then 'NORMAL' will be used. For more information see: http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_005fpriority_005finit API/ABI changes in GnuTLS 2.10 ============================== No offically supported interfaces have been modified or removed. The library should be completely backwards compatible on both the source and binary level. The following symbols have been added to the library: gnutls_certificate_set_verify_function: ADDED. gnutls_cipher_decrypt: ADDED. gnutls_cipher_deinit: ADDED. gnutls_cipher_encrypt: ADDED. gnutls_cipher_get_block_size: ADDED. gnutls_cipher_init: ADDED. gnutls_hash: ADDED. gnutls_hash_deinit: ADDED. gnutls_hash_fast: ADDED. gnutls_hash_get_len: ADDED. gnutls_hash_init: ADDED. gnutls_hash_output: ADDED. gnutls_hmac: ADDED. gnutls_hmac_deinit: ADDED. gnutls_hmac_fast: ADDED. gnutls_hmac_get_len: ADDED. gnutls_hmac_init: ADDED. gnutls_hmac_output: ADDED. gnutls_safe_renegotiation_status: ADDED. gnutls_sign_algorithm_get_requested: ADDED. gnutls_x509_crt_get_issuer_alt_name2: ADDED. gnutls_x509_crt_get_issuer_alt_name: ADDED. gnutls_x509_crt_get_issuer_alt_othername_oid: ADDED. gnutls_session_ticket_key_generate: ADDED. gnutls_session_ticket_enable_client: ADDED. gnutls_session_ticket_enable_server: ADDED. In addition to the functions above, the following non-function definitions have been added to the header files: GNUTLS_DIG_SHA224: ADDED. GNUTLS_E_CRYPTODEV_DEVICE_ERROR: ADDED. GNUTLS_E_CRYPTODEV_IOCTL_ERROR: ADDED. GNUTLS_E_SAFE_RENEGOTIATION_FAILED: ADDED. GNUTLS_E_UNKNOWN_SRP_USERNAME: ADDED. GNUTLS_E_UNSAFE_RENEGOTIATION_DENIED: ADDED. GNUTLS_MAC_SHA224: ADDED. GNUTLS_OID_X520_NAME: ADDED. GNUTLS_OID_X520_POSTALCODE: ADDED. GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS: ADDED. GNUTLS_VERSION_MAX: ADDED. GNUTLS_CIPHER_AES_192_CBC: ADDED to gnutls/gnutls.h. GNUTLS_PKCS_USE_PBES2_AES_128: ADDED to gnutls/x509.h. GNUTLS_PKCS_USE_PBES2_AES_192: ADDED to gnutls/x509.h. GNUTLS_PKCS_USE_PBES2_AES_256: ADDED to gnutls/x509.h. GNUTLS_BAG_SECRET: ADDED to gnutls/pkcs12.h. GNUTLS_DIG_UNKNOWN: ADDED to gnutls/gnutls.h. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (7.2MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.10.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 16c94a1262f8ea3c4dd34eec495bd57203bbcd3a gnutls-2.10.0.tar.bz2 f97d09916dc87315a245991ce005f658915ca3770f4c48006d28c358 gnutls-2.10.0.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: HTML: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html PDF: http://www.gnu.org/software/gnutls/reference/gnutls.pdf Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer contains libgpg-error v1.8, libgcrypt v1.4.5, libtasn1 v2.7, and GnuTLS v2.10.0. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.10.0.exe (17MB) http://josefsson.org/gnutls4win/gnutls-2.10.0.exe.sig The checksum values for SHA-1 and SHA-224 are: 5fb951d9819f45fc53ff368c87aea61391c782f1 gnutls-2.10.0.exe ad39fdbdff193c622e72eaf837443d882f7b3876a7c1a911123339cb gnutls-2.10.0.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.10.0.zip (5.5MB) http://josefsson.org/gnutls4win/gnutls-2.10.0.zip.sig A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.7.10-1_all.deb (5.0MB) The checksum values for SHA-1 and SHA-224 are: 7ffabf34274cfc73c84550aae7efe650df10f77e gnutls-2.10.0.zip a657b3c5a07964a46f214bed5d72f731d85ef5829072d15e3c817fca gnutls-2.10.0.zip 6fd7c6264237f76ba31304d16d2d72a428126267 mingw32-gnutls_2.10.0-1_all.deb 944f8fa4db48efdffd0e03630c86ca275925d5f295fd99614f58ddfd mingw32-gnutls_2.10.0-1_all.deb Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Italian, Malay, Polish, Simplified Chinese, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Glad midsommar, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From tgerke at web.de Sat Jun 26 19:51:06 2010 From: tgerke at web.de (Timo Gerke) Date: Sat, 26 Jun 2010 19:51:06 +0200 Subject: certtool: --pkcs-cipher option not working Message-ID: <4C263E0A.3050009@web.de> Hi all, I'm new to this list, so I hope this report can help you to figure out my problem. when I generate a private key (DSA) with certtool, e. g. certtool -p --dsa --pkcs-cipher aes-256 --outfile privkey.pem The key won't get encyrpted. If I use certtool -p --pkcs8 --dsa --pkcs-cipher aes-256 --outfile privkey.pem I get following output: Generating a 2048 bit DSA private key... Enter password: Confirm password: |<1>| Selecting default encryption PKCS12_3DES_SHA1 (flags: 2). I tried with gnutls 2.9.10 to 2.10.0. Now I'm wondering why the key is encrypted with 3des and not aes-256 (which I specified). Regards, Timo Gerke From nmav at gnutls.org Sat Jun 26 22:01:26 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 26 Jun 2010 22:01:26 +0200 Subject: certtool: --pkcs-cipher option not working In-Reply-To: <4C263E0A.3050009@web.de> References: <4C263E0A.3050009@web.de> Message-ID: <4C265C96.3040104@gnutls.org> Timo Gerke wrote: Hello, > Hi all, > > I'm new to this list, so I hope this report can help you to figure out > my problem. > > when I generate a private key (DSA) with certtool, e. g. > certtool -p --dsa --pkcs-cipher aes-256 --outfile privkey.pem > The key won't get encyrpted. This correct. The default output format is not pkcs8 and thus the --pkcs-cipher is ignored. > If I use > certtool -p --pkcs8 --dsa --pkcs-cipher aes-256 --outfile privkey.pem > I get following output: This is the correct command. It seems you uncovered a bug and when generating a key with the --pkcs8 parameter it always uses 3des. To avoid that generate the key as you did in the first case and then convert it to pkcs8 format using /certtool -k --to-p8 --pkcs-cipher aes-128 --load-privkey privkey.pem > output.p8 I've fixed the problem in the git repository. regards, Nikos From tgerke at web.de Mon Jun 28 17:52:16 2010 From: tgerke at web.de (Timo Gerke) Date: Mon, 28 Jun 2010 17:52:16 +0200 Subject: Problem with DSA key signed CSRs Message-ID: <4C28C530.2020804@web.de> Dear List, I think I've discoverd an other bug. Then I generate a CSR signed with an DSA key an verify the request with openssl the verification fails. I did: a.1) certtool -p --dsa --disable-quick-random --outfile dsakey.pem a.2) certtool --to-p8 --pkcs-cipher aes-256 --load-privkey dsakey.pem --outfile dsakey.p8 b) certtool -8q --load-privkey --load-privkey dsakey.pem --outfile newreq.pem c) openssl req -verify -noout -in newreq.csr Error message is: 2936:error:0A071066:dsa routines:DSA_do_verify:bad q value:dsa_ossl.c:309: 2936:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:168: I used gnutls 2.10.0 and openssl 0.9.8g. BTW the format autodectetion of certtool seems not to work properly. regards, Timo From nmav at gnutls.org Mon Jun 28 18:28:46 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 28 Jun 2010 18:28:46 +0200 Subject: Problem with DSA key signed CSRs In-Reply-To: <4C28C530.2020804@web.de> References: <4C28C530.2020804@web.de> Message-ID: <4C28CDBE.6040300@gnutls.org> Timo Gerke wrote: > Dear List, > > I think I've discoverd an other bug. > Then I generate a CSR signed with an DSA key an verify the request > with openssl the verification fails. > I did: > > a.1) certtool -p --dsa --disable-quick-random --outfile dsakey.pem > a.2) certtool --to-p8 --pkcs-cipher aes-256 --load-privkey dsakey.pem --outfile dsakey.p8 > b) certtool -8q --load-privkey --load-privkey dsakey.pem --outfile newreq.pem > c) openssl req -verify -noout -in newreq.csr > > Error message is: > 2936:error:0A071066:dsa routines:DSA_do_verify:bad q value:dsa_ossl.c:309: > 2936:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP > lib:a_verify.c:168: Hello, It seems openssl doesn't support DSA keys of size more than 1024 bits. Use --bits 1024 on your first command and it will work. > BTW the format autodectetion of certtool seems not to work properly. Does it have autodetection? :) regardsm Nikos From ilari.liusvaara at elisanet.fi Mon Jun 28 21:47:19 2010 From: ilari.liusvaara at elisanet.fi (Ilari Liusvaara) Date: Mon, 28 Jun 2010 22:47:19 +0300 Subject: Two gnutls-cli feature requests Message-ID: <20100628194719.GA12958@LK-Perkele-V2.elisa-laajakaista.fi> Gnutls version 2.8.6 (I'll upgrade to 2.10 when it appears in distro repositories, but didn't note any relevant entries in changelog summary). I have run into two problems / features I wish I had with gnutls-cli: 1) Gnutls-cli seems to send most[1] of its messages to stdout. If application calling gnutls-cli[2] expects that stdin/stdout are not molested, then it will fail. 2) Option to make gnutls-cli read SRP password interactively from /dev/tty or non-interactively from fd. Passing passwords in command line is really insecure. [1] Some messages seem to be sent into stderr. [2] It can be user-specified command (that's the case I noted this behaviour with anyway)... -Ilari From tgerke at web.de Tue Jun 29 11:06:40 2010 From: tgerke at web.de (Timo Gerke) Date: Tue, 29 Jun 2010 11:06:40 +0200 Subject: Problem with DSA key signed CSRs In-Reply-To: <4C28CDBE.6040300@gnutls.org> References: <4C28C530.2020804@web.de> <4C28CDBE.6040300@gnutls.org> Message-ID: <4C29B7A0.6080302@web.de> Nikos Mavrogiannopoulos wrote: > Timo Gerke wrote: > >> Dear List, >> >> I think I've discoverd an other bug. >> Then I generate a CSR signed with an DSA key an verify the request >> with openssl the verification fails. >> I did: >> >> a.1) certtool -p --dsa --disable-quick-random --outfile dsakey.pem >> a.2) certtool --to-p8 --pkcs-cipher aes-256 --load-privkey dsakey.pem --outfile dsakey.p8 >> b) certtool -8q --load-privkey --load-privkey dsakey.pem --outfile newreq.pem >> c) openssl req -verify -noout -in newreq.csr >> >> [...] > > Hello, > It seems openssl doesn't support DSA keys of size more than 1024 bits. > Use --bits 1024 on your first command and it will work. > > >> BTW the format autodectetion of certtool seems not to work properly. >> > > Does it have autodetection? :) > > Hello, I think it has. If I run this command: certtool -q --load-privkey dsakey.p8 --outfile newreq.csr I get this error: certtool: import error: could not find a valid PEM header; check if your key is PKCS #8 or PKCS #12 encoded regards, Timo > regardsm > Nikos > P.S. This message is resent, previously I only sent it to Nikos. From mads at kiilerich.com Wed Jun 30 01:36:17 2010 From: mads at kiilerich.com (Mads Kiilerich) Date: Wed, 30 Jun 2010 01:36:17 +0200 Subject: deallocation in gnutls_*_deinit? Message-ID: <4C2A8371.7080202@kiilerich.com> Hi Newbie question here: According to valgrind and the source then for example gnutls_hash_init and gnutls_cipher_init does a gnutls_malloc, but the corresponding _deinit apparently doesn't free it. The documentation doesn't mention anything, and I would thus expect gnutls_hash_deinit & friends to do the necessary gnutls_free. What have I missed? Should I explicitly call gnutls_free after gnutls_*_deinit? Using gnutls-2.10.0 on Fedora 13. /Mads From nmav at gnutls.org Wed Jun 30 16:36:19 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 30 Jun 2010 16:36:19 +0200 Subject: deallocation in gnutls_*_deinit? In-Reply-To: <4C2A8371.7080202@kiilerich.com> References: <4C2A8371.7080202@kiilerich.com> Message-ID: <4C2B5663.4070407@gnutls.org> Mads Kiilerich wrote: > Hi > > Newbie question here: > > According to valgrind and the source then for example gnutls_hash_init > and gnutls_cipher_init does a gnutls_malloc, but the corresponding > _deinit apparently doesn't free it. > > The documentation doesn't mention anything, and I would thus expect > gnutls_hash_deinit & friends to do the necessary gnutls_free. > > What have I missed? > > Should I explicitly call gnutls_free after gnutls_*_deinit? No you shouldn't. It's a bug. Thank you for reporting it. I corrected it at: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=75ed7cb709d949f012afff73e4728889e0e65681 regards, Nikos From nmav at gnutls.org Wed Jun 30 16:42:25 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 30 Jun 2010 16:42:25 +0200 Subject: Problem with DSA key signed CSRs In-Reply-To: <4C29B7A0.6080302@web.de> References: <4C28C530.2020804@web.de> <4C28CDBE.6040300@gnutls.org> <4C29B7A0.6080302@web.de> Message-ID: <4C2B57D1.2090808@gnutls.org> Timo Gerke wrote: > I think it has. > If I run this command: > certtool -q --load-privkey dsakey.p8 --outfile newreq.csr > > I get this error: > certtool: import error: could not find a valid PEM header; check if your > key is PKCS #8 or PKCS #12 encoded This is an indication that it doesn't support autodetection. You have to supply the --p8 or decode it first and feed it in plain format. regards, Nikos From mads at kiilerich.com Wed Jun 30 17:27:44 2010 From: mads at kiilerich.com (Mads Kiilerich) Date: Wed, 30 Jun 2010 17:27:44 +0200 Subject: deallocation in gnutls_*_deinit? In-Reply-To: <4C2B5663.4070407@gnutls.org> References: <4C2A8371.7080202@kiilerich.com> <4C2B5663.4070407@gnutls.org> Message-ID: <4C2B6270.90709@kiilerich.com> On 06/30/2010 04:36 PM, Nikos Mavrogiannopoulos wrote: > Mads Kiilerich wrote: >> Hi >> >> Newbie question here: >> >> According to valgrind and the source then for example gnutls_hash_init >> and gnutls_cipher_init does a gnutls_malloc, but the corresponding >> _deinit apparently doesn't free it. >> >> The documentation doesn't mention anything, and I would thus expect >> gnutls_hash_deinit& friends to do the necessary gnutls_free. >> >> What have I missed? >> >> Should I explicitly call gnutls_free after gnutls_*_deinit? > > No you shouldn't. It's a bug. Thank you for reporting it. I corrected it at: > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=75ed7cb709d949f012afff73e4728889e0e65681 Thanks. What do you recommend: Should I implement a workaround for 2.10.0 (and how?) or should I require 2.10.1? Is there a planned/estimated data of a release? /Mads