From jas at extundo.com  Fri Sep  8 12:12:40 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 08 Sep 2006 12:12:40 +0200
Subject: [gnutls-dev] Bleichenbacher RSA signature forgery attack and GnuTLS
Message-ID: <87lkoupsyv.fsf@latte.josefsson.org>

You may have heard about a neat attack by Daniel Bleichenbacher,
described in:

http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html

I went over the GnuTLS code to review if it is vulnerable.

Signature verification starts in
lib/x509/verify.c:_pkcs1_rsa_verify_sig, which calls
lib/gnutls_pk.c:_gnutls_pkcs1_rsa_decrypt.  It contains code like
this:

  _gnutls_mpi_print (&edata[1], &esize, res);
...
  ret = GNUTLS_E_DECRYPTION_FAILED;
  switch (btype)
    {
    case 2:
      for (i = 2; i < esize; i++)
	{
	  if (edata[i] == 0)
	    {
	      ret = 0;
	      break;
	    }
	}
      break;
    case 1:
      for (i = 2; i < esize; i++)
	{
	  if (edata[i] == 0 && i > 2)
	    {
	      ret = 0;
	      break;
	    }
	  if (edata[i] != 0xff)
	    {
	      _gnutls_handshake_log ("PKCS #1 padding error");
	      ret = GNUTLS_E_PKCS1_WRONG_PAD;
	      break;
	    }
	}
      break;
    default:
      gnutls_assert ();
      gnutls_afree (edata);
      return GNUTLS_E_INTERNAL_ERROR;
    }
  i++;

  if (ret < 0)
    {
      gnutls_assert ();
      gnutls_afree (edata);
      return GNUTLS_E_DECRYPTION_FAILED;
    }

  if (_gnutls_sset_datum (plaintext, &edata[i], esize - i) < 0)
    {
      gnutls_assert ();
      gnutls_afree (edata);
      return GNUTLS_E_MEMORY_ERROR;
    }

Thus it will save rest of the blob after the FFFF..FFFF00 sequence in
"plaintext".

Now back in _pkcs1_rsa_verify_sig, it calls decode_ber_digest_info on
"plaintext", which in turns call libtasn1 (plaintext==info):

  result = asn1_der_decoding (&dinfo, info->data, info->size, NULL);
  if (result != ASN1_SUCCESS)
    {
      gnutls_assert ();
      asn1_delete_structure (&dinfo);
      return _gnutls_asn2err (result);
    }

The libtasn1 library checks that the decoded data is of the indicated
length, so if "info" contains the correct ASN.1 blob plus some
garbage, the entire decoding will fail.  See the end of
asn1_der_decoding for the check that catches this:

  if (counter != len)
    {
      asn1_delete_structure (element);
      return ASN1_DER_ERROR;
    }

Here, len is the "plaintext" length, and "counter" is the size of the
ASN.1 structure that it computed by parsing the data.

The conclusion is that GnuTLS isn't vulnerable to _exactly_ this
attack.

/Simon



From jas at extundo.com  Fri Sep  8 15:54:26 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 08 Sep 2006 15:54:26 +0200
Subject: [gnutls-dev] Re: Bleichenbacher RSA signature forgery attack and
	GnuTLS
In-Reply-To: <87lkoupsyv.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Fri\, 08 Sep 2006 12\:12\:40 +0200")
References: <87lkoupsyv.fsf@latte.josefsson.org>
Message-ID: <87wt8ewjjh.fsf@latte.josefsson.org>

Simon Josefsson <jas at extundo.com> writes:

> 	      _gnutls_handshake_log ("PKCS #1 padding error");
> 	      ret = GNUTLS_E_PKCS1_WRONG_PAD;

Werner Koch points out that this error message may result in a
vulnerability similar to Bleichenbacher's Crypto 98 attack.  It is not
exactly the same situation -- Bleichenbacher talks about PKCS#1
encryption (block type 1, uses random padding) where this deals with
PKCS#1 verification (block type 2, uses 0xFF padding) -- but at a
glance, it appears to have similar consequences, but differ in the
number of messages required to mount the attack.

The patch to solve this, which has been installed on GnuTLS 1.4.x and
GnuTLS 1.5.x branches, is included below.  I'll release 1.4.3 later
today.

/Simon

Index: gnutls_pk.c
===================================================================
RCS file: /cvs/gnutls/gnutls/lib/gnutls_pk.c,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -p -r1.82 -r1.83
--- gnutls_pk.c	15 Dec 2005 13:24:29 -0000	1.82
+++ gnutls_pk.c	8 Sep 2006 13:19:29 -0000	1.83
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation
+ * Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation
  *
  * Author: Nikos Mavroyanopoulos
  *
@@ -265,8 +265,13 @@ _gnutls_pkcs1_rsa_decrypt (gnutls_datum_
 
   _gnutls_mpi_release (&res);
 
-  /* EB = 00||BT||PS||00||D 
+  /* EB = 00||BT||PS||00||D
    * (use block type 'btype')
+   *
+   * From now on, return GNUTLS_E_DECRYPTION_FAILED on errors, to
+   * avoid attacks similar to the one described by Bleichenbacher in:
+   * "Chosen Ciphertext Attacks against Protocols Based on RSA
+   * Encryption Standard PKCS #1".
    */
 
 
@@ -303,8 +308,8 @@ _gnutls_pkcs1_rsa_decrypt (gnutls_datum_
 	    }
 	  if (edata[i] != 0xff)
 	    {
-	      _gnutls_handshake_log ("PKCS #1 padding error");
-	      ret = GNUTLS_E_PKCS1_WRONG_PAD;
+	      /* PKCS #1 padding error.  Don't use
+		 GNUTLS_E_PKCS1_WRONG_PAD here.  */
 	      break;
 	    }
 	}
@@ -312,7 +317,6 @@ _gnutls_pkcs1_rsa_decrypt (gnutls_datum_
     default:
       gnutls_assert ();
       gnutls_afree (edata);
-      return GNUTLS_E_INTERNAL_ERROR;
     }
   i++;
 



From jas at extundo.com  Fri Sep  8 17:26:01 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 08 Sep 2006 17:26:01 +0200
Subject: [gnutls-dev] GnuTLS 1.4.3
Message-ID: <87r6ymv0qe.fsf@latte.josefsson.org>

I am happy to announce GnuTLS 1.4.3, a security bugfix release on the
stable 1.4 branch.  This version is what we recommend for those who
need a stable version of GnuTLS.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy changes since 1.4.2:

** Fix PKCS#1 verification to avoid a variant of Bleichenbacher's
** Crypto 06 rump session attack.
In particular, we check that the digestAlgorithm.parameters field is
empty, to avoid that it can contain "garbage" that may be used to
alter the numeric properties of the signature.  See
<http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html> (which is
not exactly the same as the problem we fix here).  Reported by Yutaka
OIWA <y.oiwa at aist.go.jp>.

See GNUTLS-SA-2006-4 on http://www.gnutls.org/security.html for more
up to date information.

** Fix PKCS#1 decryption to avoid Bleichenbacher's Crypto 98 attack.
See <http://www.bell-labs.com/user/bleichen/papers/pkcs.ps.gz>.
Reported by Werner Koch <wk at gnupg.org>.

See GNUTLS-SA-2006-3 on http://www.gnutls.org/security.html for more
up to date information.

** Fix crash in gnutls_x509_crt_sign2 if passed a NULL issuer_key.

** API and ABI modifications:
No changes since last version.

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.

All manual formats are available from:
  http://www.gnutls.org/manual/

Direct link to the most popular formats:
  http://www.gnutls.org/manual/gnutls.html - HTML format
  http://www.gnutls.org/manual/gnutls.pdf  - PDF format
  http://www.gnutls.org/reference/ch01.html  - API Reference, GTK-DOC HTML

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>.

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

Here are the compressed sources (3.9MB):
  http://josefsson.org/gnutls/releases/gnutls-1.4.3.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.4.3.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2007-02-15]
uid                  Simon Josefsson <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

c4182c3804235d6f3eb2f3e59bb560f22370d4fc  gnutls-1.4.3.tar.bz2
b95c5be42a41050328c70a6bee0c5fe0df20274e  gnutls-1.4.3.tar.bz2.sig

7cd58744ba1a4628f75f2c9dda2d6af4fcbda28ba155e6afead3035e  gnutls-1.4.3.tar.bz2
b84e8452859d3c98575cd5a5a1f6d161dc4c4f63bc7803a4626425ef  gnutls-1.4.3.tar.bz2.sig

Enjoy,
Nikos and 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/20060908/098cfa11/attachment.pgp>

From jas at extundo.com  Fri Sep  8 17:44:13 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 08 Sep 2006 17:44:13 +0200
Subject: [gnutls-dev] Variant of Bleichenbacher's crypto 06 rump session
	attack
Message-ID: <87fyf2uzw2.fsf@latte.josefsson.org>

The GNUTLS-SA-2006-4 security problem (fixed in 1.4.3) is a variant of
Bleichenbacher's latest attack:

http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html

The difference is that it uses the digestAlgorithm.parameters field to
store "garbage" instead of after the ASN.1 blob.  The optional
parameters field is not used for MD5/SHA1, but instead of verifying
that the field is not present, GnuTLS just ignored it.  Therefor, it
can be used to store garbage data in.

This problem was reported to us by Yutaka Oiwa, Kazukuni Kobara,
Hajime Watanabe and hopefully their original report with more
background will be available soon.

The patch that fixes this is for lib/x509/verify.c, see below.

This has been installed on the GnuTLS 1.5 branch, but I don't intend
to release 1.5.1 soon.  Try the nightly snapshots, or 1.4.3 instead.

/Simon

Update of /cvs/gnutls/gnutls/lib/x509
In directory trithemius:/tmp/cvs-serv3577

Modified Files:
      Tag: gnutls_1_4_x
	verify.c 
Log Message:
Make sure the digestAlgorithm.parameters field is empty, which it has
to be for the hashes we support.  Otherwise, the field can encode
"garbage" that might be used to make the signature be a perfect cube,
similar (but not identical) to Bleichenbacher's Crypto 06 rump session
attack.

