From ludovic.courtes at laas.fr Fri Jan 5 11:35:34 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Fri, 05 Jan 2007 11:35:34 +0100 Subject: [gnutls-dev] [PATCH] Detect GAA and fix out-of-source-tree builds References: <87mz5res78.fsf@laas.fr> <87psa59mmg.fsf@latte.josefsson.org> Message-ID: <87fyaprcax.fsf@laas.fr> A non-text attachment was scrubbed... Name: ,,gaa2.diff Type: text/x-diff Size: 1854 bytes Desc: The updated patch. Url : /pipermail/attachments/20070105/a03c9914/attachment.bin From simon at josefsson.org Fri Jan 5 13:16:52 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 05 Jan 2007 13:16:52 +0100 Subject: [gnutls-dev] [PATCH] Detect GAA and fix out-of-source-tree builds In-Reply-To: <87fyaprcax.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Fri\, 05 Jan 2007 11\:35\:34 +0100") References: <87mz5res78.fsf@laas.fr> <87psa59mmg.fsf@latte.josefsson.org> <87fyaprcax.fsf@laas.fr> Message-ID: <87bqldvfbf.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi! > > (and best wishes!) > > Simon Josefsson writes: > >> 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? > > The patch below should do the trick. Hi! Applied to CVS. Thanks, Simon From jw+debian at jameswestby.net Mon Jan 8 23:16:17 2007 From: jw+debian at jameswestby.net (James Westby) Date: Mon, 8 Jan 2007 22:16:17 +0000 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <87vejw8jrv.fsf@latte.josefsson.org> References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> Message-ID: <20070108221617.GA3591@jameswestby.net> On (28/12/06 10:14), Simon Josefsson wrote: > James Westby writes: > 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. Sorry, I should have included a pointer to http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2006-December/000338.html I have the tcpdumps in a private mail that I could forward to you if required. > 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. Unfortunately none of us have one of these phones, though Marc has been quick in getting the debug information that I have asked for. > > 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. Marc has just tested with the latest version in Debian that backports this fix to 1.4.4 with no change. > > 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? Yes, sorry, I got the numbers confused. > > 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. Marc found that his choices were very limited as the phone did not support many combinations. For instance not allowing SHA means that RC4 is the only choice available. You can see the results in the thread above. If you have any more queries then Marc can probably help, he has been excellent so far. > > 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. I haven't suggested this. Marc did ask for advice on how to get openssl to act like -serv, but I didn't know and haven't looked it up yet. On a slightly different note, -serv is an excellent tool, and has been very useful. Marc did have one problem with it though. As the first message of SMTP is sent by the server the echo mode didn't work. He asked if it would be possible to have a -cli like mode where the user can type to simulate the protocol they are testing. Would this be possible? Would you like me to open another thread on this topic or something? 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 jw+debian at jameswestby.net Mon Jan 8 23:32:22 2007 From: jw+debian at jameswestby.net (James Westby) Date: Mon, 8 Jan 2007 22:32:22 +0000 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <87vejw8jrv.fsf@latte.josefsson.org> References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> Message-ID: <20070108223222.GB3591@jameswestby.net> Apologies for posting again so quickly, but I remembered something else that I wanted to mention in the mail. When opening the tcpdumps in wireshark there is a breakdown of the handshake. Wireshark interprets it like this (without the version negotiation patch applied): Server Client Hello (SSL3.0 and TLS1.0) no compression 13 cipher suites 0x0035 0x002f 0x000a 0x0016 0x0013 0x0005 0x0004 0x0009 0x0012 0x0008 0x0003 0x0011 0x0014 Hello (TLS1.0) no compression 0x002f TLS_RSA_WITH_AES_128_CBC_SHA Certificate, Certificate request, Hello done Certificate (none) Client key exchange, Change cipher spec, Encrypted handshake Change cipher spec Encrypted handshake Encrypted alert (Bad record MAC). Which reads reasonable to me. As for debugging the actual data on the wire I'm not sure of the best approach for doing this. 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 Tue Jan 9 08:47:19 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Jan 2007 08:47:19 +0100 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <20070108221617.GA3591@jameswestby.net> (James Westby's message of "Mon\, 8 Jan 2007 22\:16\:17 +0000") References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108221617.GA3591@jameswestby.net> Message-ID: <878xgctzeg.fsf@latte.josefsson.org> James Westby writes: > On (28/12/06 10:14), Simon Josefsson wrote: >> James Westby writes: >> 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. > > Sorry, I should have included a pointer to > > http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/2006-December/000338.html > > I have the tcpdumps in a private mail that I could forward to you if > required. Please send them to me, I might get a chance to a have a look. >> 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. > > I haven't suggested this. Marc did ask for advice on how to get openssl > to act like -serv, but I didn't know and haven't looked it up yet. Try: openssl s_server ... > On a slightly different note, -serv is an excellent tool, and has been > very useful. Marc did have one problem with it though. As the first > message of SMTP is sent by the server the echo mode didn't work. He > asked if it would be possible to have a -cli like mode where the user > can type to simulate the protocol they are testing. Would this be > possible? Would you like me to open another thread on this topic or > something? Ah, I see. One problem with the -cli tool is that it needs to select() on both keyboard input and network streams, something which doesn't work reliably under Windows. gnutls-serv doesn't (yet) have that problem, since it doesn't read from keyboards. I realize this is not a good reason not to support such a mode, though... Having an --interactive parameter for -serv that would read from keyboard input would be OK, and if you want to work on it, that would be great. I'm afraid I don't have time to implement this myself without any funding though. /Simon From simon at josefsson.org Tue Jan 9 08:50:04 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Jan 2007 08:50:04 +0100 Subject: [gnutls-dev] Possible bug in GnuTLS AES/SHA1 In-Reply-To: <20070108223222.GB3591@jameswestby.net> (James Westby's message of "Mon\, 8 Jan 2007 22\:32\:22 +0000") References: <20061221183323.GJ9868@jameswestby.net> <87vejw8jrv.fsf@latte.josefsson.org> <20070108223222.GB3591@jameswestby.net> Message-ID: <871wm4tz9v.fsf@latte.josefsson.org> James Westby writes: > Apologies for posting again so quickly, but I remembered something else > that I wanted to mention in the mail. > > When opening the tcpdumps in wireshark there is a breakdown of the > handshake. Wireshark interprets it like this (without the version > negotiation patch applied): > > Server Client > > Hello (SSL3.0 and TLS1.0) no compression > 13 cipher suites > 0x0035 0x002f 0x000a 0x0016 0x0013 0x0005 0x0004 > 0x0009 0x0012 0x0008 0x0003 0x0011 0x0014 > > Hello (TLS1.0) no compression > 0x002f TLS_RSA_WITH_AES_128_CBC_SHA > > Certificate, Certificate request, Hello done > > Certificate (none) > > Client key exchange, Change cipher spec, > Encrypted handshake > > Change cipher spec > > Encrypted handshake > > Encrypted alert (Bad record MAC). > > > > Which reads reasonable to me. Me to... you'd might want to compare that with a OpenSSL server configured for similar settings. > As for debugging the actual data on the wire I'm not sure of the best > approach for doing this. Using wireshark and comparing between two sessions, one that work, and one that doesn't, and look for differences, is the only I can think of... there are some TLS dump tools around, but none as versatile as wireshark + RFC + pen&paper. /Simon From simon at josefsson.org Sun Jan 14 22:41:14 2007 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 14 Jan 2007 22:41:14 +0100 Subject: [gnutls-dev] GnuTLS 1.7.2 Message-ID: <878xg5ffr9.fsf@latte.josefsson.org> A lot of changes has been added since the last release, so it is about time to get this out for further testing. 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.2 (released 2007-01-14) ** Certtool now print the value of the pathLenConstraints field for certs. ** Certtool now query for path length constraints when generating CA certs. For batch uses, the certtool configuration name is "path_len". Suggested by Sascha Ziemann . ** Add new API to get/set pathLenConstraint in the Basic Constraints. The new functions gnutls_x509_crt_get_basic_constraints and gnutls_x509_crt_set_basic_constraints provide a superset of the functionality in the old gnutls_x509_crt_get_ca_status and gnutls_x509_crt_set_ca_status (respectively), but the old functions will continue to be supported. ** Add new API in OpenCDK to extract public/secret OpenPGP key to S-expr. The functions are cdk_pubkey_to_sexp and cdk_seckey_to_sexp. A proper OpenCDK release with this patch will be made soon, which should bump the OpenCDK version number. Patch by Mario Lenz . ** Certtool --to-p12 can now store more than one certificate in the blob. Before it could only store one certificate, but now it will read and store as many certificate there are from the --load-certificate file. Suggested by Sascha Ziemann . ** Clean up separation of gnutls and gnutls-extra for OpenPGP. In particular, the OpenPGP function variables are no longer part of the exported libgnutls interface, and no header files from libgnutls-extra (GPL) are needed by libgnutls (LGPL). The variables were never intended for non-internal purposes, and thus this does not imply a change in the external API/ABI. ** Print URL to gaa when missing, and fix srcdir!=builddir for GAA files. Reported by ludovic.courtes at laas.fr (Ludovic Court?s). ** GnuTLS no longer uses -mms-bitfields --enable-runtime-pseudo-reloc. Before these parameters were set to make GnuTLS build under mingw32, however, they appear to no longer be necessary. ** A minor fix to the C++ library to make it build. Reported by Pavlov Konstantin . ** Update of gnulib files. ** API and ABI modifications: gnutls_x509_crt_get_basic_constraints: ADD. gnutls_x509_crt_set_basic_constraints: ADD. cdk_pubkey_to_sexp: ADD (in opencdk). cdk_seckey_to_sexp: ADD (in opencdk). Here are the compressed sources (4.1MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.2.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-1.7.2.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.2.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-1.7.2.tar.bz2.sig Here are the SHA-1 and SHA-224 checksums: 708166c359e3172d11f13cf769db52701074b878 gnutls-1.7.2.tar.bz2 6b62c5af653968e1a9ca3152fd54e1bfcb5458ab gnutls-1.7.2.tar.bz2.sig 2899127cb9af44827d36b5eae556c8af20e9647fb7fb229e10fa0821 gnutls-1.7.2.tar.bz2 d9077641286903818c55c871fc3ff6e44fe2dbb58d885cae00c939f7 gnutls-1.7.2.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/20070114/fdf1aeac/attachment-0001.pgp From ludovic.courtes at laas.fr Mon Jan 15 10:38:56 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 15 Jan 2007 10:38:56 +0100 Subject: [gnutls-dev] Makefile fix for 1.7.2 Message-ID: <87bql0y6hb.fsf@laas.fr> A non-text attachment was scrubbed... Name: ,,makefile-fix-1.7.2.diff Type: text/x-diff Size: 374 bytes Desc: Makefile fix Url : /pipermail/attachments/20070115/458ea9a2/attachment.bin From simon at josefsson.org Tue Jan 16 10:56:51 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Jan 2007 10:56:51 +0100 Subject: [gnutls-dev] Makefile fix for 1.7.2 In-Reply-To: <87bql0y6hb.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Mon\, 15 Jan 2007 10\:38\:56 +0100") References: <87bql0y6hb.fsf@laas.fr> Message-ID: <87y7o3wazg.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > The latest version of `NEWS' mentions that 1.7.2 was released yesterday, > but I couldn't find the announcement (in case it hasn't yet been > released, I'm planning to submit an updated fix for the OpenPGP privkey > import today). Hi! It was released yesterday, but the announcement were delayed for some reason. But don't worry, a new release will be out in a few weeks or so... > Below is a tiny Makefile fix (without it, I get an undefined reference > to `read_binary_file ()' when building the libgnutls-extra-dependent > programs). I can't reproduce this: http://autobuild.josefsson.org/gnutls/log-200701160143145770000.txt Which platform are you on? I actually got errors about double definitions when I linked to both libraries -- libgnu.la does link to liblgnu.la. This was changed recently though, maybe you need to 'make distclean' or similar? /Simon From ludovic.courtes at laas.fr Tue Jan 16 11:43:27 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 16 Jan 2007 11:43:27 +0100 Subject: [gnutls-dev] Makefile fix for 1.7.2 References: <87bql0y6hb.fsf@laas.fr> <87y7o3wazg.fsf@latte.josefsson.org> Message-ID: <87y7o3jlps.fsf@laas.fr> Hi, Simon Josefsson writes: > ludovic.courtes at laas.fr (Ludovic Court?s) writes: >> Below is a tiny Makefile fix (without it, I get an undefined reference >> to `read_binary_file ()' when building the libgnutls-extra-dependent >> programs). > > I can't reproduce this: > > http://autobuild.josefsson.org/gnutls/log-200701160143145770000.txt > > Which platform are you on? I actually got errors about double > definitions when I linked to both libraries -- libgnu.la does link to > liblgnu.la. This was changed recently though, maybe you need to 'make > distclean' or similar? I'm using Debian GNU/Linux (sid). `libgnutls-extra' is linked against `libgnutls' which does include `liblgnu' (and `read_binary_file ()'). However, `libgnutls' does not export `read_binary_file ()': $ objdump -T lib/.libs/libgnutls.so | grep read_binary_file [ nothing ] Thus, it seems "logical" to me to also link `libgnutls-extra' against `liblgnu'. Now, I can imagine that this might fail on some other platform... Thanks, Ludo'. From simon at josefsson.org Tue Jan 16 17:07:11 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Jan 2007 17:07:11 +0100 Subject: [gnutls-dev] Makefile fix for 1.7.2 In-Reply-To: <87y7o3jlps.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Tue\, 16 Jan 2007 11\:43\:27 +0100") References: <87bql0y6hb.fsf@laas.fr> <87y7o3wazg.fsf@latte.josefsson.org> <87y7o3jlps.fsf@laas.fr> Message-ID: <8764b7t0pc.fsf@latte.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > >>> Below is a tiny Makefile fix (without it, I get an undefined reference >>> to `read_binary_file ()' when building the libgnutls-extra-dependent >>> programs). >> >> I can't reproduce this: >> >> http://autobuild.josefsson.org/gnutls/log-200701160143145770000.txt >> >> Which platform are you on? I actually got errors about double >> definitions when I linked to both libraries -- libgnu.la does link to >> liblgnu.la. This was changed recently though, maybe you need to 'make >> distclean' or similar? > > I'm using Debian GNU/Linux (sid). `libgnutls-extra' is linked against > `libgnutls' which does include `liblgnu' (and `read_binary_file ()'). > However, `libgnutls' does not export `read_binary_file ()': > > $ objdump -T lib/.libs/libgnutls.so | grep read_binary_file > [ nothing ] > > Thus, it seems "logical" to me to also link `libgnutls-extra' against > `liblgnu'. Now, I can imagine that this might fail on some other > platform... Yeah, but libgnutls-extra should be linked to libgnu: libgnutls_extra_la_LIBADD += ../gl/libgnu.la ../lib/libgnutls.la And libgnu should be linked to liblgnu: libgnu_la_LIBADD += ../lgl/liblgnu.la And libgnu seem to contain read_binary_file: jas at mocca:~/src/gnutls$ objdump -t gl/.libs/libgnu.a | grep read_binary_file 000001f8 g F .text 00000034 read_binary_file jas at mocca:~/src/gnutls$ So libgnutls-extra should pick it up. But you'll have to re-link libgnu if you don't build from a clean directory. /Simon From ludovic.courtes at laas.fr Mon Jan 22 13:27:33 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 22 Jan 2007 13:27:33 +0100 Subject: [gnutls-dev] Makefile fix for 1.7.2 References: <87bql0y6hb.fsf@laas.fr> <87y7o3wazg.fsf@latte.josefsson.org> <87y7o3jlps.fsf@laas.fr> <8764b7t0pc.fsf@latte.josefsson.org> Message-ID: <87hcujz1oq.fsf@laas.fr> Hi, Simon Josefsson writes: > Yeah, but libgnutls-extra should be linked to libgnu: > > libgnutls_extra_la_LIBADD += ../gl/libgnu.la ../lib/libgnutls.la > > And libgnu should be linked to liblgnu: > > libgnu_la_LIBADD += ../lgl/liblgnu.la > > And libgnu seem to contain read_binary_file: > > jas at mocca:~/src/gnutls$ objdump -t gl/.libs/libgnu.a | grep read_binary_file > 000001f8 g F .text 00000034 read_binary_file > jas at mocca:~/src/gnutls$ > > So libgnutls-extra should pick it up. But you'll have to re-link > libgnu if you don't build from a clean directory. Oops, indeed, after `make distclean' everything compiles and links as expected. Weird... Thanks, Ludovic. From mario.lenz at gmx.net Mon Jan 22 18:57:05 2007 From: mario.lenz at gmx.net (Mario Lenz) Date: Mon, 22 Jan 2007 18:57:05 +0100 Subject: [gnutls-dev] The future of OpenCDK In-Reply-To: <87irf3kwov.fsf@latte.josefsson.org> References: <87zm8jhyah.fsf@laas.fr> <17836.63955.481542.439077@squeak.fifthhorseman.net> <871wluj0tq.fsf@latte.josefsson.org> <1168974346.3210.25.camel@sarge> <87irf3kwov.fsf@latte.josefsson.org> Message-ID: <1169488625.3200.20.camel@etch> Hi! > It seems as if OpenCDK duplicate some of the functionality that > properly belong to GnuPG. However, as far as I know, there aren't any > APIs in GnuPG to do what OpenCDK does, even if the functionality is > there. Yes, that's a problem. gpgme doesn't seem to be an alternative, either. It's just a way to use gnupg from your application. I don't think you can realise everything gnutls needs with it. > A serious question would be if we want to continue maintain > OpenCDK at all. Making the same functionality be available from some > GnuPG component could give some advantages -- such as smartcard > support, gpg-agent support for passphrase caching, and hopefully > better maintained code. > > Right now I keep maintaining OpenCDK because we are stuck with it, and > that approach rarely results in the best products... I have the strong feeling that there's a lot of stuff in opencdk that's not used by gnutls. (I can't proof it, though.) If you think that's ok, give it it's own project. If opencdk is just a helper library to gnutls, I'd suggest to keep it small and simple and throw away everything that's not needed by gnutls. This would be the first step. Then we would know what gnutls needs and could think about possible replacements. Even if we would decide to keep opencdk (because of no alternatives) this would make things easier because there would be less code to maintain. Well, if you think that's ok, I'd try to eliminate as much code from opencdk as possible. greez Mario -- Wieners, in buns, no condiments. It's Hank's way. Anything else is wrong. From yoann at prelude-ids.org Tue Jan 23 10:27:28 2007 From: yoann at prelude-ids.org (Yoann Vandoorselaere) Date: Tue, 23 Jan 2007 10:27:28 +0100 Subject: [gnutls-dev] SRP compatibility problem between different GnuTLS version Message-ID: <1169544449.29089.65.camel@arwen.prelude-ids.org> Hi, It appear there are compatibility issues with SRP between different GnuTLS version. As an example, peers using GnuTLS-1.4.0 are not able to proceed authentication with peers using GnuTLS-1.4.5: the handshake terminate with a "GnuTLS internal error". I suspect this is due to the following change in GnuTLS-1.4.2: ** Change SRP and Cert-Type extensions to match IANA registry. The problem is that this randomly break things for the end-user although there are other authentication method usable (the client/server we are using both support SRP and Anonymous authentication, which are supposed to be negotiated when the communication start). In this specific case, I would expect GnuTLS to use another authentication method, if any, rather than failing. My question is whether such breakage are predictable, and whether a change in the application code might permit us to revert to another authentication method in case it happen. Regards, -- Yoann Vandoorselaere From simon at josefsson.org Thu Jan 25 10:33:54 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Jan 2007 10:33:54 +0100 Subject: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd) In-Reply-To: <20070125071725.GB2880@colwyn.zhadum.org.uk> (Matthias Scheler's message of "Thu\, 25 Jan 2007 07\:17\:26 +0000") References: <20070125071725.GB2880@colwyn.zhadum.org.uk> Message-ID: <87y7nrv4al.fsf@latte.josefsson.org> For some reason, the post below bounced, so I'm re-sending it. I'll look at the patches ASAP. /Simon Matthias Scheler writes: > Hello, > > I was trying to send the following e-mail to gnutls-dev at gnupg.org but > the mailing list software bounced it: > > From: Matthias Scheler > Subject: Building GnuTLS 1.6.1 under Mac OS X > To: gnutls-dev at gnupg.org > Date: Wed, 24 Jan 2007 19:21:18 +0000 > > > Hello, > > the C++ library included in "gnutls" 1.6.1 doesn't build under Mac OS X > because of a compiler bug. Apple's GCC apparently doesn't handle calling > pure virtual function in constructors and desctrutors properly, see here: > > http://porting.openoffice.org/mac/macosx_issues.html > > I've attached two patches taken from NetBSD's "pkgsrc" which inline > the copy constructor of the "credentials" class under Mac OS X. That > fixes the build problem for me under Mac OS 10.4.8 using the G++ > compiler from Xcode tools 2.4.1. > > Kind regards > > -- > Matthias Scheler http://zhadum.org.uk/ > > $NetBSD: patch-aa,v 1.9 2007/01/24 15:58:04 tron Exp $ > > --- includes/gnutls/gnutlsxx.h.orig 2006-08-07 13:40:23.000000000 +0100 > +++ includes/gnutls/gnutlsxx.h 2007-01-24 11:29:43.000000000 +0000 > @@ -233,7 +233,14 @@ > { > public: > credentials(gnutls_credentials_type_t t); > +#if defined(__APPLE__) || defined(__MACOS__) > + credentials( credentials& c) { > + type = c.type; > + set_ptr( c.ptr()); > + } > +#else > credentials( credentials& c); > +#endif > virtual ~credentials() { } > gnutls_credentials_type_t get_type() const; > protected: > > $NetBSD: patch-ac,v 1.3 2007/01/24 15:58:04 tron Exp $ > > --- lib/gnutlsxx.cpp.orig 2006-06-01 20:49:01.000000000 +0100 > +++ lib/gnutlsxx.cpp 2007-01-24 11:31:05.000000000 +0000 > @@ -822,11 +822,13 @@ > { > } > > +#if !(defined(__APPLE__) || defined(__MACOS__)) > credentials::credentials( credentials& c) > { > this->type = c.type; > this->set_ptr( c.ptr()); > } > +#endif > > gnutls_credentials_type_t credentials::get_type() const > { > > > > > > ---------- > > > Could you please resend it? I've also attached it to this e-mail. > > Kind regards > > -- > Matthias Scheler http://zhadum.org.uk/ >>From tron at colwyn.zhadum.org.uk Thu Jan 25 07:15:51 2007 +0000 > X-Keywords: > Received: from kerckhoffs.g10code.com ([217.69.77.222]) > by trithemius.gnupg.org with esmtp (Exim 4.50 #1 (Debian)) > id 1H9qac-0001Jy-Tu for ; > Wed, 24 Jan 2007 23:27:34 +0100 > Received: from colwyn.zhadum.org.uk ([81.187.181.119] ident=root) > by kerckhoffs.g10code.com with esmtp (Exim 4.50 #1 (Debian)) > id 1H9q1B-0004Ox-QC > for ; Wed, 24 Jan 2007 22:50:58 +0100 > Received: from excalibur.zhadum.org.uk (excalibur.zhadum.org.uk > [81.187.181.118]) > by colwyn.zhadum.org.uk (8.13.5.20060614/8.13.3) with ESMTP id > l0OJLJxV018309 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) > for ; Wed, 24 Jan 2007 19:21:19 GMT > Received: by localhost.localhost (Postfix, from userid 1001) > id 912095E5194; Wed, 24 Jan 2007 19:21:18 +0000 (GMT) > Date: Wed, 24 Jan 2007 19:21:18 +0000 > From: Matthias Scheler > To: gnutls-dev at gnupg.org > Subject: Building GnuTLS 1.6.1 under Mac OS X > Message-ID: <20070124192118.GA617 at colwyn.zhadum.org.uk> > Mime-Version: 1.0 > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" > Content-Disposition: inline > User-Agent: Mutt/1.4.2.2i > X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 > (colwyn.zhadum.org.uk [81.187.181.119]); > Wed, 24 Jan 2007 19:21:19 +0000 (GMT) > X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on > trithemius.gnupg.org > X-Spam-Level: > X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham > version=3.0.3 > X-Original-Status: RO > Status: RO > Content-Length: 2492 > Lines: 94 > > > --XF85m9dhOBO43t/C > Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" > Content-Disposition: inline > > > --CE+1k2dSO48ffgeK > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > > Hello, > > the C++ library included in "gnutls" 1.6.1 doesn't build under Mac OS X > because of a compiler bug. Apple's GCC apparently doesn't handle calling > pure virtual function in constructors and desctrutors properly, see here: > > http://porting.openoffice.org/mac/macosx_issues.html > > I've attached two patches taken from NetBSD's "pkgsrc" which inline > the copy constructor of the "credentials" class under Mac OS X. That > fixes the build problem for me under Mac OS 10.4.8 using the G++ > compiler from Xcode tools 2.4.1. > > Kind regards > > --=20 > Matthias Scheler http://zhadum.org.uk/ > > --CE+1k2dSO48ffgeK > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename=patch-aa > > $NetBSD: patch-aa,v 1.9 2007/01/24 15:58:04 tron Exp $ > > --- includes/gnutls/gnutlsxx.h.orig 2006-08-07 13:40:23.000000000 +0100 > +++ includes/gnutls/gnutlsxx.h 2007-01-24 11:29:43.000000000 +0000 > @@ -233,7 +233,14 @@ > { > public: > credentials(gnutls_credentials_type_t t); > +#if defined(__APPLE__) || defined(__MACOS__) > + credentials( credentials& c) { > + type = c.type; > + set_ptr( c.ptr()); > + } > +#else > credentials( credentials& c); > +#endif > virtual ~credentials() { } > gnutls_credentials_type_t get_type() const; > protected: > > --CE+1k2dSO48ffgeK > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename=patch-ac > Content-Transfer-Encoding: quoted-printable > > $NetBSD: patch-ac,v 1.3 2007/01/24 15:58:04 tron Exp $ > > --- lib/gnutlsxx.cpp.orig 2006-06-01 20:49:01.000000000 +0100 > +++ lib/gnutlsxx.cpp 2007-01-24 11:31:05.000000000 +0000 > @@ -822,11 +822,13 @@ > {=20 > } > =20 > +#if !(defined(__APPLE__) || defined(__MACOS__)) > credentials::credentials( credentials& c) > { > this->type =3D c.type; > this->set_ptr( c.ptr()); > } > +#endif > =20 > gnutls_credentials_type_t credentials::get_type() const > {=20 > > --CE+1k2dSO48ffgeK-- > > --XF85m9dhOBO43t/C > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (Darwin) > > iD8DBQFFt7GtiYEmcnvdc3cRAnbDAKCTKatP9RIxswhqfXkHT5kJuvzbuwCgvDyw > t8naVCEzAeCP8b1GA9Rnc/c= > =Glgk > -----END PGP SIGNATURE----- > > --XF85m9dhOBO43t/C-- From simon at josefsson.org Thu Jan 25 10:43:17 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Jan 2007 10:43:17 +0100 Subject: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd) In-Reply-To: <87y7nrv4al.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu\, 25 Jan 2007 10\:33\:54 +0100") References: <20070125071725.GB2880@colwyn.zhadum.org.uk> <87y7nrv4al.fsf@latte.josefsson.org> Message-ID: <87ps93v3uy.fsf@latte.josefsson.org> Matthias Scheler writes: >> Hello, >> >> the C++ library included in "gnutls" 1.6.1 doesn't build under Mac OS X >> because of a compiler bug. Apple's GCC apparently doesn't handle calling >> pure virtual function in constructors and desctrutors properly, see here: >> >> http://porting.openoffice.org/mac/macosx_issues.html >> >> I've attached two patches taken from NetBSD's "pkgsrc" which inline >> the copy constructor of the "credentials" class under Mac OS X. That >> fixes the build problem for me under Mac OS 10.4.8 using the G++ >> compiler from Xcode tools 2.4.1. Hi! While I really dislike adding #if's to work around compiler bugs (people should fix their compilers), I'm not familiar enough with C++ or the GnuTLS C++ library to offer any better solution. I have installed the patch, with a comment about removing it in a few years. Thanks, Simon From simon at josefsson.org Thu Jan 25 11:21:55 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Jan 2007 11:21:55 +0100 Subject: [gnutls-dev] SRP compatibility problem between different GnuTLS version In-Reply-To: <1169544449.29089.65.camel@arwen.prelude-ids.org> (Yoann Vandoorselaere's message of "Tue\, 23 Jan 2007 10\:27\:28 +0100") References: <1169544449.29089.65.camel@arwen.prelude-ids.org> Message-ID: <87d553v22k.fsf@latte.josefsson.org> Yoann Vandoorselaere writes: > Hi, > > It appear there are compatibility issues with SRP between different > GnuTLS version. As an example, peers using GnuTLS-1.4.0 are not able to > proceed authentication with peers using GnuTLS-1.4.5: the handshake > terminate with a "GnuTLS internal error". > > I suspect this is due to the following change in GnuTLS-1.4.2: > ** Change SRP and Cert-Type extensions to match IANA registry. Hi! Ah, yes, I can see how that becomes an interoperability problem. It seems bad if it causes internal errors though. If I read you correctly, this only happens on the GnuTLS 1.4.0 side? Does a 1.4.5 peer terminate with an internal error when it tries to negotiate with a 1.4.0 peer? > The problem is that this randomly break things for the end-user although > there are other authentication method usable (the client/server we are > using both support SRP and Anonymous authentication, which are supposed > to be negotiated when the communication start). > > In this specific case, I would expect GnuTLS to use another > authentication method, if any, rather than failing. Right, that's what I'd expect too. > My question is whether such breakage are predictable, and whether a > change in the application code might permit us to revert to another > authentication method in case it happen. Tracking down (i.e., debugging) exactly what triggers the internal error message would be useful, and might help you answer that. You could also try to add the old values into the 1.4.5 peer, and see if the 1.4.0 client then successfully negotiate SRP. We should still use the official IANA value, but we could support the old ones for compatibility too. That could go into future versions... /Simon From yoann at prelude-ids.org Thu Jan 25 12:17:08 2007 From: yoann at prelude-ids.org (Yoann Vandoorselaere) Date: Thu, 25 Jan 2007 12:17:08 +0100 Subject: [gnutls-dev] SRP compatibility problem between different GnuTLS version In-Reply-To: <87d553v22k.fsf@latte.josefsson.org> References: <1169544449.29089.65.camel@arwen.prelude-ids.org> <87d553v22k.fsf@latte.josefsson.org> Message-ID: <1169723828.29089.116.camel@arwen.prelude-ids.org> Le jeudi 25 janvier 2007 ? 11:21 +0100, Simon Josefsson a ?crit : > Yoann Vandoorselaere writes: > > > Hi, > > > > It appear there are compatibility issues with SRP between different > > GnuTLS version. As an example, peers using GnuTLS-1.4.0 are not able to > > proceed authentication with peers using GnuTLS-1.4.5: the handshake > > terminate with a "GnuTLS internal error". > > > > I suspect this is due to the following change in GnuTLS-1.4.2: > > ** Change SRP and Cert-Type extensions to match IANA registry. > > Hi! Ah, yes, I can see how that becomes an interoperability problem. > > It seems bad if it causes internal errors though. If I read you > correctly, this only happens on the GnuTLS 1.4.0 side? Does a 1.4.5 > peer terminate with an internal error when it tries to negotiate with > a 1.4.0 peer? [1.4.5 changed to 1.4.4]. It happen both way around: - 1.4.0 client connecting to 1.4.4 server: fail. - 1.4.4 client connecting to 1.4.0 server: fail. gnutls_handshake() fail on both end of the peer returning -59 (GnuTLS internal error). When looking at the TLS debug log, one can see that a TLS alert is raised (although it is never returned by gnutls_handshake): "The SRP username was not sent". See attached srp-server.log and srp-client.log TLS debug file. [...] -- Yoann Vandoorselaere -------------- next part -------------- A non-text attachment was scrubbed... Name: srp-client.log Type: text/x-log Size: 3861 bytes Desc: not available Url : /pipermail/attachments/20070125/feaed161/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: srp-server.log Type: text/x-log Size: 4723 bytes Desc: not available Url : /pipermail/attachments/20070125/feaed161/attachment-0001.bin From simon at josefsson.org Thu Jan 25 12:39:09 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Jan 2007 12:39:09 +0100 Subject: [gnutls-dev] FOSDEM Message-ID: <874pqfuyhu.fsf@latte.josefsson.org> I'll be attending FOSDEM this year, so if anyone wants to chat or have a beer or something, I'm interested! /Simon From rks at mur.at Fri Jan 26 22:08:29 2007 From: rks at mur.at (Rupert Kittinger-Sereinig) Date: Fri, 26 Jan 2007 22:08:29 +0100 Subject: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd) In-Reply-To: <87ps93v3uy.fsf@latte.josefsson.org> References: <20070125071725.GB2880@colwyn.zhadum.org.uk> <87y7nrv4al.fsf@latte.josefsson.org> <87ps93v3uy.fsf@latte.josefsson.org> Message-ID: <45BA6DCD.8090907@mur.at> Simon Josefsson schrieb: > Matthias Scheler writes: > >>> Hello, >>> >>> the C++ library included in "gnutls" 1.6.1 doesn't build under Mac OS X >>> because of a compiler bug. Apple's GCC apparently doesn't handle calling >>> pure virtual function in constructors and desctrutors properly, see here: >>> >>> http://porting.openoffice.org/mac/macosx_issues.html >>> >>> I've attached two patches taken from NetBSD's "pkgsrc" which inline >>> the copy constructor of the "credentials" class under Mac OS X. That >>> fixes the build problem for me under Mac OS 10.4.8 using the G++ >>> compiler from Xcode tools 2.4.1. > > Hi! While I really dislike adding #if's to work around compiler bugs > (people should fix their compilers), I'm not familiar enough with C++ > or the GnuTLS C++ library to offer any better solution. I have > installed the patch, with a comment about removing it in a few years. > > Thanks, > Simon Hi Simon, I think that the "compiler bug" is described in the link is actually correct behaviour. the relevant snippet: MyAbstractClass MyWrapperClass::getClass() { static MyConcreteClass rClass; return rClass; } Note that the return type is MyAbstractClass, but the function tries to return MyConcreteClass. So the return value is implicitely converted to its base class, it is "sliced". (The function being called in a constructor has nothing to do with it.) For virtual functions to work, the object must to acessed via pointer or reference. I looked up the mail that reported the error, and it seems that the compiler fails to create an instance of the set_ptr() member function in the object file. In this case, I would try to uninline set_ptr(). This can hardly be a performance problem and should fix the linker error :-) cheers, Rupert -- Rupert Kittinger-Sereinig Krenngasse 32 A-8010 Graz Austria From simon at josefsson.org Wed Jan 31 12:07:43 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 31 Jan 2007 12:07:43 +0100 Subject: [gnutls-dev] [PATCH] Authority key ID bug in certtool In-Reply-To: <20061217171543.GA16738@morgase.caliginous.net> (Dale Sedivec's message of "Sun\, 17 Dec 2006 12\:15\:43 -0500") References: <20061217171543.GA16738@morgase.caliginous.net> Message-ID: <87abzz78u8.fsf@latte.josefsson.org> Hi Dale! Thanks for your detailed report, a quite interesting bug indeed! I'm sorry for the delay. I think this problem warrants some even more detailed discussion. First, as far as I can tell, RFC 4158 section 3.5.12 suggests that OpenSSL is buggy here. Non-matching KID's should not cause verification failures: "May be used to eliminate certificates: No". Are you sure OpenSSL is rejecting the chain because of this problem alone? It looks that way, but I'm not familiar with OpenSSL. Second, it is not clear to me whether it is right to copy the SKI from the CA into the AKI in the EEC. I've posted a question to the PKIX list, but it hasn't showed up in the archives yet. To me, the spec seem a bit unclear. There's also the question what to when there is no AKI in the CA, but RFC 3280 says that you MUST add one so I guess that is what we'll do. OpenSSL appear to break on this as well. Thanks, Simon Dale Sedivec writes: > 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 simon at josefsson.org Wed Jan 31 12:29:09 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 31 Jan 2007 12:29:09 +0100 Subject: [gnutls-dev] Building GnuTLS 1.6.1 under Mac OS X (fwd) In-Reply-To: <45BA6DCD.8090907@mur.at> (Rupert Kittinger-Sereinig's message of "Fri\, 26 Jan 2007 22\:08\:29 +0100") References: <20070125071725.GB2880@colwyn.zhadum.org.uk> <87y7nrv4al.fsf@latte.josefsson.org> <87ps93v3uy.fsf@latte.josefsson.org> <45BA6DCD.8090907@mur.at> Message-ID: <8764an77ui.fsf@latte.josefsson.org> Rupert Kittinger-Sereinig writes: > Hi Simon, > > I think that the "compiler bug" is described in the link is actually > correct behaviour. > > the relevant snippet: > > MyAbstractClass MyWrapperClass::getClass() > { > static MyConcreteClass rClass; > return rClass; > } Hi Rupert! My C++ knowledge is too weak to pattern-match that with the code currently in GnuTLS. includes/gnutls/gnutlsxx.h has: class credentials { public: credentials(gnutls_credentials_type_t t); #if defined(__APPLE__) || defined(__MACOS__) /* FIXME: This #if is due to a compile bug in Mac OS X. Give it some time and then remove this cruft. See also lib/gnutlsxx.cpp. */ credentials( credentials& c) { type = c.type; set_ptr( c.ptr()); } #else credentials( credentials& c); #endif virtual ~credentials() { } gnutls_credentials_type_t get_type() const; protected: friend class session; virtual void* ptr() const=0; virtual void set_ptr(void* ptr)=0; gnutls_credentials_type_t type; }; and lib/gnutlsxx.cpp has: #if !(defined(__APPLE__) || defined(__MACOS__)) /* FIXME: This #if is due to a compile bug in Mac OS X. Give it some time and then remove this cruft. See also includes/gnutls/gnutlsxx.h. */ credentials::credentials( credentials& c) { this->type = c.type; this->set_ptr( c.ptr()); } #endif > Note that the return type is MyAbstractClass, but the function tries to > return MyConcreteClass. So the return value is implicitely converted to > its base class, it is "sliced". (The function being called in a > constructor has nothing to do with it.) For virtual functions to work, > the object must to acessed via pointer or reference. > > I looked up the mail that reported the error, and it seems that the > compiler fails to create an instance of the set_ptr() member function > in the object file. In this case, I would try to uninline set_ptr(). > This can hardly be a performance problem and should fix the linker error :-) I'd really appreciate your help here. What would your recommendation be, more specifically? The old code is the one which is used when the newly added #if's are not chosen. I've seen other bug reports too, such as this failure: >> verify-elf: ERROR: ./usr/lib/libgnutlsxx.so.13.2.2: undefined symbol: >> _ZN6gnutls11credentials7set_ptrEPv But that may actually be the same, I don't know... /Simon From simon at josefsson.org Wed Jan 31 18:36:40 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 31 Jan 2007 18:36:40 +0100 Subject: [gnutls-dev] [PATCH] Authority key ID bug in certtool In-Reply-To: <87abzz78u8.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed\, 31 Jan 2007 12\:07\:43 +0100") References: <20061217171543.GA16738@morgase.caliginous.net> <87abzz78u8.fsf@latte.josefsson.org> Message-ID: <874pq785ef.fsf@latte.josefsson.org> Hi again. Using the SKI from the CA seems to be the right thing, although I modified your patch to make it fall back to a locally computed KID if reading the SKI from the CA fails (which would happen for CAs that doesn't have any SKI, for instance..). The replies on the PKIX list also indicate that OpenSSL's behaviour here is buggy, though, so if you care about that, you'd might want to report it. Non-matching AKI/SKI shouldn't cause verification failures. /Simon Simon Josefsson writes: > Hi Dale! Thanks for your detailed report, a quite interesting bug > indeed! I'm sorry for the delay. > > I think this problem warrants some even more detailed discussion. > First, as far as I can tell, RFC 4158 section 3.5.12 suggests that > OpenSSL is buggy here. Non-matching KID's should not cause > verification failures: "May be used to eliminate certificates: No". > Are you sure OpenSSL is rejecting the chain because of this problem > alone? It looks that way, but I'm not familiar with OpenSSL. > > Second, it is not clear to me whether it is right to copy the SKI from > the CA into the AKI in the EEC. I've posted a question to the PKIX > list, but it hasn't showed up in the archives yet. To me, the spec > seem a bit unclear. > > There's also the question what to when there is no AKI in the CA, but > RFC 3280 says that you MUST add one so I guess that is what we'll do. > OpenSSL appear to break on this as well. > > Thanks, > Simon > > Dale Sedivec writes: > >> 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 gerald at wireshark.org Wed Jan 31 19:18:33 2007 From: gerald at wireshark.org (Gerald Combs) Date: Wed, 31 Jan 2007 10:18:33 -0800 Subject: [gnutls-dev] [PATCH] Fix slow startup under Windows Message-ID: <45C0DD79.9000206@wireshark.org> Attached is a modified version of the patch at http://www.securitypunk.com/libgcrypt/ which addresses the slow startup problems with libgcrypt under Windows. The patch includes following changes: - Additional flags are passed to CryptAcquireContext to increase its likelihood of success - If CryptAcquireContext fails, fall back to slower methods instead of aborting - Add Doxygen-compatible comments, including links to MSDN documentation (we'll see how long the links stay valid) - Add debug logging A version of GNUTLS with the patch applied has been included with recent Wireshark builds, and will be in the 0.99.5 release. The response from testers has been positive so far. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libgcrypt_dll-gcc.patch Url: /pipermail/attachments/20070131/8356f255/attachment.asc