From dlphsharma at gmail.com  Mon Dec  1 16:35:10 2008
From: dlphsharma at gmail.com (ravi sharma)
Date: Mon, 1 Dec 2008 21:05:10 +0530
Subject: hi I have a problem related to nufw-2.2.17
Message-ID: <f7c0b4b0812010735v140b4502i5d027c9d1afe247f@mail.gmail.com>

Hi i have gnutls-1.4.4 installed in fedora-core9

when compuling nufw-2.2.17

errors----------------------------------------

checking whether stat accepts an empty string... no
checking for gethostbyname... yes
checking for memset... yes
checking for socket... yes
checking for strcasecmp... yes
checking for strspn... yes
./configure: line 20806: syntax error near unexpected token
`"$NEED_LIBGCRYPT_VERSION"'
./configure: line 20806: `AM_PATH_LIBGCRYPT("$NEED_LIBGCRYPT_VERSION")'

-- 

Ravi Sharma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081201/c672ef19/attachment.htm>

From herrold at owlriver.com  Tue Dec  2 00:09:19 2008
From: herrold at owlriver.com (R P Herrold)
Date: Mon, 1 Dec 2008 18:09:19 -0500 (EST)
Subject: gnutls-1.6.3 error report
Message-ID: <alpine.LRH.2.00.0812011804270.13970@arj.bjyevire.pbz>


Doing a rebuild on CentOS 5, of gnutls-1.6.3-1.fc8.src.rpm 
(from Red Hat's Raw Hide archive) yields an error which asks 
that I report it:


===================================
1 of 10 tests failed
Please report to bug-gnutls at gnu.org
===================================


==9666== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 
4 from 1)
==9666== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9666== malloc/free: 2 allocs, 2 frees, 157 bytes allocated.
==9666== For counts of detected errors, rerun with: -v
==9666== All heap blocks were freed -- no leaks are possible.
/bin/sh: line 4:  9666 Segmentation fault 
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar 
valgrind ${dir}$tst
FAIL: openssl
==9671== Memcheck, a memory error detector.
==9671== Copyright (C) 2002-2006, and GNU GPL'd, by Julian 
Seward et al.


This source RPM is in my directory:

/home/herrold/build/libiphone/libiphone-0.1.0

and I have 'snapshotted' versions on all packages, if you need 
further information on the build environment

-- Russ herrold








From simon at josefsson.org  Wed Dec  3 13:04:19 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 03 Dec 2008 13:04:19 +0100
Subject: gnutls-1.6.3 error report
References: <alpine.LRH.2.00.0812011804270.13970@arj.bjyevire.pbz>
Message-ID: <87wsehh3cs.fsf@mocca.josefsson.org>

R P Herrold <herrold at owlriver.com> writes:

> Doing a rebuild on CentOS 5, of gnutls-1.6.3-1.fc8.src.rpm (from Red
> Hat's Raw Hide archive) yields an error which asks that I report it:
>
>
> ===================================
> 1 of 10 tests failed
> Please report to bug-gnutls at gnu.org
> ===================================
>
>
> ==9666== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 4 from
> 1)
> ==9666== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==9666== malloc/free: 2 allocs, 2 frees, 157 bytes allocated.
> ==9666== For counts of detected errors, rerun with: -v
> ==9666== All heap blocks were freed -- no leaks are possible.
> /bin/sh: line 4:  9666 Segmentation fault
> PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar valgrind
> ${dir}$tst
> FAIL: openssl
> ==9671== Memcheck, a memory error detector.
> ==9671== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et
> al.
>
>
> This source RPM is in my directory:
>
> /home/herrold/build/libiphone/libiphone-0.1.0
>
> and I have 'snapshotted' versions on all packages, if you need further
> information on the build environment

GnuTLS 1.6 is rather old, and we recommend to upgrade to the latest
stable branch 2.6.x.  Please check if you can reproduce the problem with
2.6.x, I suspect it has been fixed already.

/Simon





From ametzler at downhill.at.eu.org  Wed Dec  3 19:19:56 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 3 Dec 2008 19:19:56 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
In-Reply-To: <20081203071342.13532.21316.reportbug@hal>
References: <20081203071342.13532.21316.reportbug@hal>
Message-ID: <20081203181956.GA3376@downhill.g.la>

On 2008-12-03 Michael Kiefer <Michael-Kiefer at web.de> wrote:
> Package: libgnutls26
> Version: 2.4.2-3
> Severity: important

> Since I updated libgnutls26 from 2.4.2-1 to 2.4.2-3 kMyMoney2 does
> not connect to my bank any more.  When I run gnutls-cli --insecure
> -p 443 hbci-pintan-rp.s-hbci.de -d 4711 --print-cert it says

> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted
[...]

FWIW adding or dropping
http://svn.debian.org/wsvn/pkg-gnutls/packages/gnutls26/trunk/debian/patches/20_GNUTLS-SA-2008-3.patch?op=file&rev=0&sc=0
indeed makes

gnutls-cli  -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \
/etc/ssl/certs/ca-certificates.crt

succeed or not succeed in verifying the server certificate. 

openssl s_client -connect  hbci-pintan-rp.s-hbci.de:443 -CApath \
/etc/ssl/certs

also reports "Verify return code: 0 (ok)"
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'




From nmav at gnutls.org  Thu Dec  4 08:06:38 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 04 Dec 2008 09:06:38 +0200
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
In-Reply-To: <20081203181956.GA3376@downhill.g.la>
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la>
Message-ID: <4937817E.8070500@gnutls.org>