--- /cvs/gnutls/gnutls/lib/x509/verify.c	2005/11/07 23:28:02	1.52
+++ /cvs/gnutls/gnutls/lib/x509/verify.c	2006/09/08 13:38:55	1.52.2.1
 <at>  <at>  -1,5 +1,5  <at>  <at> 
 /*
- * Copyright (C) 2003, 2004, 2005 Free Software Foundation
+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation
  *
  * Author: Nikos Mavroyanopoulos
  *
 <at>  <at>  -505,6 +505,15  <at>  <at> 
       return GNUTLS_E_UNKNOWN_HASH_ALGORITHM;
     }

+  len = sizeof (str) - 1;
+  result = asn1_read_value (dinfo, "digestAlgorithm.parameters", NULL, &len);
+  if (result != ASN1_ELEMENT_NOT_FOUND)
+    {
+      gnutls_assert ();
+      asn1_delete_structure (&dinfo);
+      return _gnutls_asn2err (result);
+    }
+
   result = asn1_read_value (dinfo, "digest", digest, digest_size);
   if (result != ASN1_SUCCESS)
     {



From ametzler at downhill.at.eu.org  Sat Sep  9 15:04:57 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 9 Sep 2006 15:04:57 +0200
Subject: [gnutls-dev] Variant of Bleichenbacher's crypto 06 rump session
	attack
In-Reply-To: <87fyf2uzw2.fsf@latte.josefsson.org>
References: <87fyf2uzw2.fsf@latte.josefsson.org>
Message-ID: <20060909130457.GA21584@downhill.g.la>

On 2006-09-08 Simon Josefsson <jas at extundo.com> wrote:
[...]
> The patch that fixes this is for lib/x509/verify.c, see below.

[...]
> --- /cvs/gnutls/gnutls/lib/x509/verify.c	2005/11/07 23:28:02	1.52
> +++ /cvs/gnutls/gnutls/lib/x509/verify.c	2006/09/08 13:38:55	1.52.2.1
>  <at>  <at>  -1,5 +1,5  <at>  <at> 
>  /*
> - * Copyright (C) 2003, 2004, 2005 Free Software Foundation
> + * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation
>   *
>   * Author: Nikos Mavroyanopoulos
>   *
>  <at>  <at>  -505,6 +505,15  <at>  <at> 
>        return GNUTLS_E_UNKNOWN_HASH_ALGORITHM;
>      }

> +  len = sizeof (str) - 1;
> +  result = asn1_read_value (dinfo, "digestAlgorithm.parameters", NULL, &len);
> +  if (result != ASN1_ELEMENT_NOT_FOUND)
> +    {
> +      gnutls_assert ();
> +      asn1_delete_structure (&dinfo);
> +      return _gnutls_asn2err (result);
> +    }
> +
>    result = asn1_read_value (dinfo, "digest", digest, digest_size);
>    if (result != ASN1_SUCCESS)
>      {

Hello,
This seems to cause breakage with mutt, muttng and OpenLDAP.
http://bugs.debian.org/386643
http://bugs.debian.org/386680

The asn1_read_value() segfaults under certain conditions (libtasn1-3
0.3.5).

I have been able to reproduce the segfault using mutt 1.5.13 and
gnutls 1.0.16 + the patch quoted above on imaps:m26s25.vlinux.de, but
have been unable to find the reason.

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From jas at extundo.com  Mon Sep 11 11:17:42 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 11 Sep 2006 11:17:42 +0200
Subject: [gnutls-dev] Re: Variant of Bleichenbacher's crypto 06 rump session
	attack
In-Reply-To: <20060909130457.GA21584@downhill.g.la> (Andreas Metzler's message
	of "Sat\, 9 Sep 2006 15\:04\:57 +0200")
References: <87fyf2uzw2.fsf@latte.josefsson.org>
	<20060909130457.GA21584@downhill.g.la>
Message-ID: <87bqpmwymh.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2006-09-08 Simon Josefsson <jas at extundo.com> wrote:
> [...]
>> The patch that fixes this is for lib/x509/verify.c, see below.
>
> [...]
>> --- /cvs/gnutls/gnutls/lib/x509/verify.c	2005/11/07 23:28:02	1.52
>> +++ /cvs/gnutls/gnutls/lib/x509/verify.c	2006/09/08 13:38:55	1.52.2.1
>>  <at>  <at>  -1,5 +1,5  <at>  <at> 
>>  /*
>> - * Copyright (C) 2003, 2004, 2005 Free Software Foundation
>> + * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation
>>   *
>>   * Author: Nikos Mavroyanopoulos
>>   *
>>  <at>  <at>  -505,6 +505,15  <at>  <at> 
>>        return GNUTLS_E_UNKNOWN_HASH_ALGORITHM;
>>      }
>
>> +  len = sizeof (str) - 1;
>> +  result = asn1_read_value (dinfo, "digestAlgorithm.parameters", NULL, &len);
>> +  if (result != ASN1_ELEMENT_NOT_FOUND)
>> +    {
>> +      gnutls_assert ();
>> +      asn1_delete_structure (&dinfo);
>> +      return _gnutls_asn2err (result);
>> +    }
>> +
>>    result = asn1_read_value (dinfo, "digest", digest, digest_size);
>>    if (result != ASN1_SUCCESS)
>>      {
>
> Hello,
> This seems to cause breakage with mutt, muttng and OpenLDAP.
> http://bugs.debian.org/386643
> http://bugs.debian.org/386680
>
> The asn1_read_value() segfaults under certain conditions (libtasn1-3
> 0.3.5).
>
> I have been able to reproduce the segfault using mutt 1.5.13 and
> gnutls 1.0.16 + the patch quoted above on imaps:m26s25.vlinux.de, but
> have been unable to find the reason.

Can you reproduce it in gnutls 1.4.x?  Could you debug this and find
out exactly what instruction is crashing?  Perhaps your gnutls 1.0.16
was built with the internal (and _old_) version of libtasn1?

If you change the line into:

  result = asn1_read_value (dinfo, "digestAlgorithm.parameters", digest, &len);

does it work?

It seems weird that this works with gnutls 1.4 but not gnutls 1.0 if
the crash is in libtasn1.

/Simon



From jas at extundo.com  Mon Sep 11 15:14:48 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 11 Sep 2006 15:14:48 +0200
Subject: [gnutls-dev] Re: Bleichenbacher RSA signature forgery attack and
	GnuTLS
In-Reply-To: <87wt8ewjjh.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Fri\, 08 Sep 2006 15\:54\:26 +0200")
References: <87lkoupsyv.fsf@latte.josefsson.org>
	<87wt8ewjjh.fsf@latte.josefsson.org>
Message-ID: <87k64av92v.fsf@latte.josefsson.org>

Simon Josefsson <jas at extundo.com> writes:

> Simon Josefsson <jas at extundo.com> writes:
>
>> 	      _gnutls_handshake_log ("PKCS #1 padding error");
>> 	      ret = GNUTLS_E_PKCS1_WRONG_PAD;
>
> Werner Koch points out that this error message may result in a
> vulnerability similar to Bleichenbacher's Crypto 98 attack.  It is not
> exactly the same situation -- Bleichenbacher talks about PKCS#1
> encryption (block type 1, uses random padding) where this deals with
> PKCS#1 verification (block type 2, uses 0xFF padding) -- but at a
> glance, it appears to have similar consequences, but differ in the
> number of messages required to mount the attack.

Nikos points out that we have already protected against that attack,
for TLS sessions, in auth_rsa.c:

  ret = _gnutls_pkcs1_rsa_decrypt (&plaintext, &ciphertext, params, params_len, 2);	/* btype==2 */

  if (ret < 0 || plaintext.size != TLS_MASTER_SIZE)
    {
      /* In case decryption fails then don't inform
       * the peer. Just use a random key. (in order to avoid
       * attack against pkcs-1 formating).
       */
      gnutls_assert ();
      _gnutls_x509_log ("auth_rsa: Possible PKCS #1 format attack\n");
      randomize_key = 1;
    }
  else
    {
      /* If the secret was properly formatted, then
       * check the version number.
       */
      if (_gnutls_get_adv_version_major (session) != plaintext.data[0]
	  || _gnutls_get_adv_version_minor (session) != plaintext.data[1])
	{
	  /* No error is returned here, if the version number check
	   * fails. We proceed normally.
	   * That is to defend against the attack described in the paper
	   * "Attacking RSA-based sessions in SSL/TLS" by Vlastimil Klima,
	   * Ondej Pokorny and Tomas Rosa.
	   */
	  gnutls_assert ();
	  _gnutls_x509_log
	    ("auth_rsa: Possible PKCS #1 version check format attack\n");
	}
    }

The GNUTLS-SA-2006-3 security advisory thus was a false alarm, but I'm
keeping the information on:

http://www.gnu.org/software/gnutls/security.html

I'll add a link to this post, though.

There should be no harm in applying the patch, though.

Note 1: If someone is worried about the log file being used as the
oracle here, don't be: the above log statements are only executed if
in debug mode, and this isn't recommended nor typical behaviour.

Note 2: I'd be interested in if someone could establish whether it is
possible to extend this oracle attack from error codes to different
timings.  In other words, if it takes different amount of time to
verify a signature depending on the padding error.

/Simon

>
> /Simon
>
> Index: gnutls_pk.c
> ===================================================================
> RCS file: /cvs/gnutls/gnutls/lib/gnutls_pk.c,v
> retrieving revision 1.82
> retrieving revision 1.83
> diff -u -p -r1.82 -r1.83
> --- gnutls_pk.c	15 Dec 2005 13:24:29 -0000	1.82
> +++ gnutls_pk.c	8 Sep 2006 13:19:29 -0000	1.83
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation
> + * Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation
>   *
>   * Author: Nikos Mavroyanopoulos
>   *
> @@ -265,8 +265,13 @@ _gnutls_pkcs1_rsa_decrypt (gnutls_datum_
>  
>    _gnutls_mpi_release (&res);
>  
> -  /* EB = 00||BT||PS||00||D 
> +  /* EB = 00||BT||PS||00||D
>     * (use block type 'btype')
> +   *
> +   * From now on, return GNUTLS_E_DECRYPTION_FAILED on errors, to
> +   * avoid attacks similar to the one described by Bleichenbacher in:
> +   * "Chosen Ciphertext Attacks against Protocols Based on RSA
> +   * Encryption Standard PKCS #1".
>     */
>  
>  
> @@ -303,8 +308,8 @@ _gnutls_pkcs1_rsa_decrypt (gnutls_datum_
>  	    }
>  	  if (edata[i] != 0xff)
>  	    {
> -	      _gnutls_handshake_log ("PKCS #1 padding error");
> -	      ret = GNUTLS_E_PKCS1_WRONG_PAD;
> +	      /* PKCS #1 padding error.  Don't use
> +		 GNUTLS_E_PKCS1_WRONG_PAD here.  */
>  	      break;
>  	    }
>  	}
> @@ -312,7 +317,6 @@ _gnutls_pkcs1_rsa_decrypt (gnutls_datum_
>      default:
>        gnutls_assert ();
>        gnutls_afree (edata);
> -      return GNUTLS_E_INTERNAL_ERROR;
>      }
>    i++;



From ametzler at downhill.at.eu.org  Mon Sep 11 11:43:57 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 11 Sep 2006 09:43:57 +0000 (UTC)
Subject: [gnutls-dev] Re: Variant of Bleichenbacher's crypto 06 rump
	session	attack
References: <87fyf2uzw2.fsf@latte.josefsson.org>
	<20060909130457.GA21584@downhill.g.la>
	<87bqpmwymh.fsf@latte.josefsson.org>
Message-ID: <loom.20060911T113540-28@post.gmane.org>

