From simon at josefsson.org  Fri Feb  1 17:56:07 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 01 Feb 2008 17:56:07 +0100
Subject: [Help-gnutls] Libtasn1 1.3
Message-ID: <87zluklioo.fsf@mocca.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by Shishi to handle
Kerberos V5 packets.

Version 1.3 (released 2008-02-01)
- Handle 'INTEGER { ... } (a..b)' regression.
  Revert parts of earlier fix.  asn1Parser can now again parse src/pkix.asn1.
  The ASN1.c file was generated using Bison 2.3.
- Move examples from src/ to new directory examples/.
- Duplicate copy of divergated pkix.asn removed.
- Merge unnecessary lib/defines.h into lib/int.h.
- Configure no longer tries to use gcc -pipe.
- Update gnulib files.
- Fix mem leak in self-test.

Commercial support contracts for Libtasn1 are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a Stockholm
based privately held company, is currently funding Libtasn1 maintenance.
We are always looking for interesting development projects.  See
http://josefsson.org/ for more details.

If you need help to use Libtasn1, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.5MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.3.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.3.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.3.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.3.tar.gz.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: 2008-06-30]
      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: 2008-06-30]

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:

154d79b6e49ec9efeb758ef964c6d23a838da289  libtasn1-1.3.tar.gz

00e700b079903f98707acf521d7d49327cc125097cb389e69a27211c  libtasn1-1.3.tar.gz

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/20080201/28ceba4e/attachment.pgp>

From lists at roberthogan.net  Sat Feb  9 12:40:21 2008
From: lists at roberthogan.net (Robert Hogan)
Date: Sat, 9 Feb 2008 11:40:21 +0000
Subject: [Help-gnutls] Using gnutls_srp_base64_decode to decode something
	encoded with SSL's EVP_Encode*
Message-ID: <200802091140.26620.lists@roberthogan.net>

[originally sent to gnutls-dev in error, please ignore the post there]

Hi there,

I have the following string, which has been encoded by openssl's EVP_Encode* 
function:

8lsjlBTuh2bbNTARRgB6WnmgCm0

I want to decode it with a gnutls function, so I'm guessing 
gnutls_srp_base64_decode is the one I need. (I've tried 
gnutls_pem_base64_decode with no luck)

I can decode a result with it, however it is not the same result as if I had 
used EVP_decode*.

(Unlike with EVP_Decode I have to give it the unadorned string; EVP_Decode 
requires '8lsjlBTuh2bbNTARRgB6WnmgCm0=\n\0'. Adding the =, newline and null 
causes gnutls_srp_base64_decode to return nothing.)

Are the two incompatible? I would have though base64 was just base64!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080209/90ad7d33/attachment.pgp>

From cibyr at cibyr.com  Sun Feb 10 04:17:18 2008
From: cibyr at cibyr.com (Ian Cullinan)
Date: Sun, 10 Feb 2008 13:17:18 +1000
Subject: [Help-gnutls] Using gnutls_srp_base64_decode to decode something
	encoded with SSL's EVP_Encode*
In-Reply-To: <200802091140.26620.lists@roberthogan.net>
References: <200802091140.26620.lists@roberthogan.net>
Message-ID: <bbf19b3d0802091917j5ebb6211o36b02682f0abf758@mail.gmail.com>

On 2/9/08, Robert Hogan <lists at roberthogan.net> wrote:

> (Unlike with EVP_Decode I have to give it the unadorned string; EVP_Decode
> requires '8lsjlBTuh2bbNTARRgB6WnmgCm0=\n\0'. Adding the =, newline and null
> causes gnutls_srp_base64_decode to return nothing.)

I don't know anything about those two functions, but I do know the =
in base64 is significant. Tried using EVP_Decode with the = but not
the \n\0 ?

Cheers,

Ian Cullinan




From lists at roberthogan.net  Sun Feb 10 15:00:32 2008
From: lists at roberthogan.net (Robert Hogan)
Date: Sun, 10 Feb 2008 14:00:32 +0000
Subject: [Help-gnutls] Using gnutls_srp_base64_decode to decode something
	encoded with SSL's EVP_Encode*
In-Reply-To: <bbf19b3d0802091917j5ebb6211o36b02682f0abf758@mail.gmail.com>
References: <200802091140.26620.lists@roberthogan.net>
	<bbf19b3d0802091917j5ebb6211o36b02682f0abf758@mail.gmail.com>
Message-ID: <200802101400.37513.lists@roberthogan.net>

On Sunday 10 February 2008 03:17:18 Ian Cullinan wrote:
> On 2/9/08, Robert Hogan <lists at roberthogan.net> wrote:
> > (Unlike with EVP_Decode I have to give it the unadorned string;
> > EVP_Decode requires '8lsjlBTuh2bbNTARRgB6WnmgCm0=\n\0'. Adding the =,
> > newline and null causes gnutls_srp_base64_decode to return nothing.)
>
> I don't know anything about those two functions, but I do know the =
> in base64 is significant. Tried using EVP_Decode with the = but not
> the \n\0 ?
>

I've tried every conceivable combination! Libb64 has plugged the gap for now, 
but it would be nice to know if this is actually possible with gnutls.

Thanks anyway.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080210/b00df31e/attachment.pgp>

From simon at josefsson.org  Tue Feb 12 11:35:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 12 Feb 2008 11:35:46 +0100
Subject: [Help-gnutls] Re: Using gnutls_srp_base64_decode to decode
	something encoded with SSL's EVP_Encode*
In-Reply-To: <200802091140.26620.lists@roberthogan.net> (Robert Hogan's
	message of "Sat, 9 Feb 2008 11:40:21 +0000")
References: <200802091140.26620.lists@roberthogan.net>
Message-ID: <87lk5qa2d9.fsf@mocca.josefsson.org>

Robert Hogan <lists at roberthogan.net> writes:

> [originally sent to gnutls-dev in error, please ignore the post there]
>
> Hi there,
>
> I have the following string, which has been encoded by openssl's EVP_Encode* 
> function:
>
> 8lsjlBTuh2bbNTARRgB6WnmgCm0
>
> I want to decode it with a gnutls function, so I'm guessing 
> gnutls_srp_base64_decode is the one I need. (I've tried 
> gnutls_pem_base64_decode with no luck)
>
> I can decode a result with it, however it is not the same result as if I had 
> used EVP_decode*.
>
> (Unlike with EVP_Decode I have to give it the unadorned string; EVP_Decode 
> requires '8lsjlBTuh2bbNTARRgB6WnmgCm0=\n\0'. Adding the =, newline and null 
> causes gnutls_srp_base64_decode to return nothing.)
>
> Are the two incompatible? I would have though base64 was just base64!

Alas, base64 is not always "just base64".  SRP uses its own base64
variant, so the encoding are not compatible.  I've tried to improve the
documentation with the patch below, so that others doesn't run into this
problem in the future.  Comments welcome.

The gnutls_pem_base64_decode function is also not right, it assume the
data is PEM encoded.

Right now I don't think there are any raw base64 decoding functions in
gnutls, and frankly I'm not sure GnuTLS is a good place for such code.
I happen to maintain a gnulib module for base64 encoding, please check
it out:

http://www.gnu.org/software/gnulib/
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/base64.c;hb=HEAD
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/base64.h;hb=HEAD

What were you going to use the base64 functions for?

/Simon

diff --git a/lib/auth_srp_sb64.c b/lib/auth_srp_sb64.c
index c3d5ccd..57dd521 100644
--- a/lib/auth_srp_sb64.c
+++ b/lib/auth_srp_sb64.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation
+ * Copyright (C) 2001, 2002, 2003, 2004, 2005, 2008 Free Software Foundation
  *
  * Author: Nikos Mavrogiannopoulos
  *