Andreas Metzler wrote:
> On 2008-12-03 Michael Kiefer <Michael-Kiefer at web.de> wrote:
>> Package: libgnutls26
>> Version: 2.4.2-3
>> Severity: important
> 
>> Since I updated libgnutls26 from 2.4.2-1 to 2.4.2-3 kMyMoney2 does
>> not connect to my bank any more.  When I run gnutls-cli --insecure
>> -p 443 hbci-pintan-rp.s-hbci.de -d 4711 --print-cert it says
> 
>> - Peer's certificate issuer is unknown
>> - Peer's certificate is NOT trusted
> [...]
> 
> FWIW adding or dropping
> http://svn.debian.org/wsvn/pkg-gnutls/packages/gnutls26/trunk/debian/patches/20_GNUTLS-SA-2008-3.patch?op=file&rev=0&sc=0
> indeed makes
> 
> gnutls-cli  -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \
> /etc/ssl/certs/ca-certificates.crt

It seems to me that MD2 is missing from newer gnutls and this is the
reason why it fails. libgcrypt has the MD2 enumeration but not the
actual implementation and this tricked me into removing the included
md2. I will try to revert the old behavior of using an included version
of md2.

regards,
Nikos




From simon at josefsson.org  Thu Dec  4 09:58:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 04 Dec 2008 09:58:14 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la> <4937817E.8070500@gnutls.org>
Message-ID: <87prk8e2qh.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Andreas Metzler wrote:
>> On 2008-12-03 Michael Kiefer <Michael-Kiefer at web.de> wrote:
>>> Package: libgnutls26
>>> Version: 2.4.2-3
>>> Severity: important
>> 
>>> Since I updated libgnutls26 from 2.4.2-1 to 2.4.2-3 kMyMoney2 does
>>> not connect to my bank any more.  When I run gnutls-cli --insecure
>>> -p 443 hbci-pintan-rp.s-hbci.de -d 4711 --print-cert it says
>> 
>>> - Peer's certificate issuer is unknown
>>> - Peer's certificate is NOT trusted
>> [...]
>> 
>> FWIW adding or dropping
>> http://svn.debian.org/wsvn/pkg-gnutls/packages/gnutls26/trunk/debian/patches/20_GNUTLS-SA-2008-3.patch?op=file&rev=0&sc=0
>> indeed makes
>> 
>> gnutls-cli  -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \
>> /etc/ssl/certs/ca-certificates.crt
>
> It seems to me that MD2 is missing from newer gnutls and this is the
> reason why it fails. libgcrypt has the MD2 enumeration but not the
> actual implementation and this tricked me into removing the included
> md2. I will try to revert the old behavior of using an included version
> of md2.

I don't think MD2 should be required here: chain verification should not
need to verify the RSA-MD2 self-signature in the CA cert, because that
cert is marked as trusted.

If there were other MD2 signatures involved, verification should
definitely fail, but that doesn't seem to be the case with this chain.

It seems this problem is caused by the chain validation algorithm now
also look at the CA cert, but it didn't before the GNUTLS-SA-2008-3
patch.

/Simon





From tmraz at redhat.com  Thu Dec  4 10:16:08 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 04 Dec 2008 10:16:08 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
In-Reply-To: <87prk8e2qh.fsf@mocca.josefsson.org>
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la> <4937817E.8070500@gnutls.org>
	<87prk8e2qh.fsf@mocca.josefsson.org>
Message-ID: <1228382168.3506.50.camel@vespa.frost.loc>

On Thu, 2008-12-04 at 09:58 +0100, Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> > Andreas Metzler wrote:
> >> On 2008-12-03 Michael Kiefer <Michael-Kiefer at web.de> wrote:
> >>> Package: libgnutls26
> >>> Version: 2.4.2-3
> >>> Severity: important
> >> 
> >>> Since I updated libgnutls26 from 2.4.2-1 to 2.4.2-3 kMyMoney2 does
> >>> not connect to my bank any more.  When I run gnutls-cli --insecure
> >>> -p 443 hbci-pintan-rp.s-hbci.de -d 4711 --print-cert it says
> >> 
> >>> - Peer's certificate issuer is unknown
> >>> - Peer's certificate is NOT trusted
> >> [...]
> >> 
> >> FWIW adding or dropping
> >> http://svn.debian.org/wsvn/pkg-gnutls/packages/gnutls26/trunk/debian/patches/20_GNUTLS-SA-2008-3.patch?op=file&rev=0&sc=0
> >> indeed makes
> >> 
> >> gnutls-cli  -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \
> >> /etc/ssl/certs/ca-certificates.crt
> >
> > It seems to me that MD2 is missing from newer gnutls and this is the
> > reason why it fails. libgcrypt has the MD2 enumeration but not the
> > actual implementation and this tricked me into removing the included
> > md2. I will try to revert the old behavior of using an included version
> > of md2.
> 
> I don't think MD2 should be required here: chain verification should not
> need to verify the RSA-MD2 self-signature in the CA cert, because that
> cert is marked as trusted.
> 
> If there were other MD2 signatures involved, verification should
> definitely fail, but that doesn't seem to be the case with this chain.
> 
> It seems this problem is caused by the chain validation algorithm now
> also look at the CA cert, but it didn't before the GNUTLS-SA-2008-3
> patch.

Yes, this is caused by removing the code for removal of the last
self-signed certificate from the chain validation after fixing the
segfault in the original patch.

I had proposed to just adjust the condition for the removal so the code
would not segfault on sites with self-signed site certificate but
instead the whole removal code was deleted.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From nmav at gnutls.org  Thu Dec  4 20:06:47 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 04 Dec 2008 21:06:47 +0200
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
In-Reply-To: <87prk8e2qh.fsf@mocca.josefsson.org>
References: <20081203071342.13532.21316.reportbug@hal>	<20081203181956.GA3376@downhill.g.la>
	<4937817E.8070500@gnutls.org> <87prk8e2qh.fsf@mocca.josefsson.org>
Message-ID: <49382A47.8040006@gnutls.org>

Simon Josefsson wrote:

> I don't think MD2 should be required here: chain verification should not
> need to verify the RSA-MD2 self-signature in the CA cert, because that
> cert is marked as trusted.
> 
> If there were other MD2 signatures involved, verification should
> definitely fail, but that doesn't seem to be the case with this chain.
> 
> It seems this problem is caused by the chain validation algorithm now
> also look at the CA cert, but it didn't before the GNUTLS-SA-2008-3
> patch.

Ouch. Then it seems we correct the previous algorithm and revert to it.
I'll try to check it out.

regards,
Nikos




From nmav at gnutls.org  Fri Dec  5 20:01:00 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 05 Dec 2008 21:01:00 +0200
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
In-Reply-To: <87prk8e2qh.fsf@mocca.josefsson.org>
References: <20081203071342.13532.21316.reportbug@hal>	<20081203181956.GA3376@downhill.g.la>
	<4937817E.8070500@gnutls.org> <87prk8e2qh.fsf@mocca.josefsson.org>
Message-ID: <49397A6C.4030709@gnutls.org>

Simon Josefsson wrote:

>>> gnutls-cli  -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \
>>> /etc/ssl/certs/ca-certificates.crt
>> It seems to me that MD2 is missing from newer gnutls and this is the
>> reason why it fails. libgcrypt has the MD2 enumeration but not the
>> actual implementation and this tricked me into removing the included
>> md2. I will try to revert the old behavior of using an included version
>> of md2.
> 
> I don't think MD2 should be required here: chain verification should not
> need to verify the RSA-MD2 self-signature in the CA cert, because that
> cert is marked as trusted.
> 
> If there were other MD2 signatures involved, verification should
> definitely fail, but that doesn't seem to be the case with this chain.
> 
> It seems this problem is caused by the chain validation algorithm now
> also look at the CA cert, but it didn't before the GNUTLS-SA-2008-3
> patch.

I've added again the GNUTLS-SA-2008-3 patch this time with some checks
to avoid the crashes.

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20081205/9282f325/attachment.txt>

From simon at josefsson.org  Wed Dec 10 13:00:23 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Dec 2008 13:00:23 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la> <4937817E.8070500@gnutls.org>
	<87prk8e2qh.fsf@mocca.josefsson.org> <49397A6C.4030709@gnutls.org>
Message-ID: <87ej0gfdew.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>>>> gnutls-cli  -p 443 hbci-pintan-rp.s-hbci.de --x509cafile \
>>>> /etc/ssl/certs/ca-certificates.crt
>>> It seems to me that MD2 is missing from newer gnutls and this is the
>>> reason why it fails. libgcrypt has the MD2 enumeration but not the
>>> actual implementation and this tricked me into removing the included
>>> md2. I will try to revert the old behavior of using an included version
>>> of md2.
>> 
>> I don't think MD2 should be required here: chain verification should not
>> need to verify the RSA-MD2 self-signature in the CA cert, because that
>> cert is marked as trusted.
>> 
>> If there were other MD2 signatures involved, verification should
>> definitely fail, but that doesn't seem to be the case with this chain.
>> 
>> It seems this problem is caused by the chain validation algorithm now
>> also look at the CA cert, but it didn't before the GNUTLS-SA-2008-3
>> patch.
>
> I've added again the GNUTLS-SA-2008-3 patch this time with some checks
> to avoid the crashes.

I believe that is wrong: with your patch it will fail when the CA is
self-signed using RSA-MD2.  Reproduce using the new self-test
chainverify.c which (I believe) includes all the example chains that
have been mentioned in bug reports so far.

I believe the patch in 2.6.2 is the right thing to solve the
GNUTLS-SA_2008-3 problem.

The problem we are discussing now is that chains that end with an
trusted anchor using RSA-MD2 incorrectly fails verification.  So we need
to fix that problem.

The patch below (against master) does:

1) Revert your patch.
2) In _gnutls_verify_certificate2 it now skips further tests when the
   certificate is already trusted.

This passed both 'chainverify.c' and 'cve-2008-4989.c'.  Please test
further iterations (if any) against those self-tests.

/Simon

>From 071beb6e8038bf5ffc1d63eb0b249a37ffa80ed3 Mon Sep 17 00:00:00 2001
From: Simon Josefsson <simon at josefsson.org>
Date: Wed, 10 Dec 2008 12:57:19 +0100
Subject: [PATCH] Revert Nikos revert, and fix verification hopefully better.
 The new logic is to include the CA cert in validation,
 but short-cut full validation of trusted certificates.

---
 NEWS              |    6 ++++++
 lib/x509/verify.c |   49 ++++++++++++++-----------------------------------
 2 files changed, 20 insertions(+), 35 deletions(-)

diff --git a/NEWS b/NEWS
index 0b93c8d..021af4e 100644
--- a/NEWS
+++ b/NEWS
@@ -5,6 +5,12 @@ See the end for copying conditions.
 
 * Version 2.7.3 (unreleased)
 
+** gnutls: Fix chain verification for chains that ends with RSA-MD2 CAs.
+Reported by Michael Kiefer <Michael-Kiefer at web.de> in
+<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507633> forwarded by
+Andreas Metzler <ametzler at downhill.at.eu.org> in
+<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3309>.
+
 ** gnutls: Libgcrypt initialization changed.
 If libgcrypt has not already been initialized, GnuTLS will now
 initialize libgcrypt with disabled secure memory.  Initialize
diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index 00e2422..6fc635a 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -226,6 +226,7 @@ _gnutls_verify_certificate2 (gnutls_x509_crt_t cert,
   gnutls_datum_t cert_signature = { NULL, 0 };
   gnutls_x509_crt_t issuer;
   int ret, issuer_version, result;
+  int sigalg;
 
   if (output)
     *output = 0;
@@ -251,6 +252,11 @@ _gnutls_verify_certificate2 (gnutls_x509_crt_t cert,
       return 0;
     }
 
+  /* If self-issued, it is one of our trusted certs.  Don't bother
+     testing an explicitly trusted cert further. */
+  if (is_issuer (cert, cert))
+    return 1;
+
   issuer_version = gnutls_x509_crt_get_version (issuer);
   if (issuer_version < 0)
     {
@@ -303,24 +309,15 @@ _gnutls_verify_certificate2 (gnutls_x509_crt_t cert,
       ret = 0;
     }
 
-  /* If the certificate is not self signed check if the algorithms
-   * used are secure. If the certificate is self signed it doesn't
-   * really matter.
-   */
-  if (is_issuer (cert, cert) == 0)
-    {
-      int sigalg;
-
-      sigalg = gnutls_x509_crt_get_signature_algorithm (cert);
+  sigalg = gnutls_x509_crt_get_signature_algorithm (cert);
 
-      if (((sigalg == GNUTLS_SIGN_RSA_MD2) &&
-	   !(flags & GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2)) ||
-	  ((sigalg == GNUTLS_SIGN_RSA_MD5) &&
-	   !(flags & GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5)))
-	{
-	  if (output)
-	    *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
-	}
+  if (((sigalg == GNUTLS_SIGN_RSA_MD2) &&
+       !(flags & GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2)) ||
+      ((sigalg == GNUTLS_SIGN_RSA_MD5) &&
+       !(flags & GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5)))
+    {
+      if (output)
+	*output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
     }
 
   result = ret;
@@ -374,24 +371,6 @@ _gnutls_x509_verify_certificate (const gnutls_x509_crt_t * certificate_list,
   int i = 0, ret;
   unsigned int status = 0, output;
 
-  if (clist_size > 1) 
-    {
-      /* Check if the last certificate in the path is self signed.
-       * In that case ignore it (a certificate is trusted only if it
-       * leads to a trusted party by us, not the server's).
-       *
-       * This in addition prevents from verifying self signed certificates
-       * against themselves. This although not bad caused verification
-       * failures on some root self signed certificates that use the MD2
-       * algorithm.
-       */
-      if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-  				    certificate_list[clist_size - 1]) > 0)
-        {
-          clist_size--;
-        }
-    }
-
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *
-- 
1.5.6.5






From simon at josefsson.org  Wed Dec 10 14:08:53 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Dec 2008 14:08:53 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la> <4937817E.8070500@gnutls.org>
	<87prk8e2qh.fsf@mocca.josefsson.org> <49397A6C.4030709@gnutls.org>
	<87ej0gfdew.fsf@mocca.josefsson.org>
Message-ID: <871vwgfa8q.fsf@mocca.josefsson.org>

In case anyone is testing this patch right now: it seems it passed the
self-tests better, but there are problems with gnutls-cli against some
sites anyway.  I'm debugging it now.

/Simon





From simon at josefsson.org  Wed Dec 10 15:32:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Dec 2008 15:32:50 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la> <4937817E.8070500@gnutls.org>
	<87prk8e2qh.fsf@mocca.josefsson.org> <49397A6C.4030709@gnutls.org>
	<87ej0gfdew.fsf@mocca.josefsson.org>
Message-ID: <87skowdrsd.fsf@mocca.josefsson.org>

My approach introduced a problem with the pkcs1-padding self-test that
uses certtool --verify-chain, and the self-test assumes that the last
certificate is actually verified against its own public key...  so
short-cutting the validation of trust anchors changed the semantics of
one public interface.  Sigh.  So I have reverted my patch.

Simon Josefsson <simon at josefsson.org> writes:

> I believe that is wrong: with your patch it will fail when the CA is
> self-signed using RSA-MD2.

There aren't many of those around, so I think we can leave it as a
documented bug that self-signed RSA-MD2 certificate cannot be used as a
trust anchor.  One might see that as a feature, even. ;)

I've aligned the self-tests with Nikos' approach.

/Simon





From simon at josefsson.org  Wed Dec 10 16:07:30 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Dec 2008 16:07:30 +0100
Subject: Release candidate of 2.6.3
Message-ID: <87oczkdq6l.fsf@mocca.josefsson.org>

We'll need to do another 2.6.x release, to make X.509 certificate chains
ending with RSA-MD2 CA's (i.e., one of VeriSign's CA's) validate
successfully again.  I have prepared a daily build that incorporates
everything we want to release in 2.6.3, please test it now:

http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20081210.tar.gz
http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20081210.tar.gz.gpg

I've prepared patches against the two latest stable branches below.

/Simon

Patch against 2.6.2:

diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index 92ef722..00e2422 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -374,6 +374,24 @@ _gnutls_x509_verify_certificate (const gnutls_x509_crt_t * certificate_list,
   int i = 0, ret;
   unsigned int status = 0, output;
 
+  if (clist_size > 1) 
+    {
+      /* Check if the last certificate in the path is self signed.
+       * In that case ignore it (a certificate is trusted only if it
+       * leads to a trusted party by us, not the server's).
+       *
+       * This in addition prevents from verifying self signed certificates
+       * against themselves. This although not bad caused verification
+       * failures on some root self signed certificates that use the MD2
+       * algorithm.
+       */
+      if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
+  				    certificate_list[clist_size - 1]) > 0)
+        {
+          clist_size--;
+        }
+    }
+
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *

Patch against 2.4.2:

--- gnutls-2.4.2/lib/x509/verify.c.orig	2008-12-10 16:05:39.000000000 +0100
+++ gnutls-2.4.2/lib/x509/verify.c	2008-12-10 16:05:41.000000000 +0100
@@ -376,6 +376,24 @@
   int i = 0, ret;
   unsigned int status = 0, output;
 
+  if (clist_size > 1)
+    {
+      /* Check if the last certificate in the path is self signed.
+       * In that case ignore it (a certificate is trusted only if it
+       * leads to a trusted party by us, not the server's).
+       *
+       * This in addition prevents from verifying self signed certificates
+       * against themselves. This although not bad caused verification
+       * failures on some root self signed certificates that use the MD2
+       * algorithm.
+       */
+      if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
+					certificate_list[clist_size - 1]) > 0)
+	{
+	  clist_size--;
+	}
+    }
+
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *
@@ -414,17 +432,6 @@
     }
 #endif
 