Simon Josefsson <jas <at> extundo.com> writes:
> Andreas Metzler <ametzler <at> downhill.at.eu.org> writes:
[...]
>> This seems to cause breakage with mutt, muttng and OpenLDAP.
>> http://bugs.debian.org/386643
>> http://bugs.debian.org/386680

>> The asn1_read_value() segfaults under certain conditions (libtasn1-3
>> 0.3.5).

>> I have been able to reproduce the segfault using mutt 1.5.13 and
>> gnutls 1.0.16 + the patch quoted above on imaps:m26s25.vlinux.de, but
>> have been unable to find the reason.
 
> Can you reproduce it in gnutls 1.4.x?

On my system I could not. (Perhaps because the gnutl14 using one is a chroot), 
others did experience the bug with it.

[...] 
> It seems weird that this works with gnutls 1.4 but not gnutls 1.0 if
> the crash is in libtasn1.

The bug definitely applies to 1.4, it is just that /I/ could not reproduce 
it. - Others could. "mutt -f imaps://m26s25.vlinux.de" should do the trick.

I cannot provide more info now, since I am at work without Linux access.

cu andreas





From ametzler at downhill.at.eu.org  Mon Sep 11 20:08:24 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 11 Sep 2006 20:08:24 +0200
Subject: [gnutls-dev] Re: Variant of Bleichenbacher's crypto 06 rump
	session attack
In-Reply-To: <87bqpmwymh.fsf@latte.josefsson.org>
References: <87fyf2uzw2.fsf@latte.josefsson.org>
	<20060909130457.GA21584@downhill.g.la>
	<87bqpmwymh.fsf@latte.josefsson.org>
Message-ID: <20060911180824.GA23429@downhill.g.la>

On 2006-09-11 Simon Josefsson <jas at extundo.com> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>> On 2006-09-08 Simon Josefsson <jas at extundo.com> wrote:
>> [...]
>>> The patch that fixes this is for lib/x509/verify.c, see below.
>>
>> [...]
>>> --- /cvs/gnutls/gnutls/lib/x509/verify.c	2005/11/07 23:28:02	1.52
>>> +++ /cvs/gnutls/gnutls/lib/x509/verify.c	2006/09/08 13:38:55	1.52.2.1
[...]
>>> +  len = sizeof (str) - 1;
>>> +  result = asn1_read_value (dinfo, "digestAlgorithm.parameters", NULL, &len);
[...]
>> The asn1_read_value() segfaults under certain conditions (libtasn1-3
>> 0.3.5).
>>
>> I have been able to reproduce the segfault
[...]

> Can you reproduce it in gnutls 1.4.x?

I have now been able to reproduce this after building gnutls13,
libgcrypt11 and mutt on my worksystem. (Still no idea why it did not
crash in my Debian/unstable chroot.)

> Could you debug this and find
> out exactly what instruction is crashing?

If I single step though it after
result = asn1_read_value (dinfo, "digestAlgorithm.parameters", NULL, &len)
strange things happen. - Once the function is entered the second
argument (digestAlgorithm.parameters) seems to be corrupted.

PUT_VALUE (value, value_size, node->value + len3, len2);
is the actual crashing command.

> Perhaps your gnutls 1.0.16
> was built with the internal (and _old_) version of libtasn1?

as noted above now I've reproduced it with gnutls 1.4.3 and its
included libtasn.

> If you change the line into:

>   result = asn1_read_value (dinfo, "digestAlgorithm.parameters", digest, &len);

> does it work?

Yes, this makes it unreproducible for me (with gnutls 1.4.3).

thanks, cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From jas at extundo.com  Tue Sep 12 15:42:10 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 12 Sep 2006 15:42:10 +0200
Subject: [gnutls-dev] Re: Variant of Bleichenbacher's crypto 06 rump session
	attack
In-Reply-To: <20060911180824.GA23429@downhill.g.la> (Andreas Metzler's message
	of "Mon\, 11 Sep 2006 20\:08\:24 +0200")
References: <87fyf2uzw2.fsf@latte.josefsson.org>
	<20060909130457.GA21584@downhill.g.la>
	<87bqpmwymh.fsf@latte.josefsson.org>
	<20060911180824.GA23429@downhill.g.la>
Message-ID: <87odtlcibx.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

>> Can you reproduce it in gnutls 1.4.x?
>
> I have now been able to reproduce this after building gnutls13,
> libgcrypt11 and mutt on my worksystem. (Still no idea why it did not
> crash in my Debian/unstable chroot.)

I've also been able to reproduce it.

>> Could you debug this and find
>> out exactly what instruction is crashing?
>
> If I single step though it after
> result = asn1_read_value (dinfo, "digestAlgorithm.parameters", NULL, &len)
> strange things happen. - Once the function is entered the second
> argument (digestAlgorithm.parameters) seems to be corrupted.
>
> PUT_VALUE (value, value_size, node->value + len3, len2);
> is the actual crashing command.

Right.  The call is incorrect, but I don't know why it doesn't always
crash.

>> If you change the line into:
>
>>   result = asn1_read_value (dinfo, "digestAlgorithm.parameters", digest, &len);
>
>> does it work?
>
> Yes, this makes it unreproducible for me (with gnutls 1.4.3).

It is the correct fix.

However, the patch in 1.4.3 to fix this was too restrictive -- the
patch doesn't permit the parameters field to be present but empty
(which is typically the case).  The consequence is that many OK
certificates are rejected.  I'll be releasing 1.4.4 shortly that fix
this.  There are self tests in the gnutls 1.5.x branch that trigger
the problem, which will help everyone to verify if their gnutls
suffers from a problem or not.

/Simon



From jas at extundo.com  Tue Sep 12 16:30:21 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 12 Sep 2006 16:30:21 +0200
Subject: [gnutls-dev] Re: Variant of Bleichenbacher's crypto 06 rump session
	attack
In-Reply-To: <87odtlcibx.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Tue\, 12 Sep 2006 15\:42\:10 +0200")
References: <87fyf2uzw2.fsf@latte.josefsson.org>
	<20060909130457.GA21584@downhill.g.la>
	<87bqpmwymh.fsf@latte.josefsson.org>
	<20060911180824.GA23429@downhill.g.la>
	<87odtlcibx.fsf@latte.josefsson.org>
Message-ID: <874pvdcg3m.fsf@latte.josefsson.org>

Simon Josefsson <jas at extundo.com> writes:

> However, the patch in 1.4.3 to fix this was too restrictive -- the
> patch doesn't permit the parameters field to be present but empty
> (which is typically the case).  The consequence is that many OK
> certificates are rejected.  I'll be releasing 1.4.4 shortly that fix
> this.  There are self tests in the gnutls 1.5.x branch that trigger
> the problem, which will help everyone to verify if their gnutls
> suffers from a problem or not.

For reference, the (hopefully!) final patch between GnuTLS 1.4.2 and
GnuTLS 1.4.4 which address this problem AND doesn't cause a crash or
incorrect verification rejections is as below.

It seems that I was too trigger happy to release 1.4.3, sorry about
that.

/Simon

Index: verify.c
===================================================================
RCS file: /cvs/gnutls/gnutls/lib/x509/verify.c,v
retrieving revision 1.52
retrieving revision 1.55
diff -u -p -r1.52 -r1.55
--- verify.c	7 Nov 2005 23:28:02 -0000	1.52
+++ verify.c	12 Sep 2006 13:11:23 -0000	1.55
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2003, 2004, 2005 Free Software Foundation
+ * Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation
  *
  * Author: Nikos Mavroyanopoulos
  *
@@ -505,6 +505,19 @@ decode_ber_digest_info (const gnutls_dat
       return GNUTLS_E_UNKNOWN_HASH_ALGORITHM;
     }
 
+  len = sizeof (str) - 1;
+  result = asn1_read_value (dinfo, "digestAlgorithm.parameters", str, &len);
+  /* To avoid permitting garbage in the parameters field, either the
+     parameters field is not present, or it contains 0x05 0x00. */
+  if (!(result == ASN1_ELEMENT_NOT_FOUND ||
+	(result == ASN1_SUCCESS && len == 2 &&
+	 str[0] == 0x05 && str[1] == 0x00)))
+    {
+      gnutls_assert ();
+      asn1_delete_structure (&dinfo);
+      return GNUTLS_E_ASN1_GENERIC_ERROR;
+    }
+
   result = asn1_read_value (dinfo, "digest", digest, digest_size);
   if (result != ASN1_SUCCESS)
     {



From jas at extundo.com  Tue Sep 12 16:35:42 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 12 Sep 2006 16:35:42 +0200
Subject: [gnutls-dev] GnuTLS 1.4.4
Message-ID: <87zmd5b1a9.fsf@latte.josefsson.org>

I am happy to announce GnuTLS 1.4.4, a bugfix release on the stable
1.4 branch.  This version is what we recommend for those who need a
stable version of GnuTLS.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy changes since 1.4.3:

** Relax the test that caught signatures that exploit the variant of
** Bleichenbacher's Crypto 06 rump session attack on our
** verification logic flaw.
In particular, we now permit the digestAlgorithm.parameters field to
be present but empty, whereas in 1.4.3 we actually checked that the
field was absent.

** Revert the removal of debug information for the GNUTLS-SA-2006-3 problem.
The messages are only printed in debug mode, which is not recommended
for normal use, and thus logging this situation cannot be abused as an
oracle in typical recommended situations.

Note that this release does not contain any security fixes compared to
1.4.3, however, it does fix a crash that was introduced by 1.4.3, and
it also fixes false negatives when verifying certificates.  Thus,
users are strongly encouraged to upgrade to this version.

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.

All manual formats are available from:
  http://www.gnutls.org/manual/

Direct link to the most popular formats:
  http://www.gnutls.org/manual/gnutls.html - HTML format
  http://www.gnutls.org/manual/gnutls.pdf  - PDF format
  http://www.gnutls.org/reference/ch01.html  - API Reference, GTK-DOC HTML

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>.

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

Here are the compressed sources (3.9MB):
  http://josefsson.org/gnutls/releases/gnutls-1.4.4.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.4.4.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2007-02-15]
uid                  Simon Josefsson <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

8f6ee112c8d93dd726e8e3d0e3fbf234f085a2cd  gnutls-1.4.4.tar.bz2
a72377bccf8d49421f7f5f4e0ff85b489ef4d8d1  gnutls-1.4.4.tar.bz2.sig

a357b06cecc3ed5b79d98a26c08bc0b4137aa90bb6453e10a5845681  gnutls-1.4.4.tar.bz2
9aad60797aa994fbac8fd0b8ec6127acfa0c01a75680a6520dc28fc1  gnutls-1.4.4.tar.bz2.sig

Enjoy,
Nikos and 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/20060912/7a3528a1/attachment.pgp>

From alangley at gmail.com  Mon Sep 18 08:22:21 2006
From: alangley at gmail.com (Adam Langley)
Date: Sun, 17 Sep 2006 23:22:21 -0700
Subject: [gnutls-dev] Typo in OpenPGP example server code
In-Reply-To: <396556a20609172313x7c890c7fyaa9fe40dd5006d09@mail.gmail.com>
References: <396556a20609172313x7c890c7fyaa9fe40dd5006d09@mail.gmail.com>
Message-ID: <396556a20609172322v174058aehb7a256456219956f@mail.gmail.com>

The OpenPGP example in the manual[1] seem to have a typo:

@@ -46,9 +45,6 @@
   return 0;
 }