@@ -309,15 +309,21 @@ _gnutls_sbase64_decode (uint8_t * data, size_t idata_size, uint8_t ** result)
 }
 
 /**
-  * gnutls_srp_base64_encode - This function will convert raw data to base64 encoded
+  * gnutls_srp_base64_encode - Encode raw data using SRP-Base64
   * @data: contain the raw data
   * @result: the place where base64 data will be copied
   * @result_size: holds the size of the result
   *
-  * This function will convert the given data to printable data, using the base64 
-  * encoding, as used in the libsrp. This is the encoding used in SRP password files.
-  * If the provided buffer is not long enough GNUTLS_E_SHORT_MEMORY_BUFFER is returned.
-  * 
+  * This function will convert the given data to printable data, using
+  * the base64 encoding, as used in the libsrp.  This is the encoding
+  * used in SRP password files.  If the provided buffer is not long
+  * enough GNUTLS_E_SHORT_MEMORY_BUFFER is returned.
+  *
+  * Warning!  This base64 encoding is not the "standard" encoding, so
+  * do not use it for non-SRP purposes.
+  *
+  * Returns: %GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not
+  * long enough, or 0 on success.
   **/
 int
 gnutls_srp_base64_encode (const gnutls_datum_t * data, char *result,
@@ -347,16 +353,21 @@ gnutls_srp_base64_encode (const gnutls_datum_t * data, char *result,
 }
 
 /**
-  * gnutls_srp_base64_encode_alloc - This function will convert raw data to Base64 encoded
+  * gnutls_srp_base64_encode_alloc - encode raw data using SRP-Base64
   * @data: contains the raw data
   * @result: will hold the newly allocated encoded data
   *
-  * This function will convert the given data to printable data, using the base64 
-  * encoding. This is the encoding used in SRP password files. This function will
-  * allocate the required memory to hold the encoded data.
+  * This function will convert the given data to printable data, using
+  * the base64 encoding.  This is the encoding used in SRP password
+  * files.  This function will allocate the required memory to hold
+  * the encoded data.
   *
   * You should use gnutls_free() to free the returned data.
-  * 
+  *
+  * Warning!  This base64 encoding is not the "standard" encoding, so
+  * do not use it for non-SRP purposes.
+  *
+  * Returns: 0 on success, or an error code.
   **/
 int
 gnutls_srp_base64_encode_alloc (const gnutls_datum_t * data,
@@ -384,18 +395,21 @@ gnutls_srp_base64_encode_alloc (const gnutls_datum_t * data,
 }
 
 /**
-  * gnutls_srp_base64_decode - This function will decode base64 encoded data
+  * gnutls_srp_base64_decode - decode SRP-base64 encoded data
   * @b64_data: contain the encoded data
   * @result: the place where decoded data will be copied
   * @result_size: holds the size of the result
   *
-  * This function will decode the given encoded data, using the base64 encoding
-  * found in libsrp.
+  * This function will decode the given encoded data, using the base64
+  * encoding found in libsrp.
   *
   * Note that b64_data should be null terminated.
-  * 
-  * Returns GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not long enough,
-  * or 0 on success.
+  *
+  * Warning!  This base64 encoding is not the "standard" encoding, so
+  * do not use it for non-SRP purposes.
+  *
+  * Returns: %GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not
+  * long enough, or 0 on success.
   **/
 int
 gnutls_srp_base64_decode (const gnutls_datum_t * b64_data, char *result,
@@ -425,16 +439,20 @@ gnutls_srp_base64_decode (const gnutls_datum_t * b64_data, char *result,
 }
 
 /**
-  * gnutls_srp_base64_decode_alloc - This function will decode base64 encoded data
+  * gnutls_srp_base64_decode_alloc - decode SRP-base64 encoded data
   * @b64_data: contains the encoded data
   * @result: the place where decoded data lie
   *
   * This function will decode the given encoded data. The decoded data
-  * will be allocated, and stored into result.
-  * It will decode using the base64 algorithm found in libsrp.
+  * will be allocated, and stored into result.  It will decode using
+  * the base64 algorithm as used in libsrp.
   *
   * You should use gnutls_free() to free the returned data.
-  * 
+  *
+  * Warning!  This base64 encoding is not the "standard" encoding, so
+  * do not use it for non-SRP purposes.
+  *
+  * Returns: 0 on success, or an error code.
   **/
 int
 gnutls_srp_base64_decode_alloc (const gnutls_datum_t * b64_data,




From lists at roberthogan.net  Tue Feb 12 21:59:47 2008
From: lists at roberthogan.net (Robert Hogan)
Date: Tue, 12 Feb 2008 20:59:47 +0000
Subject: [Help-gnutls] Re: Using gnutls_srp_base64_decode to decode
	something encoded with SSL's EVP_Encode*
In-Reply-To: <87lk5qa2d9.fsf@mocca.josefsson.org>
References: <200802091140.26620.lists@roberthogan.net>
	<87lk5qa2d9.fsf@mocca.josefsson.org>
Message-ID: <200802122059.53013.lists@roberthogan.net>

On Tuesday 12 February 2008 10:35:46 Simon Josefsson wrote:
> Alas, base64 is not always "just base64".  SRP uses its own base64
> variant, so the encoding are not compatible.  I've tried to improve the
> documentation with the patch below, so that others doesn't run into this
> problem in the future.  Comments welcome.
>

Perhaps a patch for the man pages as well?

> The gnutls_pem_base64_decode function is also not right, it assume the
> data is PEM encoded.
>
> Right now I don't think there are any raw base64 decoding functions in
> gnutls, and frankly I'm not sure GnuTLS is a good place for such code.
> I happen to maintain a gnulib module for base64 encoding, please check
> it out:
>

It may not be right in principle but it would certainly be useful from an 
openSSL compatibility perspective.

> http://www.gnu.org/software/gnulib/
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/base64.c;hb=HEAD
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/base64.h;hb=HEAD
>

I ended up using a couple of snippets from the public domain code in libb64. 
This is because I just want to avoid the licensing issues with openSSL for 
packaging my project, and public domain code does the job equally well as 
gnutls.

> What were you going to use the base64 functions for?
>

For my project TorK ( a controller for Tor). Tor encodes 'router digests' in 
base64 and uses openSSL's EVP_Encode* to do the encoding. I just needed 
something equivalent that wasn't openSSL based.

Thanks for settling this one for me!

> /Simon
>
> diff --git a/lib/auth_srp_sb64.c b/lib/auth_srp_sb64.c
> index c3d5ccd..57dd521 100644
> --- a/lib/auth_srp_sb64.c
> +++ b/lib/auth_srp_sb64.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2001, 2002, 2003, 2004, 2005 Free Software Foundation
> + * Copyright (C) 2001, 2002, 2003, 2004, 2005, 2008 Free Software
> Foundation *
>   * Author: Nikos Mavrogiannopoulos
>   *
> @@ -309,15 +309,21 @@ _gnutls_sbase64_decode (uint8_t * data, size_t
> idata_size, uint8_t ** result) }
>
>  /**
> -  * gnutls_srp_base64_encode - This function will convert raw data to
> base64 encoded +  * gnutls_srp_base64_encode - Encode raw data using
> SRP-Base64
>    * @data: contain the raw data
>    * @result: the place where base64 data will be copied
>    * @result_size: holds the size of the result
>    *
> -  * This function will convert the given data to printable data, using the
> base64 -  * encoding, as used in the libsrp. This is the encoding used in
> SRP password files. -  * If the provided buffer is not long enough
> GNUTLS_E_SHORT_MEMORY_BUFFER is returned. -  *
> +  * This function will convert the given data to printable data, using
> +  * the base64 encoding, as used in the libsrp.  This is the encoding
> +  * used in SRP password files.  If the provided buffer is not long
> +  * enough GNUTLS_E_SHORT_MEMORY_BUFFER is returned.
> +  *
> +  * Warning!  This base64 encoding is not the "standard" encoding, so
> +  * do not use it for non-SRP purposes.
> +  *
> +  * Returns: %GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not
> +  * long enough, or 0 on success.
>    **/
>  int
>  gnutls_srp_base64_encode (const gnutls_datum_t * data, char *result,
> @@ -347,16 +353,21 @@ gnutls_srp_base64_encode (const gnutls_datum_t *
> data, char *result, }
>
>  /**
> -  * gnutls_srp_base64_encode_alloc - This function will convert raw data
> to Base64 encoded +  * gnutls_srp_base64_encode_alloc - encode raw data
> using SRP-Base64 * @data: contains the raw data
>    * @result: will hold the newly allocated encoded data
>    *
> -  * This function will convert the given data to printable data, using the
> base64 -  * encoding. This is the encoding used in SRP password files. This
> function will -  * allocate the required memory to hold the encoded data.
> +  * This function will convert the given data to printable data, using
> +  * the base64 encoding.  This is the encoding used in SRP password
> +  * files.  This function will allocate the required memory to hold
> +  * the encoded data.
>    *
>    * You should use gnutls_free() to free the returned data.
> -  *
> +  *
> +  * Warning!  This base64 encoding is not the "standard" encoding, so
> +  * do not use it for non-SRP purposes.
> +  *
> +  * Returns: 0 on success, or an error code.
>    **/
>  int
>  gnutls_srp_base64_encode_alloc (const gnutls_datum_t * data,
> @@ -384,18 +395,21 @@ gnutls_srp_base64_encode_alloc (const gnutls_datum_t
> * data, }
>
>  /**
> -  * gnutls_srp_base64_decode - This function will decode base64 encoded
> data +  * gnutls_srp_base64_decode - decode SRP-base64 encoded data
>    * @b64_data: contain the encoded data
>    * @result: the place where decoded data will be copied
>    * @result_size: holds the size of the result
>    *
> -  * This function will decode the given encoded data, using the base64
> encoding -  * found in libsrp.
> +  * This function will decode the given encoded data, using the base64
> +  * encoding found in libsrp.
>    *
>    * Note that b64_data should be null terminated.
> -  *
> -  * Returns GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not long
> enough, -  * or 0 on success.
> +  *
> +  * Warning!  This base64 encoding is not the "standard" encoding, so
> +  * do not use it for non-SRP purposes.
> +  *
> +  * Returns: %GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not
> +  * long enough, or 0 on success.
>    **/
>  int
>  gnutls_srp_base64_decode (const gnutls_datum_t * b64_data, char *result,
> @@ -425,16 +439,20 @@ gnutls_srp_base64_decode (const gnutls_datum_t *
> b64_data, char *result, }
>
>  /**
> -  * gnutls_srp_base64_decode_alloc - This function will decode base64
> encoded data +  * gnutls_srp_base64_decode_alloc - decode SRP-base64
> encoded data * @b64_data: contains the encoded data
>    * @result: the place where decoded data lie
>    *
>    * This function will decode the given encoded data. The decoded data
> -  * will be allocated, and stored into result.
> -  * It will decode using the base64 algorithm found in libsrp.
> +  * will be allocated, and stored into result.  It will decode using
> +  * the base64 algorithm as used in libsrp.
>    *
>    * You should use gnutls_free() to free the returned data.
> -  *
> +  *
> +  * Warning!  This base64 encoding is not the "standard" encoding, so
> +  * do not use it for non-SRP purposes.
> +  *
> +  * Returns: 0 on success, or an error code.
>    **/
>  int
>  gnutls_srp_base64_decode_alloc (const gnutls_datum_t * b64_data,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20080212/e08666ee/attachment.pgp>

From simon at josefsson.org  Wed Feb 13 10:43:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 13 Feb 2008 10:43:54 +0100
Subject: [Help-gnutls] Re: Using gnutls_srp_base64_decode to decode
	something encoded with SSL's EVP_Encode*
In-Reply-To: <200802122059.53013.lists@roberthogan.net> (Robert Hogan's
	message of "Tue, 12 Feb 2008 20:59:47 +0000")
References: <200802091140.26620.lists@roberthogan.net>
	<87lk5qa2d9.fsf@mocca.josefsson.org>
	<200802122059.53013.lists@roberthogan.net>
Message-ID: <87ejbh199h.fsf@mocca.josefsson.org>

Robert Hogan <lists at roberthogan.net> writes:

> On Tuesday 12 February 2008 10:35:46 Simon Josefsson wrote:
>> Alas, base64 is not always "just base64".  SRP uses its own base64
>> variant, so the encoding are not compatible.  I've tried to improve the
>> documentation with the patch below, so that others doesn't run into this
>> problem in the future.  Comments welcome.
>>
>
> Perhaps a patch for the man pages as well?

The man pages are generated from the source code.

>> What were you going to use the base64 functions for?
>
> For my project TorK ( a controller for Tor). Tor encodes 'router digests' in 
> base64 and uses openSSL's EVP_Encode* to do the encoding. I just needed 
> something equivalent that wasn't openSSL based.

Ok.  GnuTLS isn't a complete OpenSSL replacement, so I think for now we
won't add this feature.

> Thanks for settling this one for me!

Thanks for feedback.

/Simon




From joseph.ng at symbian.com  Wed Feb 13 12:36:36 2008
From: joseph.ng at symbian.com (joseph.ng at symbian.com)
Date: Wed, 13 Feb 2008 11:36:36 +0000
Subject: [Help-gnutls] gnutls-serv command line problem
Message-ID: <OFDC3CD844.2C7035CD-ON802573EE.003F8B19-802573EE.003FC6B1@Symbian.com>

Hi 

I am new to GnuTLS. On my PC I have installed Window GnuTLS 2.2.1. 

When I issue the following command: 

G:\my_server>gnutls-serv --http --x509fmtder --x509cafile IM-11-cert.der 
--x509certfile EU-0-cert.der --x509keyfile EU-0-key.txt -g --comp NULL 
--protocols TLS1.0 SSL3.0 -a --kx RSA 

I got: 

This method of specifying algorithms is deprecated. Please use the 
--priority option. 

Q1. I have tried a number of things but couldn't figure out what's wrong 
with the command line. Could you please tell me what is deprecated? 


Started up the server with the above command, I then try to start a client 
with: 

G:\my_client>gnutls-cli -p 5556 localhost --crlf 

and I got the following from the server: 

..... 
|<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_x509.c:1087 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_ARCFOUR_SHA1 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_ARCFOUR_MD5 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 
|<3>| HSK[a32570]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 
|<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:704 
|<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:462 
|<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:2014 
|<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:2542 
|<6>| BUF[HSK]: Cleared Data from buffer 
Error in handshake 
Error: Could not negotiate a supported cipher suite. 
|<4>| REC: Sending Alert[2|40] - Handshake failed 
|<4>| REC[a32570]: Sending Packet[0] Alert(21) with length: 2 
.... 

and the following from the client: 

... 
*** Fatal error: A TLS fatal alert has been received. 
*** Received alert [40]: Handshake failed 
*** Handshake has failed 
GNUTLS ERROR: A TLS fatal alert has been received. 
... 

Q2. I thought it would finished with TLS_RSA_AES_128_CBC_SHA1 (0x00, 
0x2f), but it didn't. Could you please tell me what's gone wrong with 
that? 


Thank you very much in anticipation. 


Regards, 
---------------
Joseph Ng

Discover tomorrow's technology on today's phones... Visit the
Symbian Stand, 8A77, Hall 8, at Mobile World Congress 2008, 11-14
February, Barcelona, Spain.
**********************************************************************
 Symbian Software Ltd is a company registered in England and Wales
with registered number 4190020 and registered office at 2-6
Boundary Row, Southwark, London,  SE1 8HP, UK. This message is
intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error
please notify postmaster at symbian.com and delete the message and any
attachments accompanying it immediately. Neither Symbian nor any of
its Affiliates accepts liability for any corruption, interception,
amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy.
**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080213/099c38fb/attachment.htm>

From simon at josefsson.org  Wed Feb 13 13:17:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 13 Feb 2008 13:17:01 +0100
Subject: [Help-gnutls] Re: gnutls-serv command line problem
In-Reply-To: <OFDC3CD844.2C7035CD-ON802573EE.003F8B19-802573EE.003FC6B1@Symbian.com>
	(joseph ng's message of "Wed, 13 Feb 2008 11:36:36 +0000")
References: <OFDC3CD844.2C7035CD-ON802573EE.003F8B19-802573EE.003FC6B1@Symbian.com>
Message-ID: <87bq6lm4oy.fsf@mocca.josefsson.org>

joseph.ng at symbian.com writes:

> Hi 
>
> I am new to GnuTLS. On my PC I have installed Window GnuTLS 2.2.1. 
>
> When I issue the following command: 
>
> G:\my_server>gnutls-serv --http --x509fmtder --x509cafile IM-11-cert.der 
> --x509certfile EU-0-cert.der --x509keyfile EU-0-key.txt -g --comp NULL 
> --protocols TLS1.0 SSL3.0 -a --kx RSA 
>
> I got: 
>
> This method of specifying algorithms is deprecated. Please use the 
> --priority option. 
>
> Q1. I have tried a number of things but couldn't figure out what's wrong 
> with the command line. Could you please tell me what is deprecated? 

Hi!  The --comp, --protocols, and --kx parameters.  With the new style,
you could type those as:

 --priority NORMAL:-VERS_TLS1_1

Compression is disabled by default.  I'm not sure how to force RSA key
exchange, but maybe you could try various strings, starting from NONE
and adding things instead of going from NORMAL and removing them.

However, the old style should continue to work, so you don't need to do
this.  But you can't use SPC to delimit protocols, try TLS1.0,SSL3.0
instead.

> Started up the server with the above command, I then try to start a client 
> with: 
>
> G:\my_client>gnutls-cli -p 5556 localhost --crlf 
>
> and I got the following from the server: 
>
> ..... 
> |<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_x509.c:1087 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_ARCFOUR_SHA1 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_ARCFOUR_MD5 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 
> |<3>| HSK[a32570]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 
> |<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:704 
> |<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:462 
> |<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:2014 
> |<2>| ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_handshake.c:2542 
> |<6>| BUF[HSK]: Cleared Data from buffer 
> Error in handshake 
> Error: Could not negotiate a supported cipher suite. 
> |<4>| REC: Sending Alert[2|40] - Handshake failed 
> |<4>| REC[a32570]: Sending Packet[0] Alert(21) with length: 2 
> .... 
>
> and the following from the client: 
>
> ... 
> *** Fatal error: A TLS fatal alert has been received. 
> *** Received alert [40]: Handshake failed 
> *** Handshake has failed 
> GNUTLS ERROR: A TLS fatal alert has been received. 
> ... 
>
> Q2. I thought it would finished with TLS_RSA_AES_128_CBC_SHA1 (0x00, 
> 0x2f), but it didn't. Could you please tell me what's gone wrong with 
> that? 

I tried the same command line parameters, and it worked fine here.
However, the first line:

 ASSERT: ../../../src/gnutls-2.2.1/lib/gnutls_x509.c:1087 

reveals that your key likely doesn't have the key encipherment bit set,
from the code:

	  if (encipher_type == CIPHER_ENCRYPT)
	    {
	      /* If the key exchange method requires an encipher
	       * type algorithm, and key's usage does not permit
	       * encipherment, then fail.
	       */
	      if (!(key_usage & KEY_KEY_ENCIPHERMENT))
		{
		  gnutls_assert ();
		  return GNUTLS_E_KEY_USAGE_VIOLATION;
		}
	    }

So you need to fix the certificate to permit encryption.

Does this help?  If you believe the certificate should work anyway,
please include it too so we can see it.

/Simon


>
>
> Thank you very much in anticipation. 
>
>
> Regards, 
> ---------------
> Joseph Ng
>
> Discover tomorrow's technology on today's phones... Visit the
> Symbian Stand, 8A77, Hall 8, at Mobile World Congress 2008, 11-14
> February, Barcelona, Spain.
> **********************************************************************
>  Symbian Software Ltd is a company registered in England and Wales
> with registered number 4190020 and registered office at 2-6
> Boundary Row, Southwark, London,  SE1 8HP, UK. This message is
> intended only for use by the named addressee and may contain
> privileged and/or confidential information. If you are not the
> named addressee you should not disseminate, copy or take any action
> in reliance on it. If you have received this message in error
> please notify postmaster at symbian.com and delete the message and any
> attachments accompanying it immediately. Neither Symbian nor any of
> its Affiliates accepts liability for any corruption, interception,
> amendment, tampering or viruses occurring to this message in
> transit or for any message sent by its employees which is not in
> compliance with Symbian corporate policy.
> **********************************************************************_______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls




From simon at josefsson.org  Wed Feb 13 13:19:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 13 Feb 2008 13:19:57 +0100
Subject: [Help-gnutls] Re: Help Required
In-Reply-To: <OFDA209B93.4BF0B31E-ON652573EE.004249CD-652573EE.0042AF5F@aricent.com>
	(Preeti Shandilya's message of "Wed, 13 Feb 2008 17:38:19 +0530")
References: <OFDA209B93.4BF0B31E-ON652573EE.004249CD-652573EE.0042AF5F@aricent.com>
Message-ID: <877ih9m4k2.fsf@mocca.josefsson.org>

I believe the entropy gathering code in libgcrypt is responsible; gnutls
doesn't ever fork.  Please ask on the libgcrypt mailing list.

/Simon

Preeti Shandilya <preeti.shandilya at aricent.com> writes:

> Hi Simon !
>
> I am facing a problem in TLS on HP-UX if you could help me
> When I invoke gnutls_global_init during initialization, the function 
> internally forking another process and I get following trace
>
> [New process 28026]
> warning: reading `r3' register: No data
> Detaching after fork from process 28026
>
> After this I see another process created in the system for the same 
> executable.
>
> So you have any idea why this is happening. If you know the solution, pl 
> let me know
>
> regards
> Preeti




From simon at josefsson.org  Wed Feb 13 18:47:55 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 13 Feb 2008 18:47:55 +0100
Subject: [Help-gnutls] Re: gnutls-serv command line problem
In-Reply-To: <OF5F4F0B56.0B20FD40-ON802573EE.005F9A4F-802573EE.00605FB9@Symbian.com>
	(joseph ng's message of "Wed, 13 Feb 2008 17:32:39 +0000")
References: <OF5F4F0B56.0B20FD40-ON802573EE.005F9A4F-802573EE.00605FB9@Symbian.com>
Message-ID: <87bq6kkat0.fsf@mocca.josefsson.org>

joseph.ng at symbian.com writes:

> Thanks Simon, for the very prompt reply.
>
> I have been playing a bit with gnutls. It looks like there is a bug in 
> gnutls_priority_init().
>
> As I try to use "--priority NONE....", it always return syntax error, no 
> matter how many parameters I put in.
>
> Syntax error at: 
> NONE:+VERS-TLS1.0:+AES-128-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+CTYPE-X.509
>
> Reading the above function, it looks like it does not handle "--priority 
> NONE".

Right, and this was fixed very recently, but has not been released yet.
Expect it in a new release shortly.  See discussion at:

http://lists.gnu.org/archive/html/gnutls-devel/2008-02/msg00002.html

Thanks,
/Simon




From h.habib at gmail.com  Fri Feb 15 12:09:42 2008
From: h.habib at gmail.com (Haidar Habib)
Date: Fri, 15 Feb 2008 16:39:42 +0530
Subject: [Help-gnutls] Unable to make gnutls in HPUX
Message-ID: <922d0b4d0802150309h4d448b12u256daee7461f8f4e@mail.gmail.com>

Hi,

I am trying to build gnutls-1.6.3 in HP-UX , but when i am running
make command after ./configure it showing following errors.

g++: +b: No such file or directory
g++: /saurabh/gnutls-1.6.3/lib/.libs:/usr/local/lib: No such file or directory

I am makeing from /saurabh/gnutls-1.6.3 directory and used configure
with following options

./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext
-Wl,+s -g" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"

pls help.
-- 
With regards,
Haidar Habib




From daniel at haxx.se  Fri Feb 15 23:47:08 2008
From: daniel at haxx.se (Daniel Stenberg)
Date: Fri, 15 Feb 2008 23:47:08 +0100 (CET)
Subject: [Help-gnutls] GnuTLS 2.2.1 problem returning
	GNUTLS_E_CONSTRAINT_ERROR
Message-ID: <Pine.LNX.4.64.0802152322230.29149@yvahk3.pbagnpgbe.fr>

Hey GnuTLS hackers!

Here's an interesting problem for you guys that Beber came up with in the 
#curl IRC channel. He's CC'ed here, please try to keep him in the loop when 
you respond to this.

#1 - build a somewhat recent curl with GnuTLS support (curl 7.17.1 and 7.18.0
      both work, presumably others too). GnuTLS 2.0.4 and 2.2.1 were tested
      and both showed this problem. The same curl versions built against
      OpenSSL instead work fine.

#2 - run this command:
      curl https://www.net222.caisse-epargne.fr -v

      This assumes you use a default cacert bundle, but I used the one Debian
      provides in /etc/ssl/certs/ca-certificates.crt with an extra option like:
      --cacert /etc/ssl/certs/ca-certificates.crt. Or, thanks to a flaw in
      these curl versions, use -k to skip the server cert verification - but it
      will still try to extract the server cert which is what fails.

#3 - the output from curl then becomes:

* About to connect() to www.net222.caisse-epargne.fr port 443 (#0)
*   Trying 91.135.177.17... connected
* Connected to www.net222.caisse-epargne.fr (91.135.177.17) port 443 (#0)
* found 102 certificates in /etc/ssl/certs/ca-certificates.crt
* server cert verify failed: -101
* Closing connection #0
curl: (35) server cert verify failed: -101

The culprit here for you is the -101. That's 
gnutls_certificate_verify_peers2() returning GNUTLS_E_CONSTRAINT_ERROR.





From daniel at haxx.se  Sat Feb 16 11:14:20 2008
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 16 Feb 2008 11:14:20 +0100 (CET)
Subject: [Help-gnutls] GnuTLS 2.2.1 memory leaks or just bad usage?
Message-ID: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>

Hi again,

When I run valgrind on curl built with GnuTLS and run it like this:

$ valgrind --leak-check=full curl https://www.openssl.org/ -v -k

I get two different leaks reported, and while I'm not done researching these I 
thought I'd post them here in case someone else wants to help out:

(It's not obvious to me that we're doing anything "illegal" in terms of API 
usage in the libcurl code.)

==19167== 128 bytes in 1 blocks are definitely lost in loss record 2 of 9
==19167==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==19167==    by 0x40F64A3: _gnutls_mpi_dprint_lz (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x4102A40: _gnutls_dh_set_peer_public (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x4108110: _gnutls_proc_dh_common_server_kx (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x40FFEE8: (within /usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x40ED6D8: _gnutls_recv_server_kx_message (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x40E9C8E: _gnutls_handshake_client (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x40EA589: gnutls_handshake (in /usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x808D428: handshake (gtls.c:156)
==19167==    by 0x808D9BD: Curl_gtls_connect (gtls.c:326)
==19167==    by 0x8063372: Curl_ssl_connect (sslgen.c:215)
==19167==    by 0x806E92A: Curl_http_connect (http.c:1700)
==19167==
==19167==
==19167== 3,506 bytes in 2 blocks are definitely lost in loss record 5 of 9
==19167==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==19167==    by 0x40F5D85: _gnutls_session_pack (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x40F056C: gnutls_session_get_data (in 
/usr/lib/libgnutls.so.26.1.2)
==19167==    by 0x808DFAC: Curl_gtls_connect (gtls.c:506)
==19167==    by 0x8063372: Curl_ssl_connect (sslgen.c:215)
==19167==    by 0x806E92A: Curl_http_connect (http.c:1700)
==19167==    by 0x807C337: Curl_protocol_connect (url.c:2782)
==19167==    by 0x807E962: SetupConnection (url.c:4268)
==19167==    by 0x807EAC2: Curl_connect (url.c:4342)
==19167==    by 0x8086EDD: connect_host (transfer.c:2271)
==19167==    by 0x808712E: Curl_perform (transfer.c:2367)
==19167==    by 0x805BF91: curl_easy_perform (easy.c:508)
==19167==
==19167== LEAK SUMMARY:
==19167==    definitely lost: 3,634 bytes in 3 blocks.
==19167==      possibly lost: 0 bytes in 0 blocks.
==19167==    still reachable: 68,792 bytes in 4,040 blocks.
==19167==         suppressed: 0 bytes in 0 blocks.
==19167== Reachable blocks (those to which a pointer was found) are not shown.





From nmav at gnutls.org  Sat Feb 16 12:36:46 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 16 Feb 2008 13:36:46 +0200
Subject: [Help-gnutls] GnuTLS 2.2.1 memory leaks or just bad usage?
In-Reply-To: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>
References: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>
Message-ID: <200802161336.47349.nmav@gnutls.org>

On Saturday 16 February 2008, Daniel Stenberg wrote:
> Hi again,
>
> When I run valgrind on curl built with GnuTLS and run it like this:
>
> $ valgrind --leak-check=full curl https://www.openssl.org/ -v -k
>
> I get two different leaks reported, and while I'm not done researching
> these I thought I'd post them here in case someone else wants to help out:

Hello,
 Thank you for reporting this. Does the attached patch solve the leaks?

regards,
Nikos
-------------- next part --------------
diff --git a/lib/gnutls_auth.c b/lib/gnutls_auth.c
index 040bf04..bfa015c 100644
--- a/lib/gnutls_auth.c
+++ b/lib/gnutls_auth.c
@@ -394,14 +394,15 @@ _gnutls_auth_info_set (gnutls_session_t session,
 	   */
 	  if (gnutls_auth_get_type (session) != session->key->auth_info_type)
 	    {
+	      _gnutls_free_auth_info (session);
+
 	      session->key->auth_info =
-		gnutls_realloc_fast (session->key->auth_info, size);
+		gnutls_calloc (1, size);
 	      if (session->key->auth_info == NULL)
 		{
 		  gnutls_assert ();
 		  return GNUTLS_E_MEMORY_ERROR;
 		}
-	      memset (session->key->auth_info, 0, size);
 	      session->key->auth_info_type = type;
 	      session->key->auth_info_size = size;
 	    }
diff --git a/lib/gnutls_session.c b/lib/gnutls_session.c
index a1cd173..3048115 100644
--- a/lib/gnutls_session.c
+++ b/lib/gnutls_session.c
@@ -61,12 +61,19 @@ gnutls_session_get_data (gnutls_session_t session,
   *session_data_size = psession.size;
 
   if (psession.size > *session_data_size)
-    return GNUTLS_E_SHORT_MEMORY_BUFFER;
+    {
+      ret = GNUTLS_E_SHORT_MEMORY_BUFFER;
+      goto error;
+    }
 
   if (session_data != NULL)
     memcpy (session_data, psession.data, psession.size);
 
-  return 0;
+  ret = 0;
+
+error:
+  _gnutls_free_datum( &psession);
+  return ret;
 }
 
 /**

From nmav at gnutls.org  Sat Feb 16 12:56:12 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 16 Feb 2008 13:56:12 +0200
Subject: Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning
	GNUTLS_E_CONSTRAINT_ERROR
In-Reply-To: <c331d99a0802160354j743eba64y2331b013f094b700@mail.gmail.com>
References: <Pine.LNX.4.64.0802152322230.29149@yvahk3.pbagnpgbe.fr>
	<c331d99a0802160354j743eba64y2331b013f094b700@mail.gmail.com>
Message-ID: <c331d99a0802160356s903cf63p3625fdebdd984e7f@mail.gmail.com>

On Feb 16, 2008 12:47 AM, Daniel Stenberg <daniel at haxx.se> wrote:
> Hey GnuTLS hackers!
> Here's an interesting problem for you guys that Beber came up with in the
> #curl IRC channel. He's CC'ed here, please try to keep him in the loop when
> you respond to this.
> *   Trying 91.135.177.17... connected
> * Connected to www.net222.caisse-epargne.fr (91.135.177.17) port 443 (#0)
> * found 102 certificates in /etc/ssl/certs/ca-certificates.crt
> * server cert verify failed: -101
> * Closing connection #0
> curl: (35) server cert verify failed: -101
>
> The culprit here for you is the -101. That's
> gnutls_certificate_verify_peers2() returning GNUTLS_E_CONSTRAINT_ERROR.

I can see two cases where this can be returned.
1. the verify depth of the certificate is quite high (ie the chain
being verified is long).
The default maximum depth is 6. Although it is possible to have such
long chain, it is most probably
a configuration error if the server sends more than 6 certificates.
- this limit can be adjusted by gnutls_certificate_set_verify_limits()

2. the key bits of the certificates are longer than the maximum allowed (8200).
this limit can also be adjusted by the same function.

regards,
Nikos




From daniel at haxx.se  Sat Feb 16 14:11:43 2008
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 16 Feb 2008 14:11:43 +0100 (CET)
Subject: [Help-gnutls] GnuTLS 2.2.1 memory leaks or just bad usage?
In-Reply-To: <200802161336.47349.nmav@gnutls.org>
References: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>
	<200802161336.47349.nmav@gnutls.org>
Message-ID: <Pine.LNX.4.64.0802161409200.14276@yvahk3.pbagnpgbe.fr>

On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:

>> I get two different leaks reported, and while I'm not done researching
>> these I thought I'd post them here in case someone else wants to help out:
>
> Thank you for reporting this. Does the attached patch solve the leaks?

Thanks!

First it doesn't build, it needs a #include "gnutls_datum.h" in 
gnutls_session.c! (If you want me to, I can produce an updated patch that 
applies cleanly.)

Then, yes it _does_ fix the worst leaks in my test case. The reamining leak 
now looks like this (with a build using only -g and not -O2 that otherwise 
confuse symbols like the ones in my initial report):

==13872== 128 bytes in 1 blocks are definitely lost in loss record 2 of 8
==13872==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==13872==    by 0x40FBC15: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
==13872==    by 0x410B4C3: _gnutls_dh_set_peer_public (gnutls_state.c:474)
==13872==    by 0x411354E: _gnutls_proc_dh_common_server_kx 
(auth_dh_common.c:297)
==13872==    by 0x4108404: proc_dhe_server_kx (auth_dhe.c:199)
==13872==    by 0x40F079F: _gnutls_recv_server_kx_message (gnutls_kx.c:401)
==13872==    by 0x40EB332: _gnutls_handshake_client (gnutls_handshake.c:2342)
==13872==    by 0x40EADF9: gnutls_handshake (gnutls_handshake.c:2238)
==13872==    by 0x8083C40: handshake (gtls.c:156)
==13872==    by 0x80841D5: Curl_gtls_connect (gtls.c:326)
==13872==    by 0x806169A: Curl_ssl_connect (sslgen.c:215)
==13872==    by 0x806C605: Curl_http_connect (http.c:1700)





From daniel at haxx.se  Sat Feb 16 14:25:12 2008
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 16 Feb 2008 14:25:12 +0100 (CET)
Subject: Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning
	GNUTLS_E_CONSTRAINT_ERROR
In-Reply-To: <c331d99a0802160356s903cf63p3625fdebdd984e7f@mail.gmail.com>
References: <Pine.LNX.4.64.0802152322230.29149@yvahk3.pbagnpgbe.fr>
	<c331d99a0802160354j743eba64y2331b013f094b700@mail.gmail.com>
	<c331d99a0802160356s903cf63p3625fdebdd984e7f@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0802161414200.14276@yvahk3.pbagnpgbe.fr>

On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:

>> The culprit here for you is the -101. That's
>> gnutls_certificate_verify_peers2() returning GNUTLS_E_CONSTRAINT_ERROR.
>
> I can see two cases where this can be returned.
> 1. the verify depth of the certificate is quite high (ie the chain
> being verified is long).
> The default maximum depth is 6. Although it is possible to have such
> long chain, it is most probably
> a configuration error if the server sends more than 6 certificates.
> - this limit can be adjusted by gnutls_certificate_set_verify_limits()
>
> 2. the key bits of the certificates are longer than the maximum allowed 
> (8200). this limit can also be adjusted by the same function.

But seeing this is a live server used by mere mortals out there (it is a bank 
after all), wouldn't it perhaps be an indication that the defaults are a bit 
too restrictive? Also, both OpenSSL and Firefox (NSS) deal with it by default.

However, I tried adding this:

     gnutls_certificate_set_verify_limits(conn->ssl[sockindex].cred,
                                          20200, 18);

Is there any way for me to figure out sensible values for me to set to this 
function? I just upped them a couple of times until the function worked!

And yes, it now makes gnutls_certificate_verify_peers2() return success but 
then... verify_status still contained the GNUTLS_CERT_INVALID bit. So 
something still isn't liking this server!




From nmav at gnutls.org  Sat Feb 16 22:39:45 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 16 Feb 2008 23:39:45 +0200
Subject: [Help-gnutls] GnuTLS 2.2.1 memory leaks or just bad usage?
In-Reply-To: <Pine.LNX.4.64.0802161409200.14276@yvahk3.pbagnpgbe.fr>
References: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>
	<200802161336.47349.nmav@gnutls.org>
	<Pine.LNX.4.64.0802161409200.14276@yvahk3.pbagnpgbe.fr>
Message-ID: <47B75821.4070403@gnutls.org>

O/H Daniel Stenberg ??????:
> First it doesn't build, it needs a #include "gnutls_datum.h" in 
> gnutls_session.c! (If you want me to, I can produce an updated patch 
> that applies cleanly.)
>
> Then, yes it _does_ fix the worst leaks in my test case. The reamining 
> leak now looks like this (with a build using only -g and not -O2 that 
> otherwise confuse symbols like the ones in my initial report):
>
> ==13872== 128 bytes in 1 blocks are definitely lost in loss record 2 of 8
> ==13872== at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==13872== by 0x40FBC15: _gnutls_mpi_dprint_lz (gnutls_mpi.c:146)
> ==13872== by 0x410B4C3: _gnutls_dh_set_peer_public (gnutls_state.c:474)
> ==13872== by 0x411354E: _gnutls_proc_dh_common_server_kx 
> (auth_dh_common.c:297)
> ==13872== by 0x4108404: proc_dhe_server_kx (auth_dhe.c:199)
> ==13872== by 0x40F079F: _gnutls_recv_server_kx_message (gnutls_kx.c:401)
> ==13872== by 0x40EB332: _gnutls_handshake_client 
> (gnutls_handshake.c:2342)
> ==13872== by 0x40EADF9: gnutls_handshake (gnutls_handshake.c:2238)
> ==13872== by 0x8083C40: handshake (gtls.c:156)
> ==13872== by 0x80841D5: Curl_gtls_connect (gtls.c:326)
> ==13872== by 0x806169A: Curl_ssl_connect (sslgen.c:215)
> ==13872== by 0x806C605: Curl_http_connect (http.c:1700)
>
What about this patch? It's quite intrusive. My development environment 
is almost inexistent now, thus I'd appreciate if you or any other 
volunteers could test it.

regards,
Nikos

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20080216/05b21555/attachment.txt>

From nmav at gnutls.org  Sat Feb 16 22:44:04 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 16 Feb 2008 23:44:04 +0200
Subject: Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning
	GNUTLS_E_CONSTRAINT_ERROR
In-Reply-To: <Pine.LNX.4.64.0802161414200.14276@yvahk3.pbagnpgbe.fr>
References: <Pine.LNX.4.64.0802152322230.29149@yvahk3.pbagnpgbe.fr>
	<c331d99a0802160354j743eba64y2331b013f094b700@mail.gmail.com>
	<c331d99a0802160356s903cf63p3625fdebdd984e7f@mail.gmail.com>
	<Pine.LNX.4.64.0802161414200.14276@yvahk3.pbagnpgbe.fr>
Message-ID: <47B75924.40301@gnutls.org>

O/H Daniel Stenberg ??????:
> On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:
>
>>> The culprit here for you is the -101. That's
>>> gnutls_certificate_verify_peers2() returning GNUTLS_E_CONSTRAINT_ERROR.
>>
>> I can see two cases where this can be returned.
>> 1. the verify depth of the certificate is quite high (ie the chain
>> being verified is long).
>> The default maximum depth is 6. Although it is possible to have such
>> long chain, it is most probably
>> a configuration error if the server sends more than 6 certificates.
>> - this limit can be adjusted by gnutls_certificate_set_verify_limits()
>>
>> 2. the key bits of the certificates are longer than the maximum 
>> allowed (8200). this limit can also be adjusted by the same function.
>
> But seeing this is a live server used by mere mortals out there (it is 
> a bank after all), wouldn't it perhaps be an indication that the 
> defaults are a bit too restrictive? Also, both OpenSSL and Firefox 
> (NSS) deal with it by default.
>
> However, I tried adding this:
>
> gnutls_certificate_set_verify_limits(conn->ssl[sockindex].cred,
> 20200, 18);
>
> Is there any way for me to figure out sensible values for me to set to 
> this function? I just upped them a couple of times until the function 
> worked!
>
> And yes, it now makes gnutls_certificate_verify_peers2() return 
> success but then... verify_status still contained the 
> GNUTLS_CERT_INVALID bit. So something still isn't liking this server!
I'm really loaded to check it right now, thus I've added a ticket at:
http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/17#preview

The original idea was to avoid denial of service attacks by a server 
(sending you 9999 certificates of 99999 bits). That would make the 
client unresponsive. Using more sensible defaults is an option. (Patches 
are always accepted! :)

regards,
Nikos





From daniel at haxx.se  Sat Feb 16 22:48:54 2008
From: daniel at haxx.se (Daniel Stenberg)
Date: Sat, 16 Feb 2008 22:48:54 +0100 (CET)
Subject: [Help-gnutls] GnuTLS 2.2.1 memory leaks or just bad usage?
In-Reply-To: <47B75821.4070403@gnutls.org>
References: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>
	<200802161336.47349.nmav@gnutls.org>
	<Pine.LNX.4.64.0802161409200.14276@yvahk3.pbagnpgbe.fr>
	<47B75821.4070403@gnutls.org>
Message-ID: <Pine.LNX.4.64.0802162244360.9918@yvahk3.pbagnpgbe.fr>

On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:

>> Then, yes it _does_ fix the worst leaks in my test case. The reamining leak 
>> now looks like this (with a build using only -g and not -O2 that otherwise 
>> confuse symbols like the ones in my initial report):
>> 
>> ==13872== 128 bytes in 1 blocks are definitely lost in loss record 2 of 8

> What about this patch? It's quite intrusive. My development environment is 
> almost inexistent now, thus I'd appreciate if you or any other volunteers 
> could test it.

Bingo! No leak left in this test case with this patch applied - I did apply it 
over the previous one you posted, I got one reject but that turned out to be 
because that was already changed in the previous patch.




From nmav at gnutls.org  Sat Feb 16 23:24:59 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Feb 2008 00:24:59 +0200
Subject: [Help-gnutls] GnuTLS 2.2.1 memory leaks or just bad usage?
In-Reply-To: <Pine.LNX.4.64.0802162244360.9918@yvahk3.pbagnpgbe.fr>
References: <Pine.LNX.4.64.0802161111440.6374@yvahk3.pbagnpgbe.fr>
	<200802161336.47349.nmav@gnutls.org>
	<Pine.LNX.4.64.0802161409200.14276@yvahk3.pbagnpgbe.fr>
	<47B75821.4070403@gnutls.org>
	<Pine.LNX.4.64.0802162244360.9918@yvahk3.pbagnpgbe.fr>
Message-ID: <47B762BB.6050704@gnutls.org>

O/H Daniel Stenberg ??????:
> On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:
>
>>> Then, yes it _does_ fix the worst leaks in my test case. The 
>>> reamining leak now looks like this (with a build using only -g and 
>>> not -O2 that otherwise confuse symbols like the ones in my initial 
>>> report):
>>>
>>> ==13872== 128 bytes in 1 blocks are definitely lost in loss record 2 
>>> of 8
>
>> What about this patch? It's quite intrusive. My development 
>> environment is almost inexistent now, thus I'd appreciate if you or 
>> any other volunteers could test it.
>
> Bingo! No leak left in this test case with this patch applied - I did 
> apply it over the previous one you posted, I got one reject but that 
> turned out to be because that was already changed in the previous patch.
Thank you!




From nmav at gnutls.org  Sun Feb 17 15:11:17 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Feb 2008 16:11:17 +0200
Subject: Fwd: [Help-gnutls] GnuTLS 2.2.1 problem returning
	GNUTLS_E_CONSTRAINT_ERROR
In-Reply-To: <47B75924.40301@gnutls.org>
References: <Pine.LNX.4.64.0802152322230.29149@yvahk3.pbagnpgbe.fr>
	<c331d99a0802160354j743eba64y2331b013f094b700@mail.gmail.com>
	<c331d99a0802160356s903cf63p3625fdebdd984e7f@mail.gmail.com>
	<Pine.LNX.4.64.0802161414200.14276@yvahk3.pbagnpgbe.fr>
	<47B75924.40301@gnutls.org>
Message-ID: <47B84085.30602@gnutls.org>

O/H Nikos Mavrogiannopoulos ??????:
> O/H Daniel Stenberg ??????:
>> On Sat, 16 Feb 2008, Nikos Mavrogiannopoulos wrote:
>>
>>>> The culprit here for you is the -101. That's
>>>> gnutls_certificate_verify_peers2() returning 
>>>> GNUTLS_E_CONSTRAINT_ERROR.
>>>
>>> I can see two cases where this can be returned.
>>> 1. the verify depth of the certificate is quite high (ie the chain
>>> being verified is long).
>>> The default maximum depth is 6. Although it is possible to have such
>>> long chain, it is most probably
>>> a configuration error if the server sends more than 6 certificates.
>>> - this limit can be adjusted by gnutls_certificate_set_verify_limits()
>>>
>>> 2. the key bits of the certificates are longer than the maximum 
>>> allowed (8200). this limit can also be adjusted by the same function.
>>
>> But seeing this is a live server used by mere mortals out there (it 
>> is a bank after all), wouldn't it perhaps be an indication that the 
>> defaults are a bit too restrictive? Also, both OpenSSL and Firefox 
>> (NSS) deal with it by default.
>>
>> However, I tried adding this:
>>
>> gnutls_certificate_set_verify_limits(conn->ssl[sockindex].cred,
>> 20200, 18);
>>
>> Is there any way for me to figure out sensible values for me to set 
>> to this function? I just upped them a couple of times until the 
>> function worked!
>>
>> And yes, it now makes gnutls_certificate_verify_peers2() return 
>> success but then... verify_status still contained the 
>> GNUTLS_CERT_INVALID bit. So something still isn't liking this server!
> I'm really loaded to check it right now, thus I've added a ticket at:
> http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/17#preview
>
> The original idea was to avoid denial of service attacks by a server 
> (sending you 9999 certificates of 99999 bits). That would make the 
> client unresponsive. Using more sensible defaults is an option. 
> (Patches are always accepted! :)

It seems my time wasn't that limited and the fix was quite easy.
The fix is in this commit:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=36bc9d48a807e303a5fe3c459ebd89389298d787


regards,
Nikos





From h.habib at gmail.com  Mon Feb 18 08:30:47 2008
From: h.habib at gmail.com (Haidar Habib)
Date: Mon, 18 Feb 2008 13:00:47 +0530
Subject: [Help-gnutls] compilation issues of gnutls-1.4.1 in HPUX
Message-ID: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>

Hi,

Following errors occurred when I compiled gnutls-1.4.1. Befor this I
successfully built libgcrypt-1.2.3 and libgcrypt-1.2.3.
Pls give some suggestions in this regard.

Error 359: "serv.c", line 646 # The expression on the left side of the
'->' (arrow member access operator) must be a pointer to completed
struct object type; the type of the left side is 'const
sockaddr_storage *' and 'struct sockaddr_storage' has not been defined
yet.
      switch (addr->ss_family)
              ^^^^
Error 628: "serv.c", line 673 # "sockaddr_storage#5 client_address"
["serv.c", line 673] cannot be defined to have an incomplete type.
      struct sockaddr_storage client_address;
                              ^^^^^^^^^^^^^^
Warning 942: "serv.c", line 916 # Types 'int *' and 'fd_set *' are not
assignment-compatible.
          n = select (n + 1, &rd, &wr, NULL, NULL);
                             ^
Warning 942: "serv.c", line 916 # Types 'int *' and 'fd_set *' are not
assignment-compatible.
          n = select (n + 1, &rd, &wr, NULL, NULL);
                                  ^
Error 244: "serv.c", line 932 # sizeof may not be applied to an
undefined struct.
              calen = sizeof (client_address);

-- 
With regards,
Haidar Habib




From simon at josefsson.org  Mon Feb 18 12:21:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 18 Feb 2008 12:21:02 +0100
Subject: [Help-gnutls] Re: Unable to make gnutls in HPUX
In-Reply-To: <922d0b4d0802150309h4d448b12u256daee7461f8f4e@mail.gmail.com>
	(Haidar Habib's message of "Fri, 15 Feb 2008 16:39:42 +0530")
References: <922d0b4d0802150309h4d448b12u256daee7461f8f4e@mail.gmail.com>
Message-ID: <87wsp2tsrl.fsf@mocca.josefsson.org>

"Haidar Habib" <h.habib at gmail.com> writes:

> Hi,
>
> I am trying to build gnutls-1.6.3 in HP-UX , but when i am running
> make command after ./configure it showing following errors.
>
> g++: +b: No such file or directory
> g++: /saurabh/gnutls-1.6.3/lib/.libs:/usr/local/lib: No such file or directory
>
> I am makeing from /saurabh/gnutls-1.6.3 directory and used configure
> with following options
>
> ./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext
> -Wl,+s -g" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"

If you don't need the C++ library, try adding --disable-cxx when running
./configure.

Otherwise, please send the output from running ./configure, and the
contents of the config.log file.

/Simon




From h.habib at gmail.com  Mon Feb 18 13:06:14 2008
From: h.habib at gmail.com (Haidar Habib)
Date: Mon, 18 Feb 2008 17:36:14 +0530
Subject: [Help-gnutls] Re: Unable to make gnutls in HPUX
In-Reply-To: <87wsp2tsrl.fsf@mocca.josefsson.org>
References: <922d0b4d0802150309h4d448b12u256daee7461f8f4e@mail.gmail.com>
	<87wsp2tsrl.fsf@mocca.josefsson.org>
Message-ID: <922d0b4d0802180406i12d8ca07ldf6240e984f97490@mail.gmail.com>

Hi Simon,

Actually my application is written in C++ so I think C++ library is needed.

As suggested by someone I included CXX=aCC also at configure time and
now I got the following errors.

I have also included output of ./configure and config.log files.

Regards,
Haidar


Error 19: "../includes/gnutls/gnutlsxx.h", line 10 # Unexpected 'std'.
    class exception: public std::exception
                            ^^^
Error 19: "../includes/gnutls/gnutlsxx.h", line 179 # Unexpected 'std'.
            bool get_peers_certificate(std::vector<gnutls_datum_t>
&out_certs) const;
                                       ^^^
Error 19: "gnutlsxx.cpp", line 237 # Unexpected 'std'.
    bool session::get_peers_certificate(std::vector<gnutls_datum_t>
&out_certs) const
                                        ^^^
Error 698: Exact position unknown; near ["/opt/aCC/include/exception",
line 46]. # The declarations class exception and class exception are
both visible and neither is preferred under the name lookup rules.
Error 698: Exact position unknown; near ["/opt/aCC/include/exception",
line 46]. # The declarations class exception and class exception are
both visible and neither is preferred under the name lookup rules.
Error 221: "gnutlsxx.cpp", line 845 # Member 'get_code' not declared
in class exception ["/opt/aCC/include/exception", line 53].
    int exception::get_code()
                   ^^^^^^^^
Error 172: "gnutlsxx.cpp", line 847 # Undeclared variable 'retcode'.
        return retcode;
               ^^^^^^^
Error 698: Exact position unknown; near ["/opt/aCC/include/exception",
line 46]. # The declarations class exception and class exception are
both visible and neither is preferred under the name lookup rules.
Error 174: "gnutlsxx.cpp", line 850 # Function redefinition;
previously defined as "const char *exception::what() const" at
["/opt/aCC/include/exception", line 59].
    const char* exception::what() const throw()
                           ^^^^
Error 445: "gnutlsxx.cpp", line 850 # Cannot recover from earlier errors.
    const char* exception::what() const throw()


On Feb 18, 2008 4:51 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
> "Haidar Habib" <h.habib at gmail.com> writes:
>
> > Hi,
> >
> > I am trying to build gnutls-1.6.3 in HP-UX , but when i am running
> > make command after ./configure it showing following errors.
> >
> > g++: +b: No such file or directory
> > g++: /saurabh/gnutls-1.6.3/lib/.libs:/usr/local/lib: No such file or directory
> >
> > I am makeing from /saurabh/gnutls-1.6.3 directory and used configure
> > with following options
> >
> > ./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext
> > -Wl,+s -g" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"
>
> If you don't need the C++ library, try adding --disable-cxx when running
> ./configure.
>
> Otherwise, please send the output from running ./configure, and the
> contents of the config.log file.
>
> /Simon
>



On Feb 18, 2008 4:51 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
> "Haidar Habib" <h.habib at gmail.com> writes:
>
> > Hi,
> >
> > I am trying to build gnutls-1.6.3 in HP-UX , but when i am running
> > make command after ./configure it showing following errors.
> >
> > g++: +b: No such file or directory
> > g++: /saurabh/gnutls-1.6.3/lib/.libs:/usr/local/lib: No such file or directory
> >
> > I am makeing from /saurabh/gnutls-1.6.3 directory and used configure
> > with following options
> >
> > ./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext
> > -Wl,+s -g" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"
>
> If you don't need the C++ library, try adding --disable-cxx when running
> ./configure.
>
> Otherwise, please send the output from running ./configure, and the
> contents of the config.log file.
>
> /Simon
>



-- 
With regards,
Md. Haidar Habib
Senior Software Engineer
haidar.habib at aricent.com
Aricent
Gurgaon
Cell- 09350042332
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: configure_output.txt
URL: </pipermail/attachments/20080218/3474a07c/attachment.txt>

From kristian.martens at freenet.de  Tue Feb 19 15:37:42 2008
From: kristian.martens at freenet.de (kristian.martens at freenet.de)
Date: Tue, 19 Feb 2008 15:37:42 +0100
Subject: [Help-gnutls] TLS message length differs
Message-ID: <E1JRTbK-000888-4k@www6.emo.freenet-rz.de>

Hello,

When monitoring the TLS handshake I observed that in the second TLS handshake message coming from a client the TLS message length always differs even though the same session parameters are used (each time a new session is started and completed). 
Does anyone have a good explanation for this? I am using X.509 certificates for authentication (on client and server side) and the certificates do not change.

The message content should be as follows: certificate,client_key_exchange,certificate_verfy, change_cipher_spec,finished

Everything works fine but I am just wondering why this happens.

Thanks in advance.

Regards,
Kris












From nmav at gnutls.org  Tue Feb 19 19:36:54 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 19 Feb 2008 20:36:54 +0200
Subject: [Help-gnutls] TLS message length differs
In-Reply-To: <E1JRTbK-000888-4k@www6.emo.freenet-rz.de>
References: <E1JRTbK-000888-4k@www6.emo.freenet-rz.de>
Message-ID: <47BB21C6.7020406@gnutls.org>

kristian.martens at freenet.de wrote:
> Hello,
> 
> When monitoring the TLS handshake I observed that in the second TLS handshake message coming from a client the TLS message length always differs even though the same session parameters are used (each time a new session is started and completed). 
> Does anyone have a good explanation for this? I am using X.509 certificates for authentication (on client and server side) and the certificates do not change.

I don't understand which message you say it is different. Is it an 
encrypted message?

regards,
Nikos




From kristian.martens at freenet.de  Wed Feb 20 08:26:07 2008
From: kristian.martens at freenet.de (kristian.martens at freenet.de)
Date: Wed, 20 Feb 2008 08:26:07 +0100
Subject: [Help-gnutls] TLS message length differs
Message-ID: <E1JRjLD-0001Kb-Ii@www4.emo.freenet-rz.de>

Yes, it seems to be related to he FINISHED message, which is the first encrypted message.

>From the debug trace I can see the following difference (245 bytes <> 277 bytes):

1. trace:

...
BUF[HSK]: Peeked 0 bytes of Data
BUF[HSK]: Emptied buffer
HSK[11c03f60]: FINISHED was send [16 bytes]
BUF[HSK]: Peeked 0 bytes of Data
BUF[HSK]: Emptied buffer
REC[11c03f60]: Sending Packet[0] Handshake(22) with length: 16
WRITE: Will write 245 bytes to 250844536.
...

2. trace:

...
BUF[HSK]: Peeked 0 bytes of Data
BUF[HSK]: Emptied buffer
HSK[11c03f60]: FINISHED was send [16 bytes]
BUF[HSK]: Peeked 0 bytes of Data
BUF[HSK]: Emptied buffer
REC[11c03f60]: Sending Packet[0] Handshake(22) with length: 16
WRITE: Will write 277 bytes to 250844536.
...

Regards,
Kris

----- original Nachricht --------

Betreff: Re: [Help-gnutls] TLS message length differs
Gesendet: Di 19 Feb 2008 19:36:54 CET
Von: "Nikos Mavrogiannopoulos"<nmav at gnutls.org>

> kristian.martens at freenet.de wrote:
> > Hello,
> > 
> > When monitoring the TLS handshake I observed that in the second TLS
> handshake message coming from a client the TLS message length always differs
> even though the same session parameters are used (each time a new session is
> started and completed). 
> > Does anyone have a good explanation for this? I am using X.509
> certificates for authentication (on client and server side) and the
> certificates do not change.
> 
> I don't understand which message you say it is different. Is it an 
> encrypted message?
> 
> regards,
> Nikos
> 

--- original Nachricht Ende ----




Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html





From nmav at gnutls.org  Wed Feb 20 09:45:18 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 Feb 2008 10:45:18 +0200
Subject: [Help-gnutls] TLS message length differs
In-Reply-To: <E1JRjLD-0001Kb-Ii@www4.emo.freenet-rz.de>
References: <E1JRjLD-0001Kb-Ii@www4.emo.freenet-rz.de>
Message-ID: <c331d99a0802200045k474fc74dud60b5e8c91ca67b6@mail.gmail.com>

On Feb 20, 2008 9:26 AM,  <kristian.martens at freenet.de> wrote:
> Yes, it seems to be related to he FINISHED message, which is the first encrypted message.
> From the debug trace I can see the following difference (245 bytes <> 277 bytes):

This is normal. Encrypted messages in gnutls use a random padding so
their size is never the same.
This will prevent certain guessing attacks against the encrypted data.
For the finished messages it might not be an issue, but when
encrypting a URL or a web page, the size of the encrypted data might
reveal the actual page being transfered.

regards,
Nikos




From simon at josefsson.org  Thu Feb 21 10:00:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 21 Feb 2008 10:00:29 +0100
Subject: [Help-gnutls] GnuTLS 2.2.2
Message-ID: <87ve4ivg42.fsf@mocca.josefsson.org>

We are pleased to announce a new stable GnuTLS release: Version 2.2.2.

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 core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains OpenPGP and TLS/IA support, LZO compression,
the OpenSSL compatibility library -- and the self tests and command line
tools are 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/
  http://josefsson.org/gnutls/

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

* Version 2.2.2 (released 2008-02-21)

** Cipher priority string handling now handle strings that starts with NULL.
Thanks to Laurence Withers <l at lwithers.me.uk>.

** Corrected memory leaks in session resuming and DHE ciphersuites. Reported
by Daniel Stenberg.

** Increased the default certificate verification chain limits and allowed
for checks without limitation.

** Corrected the behaviour of gnutls_x509_crt_get_subject_alt_name()
and gnutls_x509_crt_get_subject_alt_name() to not null terminate binary
strings and return the proper size.

** 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.gnutls.org/pub/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.  Note, that GnuPG is
not available at ftp.gnu.org.

Here are the BZIP2 compressed sources (4.8MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.2.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.2.2.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.2.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.2.2.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.2.2.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: 2008-06-30]
      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: 2008-06-30]

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:

6b9586083c6460b0efa73959d86036ecb0a6acf8  gnutls-2.2.2.tar.bz2

555e6a6a8d24f3b2ab6607f3c3e6c864fdd17b41fcb438426ff9d855  gnutls-2.2.2.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-devel 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 consists
of libgpg-error 1.6, libgcrypt 1.4.0, libtasn1 1.3, opencdk 0.6.6, and
GnuTLS 2.2.2.

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

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

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

0f33050ae3f0ab202474c5c8b35c39126b23ec45  gnutls-2.2.2.exe

2408638f2a7456ec62a97d8ae7af312262a25b1303b7c74264b0ee83  gnutls-2.2.2.exe

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

GnuTLS messages have been translated into Dutch, German, Malay, Polish
and Swedish.  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/20080221/dce20bfa/attachment.pgp>

From simon at josefsson.org  Tue Feb 26 16:05:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 26 Feb 2008 16:05:41 +0100
Subject: [Help-gnutls] Google Summer of Code 2008
Message-ID: <8763wb7o6y.fsf@mocca.josefsson.org>

All,

It is likely that GnuTLS will participate in the Google Summer of Code.
The application process isn't open yet, but I created a wiki page where
you can suggest things to do as a GSOC project.  If you are interested
in participating, let me know!

http://trac.gnutls.org/cgi-bin/trac.cgi/wiki/SoC2008

/Simon




From mike at reys.be  Tue Feb 26 21:42:29 2008
From: mike at reys.be (Mike Reys)
Date: Tue, 26 Feb 2008 21:42:29 +0100
Subject: [Help-gnutls] Compiling on Mac OS X,
	2.0.4 and up all fail at linking phase
Message-ID: <47C479B5.5000803@reys.be>

Hi,

I'm trying to get this package compiled in order to get FileZilla 
available again on Mac OS 10.4.x.

The configure script ran fine, but there are some issues during linking.

Im' working with
$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The error message I get is the following
../lib/.libs/libgnutls.dylib(gc-pbkdf2-sha1.o) definition of _gc_pbkdf2_sha1
ld: Undefined symbols:
_deflate
_deflateEnd
_deflateInit2_
_deflateInit_
_inflate
_inflateEnd
_inflateInit2_
_inflateInit_
/usr/bin/libtool: internal link edit command failed
make[3]: *** [libgnutls-extra.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

It is consistent with all versions later than (or equal to) 2.0.4.

Is this the right version mailing list for help, if not, are there any 
forums that could get me through the process of getting gnutls compiled?

Regards,

Mike Reys





From simon at josefsson.org  Wed Feb 27 01:00:23 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 27 Feb 2008 01:00:23 +0100
Subject: [Help-gnutls] Re: Compiling on Mac OS X,
	2.0.4 and up all fail at linking phase
In-Reply-To: <47C479B5.5000803@reys.be> (Mike Reys's message of "Tue, 26 Feb
	2008 21:42:29 +0100")
References: <47C479B5.5000803@reys.be>
Message-ID: <87ir0btgiw.fsf@mocca.josefsson.org>

Mike Reys <mike at reys.be> writes:

> Hi,
>
> I'm trying to get this package compiled in order to get FileZilla
> available again on Mac OS 10.4.x.
>
> The configure script ran fine, but there are some issues during linking.
>
> Im' working with
> $ gcc --version
> i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> The error message I get is the following
> ../lib/.libs/libgnutls.dylib(gc-pbkdf2-sha1.o) definition of _gc_pbkdf2_sha1
> ld: Undefined symbols:
> _deflate
> _deflateEnd
> _deflateInit2_
> _deflateInit_
> _inflate
> _inflateEnd
> _inflateInit2_
> _inflateInit_
> /usr/bin/libtool: internal link edit command failed
> make[3]: *** [libgnutls-extra.la] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> It is consistent with all versions later than (or equal to) 2.0.4.

This suggest some problem with libz.  You could start by trying
--without-zlib to see if it solves the problem.

> Is this the right version mailing list for help, if not, are there any
> forums that could get me through the process of getting gnutls
> compiled?

This is the right fora.

There is http://gnutls.darwinports.com/ but I haven't tried it.

/Simon




From mail_kurapati at yahoo.co.in  Wed Feb 27 06:53:08 2008
From: mail_kurapati at yahoo.co.in (Kurapati Raja Sekhar)
Date: Wed, 27 Feb 2008 05:53:08 +0000 (GMT)
Subject: [Help-gnutls] Handshake has failed ;
	A TLS packet with unexpected length was received
Message-ID: <551745.6600.qm@web8608.mail.in.yahoo.com>

Dear All,
   
  I installed the gnutls latest version in my linux system and tried to work with sample examples. Examples are working fine.
   
  I installed cygwin and gnutls on my windows machine and i try to execute the same examples (which are working with linux) i got following error 
   
  *** Handshake has failed
> GNUTLS ERROR: A TLS packet with unexpected length was received
   
  Can anybody tell why am i getting this error and how to solve 
   
  Thanks in advance.
  KRSC


       
---------------------------------
 Share files, take polls, and discuss your passions - all under one roof.  Click here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080227/2a27a0b6/attachment.htm>

From simon at josefsson.org  Wed Feb 27 14:53:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 27 Feb 2008 14:53:41 +0100
Subject: [Help-gnutls] Re: Handshake has failed ;
	A TLS packet with unexpected length was received
In-Reply-To: <551745.6600.qm@web8608.mail.in.yahoo.com> (Kurapati Raja
	Sekhar's message of "Wed, 27 Feb 2008 05:53:08 +0000 (GMT)")
References: <551745.6600.qm@web8608.mail.in.yahoo.com>
Message-ID: <87skzeo68q.fsf@mocca.josefsson.org>

Kurapati Raja Sekhar <mail_kurapati at yahoo.co.in> writes:

> Dear All,
>    
>   I installed the gnutls latest version in my linux system and tried to work with sample examples. Examples are working fine.
>    
>   I installed cygwin and gnutls on my windows machine and i try to execute the same examples (which are working with linux) i got following error 
>    
>   *** Handshake has failed
>> GNUTLS ERROR: A TLS packet with unexpected length was received
>    
>   Can anybody tell why am i getting this error and how to solve 

Which examples are you running and how?  Some of the examples require a
X.509 certificate and key.  Cut'n'paste from the terminal is the best to
demonstrate what doesn't work.

/Simon