From simon at josefsson.org Fri Dec 1 11:40:42 2006 From: simon at josefsson.org (Simon Josefsson) Date: Fri Dec 1 11:39:01 2006 Subject: [gnutls-dev] Re: Request for goals for GnuTLS 1.7.x In-Reply-To: <20061130123525.GV17457@sliepen.eu.org> (Guus Sliepen's message of "Thu\, 30 Nov 2006 13\:35\:25 +0100") References: <87hcwilc3r.fsf@latte.josefsson.org> <396556a20611291514l45eb8ba2jcd9cb5ec4c16733a@mail.gmail.com> <20061130123525.GV17457@sliepen.eu.org> Message-ID: <87ac27vqz9.fsf@latte.josefsson.org> Guus Sliepen writes: > On Wed, Nov 29, 2006 at 03:14:03PM -0800, Adam Langley wrote: > >> On 11/29/06, Simon Josefsson wrote: >> >Of course, if you just want to suggest something, that >> >is appreciated too, but no promises. :) >> >> DTLS (TLS over datagrams, e.g. UDP) has been discussed here a couple >> of times, but I don't actually know if it ever happened. (I just think >> it would be cool). > > I said I'd try to implement that in GNUTLS, however I haven't created > anything useful yet. It's not trivial at all. Right, it is a rather different protocol. > There is one thing that may be helpful for DTLS support, and also for > some regular TLS uses, is to have a different way to pass data to > GNUTLS. Currently, you either do gnutls_handshake(), gnutls_read() or > gnutls_write(), and those functions call read() and write() on the > filedescriptors themselves. I can specify custom push and pull > functions of course, but that doesn't change much. I'd like to see a > function to push data from a (D)TLS stream, received by the application > itself, to GNUTLS, and have GNUTLS invoke a callback if it contained > application data. Isn't that possible to do with the existing interfaces? See the following for inspiration. Of course, you'd use gnutls_transport_set_ptr2 or similar instead of global variables, and the buffer handling and error handling must be improved, but the general solution seems to be here. Perhaps I misunderstood what you wanted. If you can dedicate time to work on this, I can create a branch for DTLS when you start to send patches. ssize_t my_pull_func (gnutls_transport_ptr_t, const void *data, size_t len) { size_t chunksize = MIN(len, global_len); memcpy (data, global_data, chunksize); memmove (global_data, global_data + chunk_size, global_len - chunk_size); global_len -= chunk_size; } int push_data_from_net_to_gnutls (gnutls_session session, char *data, size_t len) { char buf[MAXBUF]; size_t len; ssize_t l; global_data = data; global_len = len; // Calls my_pull_func internally l = gnutls_record_recv (session, buf, &len); if (l > 0) { my_callback (buf, len); } } /Simon From guus at sliepen.eu.org Fri Dec 1 15:05:41 2006 From: guus at sliepen.eu.org (Guus Sliepen) Date: Fri Dec 1 15:04:35 2006 Subject: [gnutls-dev] Re: Request for goals for GnuTLS 1.7.x In-Reply-To: <87ac27vqz9.fsf@latte.josefsson.org> References: <87hcwilc3r.fsf@latte.josefsson.org> <396556a20611291514l45eb8ba2jcd9cb5ec4c16733a@mail.gmail.com> <20061130123525.GV17457@sliepen.eu.org> <87ac27vqz9.fsf@latte.josefsson.org> Message-ID: <20061201140541.GS15431@sliepen.eu.org> On Fri, Dec 01, 2006 at 11:40:42AM +0100, Simon Josefsson wrote: > > [...] I'd like to see a > > function to push data from a (D)TLS stream, received by the application > > itself, to GNUTLS, and have GNUTLS invoke a callback if it contained > > application data. > > Isn't that possible to do with the existing interfaces? See the > following for inspiration. Of course, you'd use > gnutls_transport_set_ptr2 or similar instead of global variables, and > the buffer handling and error handling must be improved, but the > general solution seems to be here. Perhaps I misunderstood what you > wanted. Sure, that's possible. I guess I just feel that it's a more cumbersome way for the application to handle it. > If you can dedicate time to work on this, I can create a > branch for DTLS when you start to send patches. I'll let you know when I can. -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20061201/efbe157d/attachment.pgp From max at duempel.org Mon Dec 11 08:52:02 2006 From: max at duempel.org (Max Kellermann) Date: Mon, 11 Dec 2006 08:52:02 +0100 Subject: [gnutls-dev] bugreport: segmentation fault in gnutls_certificate_set_x509_crl() Message-ID: <20061211075202.GA1517@roonstrasse.net> Hi, gnutls version 1.4.4 as well as the CVS head crash when a program uses gnutls_certificate_set_x509_crl(). In the for loop, it calls _gnutls_x509_crl_cpy() with new and uninitialized elements of the res->x509_crl_list array. This leads to a segmentation fault. I suggest adding gnutls_x509_crl_init() before each _gnutls_x509_crl_cpy() call. Max From max at duempel.org Tue Dec 12 18:50:17 2006 From: max at duempel.org (Max Kellermann) Date: Tue, 12 Dec 2006 18:50:17 +0100 Subject: [gnutls-dev] generate_rdn_seq() collects CA's issuers, why? Message-ID: <20061212175017.GA32492@roonstrasse.net> Hi, I'm currently hunting a tricky problem in my gnutls application; the client refuses to send any certificates to the server. I tracked it all down to generate_rdn_seq(), which does not add the CA's DNs to the rdn_seq, but adds the CA's issuer's DNs. Why that? The CAs are being trusted, not the CA's issuers. Now my client only sees the root CA, which did not sign his client certificate (Root CA -> client CA -> client certificate) - which is why the client will not send any certificate. Two experiments resulted in a success (which should not be): - first, I added another client certificate to the server's trusted "CAs", now the client would see his own issuer in the list and sent his own certificate - second, I modified generate_rdn_seq() to call _gnutls_x509_crt_get_raw_dn() instead of _gnutls_x509_crt_get_raw_issuer_dn() - the same: everything works fine. If I'm correct and if this is really a bug in gnutls, I believe my second experiment is a solution for the gnutls bug. Max From max at duempel.org Wed Dec 13 08:52:58 2006 From: max at duempel.org (Max Kellermann) Date: Wed, 13 Dec 2006 08:52:58 +0100 Subject: [gnutls-dev] bugreport: segmentation fault in gnutls_certificate_set_x509_crl() In-Reply-To: <20061211075202.GA1517@roonstrasse.net> References: <20061211075202.GA1517@roonstrasse.net> Message-ID: <20061213075258.GA24613@roonstrasse.net> On 2006/12/11 08:52, Max Kellermann wrote: > I suggest adding gnutls_x509_crl_init() before each > _gnutls_x509_crl_cpy() call. Here is a patch. Max -------------- next part -------------- Index: lib/gnutls_x509.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_x509.c,v retrieving revision 2.175 diff -u -r2.175 gnutls_x509.c --- lib/gnutls_x509.c 16 Jun 2006 13:29:36 -0000 2.175 +++ lib/gnutls_x509.c 13 Dec 2006 07:45:46 -0000 @@ -1623,14 +1623,21 @@ for (i = 0; i < crl_list_size; i++) { + ret = gnutls_x509_crl_init (&res->x509_crl_list[res->x509_ncrls]); + if (ret < 0) + { + gnutls_assert (); + return ret; + } + ret = _gnutls_x509_crl_cpy (res->x509_crl_list[ res->x509_ncrls], crl_list[i]); + res->x509_ncrls++; if (ret < 0) { gnutls_assert (); return ret; } - res->x509_ncrls++; } return 0; From max at duempel.org Wed Dec 13 08:53:45 2006 From: max at duempel.org (Max Kellermann) Date: Wed, 13 Dec 2006 08:53:45 +0100 Subject: [gnutls-dev] generate_rdn_seq() collects CA's issuers, why? In-Reply-To: <20061212175017.GA32492@roonstrasse.net> References: <20061212175017.GA32492@roonstrasse.net> Message-ID: <20061213075345.GB24613@roonstrasse.net> On 2006/12/12 18:50, Max Kellermann wrote: > If I'm correct and if this is really a bug in gnutls, I believe my > second experiment is a solution for the gnutls bug. Patch. Max -------------- next part -------------- Index: lib/gnutls_x509.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_x509.c,v retrieving revision 2.175 diff -u -r2.175 gnutls_x509.c --- lib/gnutls_x509.c 16 Jun 2006 13:29:36 -0000 2.175 +++ lib/gnutls_x509.c 13 Dec 2006 07:48:47 -0000 @@ -990,8 +990,8 @@ for (i = 0; i < res->x509_ncas; i++) { if ((ret = - _gnutls_x509_crt_get_raw_issuer_dn (res->x509_ca_list[i], - &tmp)) < 0) + _gnutls_x509_crt_get_raw_dn (res->x509_ca_list[i], + &tmp)) < 0) { gnutls_assert (); return ret; @@ -1016,8 +1016,8 @@ for (i = 0; i < res->x509_ncas; i++) { if ((ret = - _gnutls_x509_crt_get_raw_issuer_dn (res->x509_ca_list[i], - &tmp)) < 0) + _gnutls_x509_crt_get_raw_dn (res->x509_ca_list[i], + &tmp)) < 0) { _gnutls_free_datum (&res->x509_rdn_sequence); gnutls_assert (); From ludovic.courtes at laas.fr Wed Dec 13 16:22:35 2006 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 13 Dec 2006 16:22:35 +0100 Subject: [gnutls-dev] [PATCH] Detect GAA and fix out-of-source-tree builds Message-ID: <87mz5res78.fsf@laas.fr> A non-text attachment was scrubbed... Name: ,,config.diff Type: text/x-patch Size: 1323 bytes Desc: Look for GAA Url : /pipermail/attachments/20061213/5178e07a/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: ,,doc-out-of-source-tree.diff Type: text/x-patch Size: 5718 bytes Desc: Doc out-of-source-tree builds Url : /pipermail/attachments/20061213/5178e07a/attachment-0001.bin From dale-keyword-gnutls.5670f1 at codefu.org Sun Dec 17 18:15:43 2006 From: dale-keyword-gnutls.5670f1 at codefu.org (Dale Sedivec) Date: Sun, 17 Dec 2006 12:15:43 -0500 Subject: [gnutls-dev] [PATCH] Authority key ID bug in certtool Message-ID: <20061217171543.GA16738@morgase.caliginous.net> Greetings, When certtool is signing a certificate, it calculates the CA key's ID and uses that to fill in the X.509 v3 authority key ID extension. This results in certtool generating invalid certificates when the CA certificate has a different subject key ID than the one that certtool calculated for the CA key (i.e., this happens when something other than certtool was used to make the CA certificate, such as OpenSSL). To reproduce with OpenSSL: openssl req -days 3650 -nodes -new -x509 -keyout ca.key -out ca.crt # Answer the resulting questions any way you would like. certtool --generate-privkey > user.key certtool --generate-certificate --load-privkey user.key \ --load-ca-certificate ca.crt --load-ca-privkey ca.key > user.crt # Answer more questions. openssl verify -issuer_checks -CAfile ca.crt user.crt "openssl verify" should bomb with some errors, the significant ones being: error 30 at 0 depth lookup:authority and subject key identifier mismatch error 20 at 0 depth lookup:unable to get local issuer certificate When "openssl verify" succeeds, the last line should say simply "OK". certtool seems not to check/care about the subject/authority key ID mismatch: $ cat user.crt ca.crt | certtool --verify-chain Certificate[0]: Issued by: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd Verifying against certificate[1]. Verification output: Verified. Certificate[1]: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd Issued by: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd Verification output: Verified. $ I've included a patch I made against GNU TLS 1.2.11 to use the CA's subject key ID when filling in a new certificate's authority key ID. When applied here certtool generates certificates that pass "openssl verify." Dale --- src/certtool.c.orig 2006-12-16 18:22:04.000000000 -0500 +++ src/certtool.c 2006-12-16 18:58:19.000000000 -0500 @@ -524,7 +524,12 @@ */ if (ca_crt != NULL) { size = sizeof(buffer); - result = gnutls_x509_crt_get_key_id(ca_crt, 0, buffer, &size); + result = gnutls_x509_crt_get_subject_key_id(ca_crt, buffer, &size, NULL); + if (result < 0) { + fprintf(stderr, + "generate_certificate: can't read CA subject key ID\n"); + exit(1); + } if (result >= 0) { result = gnutls_x509_crt_set_authority_key_id(crt, buffer, size); From dale-keyword-gnutls.5670f1 at codefu.org Sun Dec 17 20:26:05 2006 From: dale-keyword-gnutls.5670f1 at codefu.org (Dale Sedivec) Date: Sun, 17 Dec 2006 14:26:05 -0500 Subject: [gnutls-dev] [PATCH] Authority key ID bug in certtool In-Reply-To: <20061217171543.GA16738@morgase.caliginous.net> References: <20061217171543.GA16738@morgase.caliginous.net> Message-ID: <20061217192605.GA19309@morgase.caliginous.net> On Sun, Dec 17, 2006 at 12:15:43PM -0500, Dale Sedivec wrote: > + if (result < 0) { > + fprintf(stderr, > + "generate_certificate: can't read CA subject key ID\n"); > + exit(1); > + } > if (result >= 0) { Sorry, that's obviously silly. "Improved" patch below. Dale --- src/certtool.c.orig 2006-12-17 14:18:53.000000000 -0500 +++ src/certtool.c 2006-12-17 14:20:10.000000000 -0500 @@ -524,10 +524,13 @@ */ if (ca_crt != NULL) { size = sizeof(buffer); - result = gnutls_x509_crt_get_key_id(ca_crt, 0, buffer, &size); - if (result >= 0) { - result = - gnutls_x509_crt_set_authority_key_id(crt, buffer, size); + result = gnutls_x509_crt_get_subject_key_id(ca_crt, buffer, &size, NULL); + if (result < 0) { + fprintf(stderr, + "generate_certificate: can't read CA subject key ID\n"); + exit(1); + } else { + result = gnutls_x509_crt_set_authority_key_id(crt, buffer, size); if (result < 0) { fprintf(stderr, "set_authority_key_id: %s\n", gnutls_strerror(result)); From ludovic.courtes at laas.fr Mon Dec 18 19:19:52 2006 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 18 Dec 2006 19:19:52 +0100 Subject: [gnutls-dev] Server->client cert. request not TLS 1.2-compatible Message-ID: <871wmxrrqv.fsf@laas.fr> A non-text attachment was scrubbed... Name: ,,cert-req-tls-1-2.diff Type: text/x-diff Size: 703 bytes Desc: The hack Url : /pipermail/attachments/20061218/d1bbccbd/attachment.bin From ludovic.courtes at laas.fr Mon Dec 18 18:28:35 2006 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 18 Dec 2006 18:28:35 +0100 Subject: [gnutls-dev] Buggy RSA/DSA signature verification Message-ID: <87ac1lt8os.fsf@laas.fr> Hi, There seems to be a bug in `_gnutls_pkcs1_rsa_verify_sig ()': Basically, when verifying a DSA signature, it wrongfully assumes that the SHA1 hash is located at `&hash_concat->data[16]'. In some cases, as visible in `_gnutls_verify_sig_params ()', the SHA1 hash is actually located `&hash_concat->data[15]' instead, because the PKCS#1 algorithm identifier for SHA1 is 15-octet-long, not 16. In those cases, `_gnutls_pkcs1_rsa_verify_sig ()' fails to verify the signature and performs an off-by-one memory access. I don't know what the best way to fix `_gnutls_pkcs1_rsa_verify_sig ()' is. Perhaps it could decode the header of HASH_CONCAT in order to determine the exact location of the hash value. Alternatively, since the function is only used internally, we could change callers so that they provide it directly with the hash value in the `GNUTLS_PK_DSA' case. I'd be glad to help fix this based on your comments if you don't have time to do it. Thanks, Ludovic. From max at duempel.org Wed Dec 20 13:53:09 2006 From: max at duempel.org (Max Kellermann) Date: Wed, 20 Dec 2006 13:53:09 +0100 Subject: [gnutls-dev] libgnutls failes to parse OpenSSL generated certificates Message-ID: <20061220125309.GA2668@roonstrasse.net> Package: libgnutls13 Version: 1.4.4-3 libgnutls refuses to parse the subject of certificates created by OpenSSL which have a userid attribute in their subject, i.e. oid 0.9.2342.19200300.100.1.1. Output of "certtool -i": |<1>| Found OID: '0.9.2342.19200300.100.1.1' with value '13066d6c61626962' get_dn: ASN1 parser: Error in TAG. gnutls generates certificates with an "ia5String" uid, while OpenSSL generates a "printableString". The latter violates gnutls' lib/pkix.asn which states: -- LDAP stuff -- may not be correct [...] ldap-UID ::= IA5String Which is indeed not correct. ldap-UID should be a DirectoryString. From max at duempel.org Wed Dec 20 15:19:10 2006 From: max at duempel.org (Max Kellermann) Date: Wed, 20 Dec 2006 15:19:10 +0100 Subject: [gnutls-dev] libgnutls failes to parse OpenSSL generated certificates In-Reply-To: <20061220125309.GA2668@roonstrasse.net> References: <20061220125309.GA2668@roonstrasse.net> Message-ID: <20061220141910.GA13134@roonstrasse.net> tag 403887 patch thanks On 2006/12/20 13:53, Max Kellermann wrote: > -- LDAP stuff > -- may not be correct > [...] > ldap-UID ::= IA5String > > Which is indeed not correct. ldap-UID should be a DirectoryString. Here is a patch for this bug. I had to add IA5String to the DirectoryString CHOICE. This is obviously incorrect, but seems to be the only way to ensure that certificates generated by certtool can also be parsed. Please correct me if there is a better solution. Max -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_uid_is_a_directory_string.patch Type: text/x-diff Size: 1481 bytes Desc: not available Url : /pipermail/attachments/20061220/2eb36ea1/attachment.bin From max at duempel.org Wed Dec 20 21:07:45 2006 From: max at duempel.org (Max Kellermann) Date: Wed, 20 Dec 2006 21:07:45 +0100 Subject: [gnutls-dev] libgnutls failes to parse OpenSSL generated certificates In-Reply-To: <20061220141910.GA13134@roonstrasse.net> References: <20061220125309.GA2668@roonstrasse.net> <20061220141910.GA13134@roonstrasse.net> Message-ID: <20061220200745.GA15093@roonstrasse.net> On 2006/12/20 15:19, Max Kellermann wrote: > Here is a patch for this bug. Just a note: my patch does not work with the included minitasn library, you need libtasn. Max From jw+debian at jameswestby.net Thu Dec 21 19:33:23 2006 From: jw+debian at jameswestby.net (James Westby) Date: Thu, 21 Dec 2006 18:33:23 +0000 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 Message-ID: <20061221183323.GJ9868@jameswestby.net> Hi, Marc Haber (on CC) the Debian Exim maintainer reported a bug against GnuTLS in Debian on behalf of users who were having trouble using their mobile phones with Exim using an SSL connection. YOu can read the full story here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402861 Marc has been very helpful in trying to investigate what the cause of the bug is. We now know the following things: Linking Exim against OpenSSL works. The phones fail when run against gnutls-serv and it's default options. Forcing SSL3.0 works, the phones don't support TLS1.2. Disallowing SHA1 means RC4 is negotiated, and works. There is no compression involved as the phones do not support it. I am not sure how to proceed now. Marc has provided plenty of debugging info, including dumps of debuggin output from -serv, and he sent me privately tcpdumps of the transactions. Can you suggest anyway for us to proceed? Do you have any more tools that can help us work out what is going on? Unfortuanately there is nothing we can do from the phone end as we have no idea what is going on there. Thanks, James -- James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 From simon at josefsson.org Wed Dec 27 09:32:53 2006 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Dec 2006 09:32:53 +0100 Subject: [gnutls-dev] bugreport: segmentation fault in gnutls_certificate_set_x509_crl() In-Reply-To: <20061211075202.GA1517@roonstrasse.net> (Max Kellermann's message of "Mon\, 11 Dec 2006 08\:52\:02 +0100") References: <20061211075202.GA1517@roonstrasse.net> Message-ID: <87fyb1rb62.fsf@latte.josefsson.org> Max Kellermann writes: > Hi, > > gnutls version 1.4.4 as well as the CVS head crash when a program uses > gnutls_certificate_set_x509_crl(). In the for loop, it calls > _gnutls_x509_crl_cpy() with new and uninitialized elements of the > res->x509_crl_list array. This leads to a segmentation fault. > > I suggest adding gnutls_x509_crl_init() before each > _gnutls_x509_crl_cpy() call. Hi! Sorry for the slow response, I just returned from vacation. I wrote a self-test for this, installed as tests/certificate_set_x509_crl.c, but were unable to reproduce a crash. However, the function is clearly wrong (and the self test failed), and probably leads to a crash depending on uninitialized values. Your suggestion indeed solves the problem. Fixed in CVS for both 1.6.x and 1.7.x. /Simon From simon at josefsson.org Wed Dec 27 10:00:00 2006 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Dec 2006 10:00:00 +0100 Subject: [gnutls-dev] generate_rdn_seq() collects CA's issuers, why? In-Reply-To: <20061212175017.GA32492@roonstrasse.net> (Max Kellermann's message of "Tue\, 12 Dec 2006 18\:50\:17 +0100") References: <20061212175017.GA32492@roonstrasse.net> Message-ID: <87ac19r9wv.fsf@latte.josefsson.org> Max Kellermann writes: > Hi, > > I'm currently hunting a tricky problem in my gnutls application; the > client refuses to send any certificates to the server. I tracked it > all down to generate_rdn_seq(), which does not add the CA's DNs to the > rdn_seq, but adds the CA's issuer's DNs. > > Why that? > > The CAs are being trusted, not the CA's issuers. Now my client only > sees the root CA, which did not sign his client certificate (Root CA > -> client CA -> client certificate) - which is why the client will not > send any certificate. > > Two experiments resulted in a success (which should not be): > > - first, I added another client certificate to the server's trusted > "CAs", now the client would see his own issuer in the list and sent > his own certificate > > - second, I modified generate_rdn_seq() to call > _gnutls_x509_crt_get_raw_dn() instead of > _gnutls_x509_crt_get_raw_issuer_dn() - the same: everything works > fine. > > If I'm correct and if this is really a bug in gnutls, I believe my > second experiment is a solution for the gnutls bug. Yup, I believe you are right. RFC 4346 says: certificate_authorities A list of the distinguished names of acceptable certificate authorities. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe both known roots and a desired authorization space. If the certificate_authorities list is empty then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary. One reason this hasn't come up before may be that root CAs typically have the same issuer and subject DN, and it is typical to trust root CAs and not sub-ordinate CAs. I have fixed this in CVS for both 1.6.x and 1.7.x. Thanks, Simon From simon at josefsson.org Wed Dec 27 19:28:02 2006 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Dec 2006 19:28:02 +0100 Subject: [gnutls-dev] libgnutls failes to parse OpenSSL generated certificates In-Reply-To: <20061220125309.GA2668@roonstrasse.net> (Max Kellermann's message of "Wed\, 20 Dec 2006 13\:53\:09 +0100") References: <20061220125309.GA2668@roonstrasse.net> Message-ID: <87y7ot9ost.fsf@latte.josefsson.org> Max Kellermann writes: > libgnutls refuses to parse the subject of certificates created by > OpenSSL which have a userid attribute in their subject, i.e. oid > 0.9.2342.19200300.100.1.1. Output of "certtool -i": > > |<1>| Found OID: '0.9.2342.19200300.100.1.1' with value > '13066d6c61626962' > get_dn: ASN1 parser: Error in TAG. > > gnutls generates certificates with an "ia5String" uid, while OpenSSL > generates a "printableString". The latter violates gnutls' > lib/pkix.asn which states: > > -- LDAP stuff > -- may not be correct > [...] > ldap-UID ::= IA5String > > Which is indeed not correct. ldap-UID should be a DirectoryString. I agree. > On 2006/12/20 13:53, Max Kellermann wrote: >> -- LDAP stuff >> -- may not be correct >> [...] >> ldap-UID ::= IA5String >> >> Which is indeed not correct. ldap-UID should be a DirectoryString. > > Here is a patch for this bug. I had to add IA5String to the > DirectoryString CHOICE. This is obviously incorrect, but seems to be > the only way to ensure that certificates generated by certtool can > also be parsed. Please correct me if there is a better solution. I cannot think of one. I have added a self-test in tests/userid/ to make sure future versions of GnuTLS can read certificates with UID'd encoded as IA5String (OpenSSL appear to handle this too), and installed your patch. Btw, I believe we need a copyright assignment from you to be able to use more of your patches (which I'd really like to see happen!). Is this a problem? Let me know and I can send you the forms offline. > Just a note: my patch does not work with the included minitasn > library, you need libtasn. Why is that? I updated the generated pkix_asn1_tab.c in CVS, which should make it work with minitasn1. /Simon From simon at josefsson.org Wed Dec 27 20:00:55 2006 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Dec 2006 20:00:55 +0100 Subject: [gnutls-dev] Server->client cert. request not TLS 1.2-compatible In-Reply-To: <871wmxrrqv.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Mon\, 18 Dec 2006 19\:19\:52 +0100") References: <871wmxrrqv.fsf@laas.fr> Message-ID: <87tzzh9na0.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > `_gnutls_gen_cert_server_cert_req ()' is not TLS 1.2-aware, unlike > `_gnutls_proc_cert_cert_req ()'. Specifically TLS 1.2 requires (per > `draft-ietf-tls-rfc4346-bis-02.txt') certificate request messages to > include a `certificate_hash' sequence. While `proc_cert_cert_req' does > expect and read this sequence when in TLS 1.2, > `gen_cert_server_cert_req' does not issue that sequence. > > A temporary workaround that may only works with GnuTLS-based TLS 1.2 > clients/servers is attached: basically, it modifies > `gen_cert_server_cert_req' so that it produces an empty hash algorithm > sequence. Hi! Thanks for the analysis, I agree. I installed your patch in 1.7.x. > Again, if need be, I'd be glad to provide a real fix based on your > input. What remains to be done here is to support the new hashes enabled by TLS 1.2. I have not had any time to work on that, but if you want to take a stab at making e.g. SHA-256 work, that would be very useful. I didn't think through what other changes would be required to support them, maybe some new APIs are required. Right now, the TLS 1.2 support in GnuTLS is the minimal required to conform with the protocol syntax, there is no support for SHA2. I'd be happy to work with you to improve the TLS 1.2 support, but I'm rather short on spare time so my responses may be slow. /Simon > Thanks, > Ludovic. > > > > --- orig/lib/auth_cert.c > +++ mod/lib/auth_cert.c > @@ -1403,6 +1403,7 @@ > gnutls_certificate_credentials_t cred; > int size; > opaque *pdata; > + gnutls_protocol_t ver = gnutls_protocol_get_version (session); > > /* Now we need to generate the RDN sequence. This is > * already in the CERTIFICATE_CRED structure, to improve > @@ -1439,6 +1440,13 @@ > pdata[2] = DSA_SIGN; /* only these for now */ > pdata += CERTTYPE_SIZE; > > + if (ver == GNUTLS_TLS1_2) > + { > + /* supported hashes (nothing for now -- FIXME) */ > + *pdata = 0; > + pdata++, size++; > + } > + > if (session->security_parameters.cert_type == GNUTLS_CRT_X509 && > session->internals.ignore_rdn_sequence == 0) > { > > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev From simon at josefsson.org Wed Dec 27 20:15:03 2006 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Dec 2006 20:15:03 +0100 Subject: [gnutls-dev] [PATCH] Detect GAA and fix out-of-source-tree builds In-Reply-To: <87mz5res78.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Wed\, 13 Dec 2006 16\:22\:35 +0100") References: <87mz5res78.fsf@laas.fr> Message-ID: <87psa59mmg.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > The two patches below (against HEAD) make compilation smoother by > detecting GAA and allowing for out-of-source-tree builds. Hi! Thanks for the patches. GAA shouldn't be required to build GnuTLS, so bombing out with an error seems wrong. The generated files are distributed with GnuTLS. Maybe you could modify that patch to use AC_MSG_WARN and to suggest that GAA is only needed if the user wishes to modify the source code of the command line description files? I installed the other patch, thanks! /Simon From simon at josefsson.org Wed Dec 27 21:31:07 2006 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Dec 2006 21:31:07 +0100 Subject: [gnutls-dev] Buggy RSA/DSA signature verification In-Reply-To: <87ac1lt8os.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Mon\, 18 Dec 2006 18\:28\:35 +0100") References: <87ac1lt8os.fsf@laas.fr> Message-ID: <87hcvh9j3o.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > There seems to be a bug in `_gnutls_pkcs1_rsa_verify_sig ()': Basically, > when verifying a DSA signature, it wrongfully assumes that the SHA1 hash > is located at `&hash_concat->data[16]'. In some cases, as visible in > `_gnutls_verify_sig_params ()', the SHA1 hash is actually located > `&hash_concat->data[15]' instead, because the PKCS#1 algorithm > identifier for SHA1 is 15-octet-long, not 16. In those cases, > `_gnutls_pkcs1_rsa_verify_sig ()' fails to verify the signature and > performs an off-by-one memory access. Ah, right. An important condition for this to happen is that TLS 1.2 is used, though. > I don't know what the best way to fix `_gnutls_pkcs1_rsa_verify_sig ()' > is. Perhaps it could decode the header of HASH_CONCAT in order to > determine the exact location of the hash value. Alternatively, since > the function is only used internally, we could change callers so that > they provide it directly with the hash value in the `GNUTLS_PK_DSA' > case. > > I'd be glad to help fix this based on your comments if you don't have > time to do it. I think we should change both the function parameters and the name of the function -- it is quite confusing for the function to be called _gnutls_pkcs1_rsa_verify_sig when it is actually responsible for verifying both RSA and DSA signatures. I have installed the patch below. When we support more than SHA-1, this will have to be revisited again, but at least this will solve the immediate problem. Thanks, Simon --- gnutls_sig.c 26 Nov 2006 12:10:10 +0100 2.54 +++ gnutls_sig.c 27 Dec 2006 21:28:44 +0100 @@ -259,9 +259,10 @@ static int -_gnutls_pkcs1_rsa_verify_sig (gnutls_cert * cert, +_gnutls_verify_sig (gnutls_cert * cert, const gnutls_datum_t * hash_concat, - gnutls_datum_t * signature) + gnutls_datum_t * signature, + size_t sha1pos) { int ret; gnutls_datum_t vdata; @@ -302,7 +303,7 @@ break; case GNUTLS_PK_DSA: - vdata.data = &hash_concat->data[16]; + vdata.data = &hash_concat->data[sha1pos]; vdata.size = 20; /* sha1 */ /* verify signature */ @@ -380,7 +381,7 @@ dconcat.data = concat; dconcat.size = 20 + 16; /* md5+ sha */ - ret = _gnutls_pkcs1_rsa_verify_sig (cert, &dconcat, signature); + ret = _gnutls_verify_sig (cert, &dconcat, signature, 16); if (ret < 0) { gnutls_assert (); @@ -461,7 +462,7 @@ dconcat.data = concat; - ret = _gnutls_pkcs1_rsa_verify_sig (cert, &dconcat, signature); + ret = _gnutls_verify_sig (cert, &dconcat, signature, dconcat.size - 20); if (ret < 0) { gnutls_assert (); From simon at josefsson.org Thu Dec 28 10:14:12 2006 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Dec 2006 10:14:12 +0100 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <20061221183323.GJ9868@jameswestby.net> (James Westby's message of "Thu\, 21 Dec 2006 18\:33\:23 +0000") References: <20061221183323.GJ9868@jameswestby.net> Message-ID: <87vejw8jrv.fsf@latte.josefsson.org> James Westby writes: > Hi, > > Marc Haber (on CC) the Debian Exim maintainer reported a bug against > GnuTLS in Debian on behalf of users who were having trouble using their > mobile phones with Exim using an SSL connection. YOu can read the full > story here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402861 > > Marc has been very helpful in trying to investigate what the cause of > the bug is. We now know the following things: > > Linking Exim against OpenSSL works. > The phones fail when run against gnutls-serv and it's default options. > Forcing SSL3.0 works, the phones don't support TLS1.2. > Disallowing SHA1 means RC4 is negotiated, and works. > There is no compression involved as the phones do not support it. > > I am not sure how to proceed now. Marc has provided plenty of debugging > info, including dumps of debuggin output from -serv, and he sent me > privately tcpdumps of the transactions. > > Can you suggest anyway for us to proceed? Do you have any more tools > that can help us work out what is going on? Unfortuanately there is > nothing we can do from the phone end as we have no idea what is going on > there. Hi! Interesting... it seems you have already done a fair bit of debugging yourself. I couldn't see the protocol dumps or debug info in the messages that I read (but I read only briefly), and those would help me to debug it further. However, I think it will take quite some time to study the logs and understand what is going on, but it is difficult to prioritize that for me. I think someone who can live-debug gnutls-serv against a phone is in the best position to continue debug this. What GnuTLS version are you using? There was a version-negotiating bug solved during 1.5.x (in 1.6.0), but I'm not sure it is relevant. I assume you meant TLS1.1 and not TLS1.2 above? The phone supports TLS1.0 and do not support TLS1.1 or TLS1.2, right? I suggest to try to do more binary-searching between the features that work and the features that do not work, to hopefully start to see a pattern in it. Enabling and disabling specific features, which you've started with, seems like a good move, but maybe you can go further. Like trying to force AES/SHA1 ciphersuites with SSL3.0 (if that is even possible..) or force RC4 with TLS1.0. Try to find out exactly which configurations work and which do not; try all cipher suites available. Trying to configure both GnuTLS and OpenSSL to use as similar parameters as possible, and then look at the protocol dumps to spot difference would also help. GnuTLS might be doing something different from OpenSSL that triggers the problem. /Simon From simon at josefsson.org Thu Dec 28 10:59:27 2006 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Dec 2006 10:59:27 +0100 Subject: [gnutls-dev] GnuTLS 1.6.1 Message-ID: <87r6uk8hog.fsf@latte.josefsson.org> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available Url : /pipermail/attachments/20061228/6139c77d/attachment.pgp From simon at josefsson.org Thu Dec 28 15:36:26 2006 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 28 Dec 2006 15:36:26 +0100 Subject: [gnutls-dev] GnuTLS 1.7.1 Message-ID: <87fyb084ut.fsf@latte.josefsson.org> This release almost entirely consists of the many fine patches received during my vacation. Remember, the GnuTLS 1.7.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. * Version 1.7.1 (released 2006-12-28) ** TLS 1.2 server side fix. The Certificate Request sent did not contain the list of supported hashes field, thus violating the protocol. It will now contain an empty list. Reported by ludovic.courtes at laas.fr (Ludovic Court?s). ** TLS 1.2 DSA signature verification fix. Reported by ludovic.courtes at laas.fr (Ludovic Court?s). ** Fix the list of trusted CAs that server's send to clients. Before, the list contained issuer DN's instead of subject DN's of the trusted CAs. Reported by Max Kellermann . ** Fix gnutls_certificate_set_x509_crl to initialize the CRL before using it. Also added a self-test in tests/certificate_set_x509_crl.c to test the function. Reported by Max Kellermann . ** Encode UID fields in DN's as DirectoryString. Before GnuTLS encoded and parsed UID fields as IA5String. This was incorrect, it should have used DirectoryString. Now it will use DirectoryString for the UID field, but for backwards compatibility it will also accept IA5String UID's. Reported by Max Kellermann . ** Improve out-of-sourcedir builds from CVS. Reported by ludovic.courtes at laas.fr (Ludovic Court?s). ** Bootstrap tools changed. We now require autoconf 2.61, automake 1.10, and gettext 0.16, when building GnuTLS from CVS. Libtool 1.5.22 is used. ** Fixed a syntax error in lib/gnutls.asn. Reported by Paul Millar . ** Added German translation of GnuTLS messages. ** Update of gnulib files. ** API and ABI modifications: No changes since last version. Here are the compressed sources (4.1MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.1.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.1.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.1.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.1.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: db39c51200f2068bc5ce1072ef8790c5f77250ae gnutls-1.7.1.tar.bz2 b142bbf81177b46e0d187c63509a06ae2b8cbd40 gnutls-1.7.1.tar.bz2.sig 48eae5deecf2531ae9d3426c08c7bf0a792f5ed3563e56b4a0abfe3a38975ebe gnutls-1.7.1.tar.bz2 1b5e3bfc362baa0a17783dd35cf019b0dae4f6b25566917efe1b0ebc06bb8a85 gnutls-1.7.1.tar.bz2.sig 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, 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. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available Url : /pipermail/attachments/20061228/1a38e8f0/attachment-0001.pgp