-/* These are global */
-gnutls_certificate_credentials_t x509_cred;
-
 gnutls_session_t
 initialize_tls_session (void)
 {
@@ -61,7 +57,7 @@
    */
   gnutls_set_default_priority (session);

-  gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, x509_cred);
+  gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, cred);

   /* request client certificate if any.
    */

[1] http://www.gnu.org/software/gnutls/manual/gnutls.html.gz#Echo-Server-with-OpenPGP-authentication


Cheers

--
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       650-283-9641



From agl at imperialviolet.org  Mon Sep 18 08:13:24 2006
From: agl at imperialviolet.org (Adam Langley)
Date: Sun, 17 Sep 2006 23:13:24 -0700
Subject: [gnutls-dev] Typo in OpenPGP example server code
Message-ID: <396556a20609172313x7c890c7fyaa9fe40dd5006d09@mail.gmail.com>

The OpenPGP example in the manual[1] seem to have a typo:

@@ -46,9 +45,6 @@
   return 0;
 }

-/* These are global */
-gnutls_certificate_credentials_t x509_cred;
-
 gnutls_session_t
 initialize_tls_session (void)
 {
@@ -61,7 +57,7 @@
    */
   gnutls_set_default_priority (session);

-  gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, x509_cred);
+  gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, cred);

   /* request client certificate if any.
    */

[1] http://www.gnu.org/software/gnutls/manual/gnutls.html.gz#Echo-Server-with-OpenPGP-authentication


Cheers

-- 
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       650-283-9641



From alangley at gmail.com  Mon Sep 18 08:31:07 2006
From: alangley at gmail.com (Adam Langley)
Date: Sun, 17 Sep 2006 23:31:07 -0700
Subject: [gnutls-dev] OpenCDK indexing fails if a public key is at offset 0
Message-ID: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>

(from the opencdk sources included in gnutls-1.4.4:

keydb.c:208

*r_off is set to 0 and, at line, 223, if processing hasn't set this
not a non-zero number CDK_EOF is returned. However, if we are
searching for a key at offset 0, this returns CDK_EOF anyway.

I suggest setting *r_off to 0xffffffffu and testing != to this value
at 223. (I've made this patch locally and it's working fine for me. I
guess we have to hope noone has >4GB of key data.)


AGL

-- 
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       650-283-9641



From jas at extundo.com  Mon Sep 18 10:58:05 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 18 Sep 2006 10:58:05 +0200
Subject: [gnutls-dev] Re: Typo in OpenPGP example server code
In-Reply-To: <396556a20609172313x7c890c7fyaa9fe40dd5006d09@mail.gmail.com>
	(Adam Langley's message of "Sun\, 17 Sep 2006 23\:13\:24 -0700")
References: <396556a20609172313x7c890c7fyaa9fe40dd5006d09@mail.gmail.com>
Message-ID: <8764fltuua.fsf@latte.josefsson.org>

"Adam Langley" <agl at imperialviolet.org> writes:

> The OpenPGP example in the manual[1] seem to have a typo:
>
> @@ -46,9 +45,6 @@
>   return 0;
> }
>
> -/* These are global */
> -gnutls_certificate_credentials_t x509_cred;
> -
> gnutls_session_t
> initialize_tls_session (void)
> {
> @@ -61,7 +57,7 @@
>    */
>   gnutls_set_default_priority (session);
>
> -  gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, x509_cred);
> +  gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, cred);
>
>   /* request client certificate if any.
>    */
>
> [1] http://www.gnu.org/software/gnutls/manual/gnutls.html.gz#Echo-Server-with-OpenPGP-authentication

Thanks, I have installed this in CVS.  Btw, if you wish to send more
patches (always welcome), you'll have to assign the copyright to the
FSF.  I can send you the form privately, if you are interested.

/Simon



From jas at extundo.com  Mon Sep 18 11:18:05 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 18 Sep 2006 11:18:05 +0200
Subject: [gnutls-dev] Re: OpenCDK indexing fails if a public key is at
	offset 0