-  /* Check if the last certificate in the path is self signed.
-   * In that case ignore it (a certificate is trusted only if it
-   * leads to a trusted party by us, not the server's).
-   */
-  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-				    certificate_list[clist_size - 1]) > 0
-      && clist_size > 0)
-    {
-      clist_size--;
-    }
-
   /* Verify the certificate path (chain) 
    */
   for (i = clist_size - 1; i > 0; i--)




From simon at josefsson.org  Wed Dec 10 17:35:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Dec 2008 17:35:41 +0100
Subject: GnuTLS 2.7.3
Message-ID: <87bpvkdm3m.fsf@mocca.josefsson.org>

The GnuTLS 2.7.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.3.tar.bz2 (5.8MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.3.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.3.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.3.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult 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.7.3 (released 2008-12-10)

** gnutls: Fix chain verification for chains that ends with RSA-MD2 CAs.
Reported by Michael Kiefer <Michael-Kiefer at web.de> in
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507633> forwarded by
Andreas Metzler <ametzler at downhill.at.eu.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3309>.

** gnutls: Libgcrypt initialization changed.
If libgcrypt has not already been initialized, GnuTLS will now
initialize libgcrypt with disabled secure memory.  Initialize
libgcrypt explicitly in your application if you want to enable secure
memory.  Before GnuTLS initialized libgcrypt to use GnuTLS's memory
allocation functions, which doesn't use secure memory, so there is no
real change in behaviour.

** gnutls: Fix memory leak in PSK authentication.
Reported by Michael Weiser <michael at weiser.dinsnail.net> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1465>.

** gnutls: Small byte reads via gnutls_record_recv() optimized.

** certtool: Move gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0) call earlier.
It needs to be invoked before libgcrypt is initialized.

** gnutls-cli: Return non-zero exit code on error conditions.

** gnutls-cli: Corrected bug which caused a rehandshake request to be ignored.

** tests: Added chainverify self-test that tests X.509 chain verifications.

** 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: </pipermail/attachments/20081210/1af877cc/attachment.pgp>

From nmav at gnutls.org  Wed Dec 10 18:03:24 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 10 Dec 2008 19:03:24 +0200
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
In-Reply-To: <87skowdrsd.fsf@mocca.josefsson.org>
References: <20081203071342.13532.21316.reportbug@hal>	<20081203181956.GA3376@downhill.g.la>
	<4937817E.8070500@gnutls.org>	<87prk8e2qh.fsf@mocca.josefsson.org>
	<49397A6C.4030709@gnutls.org>	<87ej0gfdew.fsf@mocca.josefsson.org>
	<87skowdrsd.fsf@mocca.josefsson.org>
Message-ID: <493FF65C.5040603@gnutls.org>

Simon Josefsson wrote:
> My approach introduced a problem with the pkcs1-padding self-test that
> uses certtool --verify-chain, and the self-test assumes that the last
> certificate is actually verified against its own public key...  so
> short-cutting the validation of trust anchors changed the semantics of
> one public interface.  Sigh.  So I have reverted my patch.
> 
> Simon Josefsson <simon at josefsson.org> writes:
> 
>> I believe that is wrong: with your patch it will fail when the CA is
>> self-signed using RSA-MD2.
> There aren't many of those around, so I think we can leave it as a
> documented bug that self-signed RSA-MD2 certificate cannot be used as a
> trust anchor.  One might see that as a feature, even. ;)
> I've aligned the self-tests with Nikos' approach.

What I don't understand is why it fails with my approach. Since I remove
the trusted certificate from the chain it shouldn't be an issue. For
example this issue does not occur any more with
hbci-pintan-rp.s-hbci.de. On which cases did you notice that?

regards,
Nikos




From davefx at gmail.com  Wed Dec 10 19:12:31 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Wed, 10 Dec 2008 19:12:31 +0100
Subject: Patch updated: New function gnutls_x509_crq_get_key_id
Message-ID: <f43cca2f0812101012h2137f4b1k182ae5a186eef4f6@mail.gmail.com>

Hi all.

I have already received the PDF document confirming that FSF got my
copyright assignment.

So I here send you again the patch for the new
gnutls_x509_crq_get_key_id, now updated to gnutls-2.7.3.

Thanks a lot.


---------- Forwarded message ----------
From: David Mar?n Carre?o <davefx at gmail.com>
Date: 2008/11/9
Subject: New function gnutls_x509_crq_get_key_id
To: GnuTLS development list <gnutls-devel at gnu.org>


Hi all.

Here I attach a patch adding a new function for getting the key_id
from a certificate signing request, so you can test if a given private
key corresponds to a given CSR.

It's based closely to the gnutls_x509_crt_get_key_id function.

Please, revise it and, if seems ok, add to the repository.

Thanks a lot.

--
David Mar?n Carre?o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-gnutls-2.7.3
Type: application/octet-stream
Size: 4959 bytes
Desc: not available
URL: </pipermail/attachments/20081210/2d072b68/attachment.obj>

From simon at josefsson.org  Thu Dec 11 08:25:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Dec 2008 08:25:14 +0100
Subject: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
References: <20081203071342.13532.21316.reportbug@hal>
	<20081203181956.GA3376@downhill.g.la> <4937817E.8070500@gnutls.org>
	<87prk8e2qh.fsf@mocca.josefsson.org> <49397A6C.4030709@gnutls.org>
	<87ej0gfdew.fsf@mocca.josefsson.org>
	<87skowdrsd.fsf@mocca.josefsson.org> <493FF65C.5040603@gnutls.org>
Message-ID: <87abb3yy05.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>> My approach introduced a problem with the pkcs1-padding self-test that
>> uses certtool --verify-chain, and the self-test assumes that the last
>> certificate is actually verified against its own public key...  so
>> short-cutting the validation of trust anchors changed the semantics of
>> one public interface.  Sigh.  So I have reverted my patch.
>> 
>> Simon Josefsson <simon at josefsson.org> writes:
>> 
>>> I believe that is wrong: with your patch it will fail when the CA is
>>> self-signed using RSA-MD2.
>> There aren't many of those around, so I think we can leave it as a
>> documented bug that self-signed RSA-MD2 certificate cannot be used as a
>> trust anchor.  One might see that as a feature, even. ;)
>> I've aligned the self-tests with Nikos' approach.
>
> What I don't understand is why it fails with my approach. Since I remove
> the trusted certificate from the chain it shouldn't be an issue.

Your approach only removes a CA cert if there are more certs in the
chain.  If there is only one cert in the chain, it will not be removed
(or there is a crash) and the code later on will call
_gnutls_verify_certificate2 on the CA cert, and that function will
extract the public key and check the signature in the cert.  This will
break if it is signed using an unsupported algorithm (e.g., RSA-MD2).

My approach does not modify the chain before validation, but changes
_gnutls_verify_certificate2 so that it detects when it has a trusted
self-signed cert and short-cuts further validation tests.

I think we should revisit this code sometime, now the code can reject
trusted CA certs when the chain is length 1, which is slightly wrong
(but doesn't lead to false positives).  We also have other requests to
support intermediary trusted anchors.  The code is also somewhat
difficult to read...

What is good now is that we have self-tests of some common chains in
tests/chainverify.c.  When we run into problems we can add new chains to
that test so we don't run into regressions.  There is also the PKITS
test vectors, but I recall license problems with them.

> For example this issue does not occur any more with
> hbci-pintan-rp.s-hbci.de. On which cases did you notice that?

That chain has a length of 3, so the self-signed root is removed, and
the problem isn't triggered.

/Simon





From simon at josefsson.org  Thu Dec 11 08:35:00 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Dec 2008 08:35:00 +0100
Subject: Patch updated: New function gnutls_x509_crq_get_key_id
References: <f43cca2f0812101012h2137f4b1k182ae5a186eef4f6@mail.gmail.com>
Message-ID: <874p1byxjv.fsf@mocca.josefsson.org>

"David Mar?n Carre?o" <davefx at gmail.com> writes:

> Hi all.
>
> I have already received the PDF document confirming that FSF got my
> copyright assignment.
>
> So I here send you again the patch for the new
> gnutls_x509_crq_get_key_id, now updated to gnutls-2.7.3.

Thank you for your patience.  I have committed it:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e311252bf0dd32fb2ca52e327763ae856e54e3f7

Do you have time to write a self-test for it?  You need to create a
dummy CRQ and call your new function on it, and test that the
fingerprint is correct.

/Simon





From simon at josefsson.org  Thu Dec 11 08:37:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Dec 2008 08:37:14 +0100
Subject: Patch updated: New function gnutls_x509_crq_get_key_id
References: <f43cca2f0812101012h2137f4b1k182ae5a186eef4f6@mail.gmail.com>
Message-ID: <87wse7xivp.fsf@mocca.josefsson.org>

"David Mar?n Carre?o" <davefx at gmail.com> writes:

> +  if (pk == GNUTLS_PK_RSA || pk == GNUTLS_PK_DSA)
> +    {
> +      /* This is for compatibility with what GnuTLS has printed for
> +         RSA/DSA before the code below was added.  The code below is
> +         applicable to all types, and it would probably be a better
> +         idea to use it for RSA/DSA too, but doing so would break
> +         backwards compatibility.  */
> +      return rsadsa_crq_get_key_id (crq, pk, output_data, output_data_size);
> +    }

Is there a particular reason you need this?  The function you copied
this code from needed it for backwards compatibility reasons, but there
are no such considerations for a new function.

I would consider removing the code quoted above, and the entire
rsadsa_crq_get_key_id function.  What do you think?

Thanks,
/Simon





From simon at josefsson.org  Thu Dec 11 09:02:37 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Dec 2008 09:02:37 +0100
Subject: Patch updated: New function gnutls_x509_crq_get_key_id
References: <f43cca2f0812101012h2137f4b1k182ae5a186eef4f6@mail.gmail.com>
	<87wse7xivp.fsf@mocca.josefsson.org>
Message-ID: <87oczjxhpe.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> "David Mar?n Carre?o" <davefx at gmail.com> writes:
>
>> +  if (pk == GNUTLS_PK_RSA || pk == GNUTLS_PK_DSA)
>> +    {
>> +      /* This is for compatibility with what GnuTLS has printed for
>> +         RSA/DSA before the code below was added.  The code below is
>> +         applicable to all types, and it would probably be a better
>> +         idea to use it for RSA/DSA too, but doing so would break
>> +         backwards compatibility.  */
>> +      return rsadsa_crq_get_key_id (crq, pk, output_data, output_data_size);
>> +    }
>
> Is there a particular reason you need this?  The function you copied
> this code from needed it for backwards compatibility reasons, but there
> are no such considerations for a new function.
>
> I would consider removing the code quoted above, and the entire
> rsadsa_crq_get_key_id function.  What do you think?

Never mind, that would make the key id for a certificate request be
different from the key id for the certificate with the same public key,
which seems like a bad idea...

Btw, I've made 'certtool --crq-info' print the public key id using your
new function.

/Simon





From davefx at gmail.com  Thu Dec 11 14:18:40 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Thu, 11 Dec 2008 14:18:40 +0100
Subject: Patch updated: New function gnutls_x509_crq_get_key_id
In-Reply-To: <874p1byxjv.fsf@mocca.josefsson.org>
References: <f43cca2f0812101012h2137f4b1k182ae5a186eef4f6@mail.gmail.com>
	<874p1byxjv.fsf@mocca.josefsson.org>
Message-ID: <f43cca2f0812110518v22cabeev9f9b91637e96a0ed@mail.gmail.com>

2008/12/11 Simon Josefsson <simon at josefsson.org>:
> "David Mar?n Carre?o" <davefx at gmail.com> writes:
>
>> Hi all.
>>
>> I have already received the PDF document confirming that FSF got my
>> copyright assignment.
>>
>> So I here send you again the patch for the new
>> gnutls_x509_crq_get_key_id, now updated to gnutls-2.7.3.
>
> Thank you for your patience.  I have committed it:
>
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e311252bf0dd32fb2ca52e327763ae856e54e3f7
>
> Do you have time to write a self-test for it?  You need to create a
> dummy CRQ and call your new function on it, and test that the
> fingerprint is correct.
>

OK. Here is the self-test.

Thank you, again.


-- 
David Mar?n Carre?o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crq_key_id.c
Type: text/x-csrc
Size: 3898 bytes
Desc: not available
URL: </pipermail/attachments/20081211/485569f1/attachment.c>

From simon at josefsson.org  Fri Dec 12 12:34:24 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 12 Dec 2008 12:34:24 +0100
Subject: Patch updated: New function gnutls_x509_crq_get_key_id
In-Reply-To: <f43cca2f0812110518v22cabeev9f9b91637e96a0ed@mail.gmail.com>
	("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Thu, 11 Dec
	2008 14:18:40 +0100")
References: <f43cca2f0812101012h2137f4b1k182ae5a186eef4f6@mail.gmail.com>
	<874p1byxjv.fsf@mocca.josefsson.org>
	<f43cca2f0812110518v22cabeev9f9b91637e96a0ed@mail.gmail.com>
Message-ID: <87ej0dzkxr.fsf@mocca.josefsson.org>

"David Mar?n Carre?o" <davefx at gmail.com> writes:

> OK. Here is the self-test.
>
> Thank you, again.

Pushed.

Thanks,
Simon




From simon at josefsson.org  Fri Dec 12 20:51:00 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 12 Dec 2008 20:51:00 +0100
Subject: GnuTLS 2.6.3
Message-ID: <87wse5w4t7.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.6.3.

GnuTLS is a modern C library that implement 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.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/

What's New
==========

Version 2.6.3 is a maintenance release on our stable branch.

** gnutls: Fix chain verification for chains that ends with RSA-MD2 CAs.
Reported by Michael Kiefer <Michael-Kiefer at web.de> in
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507633> forwarded by
Andreas Metzler <ametzler at downhill.at.eu.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3309>.

** gnutls: Fix memory leak in PSK authentication.
Reported by Michael Weiser <michael at weiser.dinsnail.net> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1465>.

** certtool: Move gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0) call earlier.
It needs to be invoked before libgcrypt is initialized.

** gnutls-cli: Return non-zero exit code on error conditions.

** gnutls-cli: Corrected bug which caused a rehandshake request to be ignored.

** 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
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (4.9MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.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.6.3.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: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-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:

f9b6a1d6135ef0a57a5cdd9fcb3e82bc62a27dcd  gnutls-2.6.3.tar.bz2

8b9ab4067b8d761ff0362635f6f47be4595a8c86dbed069f37d37005  gnutls-2.6.3.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

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 uses
libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.3.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.6.3.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.6.3.exe.sig

The checksum values for SHA-1 and SHA-224 are:

a1623f4485deb3324e1bb35cd348cfdb4af32e37  gnutls-2.6.3.exe

3017d1979bd1520e522582a7f2327340594eb5100438e504d2c3b53b  gnutls-2.6.3.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.6.3-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

4e5dbacd879b6ee6909681acd7080715aa50b02b  mingw32-gnutls_2.6.3-1_all.deb

821abf40661bda63cc529da2d08a24067f0af4e808dc465244395b6d  mingw32-gnutls_2.6.3-1_all.deb

Internationalization
====================

GnuTLS messages have been translated into 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, 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: </pipermail/attachments/20081212/5f07d77d/attachment.pgp>

From sdl.web at gmail.com  Sun Dec 14 13:01:50 2008
From: sdl.web at gmail.com (Leo)
Date: Sun, 14 Dec 2008 12:01:50 +0000
Subject: GnuTLS 2.6.3
In-Reply-To: <87wse5w4t7.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 12 Dec 2008 20:51:00 +0100")
References: <87wse5w4t7.fsf@mocca.josefsson.org>
Message-ID: <xbai63lnm0cx.fsf@cam.ac.uk>

Hi Simon,

[Please keep me CC'd]

Thank you for the new release which is the version I try to use with
smtpmail in Emacs built from CVS 2008-12-14 in windows xp.

However, I have no success using it with smtpmail. I am getting (error
"Sending failed; SMTP protocol error") because smtpmail-via-smtp returns
nil. The SMTP session log shows that the response from smtp server ends
with *two* ^M causing the following code snippet in smtpmail-via-smtp to
fail.

(memq (if (consp name) (car name) name)
      '(verb xvrb 8bitmime onex xone
             expn size dsn
             etrn
             enhancedstatuscodes
             help
             xusr
             auth=login
             auth starttls))

The SMTP session log is as follows:

220 ppsw-6.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587)
ESMTP Exim 4.70+ppsw+0 Sun, 14 Dec 2008 11:42:02 +0000^M

Process SMTP killed
EHLO CORNWALL^M
250-ppsw-6.cs8i.cam.ac.uk Hello we204.uk.cam.ac.uk [131.111.123.132]^M^M
250-SIZE 52428800^M^M
250-PIPELINING^M^M
250-STARTTLS^M^M
250 HELP^M^M
MAIL FROM:<we204 at cam.ac.uk> SIZE=446^M
250 OK^M^M
RCPT TO:<we204 at cam.ac.uk>^M
550-No SMTP service for unauthenticated users;^M^M
550 See http://www.cam.ac.uk/cs/email/muasettings.html^M^M
QUIT^M
221 ppsw-6.csi.cam.ac.uk closing connection^M^M

Thanks,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.




From gnome at flowerday.cx  Thu Dec 18 14:00:40 2008
From: gnome at flowerday.cx (Crispin Flowerday)
Date: Thu, 18 Dec 2008 13:00:40 +0000
Subject: TLS 1.2 PRF incorrect
Message-ID: <1229605240.15599.63.camel@clio.cam.zeus.com>

Hi,

I have recently been looking at TLS 1.2 support, which gnutls claims to
implement. However the PRF is wrong (gnutls_state.c::_gnutls_PRF()):

  if (ver >= GNUTLS_TLS1_2)
    {
      result =
     _gnutls_P_hash (GNUTLS_MAC_SHA1, secret, secret_size,
               s_seed, s_seed_size, total_bytes, ret);

   ...

Note the use of SHA1. RFC 5246, section 5 says:

"In this section, we define one PRF, based on HMAC.  This PRF with the
SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document when
TLS 1.2 is negotiated."

Appendix A.6 (Security Parameters) also clearly shows that the
PRFAlgorithm is sha-256.

I assume this is a hang-over from when TLS 1.2 was still draft and the
PRF was using sha-1. I haven't been able to investigate whether there
are other implementation errors against the RFC.

Regards,

Crispin





From simon at josefsson.org  Fri Dec 19 12:13:05 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 19 Dec 2008 12:13:05 +0100
Subject: TLS 1.2 PRF incorrect
In-Reply-To: <1229605240.15599.63.camel@clio.cam.zeus.com> (Crispin
	Flowerday's message of "Thu, 18 Dec 2008 13:00:40 +0000")
References: <1229605240.15599.63.camel@clio.cam.zeus.com>
Message-ID: <87r644bepq.fsf@mocca.josefsson.org>

Crispin Flowerday <gnome at flowerday.cx> writes:

> Hi,
>
> I have recently been looking at TLS 1.2 support, which gnutls claims to
> implement. However the PRF is wrong (gnutls_state.c::_gnutls_PRF()):
>
>   if (ver >= GNUTLS_TLS1_2)
>     {
>       result =
>      _gnutls_P_hash (GNUTLS_MAC_SHA1, secret, secret_size,
>                s_seed, s_seed_size, total_bytes, ret);
>
>    ...
>
> Note the use of SHA1. RFC 5246, section 5 says:
>
> "In this section, we define one PRF, based on HMAC.  This PRF with the
> SHA-256 hash function is used for all cipher suites defined in this
> document and in TLS documents published prior to this document when
> TLS 1.2 is negotiated."
>
> Appendix A.6 (Security Parameters) also clearly shows that the
> PRFAlgorithm is sha-256.
>
> I assume this is a hang-over from when TLS 1.2 was still draft and the
> PRF was using sha-1. I haven't been able to investigate whether there
> are other implementation errors against the RFC.

Indeed, the TLS 1.2 support in GnuTLS is against an earlier draft.  I
hope we can bring this up to the RFC before the GnuTLS 2.8 release.
Help wanted!  It should be much easier to finish this now when there are
multiple TLS 1.2 implementations around, compared to before when there
were none.  Connect it to a known working TLS 1.2 implementation and
debug and fix each failure until it works...

/Simon




From dkg at fifthhorseman.net  Wed Dec 31 00:14:16 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 30 Dec 2008 18:14:16 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli,serv}
Message-ID: <495AAB48.3020300@fifthhorseman.net>

Hi folks--

In light of the recent demonstration of an attack against
X.509 PKI  using weaknesses in MD5 [0], i'm quite happy to
see that you must explicitly enable the use of MD5 for
certificate validation in gnutls for over 3 years
(from the 2005-11-07 NEWS entry):

- Due to cryptographic advances, verifying untrusted X.509
  certificates signed with RSA-MD2 or RSA-MD5 will now fail with a
  GNUTLS_CERT_INSECURE_ALGORITHM verification output.  For
  applications that must remain interoperable, you can use the
  GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 or GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5
  flags when verifying certificates.  Naturally, this is not
  recommended default behaviour for applications.  To enable the
  broken algorithms, call gnutls_certificate_set_verify_flags with the
  proper flag, to change the verification mode used by
  gnutls_certificate_verify_peers2.

However, gnutls-cli seems to blithely accept certificates that *are*
signed with an md5 hash.  You can see this from a debian system with:

echo | gnutls-cli --print-cert --x509cafile /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem support.mayfirst.org | certtool -i

This seems to be the case with both 2.4.2-4 and 2.6.3-1, afaict, 
but i haven't tested with 2.7.x. 

Are there plans to change this?

	--dkg

[0] http://www.win.tue.nl/hashclash/rogue-ca/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20081230/a6f55a45/attachment.pgp>

From davefx at gmail.com  Wed Dec 31 02:13:10 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Wed, 31 Dec 2008 02:13:10 +0100
Subject: Valid hash algorithms for X.509 certificates
Message-ID: <f43cca2f0812301713o789a5410va5ede420a2590827@mail.gmail.com>

Related with the MD5 issue, if I am not wrong, currently the only
interoperable hash algorithm for use with X.509 algorithms is SHA-1.

However, in the document [0] it is said that SHA-1 will probably
follow the same fate in a not very long time.

SHA-2 is currently allowed in standard X.509 certificates according to
RFC 4055, but only if RSASSA-PSS is used (at least, I understand it
that way).
Also, a new document "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA"[1] is under
development, that includes SHA-2 hashing only when the certificate
uses DSA or ECDSA...

Does anyone know if the IETF is preparing a revision or update to RFC
3279 for deprecating (officially) MD2 and MD5 and including SHA-2 (or
other algorithms) as a proposed "standard" for all kinds of public
keys?

[0] http://www.win.tue.nl/hashclash/rogue-ca/
[1] http://tools.ietf.org/html/draft-ietf-pkix-sha2-dsa-ecdsa-05


--
David Mar?n Carre?o