From ueno at unixuser.org Tue Sep 1 01:23:19 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 01 Sep 2009 08:23:19 +0900 Subject: [PATCH] add SHA-2 ciphersuites In-Reply-To: <87r5uscdkt.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 31 Aug 2009 15:33:54 +0200") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87r5uscdkt.fsf@mocca.josefsson.org> Message-ID: <87prabmuu0.fsf_-_@broken.deisui.org> >>>>> In <87r5uscdkt.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > Confirmed, also working against Thanks for testing (and the #include fix). > Before we enable TLS 1.2 by default, I think what is missing are: > * Add SHA-2 ciphersuites Here it is: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-SHA-2-cipher-suites.patch Type: text/x-diff Size: 3943 bytes Desc: not available URL: -------------- next part -------------- As a next step, I will look into the server-side TLS 1.2 support. Regards, -- Daiki Ueno From ueno at unixuser.org Tue Sep 1 01:34:10 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 01 Sep 2009 08:34:10 +0900 Subject: [PATCH] session ticket support In-Reply-To: <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> (Daiki Ueno's message of "Wed, 19 Aug 2009 16:53:07 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> <878whgdcdw.fsf@mocca.josefsson.org> <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> Message-ID: <87k50jmubx.fsf@broken.deisui.org> >>>>> In <6c226b79-bdbf-4277-91c0-ead7ca6e67f2 at broken.deisui.org> >>>>> Daiki Ueno wrote: > > Do you have an updated patch, or should I use the last one you > > posted? > Yes, please use the attached one. The attached is a minor update: print the name of NewSessionTicket handshake message instead of "Unknown Handshake packet". Also, I noticed that Mike's test server sent a 1024-byte ticket, and when sending it back MAX_EXT_DATA_LENGTH exceeded (which is currently 1024). I'm not sure this is a normal case, but how about increasing the number? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Print-NewSessionTicket-handshake.patch Type: text/x-diff Size: 722 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From simon at josefsson.org Tue Sep 1 06:56:10 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Sep 2009 06:56:10 +0200 Subject: [PATCH] session ticket support In-Reply-To: <87k50jmubx.fsf@broken.deisui.org> (Daiki Ueno's message of "Tue, 01 Sep 2009 08:34:10 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> <878whgdcdw.fsf@mocca.josefsson.org> <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> <87k50jmubx.fsf@broken.deisui.org> Message-ID: <87iqg39sb9.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <6c226b79-bdbf-4277-91c0-ead7ca6e67f2 at broken.deisui.org> >>>>>> Daiki Ueno wrote: >> > Do you have an updated patch, or should I use the last one you >> > posted? > >> Yes, please use the attached one. > > The attached is a minor update: print the name of NewSessionTicket > handshake message instead of "Unknown Handshake packet". Pushed. > Also, I noticed that Mike's test server sent a 1024-byte ticket, and > when sending it back MAX_EXT_DATA_LENGTH exceeded (which is currently > 1024). I'm not sure this is a normal case, but how about increasing the > number? Having a hard-coded fixed size here is the source of the problem. Fixing it doesn't look too complicated, would you like to do work on that? Thanks, /Simon From simon at josefsson.org Tue Sep 1 07:09:49 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Sep 2009 07:09:49 +0200 Subject: [PATCH] add SHA-2 ciphersuites In-Reply-To: <87prabmuu0.fsf_-_@broken.deisui.org> (Daiki Ueno's message of "Tue, 01 Sep 2009 08:23:19 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87r5uscdkt.fsf@mocca.josefsson.org> <87prabmuu0.fsf_-_@broken.deisui.org> Message-ID: <87eiqr9roi.fsf@mocca.josefsson.org> Daiki Ueno writes: >> Before we enable TLS 1.2 by default, I think what is missing are: > >> * Add SHA-2 ciphersuites > > Here it is: Short and simple, pushed. I also changed gnutls_priority.c so that SHA-256 is preferred over SHA-1 by default (only effective when TLS 1.2 is enabled, which it currently isn't until we've checked that server-side works). Thanks, /Simon From simon at josefsson.org Tue Sep 1 15:16:27 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Sep 2009 15:16:27 +0200 Subject: New team member Message-ID: <877hwi3ivo.fsf@mocca.josefsson.org> I just added Daiki Ueno to the savannah project member page for GnuTLS, so everyone please welcome Ueno-san as new GnuTLS team member! Of course, in case someone missed it (likely since it was never announced), everyone please also welcome Daniel Kahn Gillmor and Ludovic Court?s as old GnuTLS team members. :-) /Simon From nmav at gnutls.org Tue Sep 1 18:44:53 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 01 Sep 2009 19:44:53 +0300 Subject: New team member In-Reply-To: <877hwi3ivo.fsf@mocca.josefsson.org> References: <877hwi3ivo.fsf@mocca.josefsson.org> Message-ID: <4A9D4F85.2080009@gnutls.org> Simon Josefsson wrote: > I just added Daiki Ueno to the savannah project member page for GnuTLS, > so everyone please welcome Ueno-san as new GnuTLS team member! > > Of course, in case someone missed it (likely since it was never > announced), everyone please also welcome Daniel Kahn Gillmor and Ludovic > Court?s as old GnuTLS team members. :-) A salutation from me for the new members! All best, Nikos From simon at yubico.com Thu Sep 3 12:03:50 2009 From: simon at yubico.com (Simon Josefsson) Date: Thu, 03 Sep 2009 12:03:50 +0200 Subject: GnuTLS 2.9.4 Message-ID: <87vdk0gxa1.fsf@mocca.josefsson.org> The GnuTLS 2.9.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources (6.0MB): http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.4.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.4.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.4.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.4.tar.bz2.sig Windows build: http://josefsson.org/gnutls4win/gnutls-2.9.4.exe http://josefsson.org/gnutls4win/gnutls-2.9.4.exe.sig http://josefsson.org/gnutls4win/gnutls-2.9.4.zip http://josefsson.org/gnutls4win/gnutls-2.9.4.zip.sig http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.4-1_all.deb 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. /Simon * Version 2.9.4 (released 2009-09-03) ** libgnutls: Client-side TLS 1.2 and SHA-256 ciphersuites now works. The new supported ciphersuites are AES-128/256 in CBC mode with ANON-DH/RSA/DHE-DSS/DHE-RSA. Contributed by Daiki Ueno. Further, SHA-256 is now the preferred default MAC (however it is only used with TLS 1.2). ** libgnutls: Make OpenPGP hostname checking work again. The patch to resolve the X.509 CN/SAN issue accidentally broken OpenPGP hostname comparison. ** libgnutls: When printing X.509 certificates, handle XMPP SANs better. Reported by Howard Chu in . ** Fix use of deprecated types internally. Use of deprecated types in GnuTLS from now on will lead to a compile error, to prevent this from happening again. ** API and ABI modifications: No changes since last version. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From tgc at jupiterrise.com Thu Sep 3 22:36:13 2009 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Thu, 3 Sep 2009 22:36:13 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <874orr527c.fsf@mocca.josefsson.org> References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> <20090821155546.GA14150@ares.tgcnet> <87skfghqgl.fsf@mocca.josefsson.org> <874orwhohc.fsf@mocca.josefsson.org> <20090826162343.GA21539@ares.tgcnet> <874orr527c.fsf@mocca.josefsson.org> Message-ID: <20090903203613.GA25645@ares.tgcnet> On Fri, Aug 28, 2009 at 06:32:23PM +0200, Simon Josefsson wrote: > Ah, lib/m4/size_max.m4 is generated by gettext. I have added an ugly > workaround to cfg.mk, please try the most recent snapshot. > Just to confirm that this change indeed took care of it: http://autobuild.josefsson.org/gnutls/log-200909030118481064000.txt Thanks. -tgc From tgc at jupiterrise.com Thu Sep 3 22:46:23 2009 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Thu, 3 Sep 2009 22:46:23 +0200 Subject: Shell portability issue in tests/key-id/key-id Message-ID: <20090903204623.GB25645@ares.tgcnet> The tests/key-id/key-id script uses 'if !' which is not understood by /bin/sh and results in an error on IRIX and Solaris. $ ./key-id !: Not found -tgc From arfrever.fta at gmail.com Thu Sep 3 23:05:20 2009 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 3 Sep 2009 23:05:20 +0200 Subject: Shell portability issue in tests/key-id/key-id In-Reply-To: <20090903204623.GB25645@ares.tgcnet> References: <20090903204623.GB25645@ares.tgcnet> Message-ID: <200909032305.24139.Arfrever.FTA@gmail.com> 2009-09-03 22:46:23 Tom G. Christensen napisa?(a): > The tests/key-id/key-id script uses 'if !' which is not understood by > /bin/sh and results in an error on IRIX and Solaris. > > $ ./key-id > !: Not found ! is documented by POSIX: http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_02_01 -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bradh at frogmouth.net Fri Sep 4 12:04:42 2009 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 4 Sep 2009 20:04:42 +1000 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <87eirpug7t.fsf@mocca.josefsson.org> References: <200908052214.44197.bradh@frogmouth.net> <87eirpug7t.fsf@mocca.josefsson.org> Message-ID: <200909042004.43049.bradh@frogmouth.net> On Friday 07 August 2009 01:14:46 Simon Josefsson wrote: > Brad Hards writes: > > This patch (which I submit as a request for review / feedback) implements > > support for getting issuer altname. It is based on the equivalent subject > > altname code. > > It looks fine to me. I wonder why that have been missing... The > self-test x509_altname was missing from your patch though? > > > [I'll submit it again for incorporation after my papers get worked > > through] I got the confirmation on my papers today. I've updated the patch to include the self-test. It is otherwise unchanged. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: x509_issuer_altname-2009-09-04.patch Type: text/x-patch Size: 15101 bytes Desc: not available URL: From simon at josefsson.org Mon Sep 7 17:59:09 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Sep 2009 17:59:09 +0200 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <200909042004.43049.bradh@frogmouth.net> (Brad Hards's message of "Fri, 4 Sep 2009 20:04:42 +1000") References: <200908052214.44197.bradh@frogmouth.net> <87eirpug7t.fsf@mocca.josefsson.org> <200909042004.43049.bradh@frogmouth.net> Message-ID: <877hwavj8y.fsf@mocca.josefsson.org> Brad Hards writes: > I've updated the patch to include the self-test. It is otherwise unchanged. Thank you! It looks fine except one nit: The code duplication between print_san and print_ian worries me, and the print_san code has been changed since you made the patch so they are not in sync with your patch. Could you instead generalize print_san into a print_an function that takes an additional parameter indicating whether it is printing a SAN or IAN? With that change, it is ready to go in. /Simon From simon at josefsson.org Mon Sep 7 18:03:59 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Sep 2009 18:03:59 +0200 Subject: Shell portability issue in tests/key-id/key-id In-Reply-To: <200909032305.24139.Arfrever.FTA@gmail.com> (Arfrever Frehtes Taifersar Arahesis's message of "Thu, 3 Sep 2009 23:05:20 +0200") References: <20090903204623.GB25645@ares.tgcnet> <200909032305.24139.Arfrever.FTA@gmail.com> Message-ID: <873a6yvj0w.fsf@mocca.josefsson.org> Arfrever Frehtes Taifersar Arahesis writes: > 2009-09-03 22:46:23 Tom G. Christensen napisa?(a): >> The tests/key-id/key-id script uses 'if !' which is not understood by >> /bin/sh and results in an error on IRIX and Solaris. >> >> $ ./key-id >> !: Not found > > ! is documented by POSIX: > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_02_01 Alas it is not portable, see: http://www.gnu.org/software/autoconf/manual/html_node/Limitations-of-Builtins.html I have rewritten the code, thanks for the report Tom. /Simon From simon at josefsson.org Tue Sep 8 09:53:31 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Sep 2009 09:53:31 +0200 Subject: 2.8.4 release candidate Message-ID: <87my55j2is.fsf@mocca.josefsson.org> All, I'll release a new stable release 2.8.4 soon to fix OpenPGP name checking. Unless I hear anything, it will be identical to http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090908.tar.bz2 so please test that file as if it were the next stable release! If you want to check the patches that went in since 2.8.3, see: http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x /Simon From bradh at frogmouth.net Tue Sep 8 12:30:03 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 8 Sep 2009 20:30:03 +1000 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <877hwavj8y.fsf@mocca.josefsson.org> References: <200908052214.44197.bradh@frogmouth.net> <200909042004.43049.bradh@frogmouth.net> <877hwavj8y.fsf@mocca.josefsson.org> Message-ID: <200909082030.04052.bradh@frogmouth.net> On Tuesday 08 September 2009 01:59:09 Simon Josefsson wrote: > Brad Hards writes: > > I've updated the patch to include the self-test. It is otherwise > > unchanged. > > Thank you! It looks fine except one nit: > > The code duplication between print_san and print_ian worries me, and the > print_san code has been changed since you made the patch so they are not > in sync with your patch. Could you instead generalize print_san into a > print_an function that takes an additional parameter indicating whether > it is printing a SAN or IAN? > > With that change, it is ready to go in. It isn't an easy refactoring, but I'm working on it. During the review, I note that the altname is sanitised if the type is GNUTLS_SAN_DNSNAME, GNUTLS_SAN_RFC822NAME or GNUTLS_SAN_URI. Should we also sanitise GNUTLS_SAN_DN ? Brad From simon at josefsson.org Tue Sep 8 12:49:31 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Sep 2009 12:49:31 +0200 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <200909082030.04052.bradh@frogmouth.net> (Brad Hards's message of "Tue, 8 Sep 2009 20:30:03 +1000") References: <200908052214.44197.bradh@frogmouth.net> <200909042004.43049.bradh@frogmouth.net> <877hwavj8y.fsf@mocca.josefsson.org> <200909082030.04052.bradh@frogmouth.net> Message-ID: <87ws49g18k.fsf@mocca.josefsson.org> Brad Hards writes: > On Tuesday 08 September 2009 01:59:09 Simon Josefsson wrote: >> Brad Hards writes: >> > I've updated the patch to include the self-test. It is otherwise >> > unchanged. >> >> Thank you! It looks fine except one nit: >> >> The code duplication between print_san and print_ian worries me, and the >> print_san code has been changed since you made the patch so they are not >> in sync with your patch. Could you instead generalize print_san into a >> print_an function that takes an additional parameter indicating whether >> it is printing a SAN or IAN? >> >> With that change, it is ready to go in. > It isn't an easy refactoring, but I'm working on it. Thanks -- a 'bool san' variable, and if-conditions for each gnutls function call to SAN/IAN functions should suffice. > During the review, I note that the altname is sanitised if the type is > GNUTLS_SAN_DNSNAME, GNUTLS_SAN_RFC822NAME or GNUTLS_SAN_URI. > > Should we also sanitise GNUTLS_SAN_DN ? DN's should already be sanitized (they should be in LDAP encoded form), although I don't have any test certificates for this. Anyway, it is best to not touch anything else in your patch, to avoid mixing separate issues in the same patch. /Simon From bradh at frogmouth.net Wed Sep 9 13:57:06 2009 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 9 Sep 2009 21:57:06 +1000 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <87ws49g18k.fsf@mocca.josefsson.org> References: <200908052214.44197.bradh@frogmouth.net> <200909082030.04052.bradh@frogmouth.net> <87ws49g18k.fsf@mocca.josefsson.org> Message-ID: <200909092157.06267.bradh@frogmouth.net> On Tuesday 08 September 2009 20:49:31 Simon Josefsson wrote: > Brad Hards writes: > > It isn't an easy refactoring, but I'm working on it. > > Thanks -- a 'bool san' variable, and if-conditions for each gnutls > function call to SAN/IAN functions should suffice. OK, I was thinking about a more complex cleanup. In the end, I changed the way the type argument works (so we don't basically have two bools to drive the three cases). See attached. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: x509_issuer_altname-2009-09-09.patch Type: text/x-patch Size: 21859 bytes Desc: not available URL: From simon at josefsson.org Thu Sep 10 08:28:50 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 10 Sep 2009 08:28:50 +0200 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <200909092157.06267.bradh@frogmouth.net> (Brad Hards's message of "Wed, 9 Sep 2009 21:57:06 +1000") References: <200908052214.44197.bradh@frogmouth.net> <200909082030.04052.bradh@frogmouth.net> <87ws49g18k.fsf@mocca.josefsson.org> <200909092157.06267.bradh@frogmouth.net> Message-ID: <87bplj9uu5.fsf@mocca.josefsson.org> Brad Hards writes: > On Tuesday 08 September 2009 20:49:31 Simon Josefsson wrote: >> Brad Hards writes: >> > It isn't an easy refactoring, but I'm working on it. >> >> Thanks -- a 'bool san' variable, and if-conditions for each gnutls >> function call to SAN/IAN functions should suffice. > OK, I was thinking about a more complex cleanup. In the end, I changed the way > the type argument works (so we don't basically have two bools to drive the > three cases). Thank you, that's better than my suggestion. Pushed, will release it next. /Simon From simon at josefsson.org Thu Sep 10 09:57:20 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 10 Sep 2009 09:57:20 +0200 Subject: GnuTLS 2.9.5 Message-ID: <87vdjr5j1b.fsf@mocca.josefsson.org> The GnuTLS 2.9.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources (6.0MB): http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.5.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.5.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.5.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.5.tar.bz2.sig Windows build: http://josefsson.org/gnutls4win/gnutls-2.9.5.exe http://josefsson.org/gnutls4win/gnutls-2.9.5.exe.sig http://josefsson.org/gnutls4win/gnutls-2.9.5.zip http://josefsson.org/gnutls4win/gnutls-2.9.5.zip.sig http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.5-1_all.deb 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. /Simon * Version 2.9.5 (released 2009-09-10) ** libgnutls: Add new functions to extract X.509 Issuer Alternative Names. The new functions are gnutls_x509_crt_get_issuer_alt_name2, gnutls_x509_crt_get_issuer_alt_name, and gnutls_x509_crt_get_issuer_alt_othername_oid. Contributed by Brad Hards . ** API and ABI modifications: gnutls_x509_crt_get_issuer_alt_name2: ADDED. gnutls_x509_crt_get_issuer_alt_name: ADDED. gnutls_x509_crt_get_issuer_alt_othername_oid: ADDED. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Thu Sep 10 21:57:06 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 10 Sep 2009 21:57:06 +0200 Subject: GNUTLS4WIN and RFC 4132 (CAMELLIA) In-Reply-To: <663025.87847.qm@web32403.mail.mud.yahoo.com> (ivan jr sy's message of "Thu, 10 Sep 2009 11:31:51 -0700 (PDT)") References: <663025.87847.qm@web32403.mail.mud.yahoo.com> Message-ID: <87my523759.fsf@mocca.josefsson.org> ivan jr sy writes: > Hi Simon, > > after unpacking > http://josefsson.org/gnutls4win/gnutls-2.9.5.zip > > gnutls-cli -l doest not show that it supports CAMELLIA ciphers > > can you provide a quick run through for me to have one.. from getting your sources so i can use it for another win32 apps.. > > also, do you have near plans adding CAMMELLIA (RFC 4132) by default? > > it seems it's default for firefox 3+ and so as other apps. > http://www.csg.is.titech.ac.jp/~yanagisawa/Sites/text/camellia-e.html Hi! For some reason, GnuTLS has defaulted to not build with Camellia support by default, but I just changed that in git so that future release on the v2.9.x branch (and eventually on the next v2.10 stable branch) will have it enabled by default. If you want to make this work with existing releases, you need to rebuild and give --enable-camellia as a ./configure parameter. /Simon From bradh at frogmouth.net Sun Sep 13 11:15:03 2009 From: bradh at frogmouth.net (Brad Hards) Date: Sun, 13 Sep 2009 19:15:03 +1000 Subject: [patch] add forgotten documentation bits for issuer altname Message-ID: <200909131915.04228.bradh@frogmouth.net> Hi, While poking around the documentation, I realised that I had forgotten part of the documentation - the "since" part that generates the "new in 2.10.0" index. Patch attached. I tested this by re-generating the documentation and making sure it appears in the html output. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: ian_since-2009-09-13.patch Type: text/x-patch Size: 1241 bytes Desc: not available URL: From simon at josefsson.org Mon Sep 14 15:53:18 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 14 Sep 2009 15:53:18 +0200 Subject: [patch] add forgotten documentation bits for issuer altname In-Reply-To: <200909131915.04228.bradh@frogmouth.net> (Brad Hards's message of "Sun, 13 Sep 2009 19:15:03 +1000") References: <200909131915.04228.bradh@frogmouth.net> Message-ID: <87fxap7hv5.fsf@mocca.josefsson.org> Brad Hards writes: > Hi, > > While poking around the documentation, I realised that I had forgotten > part of the documentation - the "since" part that generates the "new > in 2.10.0" index. > > Patch attached. I tested this by re-generating the documentation and > making sure it appears in the html output. Thanks, pushed. /Simon From simon at josefsson.org Fri Sep 18 11:26:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 18 Sep 2009 11:26:03 +0200 Subject: GnuTLS 2.8.4 Message-ID: <87ocp861uc.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.8.4. 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: Enable Camellia ciphers by default. ** libgnutls: Make OpenPGP hostname checking work again. The patch to resolve the X.509 CN/SAN issue accidentally broken OpenPGP hostname comparison. ** libgnutls: When printing X.509 certificates, handle XMPP SANs better. Reported by Howard Chu in . ** 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.4.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.4.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.4.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.4.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.4.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: 27bea240164b9287807543387682c7052f7318c2 gnutls-2.8.4.tar.bz2 01199002c127f3399a9c983e89c0a32de2983855cf20c10ffbe182a1 gnutls-2.8.4.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.4. 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.4.exe (15MB) http://josefsson.org/gnutls4win/gnutls-2.8.4.exe.sig The checksum values for SHA-1 and SHA-224 are: 0205a1ce535744e675a9d5f1087d03a671d785e8 gnutls-2.8.4.exe 84033d1d26140bf705758cb4cc813d0eb6ab59b059103c6980abf60a gnutls-2.8.4.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.8.4.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.8.4.zip.sig The checksum values for SHA-1 and SHA-224 are: 38aa360a5b4471abf66ef9f08e0cdb7374ed6957 gnutls-2.8.4.zip cf6e475623dc581a9f5b5a5deccbd764d56eddb7256c298b2d98c38b gnutls-2.8.4.zip A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.4-1_all.deb (4.8MB) The checksum values for SHA-1 and SHA-224 are: e8d222b86fe89a3819da73c8b0391e9512a9f140 mingw32-gnutls_2.8.4-1_all.deb 73fc1a233713539c454d277b1858f63fe62954c8a212ec964481c545 mingw32-gnutls_2.8.4-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: 419 bytes Desc: not available URL: From simon at josefsson.org Tue Sep 22 15:27:52 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 22 Sep 2009 15:27:52 +0200 Subject: GnuTLS 2.9.6 Message-ID: <87k4zrjehz.fsf@mocca.josefsson.org> The GnuTLS 2.9.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources (6.1MB): http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.6.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.6.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.6.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.6.tar.bz2.sig Windows build: http://josefsson.org/gnutls4win/gnutls-2.9.6.exe http://josefsson.org/gnutls4win/gnutls-2.9.6.exe.sig http://josefsson.org/gnutls4win/gnutls-2.9.6.zip http://josefsson.org/gnutls4win/gnutls-2.9.6.zip.sig http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.6-1_all.deb 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. /Simon * Version 2.9.6 (released 2009-09-22) ** libgnutls: Enable Camellia ciphers by default. ** API and ABI modifications: No changes since last version. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Tue Sep 22 19:29:18 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 22 Sep 2009 19:29:18 +0200 Subject: gnutls guile warnings Message-ID: <877hvqga6p.fsf@mocca.josefsson.org> Hi Ludo, building recent GnuTLS gives some warnings: make[4]: Entering directory `/home/jas/src/gnutls/guile/src' /bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -g -O2 -MT libguile_gnutls_v_1_la-core.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-core.Tpo -c -o libguile_gnutls_v_1_la-core.lo `test -f 'core.c' || echo './'`core.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../libextra/includes -I../.. -I. -Wno-strict-prototypes -I../../lib/gl -I../../lib/gl -g -O2 -MT libguile_gnutls_v_1_la-core.lo -MD -MP -MF .deps/libguile_gnutls_v_1_la-core.Tpo -c core.c -fPIC -DPIC -o .libs/libguile_gnutls_v_1_la-core.o In file included from enums.h:6, from core.c:27: ../../config.h:68:1: warning: "GNUTLS_COMPAT_H" redefined In file included from ../../lib/includes/gnutls/gnutls.h:48, from core.c:22: ../../lib/includes/gnutls/compat.h:4:1: warning: this is the location of the previous definition The cause seems simple: including "config.h" is not done as the first thing in these files, so gnutls/compat.h ends up being included before config.h. The solution is to make sure "config.h" is included first. However, I'm not sure how you would prefer to fix this, so would you mind taking a look at this? I can fix this later if you don't have time, but then I'll do it my way which may not be what you want. :-) /Simon From daniel at cacert.org Wed Sep 23 03:01:11 2009 From: daniel at cacert.org (Daniel Black) Date: Wed, 23 Sep 2009 11:01:11 +1000 Subject: gnutls_server_name_set and IDN Message-ID: Should gnutls_server_name_set convert the domain name to ACE as per RFC4366 3.1 where it talks about IDNA (RFC 3490)? Using libidn function call can make this occur using idna_to_ascii_8z can make this happen though this is adding dependency. From simon at josefsson.org Wed Sep 23 10:57:28 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 23 Sep 2009 10:57:28 +0200 Subject: gnutls_server_name_set and IDN In-Reply-To: (Daniel Black's message of "Wed, 23 Sep 2009 11:01:11 +1000") References: Message-ID: <87y6o69gxz.fsf@mocca.josefsson.org> Daniel Black writes: > Should gnutls_server_name_set convert the domain name to ACE as per > RFC4366 3.1 where it talks about IDNA (RFC 3490)? > > Using libidn function call can make this occur using idna_to_ascii_8z can > make this happen though this is adding dependency. That text has been dropped from RFC 4366bis: http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3 I think the text in RFC 4366 is confusing and difficult to implement interoperably. What the new text means is that GnuTLS applications are responsible for converting any internationalized domain name into ACE before passing the string on to GnuTLS. Let me know what you think of this, there is still time to bring this up in the IETF. /Simon From ludo at gnu.org Wed Sep 23 11:11:37 2009 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 23 Sep 2009 11:11:37 +0200 Subject: gnutls guile warnings In-Reply-To: <877hvqga6p.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 22 Sep 2009 19:29:18 +0200") References: <877hvqga6p.fsf@mocca.josefsson.org> Message-ID: <87my4mhvp2.fsf@gnu.org> Hi Simon, Simon Josefsson writes: > The cause seems simple: including "config.h" is not done as the first > thing in these files, so gnutls/compat.h ends up being included before > config.h. The solution is to make sure "config.h" is included first. Indeed. I just pushed a fix and a few minor Guile-related fixlets to ?master?. Please let me know if it?s OK with you. Thanks! Ludo?. From simon at josefsson.org Wed Sep 23 17:03:58 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 23 Sep 2009 17:03:58 +0200 Subject: gnutls guile warnings In-Reply-To: <87my4mhvp2.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 23 Sep 2009 11:11:37 +0200") References: <877hvqga6p.fsf@mocca.josefsson.org> <87my4mhvp2.fsf@gnu.org> Message-ID: <87ocp1snxd.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi Simon, > > Simon Josefsson writes: > >> The cause seems simple: including "config.h" is not done as the first >> thing in these files, so gnutls/compat.h ends up being included before >> config.h. The solution is to make sure "config.h" is included first. > > Indeed. I just pushed a fix and a few minor Guile-related fixlets to > ?master?. Please let me know if it?s OK with you. Works fine here. Thank you! /Simon From simon at josefsson.org Wed Sep 23 17:59:05 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 23 Sep 2009 17:59:05 +0200 Subject: gnutls_server_name_set and IDN In-Reply-To: <200909240046.19805.daniel@cacert.org> (Daniel Black's message of "Thu, 24 Sep 2009 00:46:15 +1000") References: <87y6o69gxz.fsf@mocca.josefsson.org> <200909240046.19805.daniel@cacert.org> Message-ID: <87fxadsldi.fsf@mocca.josefsson.org> Daniel Black writes: >> What the new text means is that GnuTLS applications are responsible for >> converting any internationalized domain name into ACE before passing the >> string on to GnuTLS. > > Ok. Some really clear text in the documentation about this would be > good. Improved now, thanks, see: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a1290e27f8643b68a6c2dda > As the UTF-8/ ASCII error may be common is it beneficial to validate > this input to check for >7F characters? Hm, yes, maybe -- although it would prevents usage against some server that for some reason used a non-ASCII string there. RFC 4366 can be read to say that non-ASCII strings are OK, and not being able to interop against such a server just because of a input sanitation code seems overkill. But it is a tradeoff and I don't feel strongly about it. >> Let me know what you think of this, there is still time to bring this up >> in the IETF. > > Its clarify also simplifies it to the point that their is no mention > of IDNA as an appropriate mechanism to convert encodings to ASCII. Was > this intentional? Yes I think/hope so -- not mentioning IDNA specifically avoids inheriting the problems associated with it: support of non-ASCII hostnames then becomes entirely the IDNA specifications' problem. > I'm of the opinion, until abused otherwise, that appending "UTF-8 and > other character sets can be converted to ASCII using the ToASCII > function defined in RFC3490 section 4." (or similar) to the "HostName" > definition paragraph. IDNAbis is in WGLC now, so any such reference would be obsolete soon. Given that IDNAbis is completely different (both in design and implementation) compared to RFC 3490 I think a specific reference would only confuse more than it would help. Then implementers will ask whether the intention is that TLS SNI is only to be used with IDNA and not IDNAbis. > also maybe 6.1. could say, in response to the last bit of 3.1, + "Server > applications SHOULD validate server_name against any application layer > equivalent field." That makes sense to me. I'll forward that to the TLS list. /Simon From daniel at cacert.org Wed Sep 23 16:46:15 2009 From: daniel at cacert.org (Daniel Black) Date: Thu, 24 Sep 2009 00:46:15 +1000 Subject: gnutls_server_name_set and IDN In-Reply-To: <87y6o69gxz.fsf@mocca.josefsson.org> References: <87y6o69gxz.fsf@mocca.josefsson.org> Message-ID: <200909240046.19805.daniel@cacert.org> On Wednesday 23 September 2009 18:57:28 Simon Josefsson wrote: > Daniel Black writes: > > Should gnutls_server_name_set convert the domain name to ACE as per > > RFC4366 3.1 where it talks about IDNA (RFC 3490)? > > > > Using libidn function call can make this occur using idna_to_ascii_8z can > > make this happen though this is adding dependency. > > That text has been dropped from RFC 4366bis: > > http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3 > > I think the text in RFC 4366 is confusing and difficult to implement > interoperably. definitely. Its rewrite is clearer. It did take me a bit to realise that ASCII was only 0-7F and not the same as UTF-8. > What the new text means is that GnuTLS applications are responsible for > converting any internationalized domain name into ACE before passing the > string on to GnuTLS. Ok. Some really clear text in the documentation about this would be good. As the UTF-8/ ASCII error may be common is it beneficial to validate this input to check for >7F characters? Attached patch clarifies the gnutls_server_name_set function input. I'm not sure a UTF-8 -> ASCII replacement on gnutls_server_name_get is entirely true however some additional clarification here would be good. > Let me know what you think of this, there is still time to bring this up > in the IETF. Its clarify also simplifies it to the point that their is no mention of IDNA as an appropriate mechanism to convert encodings to ASCII. Was this intentional? I'm of the opinion, until abused otherwise, that appending "UTF-8 and other character sets can be converted to ASCII using the ToASCII function defined in RFC3490 section 4." (or similar) to the "HostName" definition paragraph. also maybe 6.1. could say, in response to the last bit of 3.1, + "Server applications SHOULD validate server_name against any application layer equivalent field." Thanks Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_server_name_set-docfix.patch Type: text/x-patch Size: 575 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From daniel at cacert.org Thu Sep 24 02:43:51 2009 From: daniel at cacert.org (Daniel Black) Date: Thu, 24 Sep 2009 10:43:51 +1000 Subject: gnutls_server_name_set and IDN In-Reply-To: <87fxadsldi.fsf@mocca.josefsson.org> References: <200909240046.19805.daniel@cacert.org> <87fxadsldi.fsf@mocca.josefsson.org> Message-ID: <200909241043.55865.daniel@cacert.org> On Thursday 24 September 2009 01:59:05 you wrote: > Improved now, thanks, see: > > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a12 > 90e27f8643b68a6c2dda thank you. I'm assuming no mention of ACE because of reasons below. > > > As the UTF-8/ ASCII error may be common is it beneficial to validate > > this input to check for >7F characters? > > ....not being able to interop > against such a server just because of a input sanitation code seems > overkill. ack. I assume people are passing UTF-8 to the socket connect method and then passing the same string to gnutls_server_name_set (IP or not). Which reminds me I need to find and IP address or not method out of socket structures. > > Its clarify also simplifies it to the point that their is no mention > > of IDNA as an appropriate mechanism to convert encodings to ASCII. Was > > this intentional? > > Yes I think/hope so -- not mentioning IDNA specifically avoids > inheriting the problems associated with it: support of non-ASCII > hostnames then becomes entirely the IDNA specifications' problem. it totally leaves the implementer in the dark find that spec though. I guess once its approved, provide documentation on gnutls and see what happens. > IDNAbis is in WGLC now, so any such reference would be obsolete soon....Then implementers will ask whether the intention is that TLS SNI is only to be used with IDNA and not IDNAbis. yep agree. > "Server applications SHOULD validate server_name against any ... > > That makes sense to me. I'll forward that to the TLS list. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From simon at josefsson.org Thu Sep 24 08:56:46 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Sep 2009 08:56:46 +0200 Subject: gnutls_server_name_set and IDN In-Reply-To: <200909241043.55865.daniel@cacert.org> (Daniel Black's message of "Thu, 24 Sep 2009 10:43:51 +1000") References: <200909240046.19805.daniel@cacert.org> <87fxadsldi.fsf@mocca.josefsson.org> <200909241043.55865.daniel@cacert.org> Message-ID: <87d45gbzkh.fsf@mocca.josefsson.org> Daniel Black writes: > On Thursday 24 September 2009 01:59:05 you wrote: >> Improved now, thanks, see: >> >> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=17edc60deccccfd93a12 >> 90e27f8643b68a6c2dda > > thank you. I'm assuming no mention of ACE because of reasons below. Right. >> > As the UTF-8/ ASCII error may be common is it beneficial to validate >> > this input to check for >7F characters? >> >> ....not being able to interop >> against such a server just because of a input sanitation code seems >> overkill. > ack. > > I assume people are passing UTF-8 to the socket connect method and then > passing the same string to gnutls_server_name_set (IP or not). Which reminds > me I need to find and IP address or not method out of socket structures. Yes. >> > Its clarify also simplifies it to the point that their is no mention >> > of IDNA as an appropriate mechanism to convert encodings to ASCII. Was >> > this intentional? >> >> Yes I think/hope so -- not mentioning IDNA specifically avoids >> inheriting the problems associated with it: support of non-ASCII >> hostnames then becomes entirely the IDNA specifications' problem. > > it totally leaves the implementer in the dark find that spec though. I guess > once its approved, provide documentation on gnutls and see what happens. Yes I think that is better. IDNA has implications for all protocols that use domain names, and referencing IDNA from everywhere does not necessarily improve anything. /Simon From guido at trentalancia.com Sun Sep 27 22:23:27 2009 From: guido at trentalancia.com (Guido Trentalancia) Date: Sun, 27 Sep 2009 22:23:27 +0200 Subject: X.509 certificate verification in GNU TLS Library Message-ID: <1254083007.11343.4839.camel@tesla.lan> Hello, I have tested the current GNU TLS Library against the issue reported at http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3517 and I believe the function _gnutls_x509_verify_certificate() in lib/x509/verify.c needs to be modified according to the attached patch in order for the certificate verification to work properly. In fact, at the moment (version 2.8.4 and at least since the problem was originally reported against branch 2.4.x as GNUTLS-SA-2009-3), the certificate verification function returns the status after each check, which implies that not all checks in _gnutls_x509_verify_certificate() are necessarily performed. I believe the correct behaviour is that all checks need to be performed (and stored in the variable "status" using logical OR) and that the result in the variable "status" need to be returned only then. After the attached patch is applied, the function returns only at the end, after all the checks have been performed (and the result contained in the variable "status" is the logical OR of the results of each check performed). What I get is that only using this patch, the behaviour is consistent with the expected results, as they have been outlined in the article mentioned above. Could somebody please double-check and eventually confirm ? Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.8.4-cert-verification-return-status.patch Type: text/x-patch Size: 1337 bytes Desc: not available URL: From simon at josefsson.org Mon Sep 28 13:12:52 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Sep 2009 13:12:52 +0200 Subject: X.509 certificate verification in GNU TLS Library In-Reply-To: <1254083007.11343.4839.camel@tesla.lan> (Guido Trentalancia's message of "Sun, 27 Sep 2009 22:23:27 +0200") References: <1254083007.11343.4839.camel@tesla.lan> Message-ID: <87ljjzmiff.fsf@mocca.josefsson.org> Guido Trentalancia writes: > Hello, > > I have tested the current GNU TLS Library against the issue reported at > http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3517 and > I believe the function _gnutls_x509_verify_certificate() in > lib/x509/verify.c needs to be modified according to the attached patch > in order for the certificate verification to work properly. > > In fact, at the moment (version 2.8.4 and at least since the problem was > originally reported against branch 2.4.x as GNUTLS-SA-2009-3), the > certificate verification function returns the status after each check, > which implies that not all checks in _gnutls_x509_verify_certificate() > are necessarily performed. I believe the correct behaviour is that all > checks need to be performed (and stored in the variable "status" using > logical OR) and that the result in the variable "status" need to be > returned only then. > > After the attached patch is applied, the function returns only at the > end, after all the checks have been performed (and the result contained > in the variable "status" is the logical OR of the results of each check > performed). > > What I get is that only using this patch, the behaviour is consistent > with the expected results, as they have been outlined in the article > mentioned above. > > Could somebody please double-check and eventually confirm ? Thanks. Some test vectors would help to reinforce and explain your point, do you have a test X.509 chain that validates incorrectly that you could post? /Simon From ludo at gnu.org Mon Sep 28 22:52:05 2009 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 28 Sep 2009 22:52:05 +0200 Subject: Guile 2.x updates Message-ID: <87my4e4wsq.fsf@gnu.org> Hello, I took the freedom to update the Guile bindings in ?master? so that they work correctly with the forthcoming Guile 2.x. These are small changes so I think they can be pushed to the current stable branch as well, if you deem it appropriate. Let me know if there are any problems. Thanks, Ludo?. From simon at josefsson.org Tue Sep 29 11:08:59 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 29 Sep 2009 11:08:59 +0200 Subject: Guile 2.x updates In-Reply-To: <87my4e4wsq.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Mon, 28 Sep 2009 22:52:05 +0200") References: <87my4e4wsq.fsf@gnu.org> Message-ID: <87d45akthw.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hello, > > I took the freedom to update the Guile bindings in ?master? so that they > work correctly with the forthcoming Guile 2.x. > > These are small changes so I think they can be pushed to the current > stable branch as well, if you deem it appropriate. It looks fine to me (or rather, I don't spot anything that would break anything non-guile, and I trust you on the Guile-specific portion), so please backport it to the v2.8 branch. /Simon From ueno at unixuser.org Wed Sep 30 03:53:45 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 30 Sep 2009 10:53:45 +0900 Subject: TLS 1.2 server Message-ID: <87iqf1p592.fsf@broken.deisui.org> Hello, I've just pushed TLS 1.2 server fix. While it was done in the same way as I did for client, I'd appreciate if someone will take a look at the changes: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e0b1124f72e3d5210000b3f677b401d8b2654ea4 http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=4b48a9e8e28bbd468b48ed5cb95ba0cce7508be6 The latter change is not essential by now but it will be needed when we will use a hash algorithm other than SHA1 to compute a signature of DH params. Anyway, TLS 1.2 server works again. I tried it with Opera 10 and the test output from GnuTLS says: Server Name: localhost Ephemeral DH using prime of 1024 bits. Protocol version: TLS1.2 Certificate Type: X.509 Key Exchange: DHE-RSA Compression NULL Cipher AES-256-CBC MAC SHA256 Ciphersuite DHE_RSA_AES_256_CBC_SHA256 Regards, -- Daiki Ueno From simon at josefsson.org Wed Sep 30 07:50:35 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 30 Sep 2009 07:50:35 +0200 Subject: TLS 1.2 server In-Reply-To: <87iqf1p592.fsf@broken.deisui.org> (Daiki Ueno's message of "Wed, 30 Sep 2009 10:53:45 +0900") References: <87iqf1p592.fsf@broken.deisui.org> Message-ID: <87r5tp56c4.fsf@mocca.josefsson.org> Daiki Ueno writes: > Hello, > > I've just pushed TLS 1.2 server fix. While it was done in the same way > as I did for client, I'd appreciate if someone will take a look at the > changes: > > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=e0b1124f72e3d5210000b3f677b401d8b2654ea4 > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=4b48a9e8e28bbd468b48ed5cb95ba0cce7508be6 > > The latter change is not essential by now but it will be needed when we > will use a hash algorithm other than SHA1 to compute a signature of DH > params. > > Anyway, TLS 1.2 server works again. I tried it with Opera 10 and the > test output from GnuTLS says: Great, thank you! The patch seems fine to me. What do you think we should do about the CertificateRequest supported_signature_algorithms field? I think the application may want to look at the server preference when deciding which certificate to use, and GnuTLS may want to use this information internally too, when it is selecting the certificate. /Simon > Server Name: localhost > Ephemeral DH using prime of 1024 bits. > > Protocol version: TLS1.2 > Certificate Type: X.509 > Key Exchange: DHE-RSA > Compression NULL > Cipher AES-256-CBC > MAC SHA256 > Ciphersuite DHE_RSA_AES_256_CBC_SHA256 > > Regards, From ueno at unixuser.org Wed Sep 30 12:47:12 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 30 Sep 2009 19:47:12 +0900 Subject: TLS 1.2 server In-Reply-To: <87r5tp56c4.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 30 Sep 2009 07:50:35 +0200") References: <87iqf1p592.fsf@broken.deisui.org> <87r5tp56c4.fsf@mocca.josefsson.org> Message-ID: <87tyykemkv.fsf@broken.deisui.org> >>>>> In <87r5tp56c4.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > What do you think we should do about the CertificateRequest > supported_signature_algorithms field? I think the application may want > to look at the server preference when deciding which certificate to use, > and GnuTLS may want to use this information internally too, when it is > selecting the certificate. I have thought of something like: * Provide the following default ordering of algorithms: RSA_SHA512(*) RSA_SHA384(*) RSA_SHA256(*) RSA_SHA1(+) DSA_SHA1(+) * is only available if RSA certificate is given + is only available if DSA certificate is given * The application may supply the preference through a priority string like this: "+SIGN_RSA_SHA256:-SIGN_RSA_SHA384:!SIGN_RSA_SHA1", where "+" moves the given algorithm to the top, "-" moves it to the bottom, and "!" disables it. Any thoughts? Regards, -- Daiki Ueno From simon at josefsson.org Wed Sep 30 13:55:29 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 30 Sep 2009 13:55:29 +0200 Subject: TLS 1.2 server In-Reply-To: <87r5tp56c4.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 30 Sep 2009 07:50:35 +0200") References: <87iqf1p592.fsf@broken.deisui.org> <87r5tp56c4.fsf@mocca.josefsson.org> Message-ID: <87ske44pfy.fsf@mocca.josefsson.org> The x509self self-test started failing, and it may be TLS 1.2 related. Can you take a look? /Simon client: sent record. server: got data, forcing rehandshake. client: recv returned -37. client: doing handshake! ==12233== Invalid read of size 4 ==12233== at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172) ==12233== by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157) ==12233== by 0x4055197: _gnutls_gen_cert_client_cert_vrfy (auth_cert.c:1419) ==12233== by 0x40458BD: _gnutls_send_client_certificate_verify (gnutls_kx.c:352) ==12233== by 0x404230F: _gnutls_handshake_client (gnutls_handshake.c:2464) ==12233== by 0x4042C0F: gnutls_handshake (gnutls_handshake.c:2311) ==12233== by 0x804A362: client (x509self.c:189) ==12233== by 0x804A4D1: doit (x509self.c:511) ==12233== by 0x804AA7C: main (utils.c:148) ==12233== Address 0x43176dd3 is not stack'd, malloc'd or (recently) free'd From simon at josefsson.org Wed Sep 30 14:08:59 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 30 Sep 2009 14:08:59 +0200 Subject: TLS 1.2 server In-Reply-To: <87tyykemkv.fsf@broken.deisui.org> (Daiki Ueno's message of "Wed, 30 Sep 2009 19:47:12 +0900") References: <87iqf1p592.fsf@broken.deisui.org> <87r5tp56c4.fsf@mocca.josefsson.org> <87tyykemkv.fsf@broken.deisui.org> Message-ID: <87ocos4otg.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87r5tp56c4.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> What do you think we should do about the CertificateRequest >> supported_signature_algorithms field? I think the application may want >> to look at the server preference when deciding which certificate to use, >> and GnuTLS may want to use this information internally too, when it is >> selecting the certificate. > > I have thought of something like: > > * Provide the following default ordering of algorithms: > > RSA_SHA512(*) > RSA_SHA384(*) > RSA_SHA256(*) > RSA_SHA1(+) > DSA_SHA1(+) > > * is only available if RSA certificate is given > + is only available if DSA certificate is given The approach seems OK, but I think the ordering should depend on the NORMAL vs SECURE vs PERFORMANCE. For similar reasons GnuTLS prefer AES-128 over AES-256 (i.e., because of no known attacks and it is faster), RSA_SHA256 should probably be the default in the NORMAL mode. Thus NORMAL: RSA_SHA256(*) RSA_SHA384(*) RSA_SHA512(*) RSA_SHA1(+) DSA_SHA1(+) And PERFORMANCE: RSA_SHA1(+) DSA_SHA1(+) RSA_SHA256(*) RSA_SHA384(*) RSA_SHA512(*) And SECURE: RSA_SHA512(*) RSA_SHA384(*) RSA_SHA256(*) RSA_SHA1(+) DSA_SHA1(+) Possibly SHA-1 should not be mentioned in the SECURE mode at all? The hash is considered broken even though no practical attacks are known. > * The application may supply the preference through a priority string > like this: "+SIGN_RSA_SHA256:-SIGN_RSA_SHA384:!SIGN_RSA_SHA1", where > "+" moves the given algorithm to the top, "-" moves it to the bottom, > and "!" disables it. Sounds good. Today ! and - have the same meaning for priority strings (i.e., remove), but I like your model better. Clients will probably want to be able to inspect the server's preference list when it is in the certificate selection callback function. I think a new API function is needed to extract the algorithm identifiers. Implementing the first part (i.e., sending a server side preference list) is probably the easiest to start with. Would you like to work on it? Once that is working, it will be easier to add the API to return the algorithm list for clients. And finally, make GnuTLS automatically pick the most appropriate client certificate by default if the application supplied more than one (depending on server side preference). /Simon From ueno at unixuser.org Wed Sep 30 14:41:39 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 30 Sep 2009 21:41:39 +0900 Subject: TLS 1.2 server In-Reply-To: <87ske44pfy.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 30 Sep 2009 13:55:29 +0200") References: <87iqf1p592.fsf@broken.deisui.org> <87r5tp56c4.fsf@mocca.josefsson.org> <87ske44pfy.fsf@mocca.josefsson.org> Message-ID: <87pr98eha4.fsf@broken.deisui.org> >>>>> In <87ske44pfy.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > The x509self self-test started failing, and it may be TLS 1.2 related. > Can you take a look? Sure, but I couldn't reproduce the failure. What architecture did you run the test on? > ==12233== Invalid read of size 4 > ==12233== at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172) > ==12233== by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157) > ==12233== by 0x4055197: _gnutls_gen_cert_client_cert_vrfy (auth_cert.c:1419) > ==12233== by 0x40458BD: _gnutls_send_client_certificate_verify (gnutls_kx.c:352) Hmm, I haven't touched any of those functions, anyway I will look into it further tomorrow. Sorry if it is by my mistake (probably so...) Regards, -- Daiki Ueno From simon at josefsson.org Wed Sep 30 16:04:51 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 30 Sep 2009 16:04:51 +0200 Subject: TLS 1.2 server In-Reply-To: <87pr98eha4.fsf@broken.deisui.org> (Daiki Ueno's message of "Wed, 30 Sep 2009 21:41:39 +0900") References: <87iqf1p592.fsf@broken.deisui.org> <87r5tp56c4.fsf@mocca.josefsson.org> <87ske44pfy.fsf@mocca.josefsson.org> <87pr98eha4.fsf@broken.deisui.org> Message-ID: <87eipo4jgc.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87ske44pfy.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> The x509self self-test started failing, and it may be TLS 1.2 related. >> Can you take a look? > > Sure, but I couldn't reproduce the failure. What architecture did you > run the test on? Debian x86. >> ==12233== Invalid read of size 4 >> ==12233== at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172) >> ==12233== by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157) >> ==12233== by 0x4055197: _gnutls_gen_cert_client_cert_vrfy (auth_cert.c:1419) >> ==12233== by 0x40458BD: _gnutls_send_client_certificate_verify (gnutls_kx.c:352) > > Hmm, I haven't touched any of those functions, anyway I will look into > it further tomorrow. Sorry if it is by my mistake (probably so...) The error happened when I made TLS 1.2 the default, so if you didn't pull you might not see it. It could be something else, although the auth_cert.c stuff did change which may have caused this -- I'll look into it further as well when I get time. /Simon From ueno at unixuser.org Wed Sep 30 22:37:55 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 01 Oct 2009 05:37:55 +0900 Subject: TLS 1.2 server In-Reply-To: <87eipo4jgc.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 30 Sep 2009 16:04:51 +0200") References: <87iqf1p592.fsf@broken.deisui.org> <87r5tp56c4.fsf@mocca.josefsson.org> <87ske44pfy.fsf@mocca.josefsson.org> <87pr98eha4.fsf@broken.deisui.org> <87eipo4jgc.fsf@mocca.josefsson.org> Message-ID: <87ljjwdv8c.fsf@broken.deisui.org> >>>>> In <87eipo4jgc.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > >> The x509self self-test started failing, and it may be TLS 1.2 related. > >> Can you take a look? > > > > Sure, but I couldn't reproduce the failure. What architecture did you > > run the test on? > Debian x86. I'm now able to reproduce it on x86. I wonder why this is not the case on amd64. > >> ==12233== Invalid read of size 4 > >> ==12233== at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172) > >> ==12233== by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157) It should be fixed with: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=01c50c13f7e7a1d676451015ef66c95511d1d734 That was actually my mistake - when I changed the underlying hash function from SHA-1 to SHA256, I forgot to increase the buffer size of internal hash values. Regards, -- Daiki Ueno