In-Reply-To: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>
	(Adam Langley's message of "Sun\, 17 Sep 2006 23\:31\:07 -0700")
References: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>
Message-ID: <87wt81sfci.fsf@latte.josefsson.org>

"Adam Langley" <alangley at gmail.com> writes:

> (from the opencdk sources included in gnutls-1.4.4:
>
> keydb.c:208
>
> *r_off is set to 0 and, at line, 223, if processing hasn't set this
> not a non-zero number CDK_EOF is returned. However, if we are
> searching for a key at offset 0, this returns CDK_EOF anyway.
>
> I suggest setting *r_off to 0xffffffffu and testing != to this value
> at 223. (I've made this patch locally and it's working fine for me. I
> guess we have to hope noone has >4GB of key data.)

Makes sense to me.  I believe I have fixed this in gnutls CVS trunk,
please check.

Thanks,
Simon



From steve at localtoast.org  Tue Sep 19 08:03:37 2006
From: steve at localtoast.org (Stephen Wrobleski)
Date: Tue, 19 Sep 2006 02:03:37 -0400
Subject: [gnutls-dev] Minor libtasn1 bug
Message-ID: <20060919060337.GA32096@trop.localtoast.org>

I've come across a relatively minor bug in libtasn1-0.3.5. In the following
snippet, I first find out how long of a buffer is necessary, allocate
exactly that size buffer, and then do the real coding.

{
  char *der, *err;
  int  der_len, ret;

  /* find out the size of the coding */
  der_len = 0;
  ret = asn1_der_coding(hashkey, "", NULL, &der_len, err);
  assert(ret == ASN1_MEM_ERROR);

  der = malloc(der_len);

  ret = asn1_der_coding(hashkey, "", der, &der_len, err);
  assert(ret == ASN1_SUCCESS);
}

The second asn1_der_coding() call fails, complaining about too short of a
buffer length. I've only seen this happen when I'm attempting to encode a
NULL type (it's also implicitly tagged, by the way). I've looked in the
source for 0.3.5, as well as the cvs version as of 18SEP2006, and believe
the problem to be the lines

if (max_len >= 0)
  der[counter++] = 0;

in the TYPE_NULL coding section of the function itself (in coding.c).
Specifically, every other section increments 'counter' regardless of whether
we write to the buffer or not. This section doesn't.

I'm running against the Debian binary package (0.3.5-2). As this problem is
pretty easy to work around (for now), I've resisted building from source. I
think this should be pretty easy to independently verify and fix. Please let
me know if more information happens to be required.


Thanks,
Steve



From jas at extundo.com  Tue Sep 19 12:27:13 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 19 Sep 2006 12:27:13 +0200
Subject: [gnutls-dev] Re: Minor libtasn1 bug
In-Reply-To: <20060919060337.GA32096@trop.localtoast.org> (Stephen Wrobleski's
	message of "Tue\, 19 Sep 2006 02\:03\:37 -0400")
References: <20060919060337.GA32096@trop.localtoast.org>
Message-ID: <87venkcfsu.fsf@latte.josefsson.org>

Stephen Wrobleski <steve at localtoast.org> writes:

> I've come across a relatively minor bug in libtasn1-0.3.5. In the following
> snippet, I first find out how long of a buffer is necessary, allocate
> exactly that size buffer, and then do the real coding.
>
> {
>   char *der, *err;
>   int  der_len, ret;
>
>   /* find out the size of the coding */
>   der_len = 0;
>   ret = asn1_der_coding(hashkey, "", NULL, &der_len, err);
>   assert(ret == ASN1_MEM_ERROR);
>
>   der = malloc(der_len);
>
>   ret = asn1_der_coding(hashkey, "", der, &der_len, err);
>   assert(ret == ASN1_SUCCESS);
> }
>
> The second asn1_der_coding() call fails, complaining about too short of a
> buffer length. I've only seen this happen when I'm attempting to encode a
> NULL type (it's also implicitly tagged, by the way). I've looked in the
> source for 0.3.5, as well as the cvs version as of 18SEP2006, and believe
> the problem to be the lines
>
> if (max_len >= 0)
>   der[counter++] = 0;
>
> in the TYPE_NULL coding section of the function itself (in coding.c).
> Specifically, every other section increments 'counter' regardless of whether
> we write to the buffer or not. This section doesn't.
>
> I'm running against the Debian binary package (0.3.5-2). As this problem is
> pretty easy to work around (for now), I've resisted building from source. I
> think this should be pretty easy to independently verify and fix. Please let
> me know if more information happens to be required.

Your analysis looks correct to me, and the code looks wrong.  I've
fixed this in CVS, for 0.3.7.

Thanks,
Simon



From agl at imperialviolet.org  Wed Sep 20 21:09:07 2006
From: agl at imperialviolet.org (Adam Langley)
Date: Wed, 20 Sep 2006 12:09:07 -0700
Subject: [gnutls-dev] Re: OpenCDK indexing fails if a public key is at
	offset 0
In-Reply-To: <87wt81sfci.fsf@latte.josefsson.org>
References: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>
	<87wt81sfci.fsf@latte.josefsson.org>
Message-ID: <396556a20609201209q1a7541c7o9ec4d42695e366e3@mail.gmail.com>

On 9/18/06, Simon Josefsson <jas at extundo.com> wrote:
> Makes sense to me.  I believe I have fixed this in gnutls CVS trunk,
> please check.

Looks good.

This is probably a silly question, but I can't split the read and
write paths of a single session across several threads, can I? (e.g.
one thread which only calls record_send and other which only calls
record_recv). I'm fairly certain I can't, but I'm just checking
because it has such a large effect on the code.


Cheers,

AGL

-- 
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       650-283-9641



From jas at extundo.com  Thu Sep 21 16:37:43 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 21 Sep 2006 16:37:43 +0200
Subject: [gnutls-dev] GnuTLS 1.5.1 - experimental
Message-ID: <87y7sd4760.fsf@latte.josefsson.org>

I am happy to announce GnuTLS 1.5.1, the second release on our current
development branch.  We still recommend the 1.4.x branch as the stable
version.

One goal with the 1.5.x branch is to make Windows x86 a supported
platform for GnuTLS.  We do this by providing a binary Windows
installer of GnuTLS, cross-compiled from GNU/Linux using MinGW and
NSIS.  The installer is (lightly) tested on Windows 2000 and Windows
XP.  It is possible to develop applications in Visual Studio or MinGW
that links to the library.  See a separate announcement for the binary
installer for this release.

And yes, the patches for the security problem fixed by 1.4.4 are
included in this release too.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

* Version 1.5.1 (released 2006-09-21)

** Fix PKCS#1 verification to avoid a variant of Bleichenbacher's
** Crypto 06 rump session attack.
In particular, we check that the digestAlgorithm.parameters field is
missing or empty, to avoid that it can contain "garbage" that may be
used to alter the numeric properties of the signature.  See
<http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html> (which is
not exactly the same as the problem we fix here).  Reported by Yutaka
OIWA <y.oiwa at aist.go.jp>.

See GNUTLS-SA-2006-4 on http://www.gnutls.org/security.html for more
up to date information.

** Add self test to test for above flaw.

** Fix gnutls-cli-debug regarding resume support detection.
Earlier, if the session-id from the server had a length of 0, it would
indicate the the server supports resumption, which isn't the case.
Reported by Kataja Kai <kai.kataja at op.fi>.

** Fix building of examples on FreeBSD by including netinet/in.h.
Reported by Roman Bogorodskiy <novel at FreeBSD.org>.

** Fix certtool bug that caused the private key to not be loaded when
generating a certificate with --load-request, which in turn triggered
another unrelated bug in gnutls_x509_crt_sign2 (also fixed).  Reported
by Sascha Ziemann <sascha.ziemann at secunet.com>.

** gnutls-cli and gnutls-serv works on Windows.
The problem was the select() call that doesn't work on file
descriptors (stdin) on Windows.  We borrowed some code from plibc to
solve this.  It appears to be somewhat unreliable though.

** Autoconf 2.60 is now used.

** API and ABI modifications:
No changes since last version.

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.

All manual formats are available from:
  http://www.gnutls.org/manual/

Direct link to the most popular formats:
  http://www.gnutls.org/manual/gnutls.html - HTML format
  http://www.gnutls.org/manual/gnutls.pdf  - PDF format
  http://www.gnutls.org/reference/ch01.html  - API Reference, GTK-DOC HTML

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>.

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/ (updated fastest)

Here are the compressed sources (4.1MB):
  http://josefsson.org/gnutls/releases/gnutls-1.5.1.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.5.1.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.5.1.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-1.5.1.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2007-02-15]
uid                  Simon Josefsson <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2007-02-15]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

116cdb641fe176b4f834a2709635eeeb3bf0dd73  gnutls-1.5.1.tar.bz2
ab2a7e281c288bd928dd7fc750e75ff3beb913b6  gnutls-1.5.1.tar.bz2.sig

ebf5fadf425f93f04d1eddd71a0940a2d3a97455393be1cb38d92fc5  gnutls-1.5.1.tar.bz2
c5d049ab7df89053b7634285c74c9036963599caba7d6584c4abd14c  gnutls-1.5.1.tar.bz2.sig

Enjoy,
Nikos and 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/20060921/5153d20c/attachment.pgp>

From jas at extundo.com  Thu Sep 21 17:21:10 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 21 Sep 2006 17:21:10 +0200
Subject: [gnutls-dev] GnuTLS 1.5.1 for Windows
Message-ID: <87mz8t455l.fsf@latte.josefsson.org>

Don't forget that GnuTLS is available under Windows!

The Windows installer contains the library, binaries for the command
line tools and all example programs.  The manual, in PDF and HTML
formats, together with the GTK-DOC style API reference manual in HTML,
are also included.

This release uses libgpg-error 1.4, libgcrypt 1.2.3, libtasn1 0.3.6,
and gnutls 1.5.1.  The source code for those packages, as well as the
build makefile, is also included in the installer, but is not
installed by default.

For more information, such as an explanation how you can write
programs using Visual Studio or MinGW that uses to GnuTLS, see:

http://josefsson.org/gnutls4win/

I'm interested in feedback about the package, since it is quite
experimental.  Are you able to install it?  Does it work?  Can you
write programs that link to the DLL?  I've done some testing on
Windows XP.

The binary installer and PGP signature:

http://josefsson.org/gnutls4win/gnutls-1.5.1.exe (14MB)
http://josefsson.org/gnutls4win/gnutls-1.5.1.exe.sig

Here are the SHA-1 and SHA-224 checksums:

692c9aef88a163d9ded132e5a0dfadc981b454db  gnutls-1.5.1.exe
92b7c9bbde6de428ee8db22e814f7c3a60f5c894  gnutls-1.5.1.exe.sig

3dc6e4881880b2c81bd701a19667be55bef70a61a9ebae3ebd3074ea  gnutls-1.5.1.exe
426c1e88183fe99395b7a20ea4e6243e0b6bdce8e478d23e520972f4  gnutls-1.5.1.exe.sig

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/20060921/937024fa/attachment.pgp>

From angeli at caeruleus.net  Thu Sep 21 22:21:44 2006
From: angeli at caeruleus.net (Ralf Angeli)
Date: Thu, 21 Sep 2006 22:21:44 +0200
Subject: [gnutls-dev] Re: GnuTLS 1.5.1 for Windows
References: <87mz8t455l.fsf@latte.josefsson.org>
Message-ID: <eeus8q$t5q$1@sea.gmane.org>

* Simon Josefsson (2006-09-21) writes:

> Don't forget that GnuTLS is available under Windows!

Cool, thanks!

> I'm interested in feedback about the package, since it is quite
> experimental.  Are you able to install it?

Yes.

> Does it work?

I'm not sure.  I get the following when executing the first line in
cmd.exe.  The output appears till the line starting with "220".  After
that it does nothing.  When typing `C-c' for aborting the operation
the last lines (starting with "***") appear.

C:\foo>gnutls-cli --print-cert --port 25 --starttls smtp.web.de
Resolving 'smtp.web.de'...
Connecting to '217.72.192.157:25'...

- Simple Client Mode:

220 smtp06.web.de ESMTP WEB.DE V4.107#114 Thu, 21 Sep 2006 22:08:51 +0200
*** Starting TLS handshake
*** Fatal error: A record packet with illegal version was received.
*** Handshake has failed
^C


I am not able to send mail using smtpmail.el in Gnus either.  I am not
sure however if this is the fault of GnuTLS.  The only output after
aborting the operation (which will hang as well) I can see in the SMTP
trace buffer (`smtpmail-debug-info' set to t) is this:

220 smtp.1und1.de (mrelayeu4) Welcome to Nemesis ESMTP server^M
EHLO NEUTRINO^M
QUIT^M

-- 
Ralf




From ametzler at downhill.at.eu.org  Sat Sep 23 10:28:05 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 23 Sep 2006 10:28:05 +0200
Subject: [gnutls-dev] Re: GnuTLS 1.5.1 for Windows
In-Reply-To: <eeus8q$t5q$1@sea.gmane.org>
References: <87mz8t455l.fsf@latte.josefsson.org> <eeus8q$t5q$1@sea.gmane.org>
Message-ID: <20060923082805.GA4607@downhill.g.la>

On 2006-09-21 Ralf Angeli <angeli at caeruleus.net> wrote:
[...]
> I'm not sure.  I get the following when executing the first line in
> cmd.exe.  The output appears till the line starting with "220".  After
> that it does nothing.  When typing `C-c' for aborting the operation
> the last lines (starting with "***") appear.

> C:\foo>gnutls-cli --print-cert --port 25 --starttls smtp.web.de
> Resolving 'smtp.web.de'...
> Connecting to '217.72.192.157:25'...

> - Simple Client Mode:

> 220 smtp06.web.de ESMTP WEB.DE V4.107#114 Thu, 21 Sep 2006 22:08:51 +0200
> *** Starting TLS handshake
> *** Fatal error: A record packet with illegal version was received.
> *** Handshake has failed
> ^C
[...]

You'll need to EHLO, send STARTTLS and (on Linux, don't know abot
windows) <Ctrl>-D to start the handshake.
--------------------------------
ametzler at argenau:~$ gnutls-cli --print-cert --port 25 --starttls smtp.web.de
Resolving 'smtp.web.de'...
Connecting to '217.72.192.157:25'...

- Simple Client Mode:

220 smtp06.web.de ESMTP WEB.DE V4.107#114 Sat, 23 Sep 2006 10:24:44 +0200
ehlo adsl-028.252.166.194.arpa.as1901.net
250-smtp06.web.de Hello adsl-028.252.166.194.arpa.as1901.net. [194.166.252.28]
250-SIZE 69920427
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
starttls
220 OpenSSL/0.9.7beta go ahead
*** Starting TLS handshake
- Certificate type: X.509
[...]
- Version: TLS 1.0
- Key Exchange: RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: NULL
quit
221 smtp06.web.de closing connection
- Peer has closed the GNUTLS connection
--------------------------------

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From ametzler at downhill.at.eu.org  Sun Sep 24 12:10:10 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 24 Sep 2006 12:10:10 +0200
Subject: [gnutls-dev] Symbol versioning in gnutls 1.5.x
Message-ID: <20060924101010.GA16805@downhill.g.la>

Hello,
I have just taken a first look at packaging gnuntls 1.5.x and stumbled
upon this one:

/usr/lib/libgnutls.so.14.0.1: 
Version definitions:
1 0x01 0x0ebdb884 libgnutls.so.14
2 0x00 0x091de683 GNUTLS_1_3

/usr/lib/libgnutls.so.13.0.9: 
Version definitions:
1 0x01 0x0ebdb883 libgnutls.so.13
2 0x00 0x091de683 GNUTLS_1_3

i.e. gnutls 1.5 uses a different soname than gnutls 1.4.x but the
symbols are still versioned with GNUTLS_1_3.

Afaiu, this is going to cause exactly the breakage symbol versioning
is supposed to protect us against: If a binary links against both 1.5
and 1.4 an runtime (e.g. mutt: linking directly against 1.5 for TLS
and indirectly against 1.4 though libldap) then symbol clashes happen
and segfaults might be caused.

Both gnutls-1.5.1/libextra/libgnutls-extra.vers and
gnutls-1.5.1/lib/libgnutls.vers should be bumped.

thanks, cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20060924/25a90cc7/attachment.pgp>

From ametzler at downhill.at.eu.org  Sun Sep 24 13:16:45 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 24 Sep 2006 13:16:45 +0200
Subject: [gnutls-dev] gnutls 1.5.1 C++ library not built if CXX=g++ is set
Message-ID: <20060924111645.GA13448@downhill.g.la>

Hello,
setting CXX=g++ breaks the building of the C++ library.

(SID)ametzler at argenau:/tmp/gnutls-1.5.1$ ./configure 2>&1 |\
        grep 'checking whether to build C++ library'
checking whether to build C++ library... yes

(SID)ametzler at argenau:/tmp/gnutls-1.5.1$ CXX=g++ ./configure 2>&1 |\
        grep 'checking whether to build C++ library'
checking whether to build C++ library... no

Afaict this change to configure.in should fix it

-if test -z "$ac_cv_prog_ac_ct_CXX"; then
+if test -z "$CXX"; then

BTW, shouldn't the C++ library use symbol versioning, too?
thanks, cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From wk at gnupg.org  Sun Sep 24 20:10:35 2006
From: wk at gnupg.org (Werner Koch)
Date: Sun, 24 Sep 2006 20:10:35 +0200
Subject: [gnutls-dev] Symbol versioning in gnutls 1.5.x
In-Reply-To: <20060924101010.GA16805@downhill.g.la> (Andreas Metzler's message
	of "Sun, 24 Sep 2006 12:10:10 +0200")
References: <20060924101010.GA16805@downhill.g.la>
Message-ID: <871wq116g4.fsf@wheatstone.g10code.de>

On Sun, 24 Sep 2006 12:10, Andreas Metzler said:

> is supposed to protect us against: If a binary links against both 1.5
> and 1.4 an runtime (e.g. mutt: linking directly against 1.5 for TLS
> and indirectly against 1.4 though libldap) then symbol clashes happen
> and segfaults might be caused.

Exactly.  We had already had this trouble with GnuPG before the
release of Sarge. There is a reason why the linker tells you about
this possible conflict.

I am pretty sure that many packages do have this problem.  For example
building the current Gnupg 1.9 with gnutls-dev installed you will get
such a problem due to cURL.  It links agains gnutls11 and .13.

> Both gnutls-1.5.1/libextra/libgnutls-extra.vers and
> gnutls-1.5.1/lib/libgnutls.vers should be bumped.

I can't see how this helps.  You need to make sure that there are no
such conflicts.  Remember it is a runtime linkage problem and it is
pure coincidence that it usually (thanks to GNU ld.so) works.


Salam-Shalom,

   Werner




From jas at extundo.com  Mon Sep 25 12:08:57 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 25 Sep 2006 12:08:57 +0200
Subject: [gnutls-dev] Re: Symbol versioning in gnutls 1.5.x
In-Reply-To: <20060924101010.GA16805@downhill.g.la> (Andreas Metzler's message
	of "Sun\, 24 Sep 2006 12\:10\:10 +0200")
References: <20060924101010.GA16805@downhill.g.la>
Message-ID: <87odt4uukm.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> I have just taken a first look at packaging gnuntls 1.5.x and stumbled
> upon this one:
>
> /usr/lib/libgnutls.so.14.0.1: 
> Version definitions:
> 1 0x01 0x0ebdb884 libgnutls.so.14
> 2 0x00 0x091de683 GNUTLS_1_3
>
> /usr/lib/libgnutls.so.13.0.9: 
> Version definitions:
> 1 0x01 0x0ebdb883 libgnutls.so.13
> 2 0x00 0x091de683 GNUTLS_1_3
>
> i.e. gnutls 1.5 uses a different soname than gnutls 1.4.x but the
> symbols are still versioned with GNUTLS_1_3.
>
> Afaiu, this is going to cause exactly the breakage symbol versioning
> is supposed to protect us against: If a binary links against both 1.5
> and 1.4 an runtime (e.g. mutt: linking directly against 1.5 for TLS
> and indirectly against 1.4 though libldap) then symbol clashes happen
> and segfaults might be caused.
>
> Both gnutls-1.5.1/libextra/libgnutls-extra.vers and
> gnutls-1.5.1/lib/libgnutls.vers should be bumped.

Hi, thanks for pointing this out.  I think there is an errors here,
but maybe not the one you point out.  I have some more thoughts, but
let's start with the observation below, which may alter the problem
fundamentally.

There appear to have been no external API/ABI changes between 1.4.x
and 1.5.x.  Thus, bumping the shared library version was probably a
mistake.  Does anyone see any value in bumping it anyway?  I
incremented to avoid having old binaries built against 1.4
automatically linking to 1.5, but now when I think about it, I see no
reason to do this.  I think I should revert it back, so that GnuTLS
1.5.x also uses libgnutls.so.13.

/Simon



From jas at extundo.com  Mon Sep 25 12:48:53 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 25 Sep 2006 12:48:53 +0200
Subject: [gnutls-dev] Re: gnutls 1.5.1 C++ library not built if CXX=g++ is
	set
In-Reply-To: <20060924111645.GA13448@downhill.g.la> (Andreas Metzler's message
	of "Sun\, 24 Sep 2006 13\:16\:45 +0200")
References: <20060924111645.GA13448@downhill.g.la>
Message-ID: <87k63susq2.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> setting CXX=g++ breaks the building of the C++ library.
>
> (SID)ametzler at argenau:/tmp/gnutls-1.5.1$ ./configure 2>&1 |\
>         grep 'checking whether to build C++ library'
> checking whether to build C++ library... yes
>
> (SID)ametzler at argenau:/tmp/gnutls-1.5.1$ CXX=g++ ./configure 2>&1 |\
>         grep 'checking whether to build C++ library'
> checking whether to build C++ library... no
>
> Afaict this change to configure.in should fix it
>
> -if test -z "$ac_cv_prog_ac_ct_CXX"; then
> +if test -z "$CXX"; then

That wouldn't work if the system doesn't have a usable C++ compiler:
for some reason, AC_PROG_CXX will set CXX to g++ in that case.

I have installed the following instead, which actually tries to
compile a C++ program before deciding whether the C++ library should
be built.

--- configure.in	24 Sep 2006 10:22:17 +0200	2.440
+++ configure.in	25 Sep 2006 12:30:34 +0200	
@@ -93,17 +93,6 @@
 AC_PROG_LN_S
 GTK_DOC_CHECK(1.1)
 
-AC_ARG_ENABLE(cxx,
-       AS_HELP_STRING([--disable-cxx],
-               [unconditionally disable the C++ library]),
-       ac_enable_cxx=$enableval, ac_enable_cxx=yes)
-if test -z "$ac_cv_prog_ac_ct_CXX"; then
-  ac_enable_cxx=no
-fi
-AM_CONDITIONAL(ENABLE_CXX, test "$ac_enable_cxx" != "no")
-AC_MSG_CHECKING([whether to build C++ library])
-AC_MSG_RESULT($ac_enable_cxx)
-
 AC_MSG_RESULT([***
 *** Detecting compiler options...
 ])
@@ -112,6 +101,19 @@
 AC_C_CONST
 AC_C_INLINE
 
+AC_ARG_ENABLE(cxx,
+       AS_HELP_STRING([--disable-cxx],
+               [unconditionally disable the C++ library]),
+       use_cxx=$enableval, use_cxx=yes)
+if test "$use_cxx" != "no"; then
+  AC_LANG_PUSH(C++)
+  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],[])], use_cxx=yes, use_cxx=no)
+  AC_LANG_POP(C++)
+fi
+AM_CONDITIONAL(ENABLE_CXX, test "$use_cxx" != "no")
+AC_MSG_CHECKING([whether to build C++ library])
+AC_MSG_RESULT($use_cxx)
+
 AC_MSG_CHECKING([whether C99 macros are supported])
 AC_TRY_COMPILE(,[ 
 #define test_mac(...) 

> BTW, shouldn't the C++ library use symbol versioning, too?

Yes, I've tried to add this.

Thanks,
Simon



From jas at extundo.com  Mon Sep 25 13:05:48 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 25 Sep 2006 13:05:48 +0200
Subject: [gnutls-dev] Re: OpenCDK indexing fails if a public key is at
	offset 0
In-Reply-To: <396556a20609201209q1a7541c7o9ec4d42695e366e3@mail.gmail.com>
	(Adam Langley's message of "Wed\, 20 Sep 2006 12\:09\:07 -0700")
References: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>
	<87wt81sfci.fsf@latte.josefsson.org>
	<396556a20609201209q1a7541c7o9ec4d42695e366e3@mail.gmail.com>
Message-ID: <87d59kurxv.fsf@latte.josefsson.org>

"Adam Langley" <agl at imperialviolet.org> writes:

> On 9/18/06, Simon Josefsson <jas at extundo.com> wrote:
>> Makes sense to me.  I believe I have fixed this in gnutls CVS trunk,
>> please check.
>
> Looks good.

Great.

> This is probably a silly question, but I can't split the read and
> write paths of a single session across several threads, can I? (e.g.
> one thread which only calls record_send and other which only calls
> record_recv). I'm fairly certain I can't, but I'm just checking
> because it has such a large effect on the code.

It isn't obvious that this wouldn't work.  Looking at the code,
receiving and sending are pretty separated.  One concern I had would
be if receiving something (e.g., an alert, change cipher suite,
re-handshake request) could trigger additional alerts or other packets
that would be sent by the library automatically, but I can't find any
such examples.

Tracing all functions used by gnutls_record_send and
gnutls_record_recv, and checking if they use the same variables
somewhere, would answer this.  But even so, it isn't certain that
future versions will look the same.

Of course, you could still design things that way, and put a mutex
around the gnutls_record_send and gnutls_record_recv calls to be sure.
You could also disable the mutex during debugging, to see if something
actually breaks...

Sorry that this isn't exactly a clear answer.

/Simon



From nmav at gnutls.org  Mon Sep 25 17:18:21 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 25 Sep 2006 18:18:21 +0300
Subject: [gnutls-dev] Re: OpenCDK indexing fails if a public key is at
	offset 0
In-Reply-To: <87d59kurxv.fsf@latte.josefsson.org>
References: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>
	<87wt81sfci.fsf@latte.josefsson.org>
	<396556a20609201209q1a7541c7o9ec4d42695e366e3@mail.gmail.com>
	<87d59kurxv.fsf@latte.josefsson.org>
Message-ID: <c331d99a0609250818s673eff4aq3d7c0024f17aedb9@mail.gmail.com>

On 9/25/06, Simon Josefsson <jas at extundo.com> wrote:

> > This is probably a silly question, but I can't split the read and
> > write paths of a single session across several threads, can I? (e.g.
> > one thread which only calls record_send and other which only calls
> > record_recv). I'm fairly certain I can't, but I'm just checking
> > because it has such a large effect on the code.
> It isn't obvious that this wouldn't work.  Looking at the code,
> receiving and sending are pretty separated.  One concern I had would
> be if receiving something (e.g., an alert, change cipher suite,
> re-handshake request) could trigger additional alerts or other packets
> that would be sent by the library automatically, but I can't find any
> such examples.

Indeed this works. The only problem are the bye messages, which need
some care to be sent without the SHUT_RDWR flag but instead with the WR
flag and wait for an EOF by the peer.

Of course you cannot mix the behavior by sending later using the recv thread
etc.

regards,
Nikos



From ametzler at downhill.at.eu.org  Mon Sep 25 19:19:00 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 25 Sep 2006 19:19:00 +0200
Subject: [gnutls-dev] Re: Symbol versioning in gnutls 1.5.x
In-Reply-To: <87odt4uukm.fsf@latte.josefsson.org>
References: <20060924101010.GA16805@downhill.g.la>
	<87odt4uukm.fsf@latte.josefsson.org>
Message-ID: <20060925171900.GB2880@downhill.g.la>

On 2006-09-25 Simon Josefsson <jas at extundo.com> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > i.e. gnutls 1.5 uses a different soname than gnutls 1.4.x but the
> > symbols are still versioned with GNUTLS_1_3.
[...]
> There appear to have been no external API/ABI changes between 1.4.x
> and 1.5.x.  Thus, bumping the shared library version was probably a
> mistake.  Does anyone see any value in bumping it anyway?  I
> incremented to avoid having old binaries built against 1.4
> automatically linking to 1.5, but now when I think about it, I see no
> reason to do this.  I think I should revert it back, so that GnuTLS
> 1.5.x also uses libgnutls.so.13.

Both ways to fix the issue (decrement soname or bump symbol versioning)
will break binaries linking against 1.5. Reverting the unnecessary
soname bump seems to be the better alternative.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From ametzler at downhill.at.eu.org  Mon Sep 25 19:30:21 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 25 Sep 2006 19:30:21 +0200
Subject: [gnutls-dev] Symbol versioning in gnutls 1.5.x
In-Reply-To: <871wq116g4.fsf@wheatstone.g10code.de>
References: <20060924101010.GA16805@downhill.g.la>
	<871wq116g4.fsf@wheatstone.g10code.de>
Message-ID: <20060925173021.GC2880@downhill.g.la>

On 2006-09-24 Werner Koch <wk at gnupg.org> wrote:
> On Sun, 24 Sep 2006 12:10, Andreas Metzler said:
>> is supposed to protect us against: If a binary links against both 1.5
>> and 1.4 an runtime (e.g. mutt: linking directly against 1.5 for TLS
>> and indirectly against 1.4 though libldap) then symbol clashes happen
>> and segfaults might be caused.

> Exactly.  We had already had this trouble with GnuPG before the
> release of Sarge. There is a reason why the linker tells you about
> this possible conflict.

> I am pretty sure that many packages do have this problem.  For example
> building the current Gnupg 1.9 with gnutls-dev installed you will get
> such a problem due to cURL.  It links agains gnutls11 and .13.

Hello,
That is absolutely no problem *iff* the respective libraries use
proper symbol versioning. The GnuTLS dependency chain uses symbol
versioning throughout all libraries [1] nowadays. - There is no
problem for applications linking against libtasn1.so.2, libtasn1.so.3,
libgnutls12, libgnutls11 and libgnutls13 simultanously.

Thank you for that, BTW. ;-)

> > Both gnutls-1.5.1/libextra/libgnutls-extra.vers and
> > gnutls-1.5.1/lib/libgnutls.vers should be bumped.

> I can't see how this helps.  You need to make sure that there are no
> such conflicts.  Remember it is a runtime linkage problem and it is
> pure coincidence that it usually (thanks to GNU ld.so) works.

It does. That is the whole and only point of symbol versioning, you
won't get symbol clashes and crashes. It is no coincidence; on
architectures that support it, symbol versioning *does* work.
cu andreas
[1] Except for libgpg-error but I have been told by the author(s) that
it won't have a soname bump /ever/.
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From jas at extundo.com  Mon Sep 25 21:13:49 2006
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 25 Sep 2006 21:13:49 +0200
Subject: [gnutls-dev] Re: Symbol versioning in gnutls 1.5.x
In-Reply-To: <20060925171900.GB2880@downhill.g.la> (Andreas Metzler's message
	of "Mon\, 25 Sep 2006 19\:19\:00 +0200")
References: <20060924101010.GA16805@downhill.g.la>
	<87odt4uukm.fsf@latte.josefsson.org>
	<20060925171900.GB2880@downhill.g.la>
Message-ID: <877izriwsy.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2006-09-25 Simon Josefsson <jas at extundo.com> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> > i.e. gnutls 1.5 uses a different soname than gnutls 1.4.x but the
>> > symbols are still versioned with GNUTLS_1_3.
> [...]
>> There appear to have been no external API/ABI changes between 1.4.x
>> and 1.5.x.  Thus, bumping the shared library version was probably a
>> mistake.  Does anyone see any value in bumping it anyway?  I
>> incremented to avoid having old binaries built against 1.4
>> automatically linking to 1.5, but now when I think about it, I see no
>> reason to do this.  I think I should revert it back, so that GnuTLS
>> 1.5.x also uses libgnutls.so.13.
>
> Both ways to fix the issue (decrement soname or bump symbol versioning)
> will break binaries linking against 1.5. Reverting the unnecessary
> soname bump seems to be the better alternative.

Ok, I'm doing this now.  To avoid colliding with gnutls 1.4.x (that
use shared library version 13.0.x -- also, most likely there will
never be any ABI changes in 1.4.x and thus no so version 13.1.x from
that branch), I bumped the so version for gnutls 1.5.2 to 13.1.0.

I glanced through Drepper's howto on writing DSO's again, but it isn't
really clear to me whether we are doing the right thing here.  The
situation is a bit more complex when you want to avoid collisions
between two current branches of the same library too.  It is also not
clear how things work on non-GNU/Linux platforms without GNU ld.so.

More information or better ideas on how things should work are most
welcome...

Thanks,
Simon



From agl at imperialviolet.org  Mon Sep 25 23:53:05 2006
From: agl at imperialviolet.org (Adam Langley)
Date: Mon, 25 Sep 2006 14:53:05 -0700
Subject: [gnutls-dev] Re: OpenCDK indexing fails if a public key is at
	offset 0
In-Reply-To: <c331d99a0609250818s673eff4aq3d7c0024f17aedb9@mail.gmail.com>
References: <396556a20609172331i7aeada32g33997d444e81f56d@mail.gmail.com>
	<87wt81sfci.fsf@latte.josefsson.org>
	<396556a20609201209q1a7541c7o9ec4d42695e366e3@mail.gmail.com>
	<87d59kurxv.fsf@latte.josefsson.org>
	<c331d99a0609250818s673eff4aq3d7c0024f17aedb9@mail.gmail.com>
Message-ID: <396556a20609251453j5be2d064k799b0ad7fa3e8594@mail.gmail.com>

On 9/25/06, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Indeed this works. The only problem are the bye messages, which need
> some care to be sent without the SHUT_RDWR flag but instead with the WR
> flag and wait for an EOF by the peer.
>
> Of course you cannot mix the behavior by sending later using the recv thread
> etc.

Thanks for the clarification.


AGL

-- 
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       650-283-9641



From agl at imperialviolet.org  Mon Sep 25 23:55:37 2006
From: agl at imperialviolet.org (Adam Langley)
Date: Mon, 25 Sep 2006 14:55:37 -0700
Subject: [gnutls-dev] Off-by-one error in gnutls_openpgp.c
Message-ID: <396556a20609251455w726d3f6k13efa16d6b8c43a0@mail.gmail.com>

(line numbers from last night's snapshot, problem exists in at least
1.4.4 at well)

gnutls_openpgp.c:225
The argument to the malloc is too small, I think it should be 2 + 4 +
size. That makes sense given the comment at the top of the function as
well.

Cheers,

AGL

-- 
Adam Langley                                      agl at imperialviolet.org
http://www.imperialviolet.org                       650-283-9641



From jas at extundo.com  Tue Sep 26 10:18:12 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 26 Sep 2006 10:18:12 +0200
Subject: [gnutls-dev] Re: Off-by-one error in gnutls_openpgp.c
In-Reply-To: <396556a20609251455w726d3f6k13efa16d6b8c43a0@mail.gmail.com>
	(Adam Langley's message of "Mon\, 25 Sep 2006 14\:55\:37 -0700")
References: <396556a20609251455w726d3f6k13efa16d6b8c43a0@mail.gmail.com>
Message-ID: <87psdjghx7.fsf@latte.josefsson.org>

"Adam Langley" <agl at imperialviolet.org> writes:

> (line numbers from last night's snapshot, problem exists in at least
> 1.4.4 at well)
>
> gnutls_openpgp.c:225
> The argument to the malloc is too small, I think it should be 2 + 4 +
> size. That makes sense given the comment at the top of the function as
> well.

I agree.  Installed, thanks!

/Simon



From wk at gnupg.org  Tue Sep 26 13:16:04 2006
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Sep 2006 13:16:04 +0200
Subject: [gnutls-dev] Symbol versioning in gnutls 1.5.x
In-Reply-To: <20060925173021.GC2880@downhill.g.la> (Andreas Metzler's message
	of "Mon, 25 Sep 2006 19:30:21 +0200")
References: <20060924101010.GA16805@downhill.g.la>
	<871wq116g4.fsf@wheatstone.g10code.de>
	<20060925173021.GC2880@downhill.g.la>
Message-ID: <87wt7qswsr.fsf@wheatstone.g10code.de>

On Mon, 25 Sep 2006 19:30, Andreas Metzler said:

> That is absolutely no problem *iff* the respective libraries use
> proper symbol versioning. The GnuTLS dependency chain uses symbol

As long as the platform supports this.

> problem for applications linking against libtasn1.so.2, libtasn1.so.3,
> libgnutls12, libgnutls11 and libgnutls13 simultanously.

That really depends on the library. Conflicts may arise outside of the
symbol scope.  For example if a library opens a devices and requires
exclusive access.  The second instance of the library won't be able to
properly access this device then.  It does not know that a second
instance is already running.  Locking makes this even worse because it
is often based on the pid.

>> It does. That is the whole and only point of symbol versioning, you
> won't get symbol clashes and crashes. It is no coincidence; on
> architectures that support it, symbol versioning *does* work.

No.: It may work, but there is no guarantee for that.  Symbol
versioning solves the problem of maintaining a backward compatible
ABI.  It does not help when linking two instances of a library into
one process.


Salam-Shalom,

   Werner




From jas at extundo.com  Tue Sep 26 18:18:57 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 26 Sep 2006 18:18:57 +0200
Subject: [gnutls-dev] Original analysis of signature forgery problem
Message-ID: <1159287537.23281.3.camel@localhost.localdomain>

Hi all, I just got permission to publish the original report about the
GNUTLS-SA-2006-4 problem.
        
/Simon

Ps. For some reason my first attempt (yesterday) to post this to the
list didn't end up in the archives, let's see if this one does...

================================================================
                      Vulnerability Report                      
================================================================

Software: GNUTLS   (up to 1.4.2)

Kind of vulnerability: Certificate Forgery

Summary:

During examination for sources for CVE-2006-4339, we have found that
gnutls is vunlerable for another kind of certificate forgery attack,
when "e = 3" RSA key is used to sign certificates.

Cause:

ASN.1 syntax for decrypted signatures allows "parameter" field to
contain any kind of data.  Valid contents for this field are depending
on the hash algorithm used, and for the MD5 and SHA-1 hash these
should be NULL.  However, gnutls does not check this field and allows
arbitrary data to be stored here.

This loose implementation allows the following attack:

  The constants show below assume that a CA uses 1024 bit RSA key with
  exponent 3, and uses MD5 algorithm to make a signature.

  (1) Let c = 7908632510826885383110735189539096624229777909395926928727
* 2^144,
      which is the cubic root of an expected value, ceiled up to a
multiple of 2^144.

  (2) For given signature digest value h, find a 144-bit integer h'
      such that (h')^3 mod 2^144 == 0x0410 * 2^128 + h. This is
      possible if h is an odd number.

  (3) Calculate x = c + h'.

When x is decrypted using RSA public exponent e = 3 (i.e. calculating
x^3), the result will be following data.

00 01 FF FF 00 30 79 30 65 06 08 2a 86 48 86 f7 0d 02 05 04 59
[ 89 bytes of garbage ] 04 10 [ 16 bytes of h ].

This is a valid PKCS-1-padded ASN.1 data, except existence of
meaningless parameter field.  As 89 bytes of garbage area is
sufficient to hold value (h')^3, the whole ASN.1 structure, produced
from c, is kept unbroken.

The same attacks are possible for SHA-1 algorithm and for longer RSA
keys, using a different value for c (and other constants).
We verified that GNUTLS 1.4.2 suffers from the same attack, using
certificates using SHA-1 hash algorithm.


Mitigating Factors and/or workarounds:

Avoiding to trust CAs using RSA key with a small exponent, such as
e=3, eliminates this attack.  for a large exponent, this attack is not
possible.


Possible Fix:

During checking the validity of certificate signature, check if the
parameter field is NULL (05 00). Otherwise, reject the certificate.


Notes:

- We suppose that this attack itself might be already known to public,
  as at least one implementation of the TLS protocol is careful about
  the possibility of attacks using the parameter field.  We have
  developped the detail of the real attack and verified.

- We are reporting this issue to IPA and JPCERT/CC in Japan.  This
  means that CERT/CC or other incident response agency may contact
  you later about handling of vulnerabilities.

The address of contact:
  Yutaka Oiwa, Kazukuni Kobara, Hajime Watanabe
    Research Center for Information Security,
    National Institute of
    Advanced Industrial Science and Technology (AIST), Japan.
    Contact E-mail: y.oiwa at aist.go.jp

================================================================





From ametzler at downhill.at.eu.org  Tue Sep 26 19:14:22 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 26 Sep 2006 19:14:22 +0200
Subject: [gnutls-dev] Symbol versioning in gnutls 1.5.x
In-Reply-To: <87wt7qswsr.fsf@wheatstone.g10code.de>
References: <20060924101010.GA16805@downhill.g.la>
	<871wq116g4.fsf@wheatstone.g10code.de>
	<20060925173021.GC2880@downhill.g.la>
	<87wt7qswsr.fsf@wheatstone.g10code.de>
Message-ID: <20060926171422.GC2811@downhill.g.la>

On 2006-09-26 Werner Koch <wk at gnupg.org> wrote:
> On Mon, 25 Sep 2006 19:30, Andreas Metzler said:
[...]
> > problem for applications linking against libtasn1.so.2, libtasn1.so.3,
> > libgnutls12, libgnutls11 and libgnutls13 simultanously.

> That really depends on the library. Conflicts may arise outside of the
> symbol scope.  For example if a library opens a devices and requires
> exclusive access.  The second instance of the library won't be able to
> properly access this device then.  It does not know that a second
> instance is already running.  Locking makes this even worse because it
> is often based on the pid.
[...]

Yes, I forgot about this. Thanks for the enlightenment.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From ametzler at downhill.at.eu.org  Tue Sep 26 19:48:40 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 26 Sep 2006 19:48:40 +0200
Subject: [gnutls-dev] Re: Symbol versioning in gnutls 1.5.x
In-Reply-To: <877izriwsy.fsf@latte.josefsson.org>
References: <20060924101010.GA16805@downhill.g.la>
	<87odt4uukm.fsf@latte.josefsson.org>
	<20060925171900.GB2880@downhill.g.la>
	<877izriwsy.fsf@latte.josefsson.org>
Message-ID: <20060926174840.GD2811@downhill.g.la>

On 2006-09-25 Simon Josefsson <jas at extundo.com> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > Both ways to fix the issue (decrement soname or bump symbol versioning)
> > will break binaries linking against 1.5. Reverting the unnecessary
> > soname bump seems to be the better alternative.

> Ok, I'm doing this now.  To avoid colliding with gnutls 1.4.x (that
> use shared library version 13.0.x -- also, most likely there will
> never be any ABI changes in 1.4.x and thus no so version 13.1.x from
> that branch), I bumped the so version for gnutls 1.5.2 to 13.1.0.

Hello,
I am sure the following is obvious to anybody but me: ;-)

Afaict you have now gone from
                current revision        age
1.4.4           13      9               0
CVS HEAD        14      0               1

which is libtool's way of saying, "new release, some interfaces have
been added, none have been removed". As 1.4.4 is in freeze its
interface should stay stable (unless there some bug requiring to
change it) and therefore 1.4.x will not "catch up".

You have cheated a little bit because actually 1.5.x does not include
any new interfaces yet.

> I glanced through Drepper's howto on writing DSO's again, but it isn't
> really clear to me whether we are doing the right thing here.  The
> situation is a bit more complex when you want to avoid collisions
> between two current branches of the same library too.  It is also not
> clear how things work on non-GNU/Linux platforms without GNU ld.so.

Depending on the architecture anything might happen I guess, but you
have given libtool sane information to deal with.

I think this is ok.

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From jas at extundo.com  Wed Sep 27 10:02:16 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 27 Sep 2006 10:02:16 +0200
Subject: [gnutls-dev] Re: Symbol versioning in gnutls 1.5.x
In-Reply-To: <20060926174840.GD2811@downhill.g.la> (Andreas Metzler's message
	of "Tue\, 26 Sep 2006 19\:48\:40 +0200")
References: <20060924101010.GA16805@downhill.g.la>
	<87odt4uukm.fsf@latte.josefsson.org>
	<20060925171900.GB2880@downhill.g.la>
	<877izriwsy.fsf@latte.josefsson.org>
	<20060926174840.GD2811@downhill.g.la>
Message-ID: <878xk5n3ef.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2006-09-25 Simon Josefsson <jas at extundo.com> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> > Both ways to fix the issue (decrement soname or bump symbol versioning)
>> > will break binaries linking against 1.5. Reverting the unnecessary
>> > soname bump seems to be the better alternative.
>
>> Ok, I'm doing this now.  To avoid colliding with gnutls 1.4.x (that
>> use shared library version 13.0.x -- also, most likely there will
>> never be any ABI changes in 1.4.x and thus no so version 13.1.x from
>> that branch), I bumped the so version for gnutls 1.5.2 to 13.1.0.
>
> Hello,
> I am sure the following is obvious to anybody but me: ;-)
>
> Afaict you have now gone from
>                 current revision        age
> 1.4.4           13      9               0
> CVS HEAD        14      0               1

Yup.

> which is libtool's way of saying, "new release, some interfaces have
> been added, none have been removed". As 1.4.4 is in freeze its
> interface should stay stable (unless there some bug requiring to
> change it) and therefore 1.4.x will not "catch up".

Yes.

> You have cheated a little bit because actually 1.5.x does not include
> any new interfaces yet.

Right.  Of course, nobody can tell from the outside whether the
interface did change or not (since they can change internally, as
Werner describes).

I considered using 13, 50, 0 instead, to leave some room for future
1.4.x releases, but it seemed somewhat unclean, and the 14,0, 1
approach generate the same libgnutls.so.13 library name.

>> I glanced through Drepper's howto on writing DSO's again, but it isn't
>> really clear to me whether we are doing the right thing here.  The
>> situation is a bit more complex when you want to avoid collisions
>> between two current branches of the same library too.  It is also not
>> clear how things work on non-GNU/Linux platforms without GNU ld.so.
>
> Depending on the architecture anything might happen I guess, but you
> have given libtool sane information to deal with.
>
> I think this is ok.

We'll leave it as is until someone complains.

/Simon



From ametzler at downhill.at.eu.org  Sat Sep 30 18:39:31 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 30 Sep 2006 18:39:31 +0200
Subject: [gnutls-dev] Re: pkg-config support for opencdk
In-Reply-To: <87veoqcu6s.fsf@latte.josefsson.org>
References: <20060806180314.GA3872@downhill.g.la>
	<87bqqxjc4g.fsf@latte.josefsson.org>
	<20060807182414.GB11433@downhill.g.la>
	<87r6zrqtqs.fsf@latte.josefsson.org>
	<20060810170958.GA6152@cthulhu.lambers.home>
	<87veoqcu6s.fsf@latte.josefsson.org>
Message-ID: <20060930163931.GD2869@downhill.g.la>

On 2006-08-18 Simon Josefsson <jas at extundo.com> wrote:
> Martin Lambers <marlam at marlam.de> writes:
>> On Tue, 08. Aug 2006, 14:47:39 +0200, Simon Josefsson wrote:
>>> I think Bruno's AC_LIB_HAVE_LINKFLAGS is the best choice.  It works
>>> for cross-compilations, can check for particular versions through the
>>> gnutls.h LIBGNUTLS_VERSION* symbols, and doesn't add unnecessary
>>> libraries to the link line, and works with and without libtool.

>> How does the check for particular versions work with
>> AC_LIB_HAVE_LINKFLAGS? Can you give an example?
[...]
> You could modify it into:

>   AC_LIB_HAVE_LINKFLAGS(gnutls,,
>     [#include <gnutls/gnutls.h>
>      #if LIBGNUTLS_VERSION_NUMBER < 0x010500
>      error too old gnutls
>      #endif],
>     [gnutls_certificate_verify_peers2 (0, 0);])

> I didn't test this, but something like it should work.

> Note that the test for gnutls_certificate_verify_peers2() is an
> implicit version test -- gsasl need a gnutls version that have that
> particular feature.  That is the best approach: test the GnuTLS
> library for the properties (e.g., APIs) that your application actually
> needs.  Doing so will work even if someone has back-ported a feature
> to an older version, for example.

Hello,
I have wasted a bit of time with this today by taking a look at an
obvious candidate, gnutls itself. It currently uses AM_PATH_LIBTASN1
to search for a minimal version of tasn1. Afaiui the version
requirement is not due to some special function only available in this
version but to ignore known to be buggy versions. Libtasn1 doesn't
ship a LIBTASN1_VERSION_NUMBER available for the trick noted above.

I have thought about ways to work around it:

#1 Use a custom autoconf macro to pull the *value* of LIBTASN1_VERSION
from libtasn1.h using the C preprocessor and then compare this string
and GNUTLS_LIBTASN1_VERSION using to be written shell code.
(hideous, imho)

#2 Use asn1_check_version("$GNUTLS_LIBTASN1_VERSION") in
AC_RUN_IFELSE. - This breaks cross-compilation.

#3 continue using AM_PATH_LIBTASN1.

#4 PKG_CHECK_MODULES([LIBTASN1], [libtasn1 >= $GNUTLS_LIBTASN1_VERSION])

#5 remove the version requirement and search for used features,
allowing linkage with buggy libtasn1.

Thoughts?
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde