From simon at josefsson.org Mon Nov 2 12:55:43 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 02 Nov 2009 12:55:43 +0100 Subject: GnuTLS 2.8.5 Message-ID: <87eiohm98g.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.8.5. 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 ========== ** libgnutls: In server side when resuming a session do not overwrite the ** initial session data with the resumed session data. ** 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. ** guile: Compatibility with guile 2.x. By Ludovic Courtes . ** tests: Fix expired cert in chainverify self-test. ** tests: Fix time bomb in chainverify self-test. Reported by Andreas Metzler in . ** API and ABI modifications: No changes since last version. 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 (6.0MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.5.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.8.5.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: 2010-04-21] 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: 2010-04-21] 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: 5121c52efd4718ad3d8b641d28343b0c6abaa571 gnutls-2.8.5.tar.bz2 9d6f1906e380cc7366e2427493c33b72a137e438cdc9080fba3d84f6 gnutls-2.8.5.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: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ 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 includes libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.5. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.8.5.exe (15MB) http://josefsson.org/gnutls4win/gnutls-2.8.5.exe.sig The checksum values for SHA-1 and SHA-224 are: 5dadd78a630f30d3b4b3a34261068e74cba28d80 gnutls-2.8.5.exe 53af38a54ff2f971d9eecfb44f4ab39cc6dbad371ad6425d312eaccd gnutls-2.8.5.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.8.5.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.8.5.zip.sig The checksum values for SHA-1 and SHA-224 are: b41c0ac3088620bf78996d719b335317cb90405a gnutls-2.8.5.zip 73ca7da90ebac569948114735d6899a08431ebbe15be3d619bec05a3 gnutls-2.8.5.zip A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.5-1_all.deb (4.8MB) The checksum values for SHA-1 and SHA-224 are: 4ecb2e7617d8722d090ec96138ce595647c06a82 mingw32-gnutls_2.8.5-1_all.deb cbdd418aea622dfaf9876f563ebc1e192ec0ab90bca8748277501e76 mingw32-gnutls_2.8.5-1_all.deb Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Malay, Polish, 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 Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From simon at josefsson.org Mon Nov 2 15:20:28 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 02 Nov 2009 15:20:28 +0100 Subject: GnuTLS 2.8.5 In-Reply-To: <87d441qec0.fsf@rapitore.luna> (Marco Maggi's message of "Mon, 02 Nov 2009 13:51:59 +0100") References: <87eiohm98g.fsf@mocca.josefsson.org> <87d441qec0.fsf@rapitore.luna> Message-ID: <87vdhtatzn.fsf@mocca.josefsson.org> Marco Maggi writes: >> Internationalization >> ==================== >> >> The GnuTLS library messages have been translated into >> Czech, Dutch, French, German, Malay, Polish, Swedish, and >> Vietnamese. We welcome the addition of more translations. > > Let's say that, in a purely hypothetical parallel universe, > I can attempt Italian translation; what should I do? Check out http://translationproject.org/html/translators.html and contact the Italian translation team. Thanks in advance! /Simon From simon at josefsson.org Mon Nov 9 16:19:50 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 09 Nov 2009 16:19:50 +0100 Subject: TLS Renegotiation problem Message-ID: <87d43rwwrt.fsf@mocca.josefsson.org> As you may have heard, people how found out how to attack TLS as used in many application protocols. For more info see: http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html http://extendedsubset.com/ http://www.imperialviolet.org/2009/11/05/tls-reneg.html It is important to understand that you are not vulnerable unless you use renegotiation, which is not typical. If you use renegotiation, perhaps to request client certificates in a web server, the simplest "fix" is to disable any use of renegotiation. You don't need to do this if your application protocol is robust -- for example XMPP/Jabber appears to be robust against the problem. HTTPS is not robust. There is work ongoing to specify a new extension to make TLS renegotiation safe against this attack, and hopefully GnuTLS will support it soon. Patches have been published in http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3944 but not yet tested or verified, and the IETF/IANA has not allocated a TLS extension number for it yet either. /Simon From dkg at fifthhorseman.net Mon Nov 9 19:01:23 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 09 Nov 2009 13:01:23 -0500 Subject: TLS Renegotiation problem In-Reply-To: <87d43rwwrt.fsf@mocca.josefsson.org> References: <87d43rwwrt.fsf@mocca.josefsson.org> Message-ID: <4AF858F3.9000204@fifthhorseman.net> On 11/09/2009 10:19 AM, Simon Josefsson wrote: > It is important to understand that you are not vulnerable unless you use > renegotiation, which is not typical. If you use renegotiation, perhaps > to request client certificates in a web server, the simplest "fix" is to > disable any use of renegotiation. My understanding is that the published attacks are undetectable from the client-side without the use of the newly-proposed extension. So barring that extension, it seems that that the protective workaround you describe (disabling renegotiation) needs to be done on the server side. Is there a way that this can be done generically with GnuTLS (e.g. a priority string, which could conceivably be passed into gnutls by an administrator without needing a rebuild), or should the server simply avoid calling gnutls_handshake() more than once per session? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Mon Nov 9 19:09:51 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 09 Nov 2009 19:09:51 +0100 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <4ACDADDB.3030703@unifr.ch> (Carolin Latze's message of "Thu, 08 Oct 2009 11:16:11 +0200") References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> Message-ID: <87iqdj8t8w.fsf@mocca.josefsson.org> Carolin, I just re-ran the x509signself self-test with gnutls 2.9.x and the hash size passed to the function is now 20 bytes. I suppose GnuTLS adds the right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the callback should receive the entire PKCS#1 blob, to avoid having the callback reconstruct it, instead of just the hash value, but maybe this is sufficient to make things work for you? I'll release 2.9.9 in a few minutes with some minor fixes, please test it. /Simon Carolin Latze writes: > Hi Simon, > > I tried to use TLS 1.2 with and without sign callback, and I still see a > signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't > it be max 35 then? Maybe we should check, whether I check the right > variables: > > In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure > called dconcat. dconcat.size holds the hash size, right? and > dconcat.data should hold the hash itself? dconcat.size has a value of 36 > for me... > > If I use the sign callback, I print the value of hash->size (=36) and > hash->data (cannot see the OID included in that value, so for me it > looks like it is really not SHA-1 only). > > Maybe I check the wrong values? > > BTW: I used the latest Snapshot, 2.9.8 to test it. > > Sorry... :-/ > Carolin > > Simon Josefsson wrote: >> Carolin Latze writes: >> >> >>> Hi all, >>> >>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>> 36... that does not sound like a standard signature.. I would expect >>> something like 20 for SHA1. Am I wrong? >>> >> >> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >> a look? It should have more solid TLS 1.2 support. >> >> Thanks, >> Simon >> From simon at josefsson.org Tue Nov 10 08:08:49 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 10 Nov 2009 08:08:49 +0100 Subject: TLS Renegotiation problem In-Reply-To: <4AF858F3.9000204@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 09 Nov 2009 13:01:23 -0500") References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> Message-ID: <87zl6u7t6m.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On 11/09/2009 10:19 AM, Simon Josefsson wrote: >> It is important to understand that you are not vulnerable unless you use >> renegotiation, which is not typical. If you use renegotiation, perhaps >> to request client certificates in a web server, the simplest "fix" is to >> disable any use of renegotiation. > > My understanding is that the published attacks are undetectable from the > client-side without the use of the newly-proposed extension. Yes. > So barring that extension, it seems that that the protective > workaround you describe (disabling renegotiation) needs to be done on > the server side. > > Is there a way that this can be done generically with GnuTLS (e.g. a > priority string, which could conceivably be passed into gnutls by an > administrator without needing a rebuild), or should the server simply > avoid calling gnutls_handshake() more than once per session? In GnuTLS, rehandshaking needs to be done explicitly by servers when they get the GNUTLS_E_REHANDSHAKE error back from gnutls_record_recv. If servers don't call gnutls_handshake when that happens, there is no problem. So people can check their applications if they are vulnerable to this problem. For example, the mod_gnutls Apache plugin does not support renegotiation so there is no problem with it (this was the main case that I were concerned with): if (rc == GNUTLS_E_REHANDSHAKE) { /* A client has asked for a new Hankshake. Currently, we don't do it */ ap_log_error(APLOG_MARK, APLOG_INFO, ctxt->input_rc, ctxt->c->base_server, "GnuTLS: Error reading data. Client Requested a New Handshake." " (%d) '%s'", rc, gnutls_strerror(rc)); } Possibly we could indeed have a new mode where GnuTLS refuses to do renegotiation based on a priority string. /Simon From simon at josefsson.org Tue Nov 10 09:55:52 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 10 Nov 2009 09:55:52 +0100 Subject: TLS Renegotiation problem In-Reply-To: <87zl6u7t6m.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 10 Nov 2009 08:08:49 +0100") References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> Message-ID: <87ws1y4v3b.fsf@mocca.josefsson.org> Simon Josefsson writes: > For example, the mod_gnutls Apache plugin does not support renegotiation > so there is no problem with it (this was the main case that I were > concerned with): Other servers that use GnuTLS is Exim4 and GNU Mailutils. I checked the sources and cannot find any place where they performs TLS renegotiation. So as far as I can tell, they are safe too. (Of course, this assume that it is even possible to exploit this problem with SMTP/IMAP/POP3 which I haven't seen explained yet.) What other popular servers use GnuTLS? Is there _any_ GnuTLS server that is vulnerable? Not even our gnutls-serv appears to support renegotiation as far as I can tell. /Simon From hajimasta at i2r.a-star.edu.sg Tue Nov 10 11:40:20 2009 From: hajimasta at i2r.a-star.edu.sg (Handi Ajimasta) Date: Tue, 10 Nov 2009 18:40:20 +0800 Subject: GNUTLS compression Message-ID: <162B8AFBFBBB2148A9A1B8F9C575342808B3CD9A@mailbe01.teak.local.net> Hi all, I installed gnutls 2.5.5 in Windows XP, and gnutls 2.8.4 in Windows 7 Release Candidate from http://josefsson.org/gnutls4win/ . I thought that 'DEFLATE' compression algorithm is enabled by default in all gnutls releases. However, when I force my TLS client to use DEFLATE algorithm (and not the NULL) by: int pPriorities[3] = {GNUTLS_COMP_DEFLATE, 0}; gnutls_compression_set_priority(session, pPriorities); My TLS client is not able to handshake with the server, because the compression algorithm is not available. When I did a 'gnutls-cli -l' in command prompt in both Windows XP and Windows 7, what I saw was: "COMPRESSION: NULL" only, without DEFLATE nor LZO algorithm. I successfully installed gnutls in an Ubuntu machine though, and when I did 'gnutls-cli -l' I could see that it has both DEFLATE algorithm and NULL there without me configuring anything at all. My questions are: 1) Is compression available for gnutls in Windows? 2) If it's yes.. how do I enable it? 3) If it's not available.. is there any way that I could enable it? 4) Is there any performance gain from enabling the compression? I understand that we might save some bandwidth with the compression, but with increased lag time, is there any noticeable difference? Thanks in advance for any help given. Regards, Handi Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From simon at josefsson.org Tue Nov 10 12:29:04 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 10 Nov 2009 12:29:04 +0100 Subject: TLS Renegotiation problem In-Reply-To: <20091110111754.GA14025@redhat.com> (Tomas Hoger's message of "Tue, 10 Nov 2009 12:17:54 +0100") References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> <87ws1y4v3b.fsf@mocca.josefsson.org> <20091110111754.GA14025@redhat.com> Message-ID: <87zl6u39fj.fsf@mocca.josefsson.org> Tomas Hoger writes: > On Tue, Nov 10, 2009 at 09:55:52AM +0100, Simon Josefsson wrote: >> What other popular servers use GnuTLS? > > CUPS and libvirt(d). No GNUTLS_E_REHANDSHAKE in their sources, client > requested renegotiations seem to fail. Thanks for checking. So to summarize, so far the following servers appears to not be affected by this problem when used with GnuTLS: gnutls-serv mod_gnutls exim4 mailutils CUPS libvirtd If the servers are linked with OpenSSL I don't know if they are vulnerable or not, it would depend on whether OpenSSL perform renegotiation without application interaction. So make sure they are linked to GnuTLS before declaring victory. I think we now have some evidence to suggest GnuTLS needn't do anything about this. It seems any use of rehandshake with GnuTLS is application-specific and then the answer is probably to fix that application instead of GnuTLS. Any more insight or thoughts on this is welcome. What GnuTLS needs to do, though, is to have a discussion of the issue in the manual where renegotiation is discussed, so application writers are aware of the problem. /Simon From thoger at redhat.com Tue Nov 10 14:22:16 2009 From: thoger at redhat.com (Tomas Hoger) Date: Tue, 10 Nov 2009 14:22:16 +0100 Subject: TLS Renegotiation problem In-Reply-To: <87zl6u39fj.fsf@mocca.josefsson.org> References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> <87ws1y4v3b.fsf@mocca.josefsson.org> <20091110111754.GA14025@redhat.com> <87zl6u39fj.fsf@mocca.josefsson.org> Message-ID: <20091110132216.GA15446@redhat.com> On Tue, Nov 10, 2009 at 12:29:04PM +0100, Simon Josefsson wrote: > If the servers are linked with OpenSSL I don't know if they are > vulnerable or not, it would depend on whether OpenSSL perform > renegotiation without application interaction. OpenSSL and NSS both do renegotiation transparently for application. > I think we now have some evidence to suggest GnuTLS needn't do anything > about this. It seems any use of rehandshake with GnuTLS is > application-specific and then the answer is probably to fix that > application instead of GnuTLS. Is that meant as meant as "no change needed" or "no urgent temporary hotfix needed"? Is the implementation of the proposed extension still the long-term plan, so that apps needing rehandshakes can do them safely? Thanks! th. From simon at josefsson.org Tue Nov 10 17:43:55 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 10 Nov 2009 17:43:55 +0100 Subject: TLS Renegotiation problem In-Reply-To: <20091110132216.GA15446@redhat.com> (Tomas Hoger's message of "Tue, 10 Nov 2009 14:22:16 +0100") References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> <87ws1y4v3b.fsf@mocca.josefsson.org> <20091110111754.GA14025@redhat.com> <87zl6u39fj.fsf@mocca.josefsson.org> <20091110132216.GA15446@redhat.com> Message-ID: <87my2u2uus.fsf@mocca.josefsson.org> Tomas Hoger writes: >> I think we now have some evidence to suggest GnuTLS needn't do anything >> about this. It seems any use of rehandshake with GnuTLS is >> application-specific and then the answer is probably to fix that >> application instead of GnuTLS. > > Is that meant as meant as "no change needed" or "no urgent temporary hotfix > needed"? Both. ;-) The situation appears to be that 1) there is no patch against GnuTLS that we can use as a temporary hotfix, and 2) there appears (so far) to be no servers that use GnuTLS in a way that is vulnerable to this problem. There _could_ be servers that use GnuTLS which were vulnerable. For these applications, the simplest short-term solution appears to be to remove/disable the TLS renegotiation code. That would be an urgent problem that needs to be addressed quickly, if there actually are deployed instances of that situation. If a majority of servers that used GnuTLS were vulnerable to this problem, I think we'd have to consider patching GnuTLS instead of recommending patching application. Compare when we changed X.509 path validation in GnuTLS to check expiry/activation times: it was not a GnuTLS problem but it affected so many applications and it made more sense to fix it in GnuTLS than change all the applications. Our survey of servers using GnuTLS indicates that we are not close to being in this situation for this problem. Daniel suggested to add a priority string to allow admin's to disable TLS renegotiation unconditionally without having to recompile application/libraries. That seems like a good idea, but there are no instances where we known that it would improve anything. Priority strings is a quite new features, so the application would have to make use of priority strings AND do renegotiation AND implement a protocol that is vulnerable to this attack (e.g., HTTP) in order for things to work. That situation seems unlikely, but could happen, and then we'll certainly implement Daniel's suggestion. We could also release a GnuTLS that does not support TLS renegotiation at all. Right now, that is not known to fix anything, so I don't see what you would gain in doing so. But we could end up needing to do that too. So, in summary, given (my) current knowledge there is no need to either patch GnuTLS or any server application using GnuTLS. > Is the implementation of the proposed extension still the long-term > plan, so that apps needing rehandshakes can do them safely? Yes. /Simon From simon at josefsson.org Tue Nov 10 17:49:28 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 10 Nov 2009 17:49:28 +0100 Subject: TLS Renegotiation problem In-Reply-To: (Steve Dispensa's message of "Tue, 10 Nov 2009 08:08:00 -0600") References: <20091110132216.GA15446@redhat.com> Message-ID: <87iqdi2ulj.fsf@mocca.josefsson.org> Steve Dispensa writes: > On 11/10/09 7:22 AM, "Tomas Hoger" wrote: >>> I think we now have some evidence to suggest GnuTLS needn't do anything >>> about this. It seems any use of rehandshake with GnuTLS is >>> application-specific and then the answer is probably to fix that >>> application instead of GnuTLS. >> >> Is that meant as meant as "no change needed" or "no urgent temporary hotfix >> needed"? Is the implementation of the proposed extension still the >> long-term plan, so that apps needing rehandshakes can do them safely? > > [sorry if I'm late to the game; we had a baby a few days ago and I'm sadly > behind on e-mail and most other things.] Congratulations! Perfect timing.. ;) > I agree with Tomas. When I wrote up the patch, I noticed that there were a > few impediments to doing renegotiation at all in the way things are > currently implemented (unless I misunderstood, which I always quite > possible). Still, at some point, someone is going to really need the feature > (or decide that the implementation is incomplete without perfect support for > it), and once that happens, the bug will magically appear unless the TLS > extension I supported. > > There's also a good reason to support the extension from an interop > standpoint - servers will want to detect patched clients in the (near?) > future, so sending the extension along will be helpful. Definitely. Given a patch (and copyright assignment) for this, we could add it to the experimental branch today, and once the IANA has allocated a code point it could even be backported into the stable branch. But that would be completely unrelated to fixing any short-term security problem. /Simon From fw at deneb.enyo.de Tue Nov 10 19:13:27 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 10 Nov 2009 19:13:27 +0100 Subject: TLS Renegotiation problem In-Reply-To: <87my2u2uus.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 10 Nov 2009 17:43:55 +0100") References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> <87ws1y4v3b.fsf@mocca.josefsson.org> <20091110111754.GA14025@redhat.com> <87zl6u39fj.fsf@mocca.josefsson.org> <20091110132216.GA15446@redhat.com> <87my2u2uus.fsf@mocca.josefsson.org> Message-ID: <87eio6b648.fsf@mid.deneb.enyo.de> * Simon Josefsson: > So, in summary, given (my) current knowledge there is no need to either > patch GnuTLS or any server application using GnuTLS. But GNUTLS would have to implement the extension to secure connections to servers which support renegotiation. From fw at deneb.enyo.de Tue Nov 10 20:28:04 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 10 Nov 2009 20:28:04 +0100 Subject: TLS Renegotiation problem In-Reply-To: (Steve Dispensa's message of "Tue, 10 Nov 2009 13:27:00 -0600") References: Message-ID: <87y6me89iz.fsf@mid.deneb.enyo.de> * Steve Dispensa: > On 11/10/09 12:13 PM, "Florian Weimer" wrote: > >> * Simon Josefsson: >> >>> So, in summary, given (my) current knowledge there is no need to either >>> patch GnuTLS or any server application using GnuTLS. >> >> But GNUTLS would have to implement the extension to secure connections >> to servers which support renegotiation. > > (...which support safe renegotiation using the extension - no such thing as > safe renegotiation absent both client and server supporting the extension.) Eh, yes, this was sort-of implied. Thanks for the correction. From bdt at shaw.ca Tue Nov 10 23:16:54 2009 From: bdt at shaw.ca (Borislav Trifonov) Date: Tue, 10 Nov 2009 14:16:54 -0800 Subject: Unencrypted connection? Message-ID: I'm interested in using gnutls both for secure communication, but also as a cross-platform wrapper (Linux+Windows) for my unencrypted sockets use, so I don't have to write one myself.? I'm wondering if it's possible to have an unencrypted connection, would it be say using GNUTLS_CIPHER_NULL, and also any detriments to doing that. I'm using the http://josefsson.org/gnutls4win/ port for Windows.? However, I can't build the examples since tcp.c includes *nix headers not present on Windows... I'm a bit confused, does that mean the examples aren't ported? Also, is it possible to use UDP instead of TCP? Thanks From carolin.latze at unifr.ch Wed Nov 11 08:08:03 2009 From: carolin.latze at unifr.ch (Carolin Latze) Date: Wed, 11 Nov 2009 08:08:03 +0100 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <87iqdj8t8w.fsf@mocca.josefsson.org> References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> <87iqdj8t8w.fsf@mocca.josefsson.org> Message-ID: <4AFA62D3.2020009@unifr.ch> Hi Simon, that sounds good. I will check it in two weeks (I am out of office at the moment, only reading my mails from time to time :-)) Thanks a lot! Carolin Simon Josefsson wrote: > Carolin, > > I just re-ran the x509signself self-test with gnutls 2.9.x and the hash > size passed to the function is now 20 bytes. I suppose GnuTLS adds the > right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the > callback should receive the entire PKCS#1 blob, to avoid having the > callback reconstruct it, instead of just the hash value, but maybe this > is sufficient to make things work for you? I'll release 2.9.9 in a few > minutes with some minor fixes, please test it. > > /Simon > > Carolin Latze writes: > > >> Hi Simon, >> >> I tried to use TLS 1.2 with and without sign callback, and I still see a >> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't >> it be max 35 then? Maybe we should check, whether I check the right >> variables: >> >> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure >> called dconcat. dconcat.size holds the hash size, right? and >> dconcat.data should hold the hash itself? dconcat.size has a value of 36 >> for me... >> >> If I use the sign callback, I print the value of hash->size (=36) and >> hash->data (cannot see the OID included in that value, so for me it >> looks like it is really not SHA-1 only). >> >> Maybe I check the wrong values? >> >> BTW: I used the latest Snapshot, 2.9.8 to test it. >> >> Sorry... :-/ >> Carolin >> >> Simon Josefsson wrote: >> >>> Carolin Latze writes: >>> >>> >>> >>>> Hi all, >>>> >>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>>> 36... that does not sound like a standard signature.. I would expect >>>> something like 20 for SHA1. Am I wrong? >>>> >>>> >>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >>> a look? It should have more solid TLS 1.2 support. >>> >>> Thanks, >>> Simon >>> >>> From thoger at redhat.com Wed Nov 11 11:03:54 2009 From: thoger at redhat.com (Tomas Hoger) Date: Wed, 11 Nov 2009 11:03:54 +0100 Subject: TLS Renegotiation problem In-Reply-To: <87eio6b648.fsf@mid.deneb.enyo.de> References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> <87ws1y4v3b.fsf@mocca.josefsson.org> <20091110111754.GA14025@redhat.com> <87zl6u39fj.fsf@mocca.josefsson.org> <20091110132216.GA15446@redhat.com> <87my2u2uus.fsf@mocca.josefsson.org> <87eio6b648.fsf@mid.deneb.enyo.de> Message-ID: <20091111110354.5e39bc93@redhat.com> On Tue, 10 Nov 2009 19:13:27 +0100 Florian Weimer wrote: > > So, in summary, given (my) current knowledge there is no need to > > either patch GnuTLS or any server application using GnuTLS. > > But GNUTLS would have to implement the extension to secure connections > to servers which support renegotiation. Simon confirmed that the implementation of the extension is planned. I apologize for not properly specifying that "no change needed" was actually meant as "no change needed, not even reneg extension implemented", which caused the confusion. th. From simon at josefsson.org Wed Nov 11 11:10:25 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 11 Nov 2009 11:10:25 +0100 Subject: GNUTLS compression In-Reply-To: <162B8AFBFBBB2148A9A1B8F9C575342808B3CD9A@mailbe01.teak.local.net> (Handi Ajimasta's message of "Tue, 10 Nov 2009 18:40:20 +0800") References: <162B8AFBFBBB2148A9A1B8F9C575342808B3CD9A@mailbe01.teak.local.net> Message-ID: <87pr7pe5im.fsf@mocca.josefsson.org> "Handi Ajimasta" writes: > Hi all, > > I installed gnutls 2.5.5 in Windows XP, and gnutls 2.8.4 in Windows 7 > Release Candidate from http://josefsson.org/gnutls4win/ . > > I thought that 'DEFLATE' compression algorithm is enabled by default in > all gnutls releases. However, when I force my TLS client to use DEFLATE > algorithm (and not the NULL) by: > > int pPriorities[3] = {GNUTLS_COMP_DEFLATE, 0}; > gnutls_compression_set_priority(session, pPriorities); > > My TLS client is not able to handshake with the server, because the > compression algorithm is not available. > > When I did a 'gnutls-cli -l' in command prompt in both Windows XP and > Windows 7, what I saw was: "COMPRESSION: NULL" only, without DEFLATE nor > LZO algorithm. > > > I successfully installed gnutls in an Ubuntu machine though, and when I > did 'gnutls-cli -l' I could see that it has both DEFLATE algorithm and > NULL there without me configuring anything at all. > > My questions are: > 1) Is compression available for gnutls in Windows? > 2) If it's yes.. how do I enable it? > 3) If it's not available.. is there any way that I could enable it? > 4) Is there any performance gain from enabling the compression? I > understand that we might save some bandwidth with the compression, but > with increased lag time, is there any noticeable difference? My Windows build of GnuTLS does not include libz, so it is not available. You should be able to install libz and recompile GnuTLS for Windows yourself, or provide me with a patch against the gnutls4win makefile so that future builds will support libz. I don't think compression is all that useful in normal use cases. It can be relevant if you are on dial-up or slow wireless links though. /Simon From nmav at gnutls.org Wed Nov 11 21:00:45 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 11 Nov 2009 22:00:45 +0200 Subject: GNUTLS compression In-Reply-To: <162B8AFBFBBB2148A9A1B8F9C575342808B3CD9A@mailbe01.teak.local.net> References: <162B8AFBFBBB2148A9A1B8F9C575342808B3CD9A@mailbe01.teak.local.net> Message-ID: <4AFB17ED.9050106@gnutls.org> Handi Ajimasta wrote: > 4) Is there any performance gain from enabling the compression? I > understand that we might save some bandwidth with the compression, but > with increased lag time, is there any noticeable difference? Hello, Check some tests I did when I implemented it: http://lists.gnupg.org/pipermail/gnutls-dev/2002-September/000362.html regards, Nikos From hajimasta at i2r.a-star.edu.sg Fri Nov 13 08:09:50 2009 From: hajimasta at i2r.a-star.edu.sg (Handi Ajimasta) Date: Fri, 13 Nov 2009 15:09:50 +0800 Subject: GNUTLS compression In-Reply-To: <4AFB17ED.9050106@gnutls.org> References: <162B8AFBFBBB2148A9A1B8F9C575342808B3CD9A@mailbe01.teak.local.net> <4AFB17ED.9050106@gnutls.org> Message-ID: <162B8AFBFBBB2148A9A1B8F9C5753428028912ED@mailbe01.teak.local.net> Hi Nikos, Thanks for link. It helps! :) Handi -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Thursday, 12 November, 2009 4:01 AM To: Handi Ajimasta Cc: help-gnutls at gnu.org Subject: Re: GNUTLS compression Handi Ajimasta wrote: > 4) Is there any performance gain from enabling the compression? I > understand that we might save some bandwidth with the compression, but > with increased lag time, is there any noticeable difference? Hello, Check some tests I did when I implemented it: http://lists.gnupg.org/pipermail/gnutls-dev/2002-September/000362.html regards, Nikos Institute for Infocomm Research disclaimer: "This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you." From simon at josefsson.org Tue Nov 17 11:32:46 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 17 Nov 2009 11:32:46 +0100 Subject: TLS Renegotiation problem In-Reply-To: <87zl6u7t6m.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 10 Nov 2009 08:08:49 +0100") References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> Message-ID: <87bpj11lwx.fsf@mocca.josefsson.org> Simon Josefsson writes: > In GnuTLS, rehandshaking needs to be done explicitly by servers when > they get the GNUTLS_E_REHANDSHAKE error back from gnutls_record_recv. > If servers don't call gnutls_handshake when that happens, there is no > problem. So people can check their applications if they are vulnerable > to this problem. For everyone's information, searching for "GNUTLS_E_REHANDSHAKE" in code is not be sufficient: that only takes care of the situation where the local client reacts on a renegotiation request from the remote server. You also have to search for "gnutls_rehandshake" to take care of the situation where the local server initiates the renegotiation request. I believe one still has to look carefully at each example to understand whether a particular instance is vulnerable or not: not all instances of TLS reneg appears vulnerable. For example, a server could make sure that before calling gnutls_rehandshake it reads all data coming from the client and performs input sanitizing on it because there is no guarantee that data comes from the same identity who performs the TLS rehandshake and sends more data later on. /Simon From simon at josefsson.org Tue Nov 17 11:58:45 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 17 Nov 2009 11:58:45 +0100 Subject: FIPS Certification In-Reply-To: <87zl81ycyc.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 08 Oct 2009 20:09:47 +0200") References: <87zl81ycyc.fsf@mocca.josefsson.org> Message-ID: <871vjx1kpm.fsf@mocca.josefsson.org> Simon Josefsson writes: > "Hoyt, David" writes: > >> Is or will there be an effort to become FIPS certified? If so, is >> there a schedule laid out for the process? Is there a webpage I can >> look at to keep myself up-to-date on the certification process? > > All the crypto in GnuTLS normally happens in libgcrypt, and I recall > seeing libgcrypt mentioned on the list of projects underway of becoming > FIPS-certified some time ago. Looking again, I see that AES/3DES/SHA1/SHA2/RSA/DSA/RNG in libgcrypt have been FIPS certified. Follow links from: http://csrc.nist.gov/groups/STM/cavp/validation.html Still, older TLS does not use standard RSA PKCS#1 so you have to make sure GnuTLS is really using the right crypto bits from libgcrypt. /Simon From thoger at redhat.com Wed Nov 18 19:28:52 2009 From: thoger at redhat.com (Tomas Hoger) Date: Wed, 18 Nov 2009 19:28:52 +0100 Subject: TLS Renegotiation problem In-Reply-To: <87bpj11lwx.fsf@mocca.josefsson.org> References: <87d43rwwrt.fsf@mocca.josefsson.org> <4AF858F3.9000204@fifthhorseman.net> <87zl6u7t6m.fsf@mocca.josefsson.org> <87bpj11lwx.fsf@mocca.josefsson.org> Message-ID: <20091118192852.15c4563c@redhat.com> On Tue, 17 Nov 2009 11:32:46 +0100 Simon Josefsson wrote: > > In GnuTLS, rehandshaking needs to be done explicitly by servers when > > they get the GNUTLS_E_REHANDSHAKE error back from > > gnutls_record_recv. If servers don't call gnutls_handshake when > > that happens, there is no problem. So people can check their > > applications if they are vulnerable to this problem. > > For everyone's information, searching for "GNUTLS_E_REHANDSHAKE" in > code is not be sufficient: that only takes care of the situation > where the local client reacts on a renegotiation request from the > remote server. > > You also have to search for "gnutls_rehandshake" to take care of the > situation where the local server initiates the renegotiation request. I did a search for that in Red Hat Enterprise Linux sources and I've not found anything using it. Google codesearch finds it in mod_gnutls though. From a 30sec look, it may be using it in similar cases as mod_ssl / mod_nss. th. From tomasz.welman at pl.ibm.com Thu Nov 19 09:02:59 2009 From: tomasz.welman at pl.ibm.com (Tomasz Welman) Date: Thu, 19 Nov 2009 09:02:59 +0100 Subject: gnutls is unable to get x509 certificate Message-ID: Hi, The problem is that I am using LDAP, and ldaps://, but it doesn't work. With the help op openldap guys, I've tracked down the issue to be gnutls problem. The full description (with (hopefully all of the) debugging info) is here: http://www.openldap.org/lists/openldap-technical/200911/msg00039.html -- Tomasz 'Trog' Welman Software Developer external: 48-12-628-9449 ITN: 34819449 T/L: 9449 IBM SWG Lab, Krakow, Poland IBM Polska Sp. z o.o. oddzia? w Krakowie ul. Armii Krajowej 18 30 -150 Krak?w NIP: 526-030-07-24, KRS 0000012941 Kapita? zak?adowy: 33.000.000 PLN -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Nov 19 23:25:47 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Nov 2009 00:25:47 +0200 Subject: gnutls is unable to get x509 certificate In-Reply-To: References: Message-ID: <4B05C5EB.7070809@gnutls.org> Tomasz Welman wrote: > Hi, > > The problem is that I am using LDAP, and ldaps://, but it doesn't work. > With the help op openldap guys, I've tracked down the issue to be gnutls > problem. > > The full description (with (hopefully all of the) debugging info) is here: > > http://www.openldap.org/lists/openldap-technical/200911/msg00039.html Please tell us for a way to reproduce. If you cannot please run gnutls-cli-debug against this server and send the output. regards, Nikos From simon at josefsson.org Fri Nov 20 08:57:06 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 20 Nov 2009 08:57:06 +0100 Subject: gnutls is unable to get x509 certificate In-Reply-To: (Tomasz Welman's message of "Thu, 19 Nov 2009 09:02:59 +0100") References: Message-ID: <87tywphbn1.fsf@mocca.josefsson.org> Tomasz Welman writes: > Hi, > > The problem is that I am using LDAP, and ldaps://, but it doesn't work. > With the help op openldap guys, I've tracked down the issue to be gnutls > problem. > > The full description (with (hopefully all of the) debugging info) is here: > > http://www.openldap.org/lists/openldap-technical/200911/msg00039.html The IBM server is buggy, this has been debugged before, see complete discussion and workarounds: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477 /Simon From lfinsto at gwdg.de Wed Nov 25 09:38:44 2009 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Wed, 25 Nov 2009 09:38:44 +0100 (CET) Subject: Problems handling X.509 certificates Message-ID: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> Hello, I need to use X.509 certificates for authentication/authorization in an application and I've been working through the examples in the GNUTLS manual. I'm new to GNUTLS (and network programming), so please excuse me if my questions are naive. I've been using and modifying the programs "7.3.2 Simple Client Example with X.509 Certificate Support" and "7.4.2 Echo Server with X.509 Authentication II". I've been trying to use the function `verify_certificate_chain' (defined in `ex-verify.c') instead of `verify_certificate' (defined in `ex-rfc2818.c'), but I can't seem to get it to work. I have two certificates that I want the client to send to the server. In the client, I call `gnutls_certificate_set_x509_key_file' twice, once for each certificate/key pair. However, in the server, `gnutls_certificate_get_peers' sets the `*LIST_SIZE' to 1, i.e., it only finds one certificate. I've tried various things to get it to work, but with no success. I must be overlooking something, but I don't know what it could be. Any help would be much appreciated. Laurence Finston From tomasz.welman at pl.ibm.com Thu Nov 26 10:39:53 2009 From: tomasz.welman at pl.ibm.com (Tomasz Welman) Date: Thu, 26 Nov 2009 10:39:53 +0100 Subject: gnutls is unable to get x509 certificate In-Reply-To: <87tywphbn1.fsf@mocca.josefsson.org> References: <87tywphbn1.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson wrote on 11/20/2009 08:57:06 AM: > Simon Josefsson > 11/20/2009 08:57 AM > > To > > Tomasz Welman/Poland/IBM at IBMPL > > cc > > help-gnutls at gnu.org > > Subject > > Re: gnutls is unable to get x509 certificate > > Tomasz Welman writes: > > > Hi, > > > > The problem is that I am using LDAP, and ldaps://, but it doesn't work. > > With the help op openldap guys, I've tracked down the issue to be gnutls > > problem. > > > > The full description (with (hopefully all of the) debugging info) is here: > > > > http://www.openldap.org/lists/openldap-technical/200911/msg00039.html > > The IBM server is buggy, this has been debugged before, see complete > discussion and workarounds: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477 > Ok, that helped a bit. When I'm doing: gnutls-cli -p 636 bluepages.ibm.com --priority NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-TLS1.2:-CTYPE-OPENPGP it's working, but if I am giving it the CA certificate obtained this way: openssl s_client -host bluepages.ibm.com -port 636 > bp.cert and then: twelman at darthvader:~$ gnutls-cli --x509cafile bp.cert -p 636 bluepages.ibm.com --priority NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-TLS1.2:-CTYPE-OPENPGP it fails with message: Processed 1 CA certificate(s). Resolving 'bluepages.ibm.com'... Connecting to '9.17.186.253:636'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=Colorado,L=Boulder,O=International Business Machines,OU=Terms of use at www.verisign.com/rpa (c)05,OU=Terms of use at www.verisign.com/rpa (c)05,CN=bluepages.ibm.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', RSA key 1024 bits, signed using RSA-SHA, activated `2008-03-19 00:00:00 UTC', expires `2011-05-23 23:59:59 UTC', SHA-1 fingerprint `b4ed74f52d5de2efac31cbac286ef20bccaba87a' - Certificate[1] info: - subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5' - Certificate[2] info: - subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2' - The hostname in the certificate matches 'bluepages.ibm.com'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: SSL3.0 - Key Exchange: RSA - Cipher: AES-256-CBC - MAC: SHA1 - Compression: NULL *** Verifying server certificate failed... The bp.cert looks like this: twelman at darthvader:~$ cat bp.cert -----BEGIN CERTIFICATE----- MIIFbzCCBFegAwIBAgIQQqowfydfbhGjnIrdG/yoqTANBgkqhkiG9w0BAQUFADCB sDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEqMCgGA1UEAxMh VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBMB4XDTA4MDMxOTAwMDAw MFoXDTExMDUyMzIzNTk1OVowgeIxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2xv cmFkbzEQMA4GA1UEBxQHQm91bGRlcjEoMCYGA1UEChQfSW50ZXJuYXRpb25hbCBC dXNpbmVzcyBNYWNoaW5lczEzMDEGA1UECxQqVGVybXMgb2YgdXNlIGF0IHd3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA1MTMwMQYDVQQLFCpUZXJtcyBvZiB1c2UgYXQg d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxGjAYBgNVBAMUEWJsdWVwYWdlcy5p Ym0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDSUyh7l1px1jcmNeqf 48bV4DQUKhk1h0uBOn24+HdD5YS0TuYrOVtY7L/oX6jT+2Klaogyq8JdYaREnKJo NVAHyPoAYUrnCHwguZdK0KRo9EjbP55qGoYw0gtd0zD9f/G03237x+Kz6sVAvnmN zWeHZ8OT4EfLKDa1pGW/F7QHTQIDAQABo4IB0zCCAc8wCQYDVR0TBAIwADALBgNV HQ8EBAMCBaAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL1NWUlNlY3VyZS1jcmwu dmVyaXNpZ24uY29tL1NWUlNlY3VyZTIwMDUuY3JsMEQGA1UdIAQ9MDswOQYLYIZI AYb4RQEHFwMwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYTAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU b+yvoN2KpO/1KhBnLT9VgrzX7yUweQYIKwYBBQUHAQEEbTBrMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wQwYIKwYBBQUHMAKGN2h0dHA6Ly9T VlJTZWN1cmUtYWlhLnZlcmlzaWduLmNvbS9TVlJTZWN1cmUyMDA1LWFpYS5jZXIw bgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMC GgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24u Y29tL3ZzbG9nbzEuZ2lmMA0GCSqGSIb3DQEBBQUAA4IBAQBXSkgfiiwhOkhj1jZn NYM+ic3E3niRM7xFuz4nz2vX5L7ThVFlYFlWoOynNyfuVXqMxqrf6f8Y2uVMY5Cj PohjrjVocgDsN8epFaplIH/HSXj21q385wAajfYBsxzTQqHytUZ0Apva7rpGAG9l TUYyqA7vxmr/xLTIPzWNk680hwXihFFw8f4vcIvS1riu1AwESUiRQN2BJkTAaRKt n2qjBWirioah4j8kJWvsH/p1P7OAg63rM9hEWi3t9aQBZ2JKKKwmdTI98J2wG/nC PkwhK2dIdkBjr+6ICd0Hp8MME0oTpXq8CuiAbEQRcvQ6aUttnDYOnE8dluRPccgf 5BFI -----END CERTIFICATE----- Can you help? What I want to achieve is get the CA (as I did with openssl s_client) and then be able to connect giving this CA for validation so I'm sure this bluepages.ibm.com is actually the same server that gave me the CA. -- Tomasz 'Trog' Welman Software Developer external: 48-12-628-9449 ITN: 34819449 T/L: 9449 IBM SWG Lab, Krakow, Poland IBM Polska Sp. z o.o. oddzia? w Krakowie ul. Armii Krajowej 18 30 -150 Krak?w NIP: 526-030-07-24, KRS 0000012941 Kapita? zak?adowy: 33.000.000 PLN -------------- next part -------------- An HTML attachment was scrubbed... URL: From carolin.latze at unifr.ch Thu Nov 26 14:31:22 2009 From: carolin.latze at unifr.ch (Carolin Latze) Date: Thu, 26 Nov 2009 14:31:22 +0100 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <87iqdj8t8w.fsf@mocca.josefsson.org> References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> <87iqdj8t8w.fsf@mocca.josefsson.org> Message-ID: <4B0E832A.3040305@unifr.ch> Hi Simon, yup, it is perfectly working now (I tested with 2.9.10)! Thanks a lot for fixing that!!! Cheers Carolin Simon Josefsson wrote: > Carolin, > > I just re-ran the x509signself self-test with gnutls 2.9.x and the hash > size passed to the function is now 20 bytes. I suppose GnuTLS adds the > right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the > callback should receive the entire PKCS#1 blob, to avoid having the > callback reconstruct it, instead of just the hash value, but maybe this > is sufficient to make things work for you? I'll release 2.9.9 in a few > minutes with some minor fixes, please test it. > > /Simon > > Carolin Latze writes: > > >> Hi Simon, >> >> I tried to use TLS 1.2 with and without sign callback, and I still see a >> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't >> it be max 35 then? Maybe we should check, whether I check the right >> variables: >> >> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure >> called dconcat. dconcat.size holds the hash size, right? and >> dconcat.data should hold the hash itself? dconcat.size has a value of 36 >> for me... >> >> If I use the sign callback, I print the value of hash->size (=36) and >> hash->data (cannot see the OID included in that value, so for me it >> looks like it is really not SHA-1 only). >> >> Maybe I check the wrong values? >> >> BTW: I used the latest Snapshot, 2.9.8 to test it. >> >> Sorry... :-/ >> Carolin >> >> Simon Josefsson wrote: >> >>> Carolin Latze writes: >>> >>> >>> >>>> Hi all, >>>> >>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>>> 36... that does not sound like a standard signature.. I would expect >>>> something like 20 for SHA1. Am I wrong? >>>> >>>> >>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >>> a look? It should have more solid TLS 1.2 support. >>> >>> Thanks, >>> Simon >>> >>> -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de P?rolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec From simon at josefsson.org Thu Nov 26 14:42:02 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 26 Nov 2009 14:42:02 +0100 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <4B0E832A.3040305@unifr.ch> (Carolin Latze's message of "Thu, 26 Nov 2009 14:31:22 +0100") References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> <87iqdj8t8w.fsf@mocca.josefsson.org> <4B0E832A.3040305@unifr.ch> Message-ID: <874oohjtcl.fsf@mocca.josefsson.org> That is great! Did you have to re-add the PKCS#1 ASN.1 OID before signing the data manually? Or was that not necessary? I'm wondering whether current API to only give the callback the hash value is OK, or whether it should also include the ASN.1 OID in the data passed to the callback. One problem with the current callback API is that there is no signalling of which hash function was used -- before in TLS this was not necessary since only MD5/SHA1 was used, and the default is still SHA-1, but it will be possible to sign using SHA-256 or similar too. The callback needs to be able to figure out that somehow. /Simon Carolin Latze writes: > Hi Simon, > > yup, it is perfectly working now (I tested with 2.9.10)! Thanks a lot > for fixing that!!! > > Cheers > Carolin > > Simon Josefsson wrote: >> Carolin, >> >> I just re-ran the x509signself self-test with gnutls 2.9.x and the hash >> size passed to the function is now 20 bytes. I suppose GnuTLS adds the >> right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the >> callback should receive the entire PKCS#1 blob, to avoid having the >> callback reconstruct it, instead of just the hash value, but maybe this >> is sufficient to make things work for you? I'll release 2.9.9 in a few >> minutes with some minor fixes, please test it. >> >> /Simon >> >> Carolin Latze writes: >> >> >>> Hi Simon, >>> >>> I tried to use TLS 1.2 with and without sign callback, and I still see a >>> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't >>> it be max 35 then? Maybe we should check, whether I check the right >>> variables: >>> >>> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure >>> called dconcat. dconcat.size holds the hash size, right? and >>> dconcat.data should hold the hash itself? dconcat.size has a value of 36 >>> for me... >>> >>> If I use the sign callback, I print the value of hash->size (=36) and >>> hash->data (cannot see the OID included in that value, so for me it >>> looks like it is really not SHA-1 only). >>> >>> Maybe I check the wrong values? >>> >>> BTW: I used the latest Snapshot, 2.9.8 to test it. >>> >>> Sorry... :-/ >>> Carolin >>> >>> Simon Josefsson wrote: >>> >>>> Carolin Latze writes: >>>> >>>> >>>> >>>>> Hi all, >>>>> >>>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>>>> 36... that does not sound like a standard signature.. I would expect >>>>> something like 20 for SHA1. Am I wrong? >>>>> >>>>> >>>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >>>> a look? It should have more solid TLS 1.2 support. >>>> >>>> Thanks, >>>> Simon >>>> >>>> From simon at josefsson.org Thu Nov 26 15:18:40 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 26 Nov 2009 15:18:40 +0100 Subject: Problems handling X.509 certificates In-Reply-To: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> (lfinsto@gwdg.de's message of "Wed, 25 Nov 2009 09:38:44 +0100 (CET)") References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> Message-ID: <87r5rlfjy7.fsf@mocca.josefsson.org> lfinsto at gwdg.de writes: > Hello, > > I need to use X.509 certificates for authentication/authorization in an > application and I've been working through the examples in the GNUTLS > manual. > > I'm new to GNUTLS (and network programming), so please excuse me if my > questions are naive. > > I've been using and modifying the programs > "7.3.2 Simple Client Example with X.509 Certificate Support" > and > "7.4.2 Echo Server with X.509 Authentication II". > > I've been trying to use the function `verify_certificate_chain' (defined > in `ex-verify.c') instead of `verify_certificate' (defined in > `ex-rfc2818.c'), but I can't seem to get it to work. > > I have two certificates that I want the client to send to the server. In > the client, I call `gnutls_certificate_set_x509_key_file' twice, once for > each certificate/key pair. However, in the server, > `gnutls_certificate_get_peers' sets the `*LIST_SIZE' to 1, i.e., it only > finds one certificate. > > I've tried various things to get it to work, but with no success. I must > be overlooking something, but I don't know what it could be. The TLS protocol only allow clients to send one X.509 certificate to the server. I suspect that if you need to send two client certificates, something is wrong with your architecture. /Simon From carolin.latze at unifr.ch Thu Nov 26 15:21:21 2009 From: carolin.latze at unifr.ch (Carolin Latze) Date: Thu, 26 Nov 2009 15:21:21 +0100 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <874oohjtcl.fsf@mocca.josefsson.org> References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> <87iqdj8t8w.fsf@mocca.josefsson.org> <4B0E832A.3040305@unifr.ch> <874oohjtcl.fsf@mocca.josefsson.org> Message-ID: <4B0E8EE1.40901@unifr.ch> Hi Simon, I didn't go that yet (I do not really have time to go on developing my projekt at the moment :-( ), but for me, the hash excluding the OID should be fine. I am not sure that is the case for every possible application using the callback. Maybe it is better to pass the OID too... It is easy to cut it of if it is not needed for further processing. Carolin Simon Josefsson wrote: > That is great! > > Did you have to re-add the PKCS#1 ASN.1 OID before signing the data > manually? Or was that not necessary? I'm wondering whether current API > to only give the callback the hash value is OK, or whether it should > also include the ASN.1 OID in the data passed to the callback. One > problem with the current callback API is that there is no signalling of > which hash function was used -- before in TLS this was not necessary > since only MD5/SHA1 was used, and the default is still SHA-1, but it > will be possible to sign using SHA-256 or similar too. The callback > needs to be able to figure out that somehow. > > /Simon > > Carolin Latze writes: > > >> Hi Simon, >> >> yup, it is perfectly working now (I tested with 2.9.10)! Thanks a lot >> for fixing that!!! >> >> Cheers >> Carolin >> >> Simon Josefsson wrote: >> >>> Carolin, >>> >>> I just re-ran the x509signself self-test with gnutls 2.9.x and the hash >>> size passed to the function is now 20 bytes. I suppose GnuTLS adds the >>> right PKCS#1 ASN.1 OID internally. It occurs to me that perhaps the >>> callback should receive the entire PKCS#1 blob, to avoid having the >>> callback reconstruct it, instead of just the hash value, but maybe this >>> is sufficient to make things work for you? I'll release 2.9.9 in a few >>> minutes with some minor fixes, please test it. >>> >>> /Simon >>> >>> Carolin Latze writes: >>> >>> >>> >>>> Hi Simon, >>>> >>>> I tried to use TLS 1.2 with and without sign callback, and I still see a >>>> signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't >>>> it be max 35 then? Maybe we should check, whether I check the right >>>> variables: >>>> >>>> In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure >>>> called dconcat. dconcat.size holds the hash size, right? and >>>> dconcat.data should hold the hash itself? dconcat.size has a value of 36 >>>> for me... >>>> >>>> If I use the sign callback, I print the value of hash->size (=36) and >>>> hash->data (cannot see the OID included in that value, so for me it >>>> looks like it is really not SHA-1 only). >>>> >>>> Maybe I check the wrong values? >>>> >>>> BTW: I used the latest Snapshot, 2.9.8 to test it. >>>> >>>> Sorry... :-/ >>>> Carolin >>>> >>>> Simon Josefsson wrote: >>>> >>>> >>>>> Carolin Latze writes: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>>>>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>>>>> 36... that does not sound like a standard signature.. I would expect >>>>>> something like 20 for SHA1. Am I wrong? >>>>>> >>>>>> >>>>>> >>>>> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >>>>> a look? It should have more solid TLS 1.2 support. >>>>> >>>>> Thanks, >>>>> Simon >>>>> >>>>> >>>>> From dkg at fifthhorseman.net Thu Nov 26 16:14:06 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 26 Nov 2009 10:14:06 -0500 Subject: Problems handling X.509 certificates In-Reply-To: <87r5rlfjy7.fsf@mocca.josefsson.org> References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> Message-ID: <4B0E9B3E.9040800@fifthhorseman.net> On 11/26/2009 09:18 AM, Simon Josefsson wrote: > The TLS protocol only allow clients to send one X.509 certificate to the > server. I suspect that if you need to send two client certificates, > something is wrong with your architecture. Laurence may be confused about this, and trying to send two end-entity certificates, in which case Simon's remarks here are correct. But a gnutls client may also offer intermediate certificate authority certificates (to bridge the gap from the server's announced root CAs to the client's end-entity certificate). In that case, the spec certainly allows the client to inject multiple certificates in the certificate_list structure, with the (maybe not-so-clear) intention of giving the server a chained trust path to the client's own certificate: http://tools.ietf.org/html/rfc5246#section-7.4.2 Laurence, if this is what you're trying to do, i don't think you want to call gnutls_certificate_set_x509_key_file twice. What you want to do is to put the ordered certificates (end-entity cert, followed by successive CA certs) in file A, and then the private key in a file B (only the end-entity's private key -- there's no need to have the private key for any intermediate CA). then call gnutls_certificate_set_x509_key_file once, pointing to A and B. hope this helps clear up confusion. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Fri Nov 27 09:59:35 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 27 Nov 2009 09:59:35 +0100 Subject: Problems handling X.509 certificates In-Reply-To: <4B0E9B3E.9040800@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 26 Nov 2009 10:14:06 -0500") References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> <4B0E9B3E.9040800@fifthhorseman.net> Message-ID: <87fx809wco.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On 11/26/2009 09:18 AM, Simon Josefsson wrote: >> The TLS protocol only allow clients to send one X.509 certificate to the >> server. I suspect that if you need to send two client certificates, >> something is wrong with your architecture. > > Laurence may be confused about this, and trying to send two end-entity > certificates, in which case Simon's remarks here are correct. > > But a gnutls client may also offer intermediate certificate authority > certificates (to bridge the gap from the server's announced root CAs to > the client's end-entity certificate). > > In that case, the spec certainly allows the client to inject multiple > certificates in the certificate_list structure, with the (maybe > not-so-clear) intention of giving the server a chained trust path to the > client's own certificate: > > http://tools.ietf.org/html/rfc5246#section-7.4.2 > > Laurence, if this is what you're trying to do, i don't think you want to > call gnutls_certificate_set_x509_key_file twice. What you want to do is > to put the ordered certificates (end-entity cert, followed by successive > CA certs) in file A, and then the private key in a file B (only the > end-entity's private key -- there's no need to have the private key for > any intermediate CA). then call gnutls_certificate_set_x509_key_file > once, pointing to A and B. > > hope this helps clear up confusion. Thank you, I hope that helps in case Laurence wanted to provide two certs from the same chain to the server. /Simon From lfinsto at gwdg.de Mon Nov 30 10:13:30 2009 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Mon, 30 Nov 2009 10:13:30 +0100 (CET) Subject: Problems handling X.509 certificates In-Reply-To: <4B0E9B3E.9040800@fifthhorseman.net> References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> <4B0E9B3E.9040800@fifthhorseman.net> Message-ID: <38103.134.76.5.25.1259572410.squirrel@mailbox.gwdg.de> "Daniel Kahn Gillmor" wrote: Date: Thu, November 26, 2009 4:14 pm Thank you both for your answers. It's not really necessary for me to send more than one certificate. However, it is necessary for the client to be able to send proxies. Does this mean that the certificates which are used to create the proxies must be "registered" as trusted in the server? > On 11/26/2009 09:18 AM, Simon Josefsson wrote: >> The TLS protocol only allow clients to send one X.509 certificate to the >> server. I suspect that if you need to send two client certificates, something is wrong with your architecture. > One reason I wanted to try verifying a certificate chain using the library functions was because of a problem I'm having with the actual certificates I need to use. Verification works in the client and server programs when I use certificates generated by `certtool', but it fails when I use my certificate from the DFN (Deutsches Forschungsnetz (http://www.pki.dfn.de/index.php?id=gridroot) and its root certificate. However, it does work to verify them using `certtool -e'. Does anyone have an idea what the reason for this could be? > Laurence, if this is what you're trying to do, i don't think you want to call gnutls_certificate_set_x509_key_file twice. What you want to do is to put the ordered certificates (end-entity cert, followed by successive CA certs) in file A, and then the private key in a file B (only the end-entity's private key -- there's no need to have the private key for any intermediate CA). then call gnutls_certificate_set_x509_key_file once, pointing to A and B. Thank you. It wasn't clear to me that certificates could be concatenated in a single file. > hope this helps clear up confusion. Thanks again for your help. Laurence -------------- next part -------------- A non-text attachment was scrubbed... Name: DFN-VereinPCAGrid-G01.pem Type: application/x-x509-ca-cert Size: 1615 bytes Desc: not available URL: From lfinsto at gwdg.de Mon Nov 30 11:11:49 2009 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Mon, 30 Nov 2009 11:11:49 +0100 (CET) Subject: Problems handling X.509 certificates In-Reply-To: <38103.134.76.5.25.1259572410.squirrel@mailbox.gwdg.de> References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> <4B0E9B3E.9040800@fifthhorseman.net> <38103.134.76.5.25.1259572410.squirrel@mailbox.gwdg.de> Message-ID: <40426.134.76.5.25.1259575909.squirrel@mailbox.gwdg.de> Laurence Finston wrote: > One reason I wanted to try verifying a certificate chain using the library > functions was because of a problem I'm having with the actual certificates > I need to use. Verification works in the client and server programs when > I use certificates generated by `certtool', but it fails when I use my > certificate from the DFN (Deutsches Forschungsnetz > (http://www.pki.dfn.de/index.php?id=gridroot) and its root certificate. > However, it does work to verify them using `certtool -e'. Does anyone > have an idea what the reason for this could be? Never mind, I found the problem: I had extracted the private key using `openssl pkcs12 -nocerts -in usercred.p12 -out userkey.pem' so that key was encrypted. It worked after I extracted an unencrypted key using the `-nodes' option. Thanks, Laurence Laurence Finston Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Am Fassberg 11 37077 Goettingen Telefon: +49 551 201-1882 E-Mail: lfinsto at gwdg.de From lfinsto at gwdg.de Mon Nov 30 16:52:49 2009 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Mon, 30 Nov 2009 16:52:49 +0100 (CET) Subject: Problems handling X.509 certificates In-Reply-To: <4B0E9B3E.9040800@fifthhorseman.net> References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> <4B0E9B3E.9040800@fifthhorseman.net> Message-ID: <37863.134.76.5.25.1259596369.squirrel@mailbox.gwdg.de> Daniel Kahn Gillmor wrote: > On 11/26/2009 09:18 AM, Simon Josefsson wrote: > [... What you want to do is > to put the ordered certificates (end-entity cert, followed by successive CA certs) in file A, and then the private key in a file B (only the end-entity's private key -- there's no need to have the private key for any intermediate CA). then call gnutls_certificate_set_x509_key_file once, pointing to A and B. With your help and Simon's, I have now managed to get verification to work this way using a proxy, the certificate with which I signed the proxy, and the CA's certificate. There are a couple of points I thought I'd mention, in case Simon would like to account for them when revising the documentation: 1. In the file `ex-verify.c', the following variables are global: gnutls_x509_crl_t *crl_list; int crl_list_size; gnutls_x509_crt_t *ca_list; int ca_list_size; They are passed to `verify_last_cert' by `verify_certificate_chain'. It was not clear to me where the values they contained were supposed to come from. I solved the problem by calling the following code in `main' (from Example 7.4.2 Echo Server with X.509 Authentication II): ca_list = malloc(sizeof(gnutls_x509_crt_t)); gnutls_certificate_get_x509_cas(cert_cred, &ca_list, &ca_list_size); ... free(ca_list); /* After we're done with verification */ ca_list = 0; (The variables had to be declared `extern' in the file that contains `main'.) Is this what I ought to be doing? 2. `gnutls_x509_crt_verify' sets the 'GNUTLS_CERT_INVALID' bit in its `*FLAGS' argument when the signer isn't a CA, which is the case when the certificate being tested is the proxy signed by my certificate. This isn't a serious problem, but it didn't work when I tried to use my non-CA certificate as a trusted CA file. I haven't tested this thoroughly, however. I would like for the clients to be able to just send a proxy, though they will have had to have sent a trusted certificate previously. It would be easier if I could use the latter as a trusted CA certificate, but I can work around this if this isn't possible. Thanks again for your help. Laurence Laurence Finston Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Am Fassberg 11 37077 Goettingen Telefon: +49 551 201-1882 E-Mail: lfinsto at gwdg.de From simon at josefsson.org Mon Nov 30 19:03:07 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 30 Nov 2009 19:03:07 +0100 Subject: Problems handling X.509 certificates In-Reply-To: <38103.134.76.5.25.1259572410.squirrel@mailbox.gwdg.de> (lfinsto@gwdg.de's message of "Mon, 30 Nov 2009 10:13:30 +0100 (CET)") References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> <4B0E9B3E.9040800@fifthhorseman.net> <38103.134.76.5.25.1259572410.squirrel@mailbox.gwdg.de> Message-ID: <87ws17nb50.fsf@mocca.josefsson.org> lfinsto at gwdg.de writes: > Thank you both for your answers. It's not really necessary for me to send > more than one certificate. However, it is necessary for the client to be > able to send proxies. You mean proxy certs (RFC 3820)? Then that shouldn't be a problem -- they are part of the client cert chain that traces back to the CA. I believe this is how you are supposed to use proxy certs. > Does this mean that the certificates which are used to create the > proxies must be "registered" as trusted in the server? GnuTLS will need to be teached about how to verify cert chains involving proxy certs. I suspect it will refuse validation now, since the end entity cert signs the proxy certs but doesn't have CA=false. Unless someone has added support for validating proxy certs to GnuTLS when I didn't look... > One reason I wanted to try verifying a certificate chain using the library > functions was because of a problem I'm having with the actual certificates > I need to use. Verification works in the client and server programs when > I use certificates generated by `certtool', but it fails when I use my > certificate from the DFN (Deutsches Forschungsnetz > (http://www.pki.dfn.de/index.php?id=gridroot) and its root certificate. > However, it does work to verify them using `certtool -e'. Does anyone > have an idea what the reason for this could be? Not sure -- we'd need to see the entire certificate chain to be able to debug it. >> Laurence, if this is what you're trying to do, i don't think you want to > call gnutls_certificate_set_x509_key_file twice. What you want to do is > to put the ordered certificates (end-entity cert, followed by successive > CA certs) in file A, and then the private key in a file B (only the > end-entity's private key -- there's no need to have the private key for > any intermediate CA). then call gnutls_certificate_set_x509_key_file > once, pointing to A and B. > > Thank you. It wasn't clear to me that certificates could be concatenated > in a single file. Right, I have improved the documentation: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=2ae95bfe200b6a39bd3908bf5b74f84c643bd5e3 Thanks, /Simon From dkg at fifthhorseman.net Mon Nov 30 19:50:47 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 30 Nov 2009 13:50:47 -0500 Subject: Problems handling X.509 certificates In-Reply-To: <37863.134.76.5.25.1259596369.squirrel@mailbox.gwdg.de> References: <39146.134.76.5.25.1259138324.squirrel@mailbox.gwdg.de> <87r5rlfjy7.fsf@mocca.josefsson.org> <4B0E9B3E.9040800@fifthhorseman.net> <37863.134.76.5.25.1259596369.squirrel@mailbox.gwdg.de> Message-ID: <4B141407.5020109@fifthhorseman.net> On 11/30/2009 10:52 AM, lfinsto at gwdg.de wrote: > 1. In the file `ex-verify.c', the following variables are global: > > gnutls_x509_crl_t *crl_list; > int crl_list_size; > > gnutls_x509_crt_t *ca_list; > int ca_list_size; > > They are passed to `verify_last_cert' by `verify_certificate_chain'. It > was not clear to me where the values they contained were supposed to come > from. > > I solved the problem by calling the following code in `main' (from Example > 7.4.2 Echo Server with X.509 Authentication II): > > ca_list = malloc(sizeof(gnutls_x509_crt_t)); > gnutls_certificate_get_x509_cas(cert_cred, &ca_list, &ca_list_size); According to the docs here: http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_005fcertificate_005fget_005fx509_005fcas It looks like you should *not* be allocating them yourself (and you should not be freeing them either). In particular, these calls return pointers to elements internal to the gnutls_certificate_credentials_t object, and should probably be considered valid only as long as that object remains unaltered. Check out line 127 of lib/gnutls_cert.c to understand how they get set by this function. > 2. `gnutls_x509_crt_verify' sets the 'GNUTLS_CERT_INVALID' bit in its > `*FLAGS' argument when the signer isn't a CA, which is the case when the > certificate being tested is the proxy signed by my certificate. This > isn't a serious problem, but it didn't work when I tried to use my non-CA > certificate as a trusted CA file. I haven't tested this thoroughly, > however. I would like for the clients to be able to just send a proxy, > though they will have had to have sent a trusted certificate previously. > It would be easier if I could use the latter as a trusted CA certificate, > but I can work around this if this isn't possible. Simon's response just now suggests that GnuTLS doesn't know how to interact with proxy certificates. They're specified in RFC 3820, if anyone wants to take a crack at implementing support for them. http://tools.ietf.org/html/rfc3820 That would be a Good Thing, i think, if done properly. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: