From joe at x2a.org  Sat Aug  1 18:43:36 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Sat, 01 Aug 2009 12:43:36 -0400
Subject: [PATCH][PULL] Add explicit feature checks
Message-ID: <4A7470B8.1090909@x2a.org>

As promised, I have added functions for explicit feature checks. I have
not changed version == GNUTLS_SSL3 checks since those are version checks
and not feature checks. No test-suite detectable regressions were
introduced.

Thanks for reviewing my patches.

The following changes since commit c9f5ec9d1b504e5341b660c5062729325243a633:
  Simon Josefsson (1):
        Drop .c and sort.

are available in the git repository at:

  git://x2a.org/gnutls.git version-checks

Jonathan Bastien-Filiatrault (9):
      Add version check functions for selectable PRF and extension handling.
      Add version check function for explicit IV.
      Add version check functions for non-minimal padding.
      Add version check function for selectable signature/hash
certificate algorithms.
      Remove hardcoded version checks in gnutls_handshake.c.
      Remove hardcoded version checks in gnutls_sig.c.
      Remove hardcoded version checks in gnutls_cipher.c.
      Remove hardcoded version check in gnutls_state.c.
      Remove hardcoded version checks in auth_cert.c.

 lib/auth_cert.c         |    6 +++---
 lib/gnutls_algorithms.c |   41 +++++++++++++++++++++++++++++++++++++++++
 lib/gnutls_algorithms.h |    7 +++++++
 lib/gnutls_cipher.c     |   12 ++++++------
 lib/gnutls_handshake.c  |   12 ++++++------
 lib/gnutls_sig.c        |    8 ++++----
 lib/gnutls_state.c      |    2 +-
 7 files changed, 68 insertions(+), 20 deletions(-)

Regards,
Jonathan




From simon at josefsson.org  Mon Aug  3 15:16:38 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 03 Aug 2009 15:16:38 +0200
Subject: [PATCH][PULL] Add explicit feature checks
In-Reply-To: <4A7470B8.1090909@x2a.org> (Jonathan Bastien-Filiatrault's
	message of "Sat, 01 Aug 2009 12:43:36 -0400")
References: <4A7470B8.1090909@x2a.org>
Message-ID: <871vntrqa1.fsf@mocca.josefsson.org>

Jonathan Bastien-Filiatrault <joe at x2a.org> writes:

> As promised, I have added functions for explicit feature checks.

Thank you.  I'll apply as soon as the FSF copyright papers have arrived.
I'll review them when my 'git clone' finishes downloading your
repository...

/Simon




From ueno at unixuser.org  Mon Aug  3 20:19:21 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Tue, 04 Aug 2009 03:19:21 +0900
Subject: [PATCH] session ticket support
In-Reply-To: <c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 30 Jul 2009 23:48:43
	+0300")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>
Message-ID: <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org>

>>>>> In <c331d99a0907301348s3e7efe47nb47b2ccd47592f1e at mail.gmail.com> 
>>>>>	Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> > When I changed _gnutls_recv_new_session_ticket to generate new session
> > ID, it started to work. ?I attach the new patch, which includes:

>  I have some questions for you.  I was checking the parts that unpack
> and pack the session and was wondering whether using the
> _gnutls_session_pack() would be possible. In that case both
> implementations of the DB and session ticket backends will share
> common code.

I chose the RFC format just because the patch was initially for
experimental purpose.  Using _gnutls_session_pack() would be definitely
better.

I've just tried to make use of the internal format, the code became much
simpler (which reduced ~100 lines).  Thanks for the suggestion.

> Another issue I noticed while checking the code is that if the session
> ticket doesn't decrypt well or doesn't verify well, an error is
> returned... Wouldn't it be more appropriate to just continue ignoring
> the ticket and perform a full handshake?

Absolutely.  I'll post a new patch shortly, with other polishments
(adding interface docs, etc.).

Regards,
-- 
Daiki Ueno




From simon at josefsson.org  Mon Aug  3 23:25:54 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 03 Aug 2009 23:25:54 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> (Daiki
	Ueno's message of "Tue, 04 Aug 2009 03:19:21 +0900")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>
	<91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org>
Message-ID: <87iqh4pp25.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <c331d99a0907301348s3e7efe47nb47b2ccd47592f1e at mail.gmail.com> 
>>>>>>	Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> > When I changed _gnutls_recv_new_session_ticket to generate new session
>> > ID, it started to work. ?I attach the new patch, which includes:
>
>>  I have some questions for you.  I was checking the parts that unpack
>> and pack the session and was wondering whether using the
>> _gnutls_session_pack() would be possible. In that case both
>> implementations of the DB and session ticket backends will share
>> common code.
>
> I chose the RFC format just because the patch was initially for
> experimental purpose.  Using _gnutls_session_pack() would be definitely
> better.

I'm not sure, couldn't there be situations where applications want to
use the RFC ticket format?  Maybe the format should be configurable, so
the application can decide.  Since you have already written support for
the RFC ticket format, I think it would be nice to support it somehow.

/Simon




From simon at josefsson.org  Mon Aug  3 23:38:18 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 03 Aug 2009 23:38:18 +0200
Subject: solutions
In-Reply-To: <4A43C7FE.9090108@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Thu, 25 Jun 2009 21:54:54 +0300")
References: <4A43C7FE.9090108@gnutls.org>
Message-ID: <87bpmwpohh.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> diff --git a/lib/x509/common.c b/lib/x509/common.c
> index 51da7b1..71a4114 100644
> --- a/lib/x509/common.c
> +++ b/lib/x509/common.c
> @@ -181,7 +181,7 @@ _gnutls_x509_oid_data2string (const char *oid, void *value,
>  {
>    char str[MAX_STRING_LEN], tmpname[128];
>    const char *ANAME = NULL;
> -  int CHOICE = -1, len = -1, result;
> +  int CHOICE = -1, len = -1, result, i;
>    ASN1_TYPE tmpasn = ASN1_TYPE_EMPTY;
>    char asn1_err[ASN1_MAX_ERROR_DESCRIPTION_SIZE] = "";
>  
> @@ -309,6 +309,12 @@ _gnutls_x509_oid_data2string (const char *oid, void *value,
>  	    }
>  	}
>      }
> +  
> +  /* Convert null char in the name to '?'
> +   * to protect applications */
> +  for (i=0;i<*res_size;i++) {
> +      if (res[i] == 0) res[i]='?';
> +  }
>  
>    return 0;
>  }

Hi Nikos -- this code crashed the self-tests, but I fixed that.

However, isn't this the wrong way to address the real problem?  It seems
callers of the function should be fixed to be careful not to assume
decoded data does not contain NULs?

/Simon




From simon at josefsson.org  Tue Aug  4 00:20:48 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 00:20:48 +0200
Subject: solutions
In-Reply-To: <87bpmwpohh.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 03 Aug 2009 23:38:18 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
Message-ID: <87k51ko7y7.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
>> diff --git a/lib/x509/common.c b/lib/x509/common.c
>> index 51da7b1..71a4114 100644
>> --- a/lib/x509/common.c
>> +++ b/lib/x509/common.c
>> @@ -181,7 +181,7 @@ _gnutls_x509_oid_data2string (const char *oid, void *value,
>>  {
>>    char str[MAX_STRING_LEN], tmpname[128];
>>    const char *ANAME = NULL;
>> -  int CHOICE = -1, len = -1, result;
>> +  int CHOICE = -1, len = -1, result, i;
>>    ASN1_TYPE tmpasn = ASN1_TYPE_EMPTY;
>>    char asn1_err[ASN1_MAX_ERROR_DESCRIPTION_SIZE] = "";
>>  
>> @@ -309,6 +309,12 @@ _gnutls_x509_oid_data2string (const char *oid, void *value,
>>  	    }
>>  	}
>>      }
>> +  
>> +  /* Convert null char in the name to '?'
>> +   * to protect applications */
>> +  for (i=0;i<*res_size;i++) {
>> +      if (res[i] == 0) res[i]='?';
>> +  }
>>  
>>    return 0;
>>  }
>
> Hi Nikos -- this code crashed the self-tests, but I fixed that.
>
> However, isn't this the wrong way to address the real problem?  It seems
> callers of the function should be fixed to be careful not to assume
> decoded data does not contain NULs?

Indeed the code doesn't seem to be right, since it uses _gnutls_str_cpy
which uses strlen earlier to get the length of the string.  So instead
of truncating on the \0 it will add a ? and truncate after the \0.

Fixing the callers should be the right solution.  Let's hope our API
isn't broken and uses zero terminated strings for these strings...

/Simon




From nmav at gnutls.org  Tue Aug  4 07:23:28 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 04 Aug 2009 08:23:28 +0300
Subject: solutions
In-Reply-To: <87bpmwpohh.fsf@mocca.josefsson.org>
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
Message-ID: <4A77C5D0.9060901@gnutls.org>

Simon Josefsson wrote:

>>    return 0;
>>  }
> 
> Hi Nikos -- this code crashed the self-tests, but I fixed that.
> 
> However, isn't this the wrong way to address the real problem?  It seems
> callers of the function should be fixed to be careful not to assume
> decoded data does not contain NULs?

A null byte there is really malicious (why would a string contain a null
byte?). Maybe using '?' is not the right solution, though. However I
don't think the callers of this function will be safe... even the
description of it says that the string will be null terminated :(
I'd suggest to use memcpy for the cases of the gnutls_str_cpy to avoid
having certificates that return a smaller DN value...





From nmav at gnutls.org  Tue Aug  4 07:25:06 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 04 Aug 2009 08:25:06 +0300
Subject: [PATCH] session ticket support
In-Reply-To: <87iqh4pp25.fsf@mocca.josefsson.org>
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>	<4A5F93EA.9050100@gnutls.org>	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>	<4A6ACB0A.4030801@gnutls.org>	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>	<4A6C5385.9010504@gnutls.org>	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>	<c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>	<91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org>
	<87iqh4pp25.fsf@mocca.josefsson.org>
Message-ID: <4A77C632.3050201@gnutls.org>

Simon Josefsson wrote:

> I'm not sure, couldn't there be situations where applications want to
> use the RFC ticket format?  Maybe the format should be configurable, so
> the application can decide.  Since you have already written support for
> the RFC ticket format, I think it would be nice to support it somehow.

Actually the ticket format is transparent (or better encrypted) to
everyone except gnutls. Thus there is very little incentive to keep
separate code for something that is useful only to us (if someone can
use our ticket, it should be problem in our encryption :).

regards,
Nikos






From wk at gnupg.org  Tue Aug  4 10:31:46 2009
From: wk at gnupg.org (Werner Koch)
Date: Tue, 04 Aug 2009 10:31:46 +0200
Subject: solutions
In-Reply-To: <87bpmwpohh.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 03 Aug 2009 23:38:18 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
Message-ID: <87tz0ornd9.fsf@wheatstone.g10code.de>

On Mon,  3 Aug 2009 23:38, simon at josefsson.org said:

> However, isn't this the wrong way to address the real problem?  It seems
> callers of the function should be fixed to be careful not to assume
> decoded data does not contain NULs?

This is often hard to implement.

FWIW, Libksba uses an rfc-2253 representation of DNs in its API, thus
there is no problem due to the required quoting.  However, for bad
(well, unlikely) encodings of URLs, Libksba now uses a made up OID to
indicate this error:  1.3.6.1.4.1.11591.2.12242973 (invalid encoded OID).
You may want to use a similar hack.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.





From simon at josefsson.org  Tue Aug  4 13:53:20 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 13:53:20 +0200
Subject: solutions
In-Reply-To: <4A77C5D0.9060901@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Tue, 04 Aug 2009 08:23:28 +0300")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org>
Message-ID: <87ab2flrrj.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>>>    return 0;
>>>  }
>> 
>> Hi Nikos -- this code crashed the self-tests, but I fixed that.
>> 
>> However, isn't this the wrong way to address the real problem?  It seems
>> callers of the function should be fixed to be careful not to assume
>> decoded data does not contain NULs?
>
> A null byte there is really malicious (why would a string contain a null
> byte?).

The standards permit it...

> Maybe using '?' is not the right solution, though. However I don't
> think the callers of this function will be safe... even the
> description of it says that the string will be null terminated :( I'd
> suggest to use memcpy for the cases of the gnutls_str_cpy to avoid
> having certificates that return a smaller DN value...

The function already escape strings as per RFC 2253 in some cases, so I
think it would be fine to escape any NUL byte with \00 which is as per
RFC 2253.  Then the string will be zero terminated and will look
correct.  Replacing NUL bytes with ? isn't perfect since it damages
information.  So to avoid similar issues, we'd also need to replace any
\ with \\ or \5C in the string.

I'm implementing this now.

/Simon




From simon at josefsson.org  Tue Aug  4 13:56:27 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 13:56:27 +0200
Subject: solutions
In-Reply-To: <87tz0ornd9.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Tue, 04 Aug 2009 10:31:46 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<87tz0ornd9.fsf@wheatstone.g10code.de>
Message-ID: <8763d3lrmc.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Mon,  3 Aug 2009 23:38, simon at josefsson.org said:
>
>> However, isn't this the wrong way to address the real problem?  It seems
>> callers of the function should be fixed to be careful not to assume
>> decoded data does not contain NULs?
>
> This is often hard to implement.
>
> FWIW, Libksba uses an rfc-2253 representation of DNs in its API, thus
> there is no problem due to the required quoting.

Right, and this seems to be the right way forward too.  GnuTLS uses RFC
2253 format too, but it didn't escape strings properly.  :-(

> However, for bad (well, unlikely) encodings of URLs, Libksba now uses
> a made up OID to indicate this error: 1.3.6.1.4.1.11591.2.12242973
> (invalid encoded OID).  You may want to use a similar hack.

I don't see how to use this in GnuTLS since there are functions that
return data associated with a particular (input variable) OID.  If that
function is passed the OID for CN, it has to return the information,
otherwise you'll get other problems if you return an error saying that
there is no CN field.

But if we use the RFC 2253 formatting, all things are safe.

/Simon




From simon at josefsson.org  Tue Aug  4 13:59:03 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 13:59:03 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <4A77C632.3050201@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Tue, 04 Aug 2009 08:25:06 +0300")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>
	<91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org>
	<87iqh4pp25.fsf@mocca.josefsson.org> <4A77C632.3050201@gnutls.org>
Message-ID: <871vnrlri0.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>> I'm not sure, couldn't there be situations where applications want to
>> use the RFC ticket format?  Maybe the format should be configurable, so
>> the application can decide.  Since you have already written support for
>> the RFC ticket format, I think it would be nice to support it somehow.
>
> Actually the ticket format is transparent (or better encrypted) to
> everyone except gnutls. Thus there is very little incentive to keep
> separate code for something that is useful only to us (if someone can
> use our ticket, it should be problem in our encryption :).

If we use our own pack/unpack format, it won't be possible to set up TLS
load-balancing between GnuTLS and some other implementation that accepts
session tickets on another format.  Maybe that is a minor issue, but it
could come up.  Or is there some other reason why that setup would never
work anyway?

/Simon




From simon at josefsson.org  Tue Aug  4 14:15:33 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 14:15:33 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org> (Daiki
	Ueno's message of "Tue, 28 Jul 2009 10:27:39 +0900")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
Message-ID: <87ws5jkc62.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> * New interface functions as you suggested.
>
>   int gnutls_session_ticket_allocate_key (gnutls_session_ticket_key_t *);
>   int gnutls_session_ticket_randomize (gnutls_session_ticket_key_t);
>   int gnutls_session_ticket_import (gnutls_session_t, void *, size_t);
>   int gnutls_session_ticket_export (gnutls_session_t, void *, size_t *);

I suggest renaming these APIs like this:

 gnutls_session_ticket_key_allocate
 gnutls_session_ticket_key_randomize
 gnutls_session_ticket_key_import
 gnutls_session_ticket_key_export

Also, what do you think about a 'gnutls_session_ticket_key_format_t'
parameter?  I think some people may want to export the key in
text-format rather than raw binary.

Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which
won't be good choices forever.  How about changing the randomize
function into:

 int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t,
                                          gnutls_cipher_algorithm_t cipher,
                                          gnutls_mac_algorithm_t mac);

The docstring should recommend applications to use AES-128 and
HMAC-SHA-256.

I see that some struct sizes in the RFC (like IV and MAC size) are hard
coded, so it may not be worth time to extrapolate that part to support
non-AES-128/HMAC-SHA-256 options.  So
gnutls_session_ticket_key_randomize could return an error if other
choices than AES-128/HMAC-SHA-256 are used.  This means the API is ready
if RFC 5077bis defines support for HMAC-SHA-3 or similar.

Thanks,
/Simon




From nmav at gnutls.org  Tue Aug  4 14:38:39 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 4 Aug 2009 15:38:39 +0300
Subject: [PATCH] session ticket support
In-Reply-To: <871vnrlri0.fsf@mocca.josefsson.org>
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>
	<91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org>
	<87iqh4pp25.fsf@mocca.josefsson.org> <4A77C632.3050201@gnutls.org>
	<871vnrlri0.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0908040538t2fe679cao343b5f72bfabfe32@mail.gmail.com>

On Tue, Aug 4, 2009 at 2:59 PM, Simon Josefsson<simon at josefsson.org> wrote:

> If we use our own pack/unpack format, it won't be possible to set up TLS
> load-balancing between GnuTLS and some other implementation that accepts
> session tickets on another format. ?Maybe that is a minor issue, but it
> could come up. ?Or is there some other reason why that setup would never
> work anyway?

No not really :) Especially since the RFC ticket format is
underdefined (several parts are missing). If there will ever be some
standard format we can switch our internal format and solve that
issue, and in addition our DBs will be readable by others via
memcached etc.

regards,
Nikos




From nmav at gnutls.org  Tue Aug  4 15:00:35 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 4 Aug 2009 16:00:35 +0300
Subject: [PATCH] session ticket support
In-Reply-To: <87ws5jkc62.fsf@mocca.josefsson.org>
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0908040600r7abcb4baif0496b6ac6273a2@mail.gmail.com>

On Tue, Aug 4, 2009 at 3:15 PM, Simon Josefsson<simon at josefsson.org> wrote:

> Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which
> won't be good choices forever. ?How about changing the randomize
> function into:
>
> ?int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_cipher_algorithm_t cipher,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_mac_algorithm_t mac);

Indeed the rename will make things more clear. However
this might not be proper place to make the algorithms flexible since
the allocation has been done before and had
no knowledge of the required key sizes. Those options could have been
in the allocation part.

> I see that some struct sizes in the RFC (like IV and MAC size) are hard
> coded, so it may not be worth time to extrapolate that part to support
> non-AES-128/HMAC-SHA-256 options. ?So
> gnutls_session_ticket_key_randomize could return an error if other
> choices than AES-128/HMAC-SHA-256 are used. ?This means the API is ready
> if RFC 5077bis defines support for HMAC-SHA-3 or similar.

I am not really sure about the flexibility here. If a new rfc mandates
some different algorithms would we
expect the application need the change those? I would expect gnutls
should have done it implicitely. Anyway I
don't think is bad since many people would want to use AES-256 and
hmac with 512 etc etc... If we add it we could do
it with a different function that accepts additional parameters such
as gnutls_session_ticket_key_allocate2(z,x,y ) and leave a simple
allocate(x) that will set the defaults?

regards,
Nikos




From simon at josefsson.org  Tue Aug  4 15:21:29 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 15:21:29 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <c331d99a0908040538t2fe679cao343b5f72bfabfe32@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 4 Aug 2009 15:38:39
	+0300")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<c331d99a0907301348s3e7efe47nb47b2ccd47592f1e@mail.gmail.com>
	<91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org>
	<87iqh4pp25.fsf@mocca.josefsson.org> <4A77C632.3050201@gnutls.org>
	<871vnrlri0.fsf@mocca.josefsson.org>
	<c331d99a0908040538t2fe679cao343b5f72bfabfe32@mail.gmail.com>
Message-ID: <87fxc7k946.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Tue, Aug 4, 2009 at 2:59 PM, Simon Josefsson<simon at josefsson.org> wrote:
>
>> If we use our own pack/unpack format, it won't be possible to set up TLS
>> load-balancing between GnuTLS and some other implementation that accepts
>> session tickets on another format. ?Maybe that is a minor issue, but it
>> could come up. ?Or is there some other reason why that setup would never
>> work anyway?
>
> No not really :) Especially since the RFC ticket format is
> underdefined (several parts are missing).

Yes, and I suspect it is impossible to fully describe a format that
covers all TLS extensions.  What could be done to improve the current
document is to allow type=value extensibility to let implementations
store additional parameters.  As the spec progress, it can be improved
to specify some of the implementation-specific type=value fields.
Implementations that doesn't support a particular type=value attribute
can ignore it, and there could be better interoperability when using TLS
load-balancing.  If the document was designed this way, we could change
GnuTLS pack/unpack format to use the core format and then add the
non-standard parameters as extended type=value fields.

> If there will ever be some standard format we can switch our internal
> format and solve that issue, and in addition our DBs will be readable
> by others via memcached etc.

Right.

/Simon




From simon at josefsson.org  Tue Aug  4 15:23:53 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Aug 2009 15:23:53 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <c331d99a0908040600r7abcb4baif0496b6ac6273a2@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 4 Aug 2009 16:00:35
	+0300")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<c331d99a0908040600r7abcb4baif0496b6ac6273a2@mail.gmail.com>
Message-ID: <87bpmvk906.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Tue, Aug 4, 2009 at 3:15 PM, Simon Josefsson<simon at josefsson.org> wrote:
>
>> Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which
>> won't be good choices forever. ?How about changing the randomize
>> function into:
>>
>> ?int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_cipher_algorithm_t cipher,
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_mac_algorithm_t mac);
>
> Indeed the rename will make things more clear. However
> this might not be proper place to make the algorithms flexible since
> the allocation has been done before and had
> no knowledge of the required key sizes. Those options could have been
> in the allocation part.

Good point.  Let's ignore my suggestion.  We can always add new APIs to
generate particular keys later on if there is a need.

>> I see that some struct sizes in the RFC (like IV and MAC size) are hard
>> coded, so it may not be worth time to extrapolate that part to support
>> non-AES-128/HMAC-SHA-256 options. ?So
>> gnutls_session_ticket_key_randomize could return an error if other
>> choices than AES-128/HMAC-SHA-256 are used. ?This means the API is ready
>> if RFC 5077bis defines support for HMAC-SHA-3 or similar.
>
> I am not really sure about the flexibility here. If a new rfc mandates
> some different algorithms would we
> expect the application need the change those? I would expect gnutls
> should have done it implicitely. Anyway I
> don't think is bad since many people would want to use AES-256 and
> hmac with 512 etc etc... If we add it we could do
> it with a different function that accepts additional parameters such
> as gnutls_session_ticket_key_allocate2(z,x,y ) and leave a simple
> allocate(x) that will set the defaults?

I agree.

/Simon




From nmav at gnutls.org  Tue Aug  4 18:41:51 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 04 Aug 2009 19:41:51 +0300
Subject: solutions
In-Reply-To: <87ab2flrrj.fsf@mocca.josefsson.org>
References: <4A43C7FE.9090108@gnutls.org>
	<87bpmwpohh.fsf@mocca.josefsson.org>	<4A77C5D0.9060901@gnutls.org>
	<87ab2flrrj.fsf@mocca.josefsson.org>
Message-ID: <4A7864CF.4080702@gnutls.org>

Simon Josefsson wrote:

>>>>    return 0;
>>>>  }
>>> Hi Nikos -- this code crashed the self-tests, but I fixed that.
>>>
>>> However, isn't this the wrong way to address the real problem?  It seems
>>> callers of the function should be fixed to be careful not to assume
>>> decoded data does not contain NULs?
>> A null byte there is really malicious (why would a string contain a null
>> byte?).
> 
> The standards permit it...

To be precise it is only allowed if a the string is tagged as ia5String.
Other types do not allow null.






From joe at x2a.org  Wed Aug  5 01:06:12 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Tue, 04 Aug 2009 19:06:12 -0400
Subject: [RFC] Suggestion for the improvement of the buffering layer
Message-ID: <4A78BEE4.3010802@x2a.org>

Here is an implementation suggestion for the improvement of the current
buffering code. This would be mostly for enabling easier DTLS
integration and better maintainability in the future.

Goals:

- Preserve read/write boundaries at the transport level. This is mostly
important for datagram packing.

- Simplify interfaces between layers.

- Eliminate the need for peeking (is this possible/desirable ?).

- Allow pushing data into GnuTLS when the socket becomes readable and
pulling from GnuTLS when the socket becomes writable. This is especially
important for event-driven servers. Read and write callbacks could
therefore be made optional for such programs.


Suggested implementation:

A pyramid of FIFO queues (linked lists would do), one queue per
direction per layer. On the read() side, data would move upward by
forming records from transport buffers. Records would then be
demultiplexed and queued into upper layer protocols (handshake, alert,
application). For the write() direction this would simply be reversed.
This is close to what is done currently except the buffers would be
message-based instead of bytestream-based.

Advantages:

- The separation of "message framing" and message processing. Example: A
buffer_process function would form as much records as it can from the
available transport buffers then a record_read would simply dequeue the
first record from the list and process that record. If there is not
enough data, the transport buffers would be refilled by invoking a
read() on the socket. This would eliminate logic such as read_headers()
then read() from the message processing pipeline and would move that
logic inside the "message framing" code.

- Better separation of concerns, easier to understand code, better
modularity. It can be argued that better understandability, readability
and modularity lead to better security (from programming errors).

Disadvantages:

- Much previously tested/debugged code would be discarded.

- Feasibility not clear (to me).

- Is it worth it ? Would it really be better ?

Thanks for your input,
Jonathan




From ueno at unixuser.org  Wed Aug  5 07:31:06 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Wed, 05 Aug 2009 14:31:06 +0900
Subject: [PATCH] session ticket support
In-Reply-To: <87ws5jkc62.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 04 Aug 2009 14:15:33 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
Message-ID: <87vdl2rfmt.fsf@broken.deisui.org>

>>>>> In <87ws5jkc62.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> I suggest renaming these APIs like this:

>  gnutls_session_ticket_key_allocate
>  gnutls_session_ticket_key_randomize
>  gnutls_session_ticket_key_import
>  gnutls_session_ticket_key_export

Thanks for the suggestion.  I'll reflect them in the next patch.

> Also, what do you think about a 'gnutls_session_ticket_key_format_t'
> parameter?  I think some people may want to export the key in
> text-format rather than raw binary.

As another option, how about making gnutls_session_ticket_key_t a public
struct so that people can write custom export function?

Regards,
-- 
Daiki Ueno




From wk at gnupg.org  Wed Aug  5 09:03:27 2009
From: wk at gnupg.org (Werner Koch)
Date: Wed, 05 Aug 2009 09:03:27 +0200
Subject: solutions
In-Reply-To: <8763d3lrmc.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 04 Aug 2009 13:56:27 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<87tz0ornd9.fsf@wheatstone.g10code.de>
	<8763d3lrmc.fsf@mocca.josefsson.org>
Message-ID: <87r5vqrbcw.fsf@wheatstone.g10code.de>

On Tue,  4 Aug 2009 13:56, simon at josefsson.org said:

> function is passed the OID for CN, it has to return the information,
> otherwise you'll get other problems if you return an error saying that
> there is no CN field.

Better an error than doing something not intended.

> But if we use the RFC 2253 formatting, all things are safe.

Just make sure that parsing the BER of all arcs is fine and does not
overflow.  I consider an arc which can't be represented by a 32 bit
value as fishy and return an error (i.e. the mentioned special OID).


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.





From simon at josefsson.org  Wed Aug  5 10:08:02 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 05 Aug 2009 10:08:02 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <87vdl2rfmt.fsf@broken.deisui.org> (Daiki Ueno's message of "Wed, 
	05 Aug 2009 14:31:06 +0900")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
Message-ID: <87prbahee5.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87ws5jkc62.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> I suggest renaming these APIs like this:
>
>>  gnutls_session_ticket_key_allocate
>>  gnutls_session_ticket_key_randomize
>>  gnutls_session_ticket_key_import
>>  gnutls_session_ticket_key_export
>
> Thanks for the suggestion.  I'll reflect them in the next patch.

Great.

>> Also, what do you think about a 'gnutls_session_ticket_key_format_t'
>> parameter?  I think some people may want to export the key in
>> text-format rather than raw binary.
>
> As another option, how about making gnutls_session_ticket_key_t a public
> struct so that people can write custom export function?

Thinking about that, doesn't a gnutls_datum_t suffice?  Then you don't
need the import/export functions at all.  Possibly the
allocate+randomize function could also be merged into one API:

  int gnutls_session_ticket_key_generate (gnutls_datum_t *key);

The function would allocate and randomize key->data and set key->size
accordingly.  The key->data field needs to be released using gnutls_free
as usual.

/Simon




From simon at josefsson.org  Wed Aug  5 13:21:24 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 05 Aug 2009 13:21:24 +0200
Subject: solutions
In-Reply-To: <87ab2flrrj.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 04 Aug 2009 13:53:20 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org>
Message-ID: <87zlaefqvf.fsf@mocca.josefsson.org>

Having had some time to read the code, here are some observations:

* The old _gnutls_x509_oid_data2string in lib/x509/common.c is buggy
  since it truncates the string after a NUL (it copies the string using
  strcpy instead of memcpy).  The RES_SIZE length output variable is
  correct though, but output data beyond the NUL will be garbage.

* I can see a few ways to solve the problem:

  1) Make _gnutls_x509_oid_data2string escape NULs as \00 following RFC
     2253.

  2) Use memcpy instead of strcpy and change the documentation of the
     function to say that the returned string may contain embedded NULs,
     and fix the callers of that function.

  3) Return a RFC 2253 #-style string for these strings.

  4) Return an error when a NUL is encountered.

* Solution 1) and 3) appear to break
  gnutls_x509_crq_get_challenge_password which is used to extract the
  certificate request challenge password.  Password strings are not DNs
  and should not be escaped as per RFC 2253.  If any of the escaped
  characters in RFC 2253 is used in a password (e.g., plus or comma),
  and if _gnutls_x509_oid_data2string escapes them, things will break.
  Further, the gnutls_x509_crq_get_challenge_password API does not use
  zero-terminated strings, so it can handle embedded NULs in password.

  The same problem could apply to DN SAN's and CRL distribution points,
  they are not documented in GnuTLS to be in LDAP escape format
  (although not documented to be in any other format either).

  However, if we really want to use 1) or 3) as the solution, the
  gnutls_x509_crq_get_challenge_password function could be modified to
  use some other code path to yield correct results.

* Solution 2) could work but require that we investigate and possibly
  fix all callers.  The function is used in three places:

    A) By parse_attribute in lib/x509/crq.c which is used by two other
       functions:

      A.1.) gnutls_x509_crq_get_challenge_password which is OK as per above.

      A.2) gnutls_x509_crq_get_attribute_by_oid.  That function calls
      parse_attribute with RAW=1 which means that
      _gnutls_x509_oid_data2string is never called.

    B) By _gnutls_x509_parse_dn in lib/x509/dn.c.  That function is
       documented to return a LDAP string.  It performs RFC 2253
       escaping by calling str_escape, which doesn't handle embedded
       NULs.

    C) By _gnutls_x509_parse_dn_oid in lib/x509/dn.c.  That function is
       also documented to return a LDAP string, but does not perform RFC
       2253 escaping so it is arguable broken.

  Both _gnutls_x509_parse_dn and _gnutls_x509_parse_dn_oid are used in
  many places in GnuTLS.  Most of them are from APIs that actually are
  documented to return LDAP escaped strings (yay!) so we are relatively
  safe.  However there is one usages that could be problematic:

    A) _gnutls_parse_general_name uses _gnutls_x509_parse_dn to extract
    a DirectoryName type of GeneralName.  The _gnutls_parse_general_name
    function is also by gnutls_x509_crt_get_crl_dist_points to get the
    CRL distribution point.

  I suspect DN SAN's and use of CRL dist points are quite rare.  Anyone
  with more insight?

I believe 2 is actually the right solution but it may not be worth it,
especially considering that there are not likely to be any non-malicious
uses of NUL in a DNs.

So while I prefer 2) since it allows GnuTLS to handle embedded NULs, I
suspect 4) will result in more robust overall design.  The patch could
be as simple as the one below, but I need to do more testing.

/Simon

--- common.c~	2009-06-02 20:59:32.000000000 +0200
+++ common.c	2009-08-05 13:18:17.000000000 +0200
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation
+ * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation
  *
  * Author: Nikos Mavrogiannopoulos
  *
@@ -242,6 +242,9 @@
     {
       str[len] = 0;
 
+      if (strlen (str) != len)
+	return GNUTLS_E_ASN1_DER_ERROR;
+
       if (res)
 	_gnutls_str_cpy (res, *res_size, str);
       *res_size = len;
@@ -296,6 +299,8 @@
 	  if (non_printable == 0)
 	    {
 	      str[len] = 0;
+	      if (strlen (str) != len)
+		return GNUTLS_E_ASN1_DER_ERROR;
 	      _gnutls_str_cpy (res, *res_size, str);
 	      *res_size = len;
 	    }




From bradh at frogmouth.net  Wed Aug  5 14:14:43 2009
From: bradh at frogmouth.net (Brad Hards)
Date: Wed, 5 Aug 2009 22:14:43 +1000
Subject: [patch] Request for review - X509 Issuer Altname handling
Message-ID: <200908052214.44197.bradh@frogmouth.net>

Hi,

This patch (which I submit as a request for review / feedback) implements 
support for getting issuer altname. It is based on the equivalent subject 
altname code.

[I'll submit it again for incorporation after my papers get worked through]

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x509_issuer_altname-2009-08-05.patch
Type: text/x-patch
Size: 15121 bytes
Desc: not available
URL: </pipermail/attachments/20090805/0847fb7a/attachment.bin>

From nmav at gnutls.org  Wed Aug  5 20:25:20 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Aug 2009 21:25:20 +0300
Subject: solutions
In-Reply-To: <87zlaefqvf.fsf@mocca.josefsson.org>
References: <4A43C7FE.9090108@gnutls.org>
	<87bpmwpohh.fsf@mocca.josefsson.org>	<4A77C5D0.9060901@gnutls.org>
	<87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org>
Message-ID: <4A79CE90.8020706@gnutls.org>

Simon Josefsson wrote:
> Having had some time to read the code, here are some observations:
> 
> * The old _gnutls_x509_oid_data2string in lib/x509/common.c is buggy
>   since it truncates the string after a NUL (it copies the string using
>   strcpy instead of memcpy).  The RES_SIZE length output variable is
>   correct though, but output data beyond the NUL will be garbage.
> 
> * I can see a few ways to solve the problem:
> 
>   1) Make _gnutls_x509_oid_data2string escape NULs as \00 following RFC
>      2253.
> 
>   2) Use memcpy instead of strcpy and change the documentation of the
>      function to say that the returned string may contain embedded NULs,
>      and fix the callers of that function.
> 
>   3) Return a RFC 2253 #-style string for these strings.
> 
>   4) Return an error when a NUL is encountered.

4 is just ok. One could do 1 if he really bothers, but there is no
reason for that. Even though IA5 string allows for null character there
is no reason for us to allow it. It is the null terminator for C strings
thus allowing it can cause only problems and complicated code.

> * Solution 2) could work but require that we investigate and possibly
>   fix all callers.  The function is used in three places:
> 
>     A) By parse_attribute in lib/x509/crq.c which is used by two other
>        functions:
> 
>       A.1.) gnutls_x509_crq_get_challenge_password which is OK as per above.
> 
>       A.2) gnutls_x509_crq_get_attribute_by_oid.  That function calls
>       parse_attribute with RAW=1 which means that
>       _gnutls_x509_oid_data2string is never called.
> 
>     B) By _gnutls_x509_parse_dn in lib/x509/dn.c.  That function is
>        documented to return a LDAP string.  It performs RFC 2253
>        escaping by calling str_escape, which doesn't handle embedded
>        NULs.
> 
>     C) By _gnutls_x509_parse_dn_oid in lib/x509/dn.c.  That function is
>        also documented to return a LDAP string, but does not perform RFC
>        2253 escaping so it is arguable broken.
[...]
> I believe 2 is actually the right solution but it may not be worth it,
> especially considering that there are not likely to be any non-malicious
> uses of NUL in a DNs.

It looks a lot of effort to me and I also do not think it can weight the
gain. I see no reason to allow nulls in a string that has the purpose to
be shown and/or typed.

regards,
Nikos





From nmav at gnutls.org  Wed Aug  5 20:48:14 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Aug 2009 21:48:14 +0300
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A78BEE4.3010802@x2a.org>
References: <4A78BEE4.3010802@x2a.org>
Message-ID: <4A79D3EE.80106@gnutls.org>

Jonathan Bastien-Filiatrault wrote:

> Advantages:
> 
> - The separation of "message framing" and message processing. Example: A
> buffer_process function would form as much records as it can from the
> available transport buffers then a record_read would simply dequeue the

Hi,
 If I understand well you propose using something similar to skb's in
linux?  Can you give me an example of your proposal? Say in the TCP case
we received a handshake message in 3 different packets and one is not
yet received. How the processing will go before the 4th is received and
how after that?

> - Better separation of concerns, easier to understand code, better
> modularity. It can be argued that better understandability, readability
> and modularity lead to better security (from programming errors).
> Disadvantages:
> 
> - Much previously tested/debugged code would be discarded.

Replacing ugly code with simpler one (or more efficient one) does not
count as disadvantage to me.

> - Is it worth it ? Would it really be better ?

I'm curious whether something like that would be more efficient. In
theory, if I get your idea correct, it would have less memcopy etc but
in practice we are spending more time in decrypting/encrypting and the
current code has quite reduced memcpy. However there is still space for
improvement.

If you are asking a go or not go, I'd say that it's up to you. In any
case I am curious of any results and more design information.

regards,
Nikos




From nmav at gnutls.org  Wed Aug  5 20:49:45 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Aug 2009 21:49:45 +0300
Subject: [patch] Request for review - X509 Issuer Altname handling
In-Reply-To: <200908052214.44197.bradh@frogmouth.net>
References: <200908052214.44197.bradh@frogmouth.net>
Message-ID: <4A79D449.4070904@gnutls.org>

Brad Hards wrote:
> Hi,
> 
> This patch (which I submit as a request for review / feedback) implements 
> support for getting issuer altname. It is based on the equivalent subject 
> altname code.

No comments. Looks nice to me!

regards,
Nikos




From joe at x2a.org  Wed Aug  5 21:32:38 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Wed, 05 Aug 2009 15:32:38 -0400
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A79D3EE.80106@gnutls.org>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>
Message-ID: <4A79DE56.9030508@x2a.org>

Nikos Mavrogiannopoulos wrote:
> Jonathan Bastien-Filiatrault wrote:
> 
>> Advantages:
>>
>> - The separation of "message framing" and message processing. Example: A
>> buffer_process function would form as much records as it can from the
>> available transport buffers then a record_read would simply dequeue the
> 
> Hi,
>  If I understand well you propose using something similar to skb's in
> linux?  Can you give me an example of your proposal? Say in the TCP case
> we received a handshake message in 3 different packets and one is not
> yet received. How the processing will go before the 4th is received and
> how after that?

The handshake framing layer would determine how many more bytes it needs
(header present in the first few packets) and compare that with the
number of bytes available in the record FIFO. It would return a code
such as EAGAIN until it has enough data available. When the last packet
is received, it would dequeue the record packets (possibly splitting a
partial record packet in two) and memcpy them into a handshake buffer
and queue the handshake packet in the handshake FIFO. Just to be clear,
there would be a record FIFO for each upper-layer protocol (demultiplex
sub-layer).

Skb's tend to reduce copying to a minimum. In the implementation I
suggest I don't see how I can get away with less that one memcpy per
layer transition (unless I implement some zero-copy record-slicing
code-fu; something I want to avoid).

> 
>> - Better separation of concerns, easier to understand code, better
>> modularity. It can be argued that better understandability, readability
>> and modularity lead to better security (from programming errors).
>> Disadvantages:
>>
>> - Much previously tested/debugged code would be discarded.
> 
> Replacing ugly code with simpler one (or more efficient one) does not
> count as disadvantage to me.

I was hoping someone would say that :P.

> 
>> - Is it worth it ? Would it really be better ?
> 
> I'm curious whether something like that would be more efficient. In
> theory, if I get your idea correct, it would have less memcopy etc but
> in practice we are spending more time in decrypting/encrypting and the
> current code has quite reduced memcpy. However there is still space for
> improvement.

Right, encryption is a few orders of magnitude more costly than memcpy,
 in theory I could therefore get away with more memcpy without a
significant performance degradation (I won't push this too far, hopefully).

> 
> If you are asking a go or not go, I'd say that it's up to you. In any
> case I am curious of any results and more design information.

Well, I have basically brain-dumped the design I had in the email you
replied to. I want to be sure I have the basics right before building a
concrete implementation on top of that.

PS: I have just received the FSF papers, I have signed them and I will
return them soon.

> regards,
> Nikos

Thanks,
Jonathan




From ueno at unixuser.org  Thu Aug  6 09:12:49 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Thu, 06 Aug 2009 16:12:49 +0900
Subject: [PATCH] session ticket support
In-Reply-To: <87prbahee5.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 05 Aug 2009 10:08:02 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
Message-ID: <87k51hxvny.fsf@broken.deisui.org>

>>>>> In <87prbahee5.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> >> Also, what do you think about a 'gnutls_session_ticket_key_format_t'
> >> parameter?  I think some people may want to export the key in
> >> text-format rather than raw binary.
> >
> > As another option, how about making gnutls_session_ticket_key_t a public
> > struct so that people can write custom export function?

> Thinking about that, doesn't a gnutls_datum_t suffice?

Sorry, perhaps I misunderstood what you meant with "text-format".  I had
thought that the key is represented as a set of attributes such as
cipher/mac keys and used algorithms in human readable form.

It is simply an option to select output format in binary or base64,
isn't it?

Regards,
-- 
Daiki Ueno




From bradh at frogmouth.net  Thu Aug  6 09:45:37 2009
From: bradh at frogmouth.net (Brad Hards)
Date: Thu, 6 Aug 2009 17:45:37 +1000
Subject: [patch] Problems with "make check"
Message-ID: <200908061745.38342.bradh@frogmouth.net>

Hi,

With an up-to-date git, I have problems with "make check"
libtool: link: gcc -std=gnu99 -Wall -W -Wformat-security -Winit-self -
Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-
equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -
Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -
Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -
Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvla -
Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength-
strings -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand 
-Wattributes -Wcoverage-mismatch -Wmultichar -Wunused-macros -Wno-missing-
field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter -
Wno-unused-parameter -Wno-stack-protector -fdiagnostics-show-option -Werror -g 
-O2 -o nul-in-x509-names nul-in-x509-names.o  ../lib/.libs/libgnutls.so -
ltasn1 -lz ../gl/.libs/libgnu.a ./.libs/libutils.a -lgcrypt -Wl,-rpath -
Wl,/home/bradh-dev/gnutls-buildfix/lib/.libs
make[3]: *** No rule to make target `rfc2231-escape-test.o', needed by 
`rfc2231-escape-test'.  Stop.

I note that the shell script added in a532faf3bd6d95bf41ba75733a72b504090667af 
is rfc2253-escape-test rather than rfc2231-escape-test. See:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commit;h=a532faf3bd6d95bf41ba75733a72b504090667af

I've attached a (trivial) patch to address it.

Brad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-make-check-buildsystem-fix-2009-08-06.patch
Type: text/x-patch
Size: 974 bytes
Desc: not available
URL: </pipermail/attachments/20090806/003c0789/attachment.bin>

From simon at josefsson.org  Thu Aug  6 17:11:21 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 06 Aug 2009 17:11:21 +0200
Subject: [patch] Problems with "make check"
In-Reply-To: <200908061745.38342.bradh@frogmouth.net> (Brad Hards's message of
	"Thu, 6 Aug 2009 17:45:37 +1000")
References: <200908061745.38342.bradh@frogmouth.net>
Message-ID: <87iqh1ugdi.fsf@mocca.josefsson.org>

Brad Hards <bradh at frogmouth.net> writes:

> make[3]: *** No rule to make target `rfc2231-escape-test.o', needed by 
> `rfc2231-escape-test'.  Stop.

Thank you, should be fixed now.

/Simon




From simon at josefsson.org  Thu Aug  6 17:14:46 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 06 Aug 2009 17:14:46 +0200
Subject: [patch] Request for review - X509 Issuer Altname handling
In-Reply-To: <200908052214.44197.bradh@frogmouth.net> (Brad Hards's message of
	"Wed, 5 Aug 2009 22:14:43 +1000")
References: <200908052214.44197.bradh@frogmouth.net>
Message-ID: <87eirpug7t.fsf@mocca.josefsson.org>

Brad Hards <bradh at frogmouth.net> writes:

> Hi,
>
> This patch (which I submit as a request for review / feedback) implements 
> support for getting issuer altname. It is based on the equivalent subject 
> altname code.

It looks fine to me.  I wonder why that have been missing...  The
self-test x509_altname was missing from your patch though?

> [I'll submit it again for incorporation after my papers get worked through]

Please do, otherwise I'm likely to forget about it.

/Simon




From simon at josefsson.org  Fri Aug  7 00:22:10 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Aug 2009 00:22:10 +0200
Subject: solutions
In-Reply-To: <4A79CE90.8020706@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Wed, 05 Aug 2009 21:25:20 +0300")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org>
Message-ID: <87skg4twfh.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>> Having had some time to read the code, here are some observations:
>> 
>> * The old _gnutls_x509_oid_data2string in lib/x509/common.c is buggy
>>   since it truncates the string after a NUL (it copies the string using
>>   strcpy instead of memcpy).  The RES_SIZE length output variable is
>>   correct though, but output data beyond the NUL will be garbage.
>> 
>> * I can see a few ways to solve the problem:
>> 
>>   1) Make _gnutls_x509_oid_data2string escape NULs as \00 following RFC
>>      2253.
>> 
>>   2) Use memcpy instead of strcpy and change the documentation of the
>>      function to say that the returned string may contain embedded NULs,
>>      and fix the callers of that function.
>> 
>>   3) Return a RFC 2253 #-style string for these strings.
>> 
>>   4) Return an error when a NUL is encountered.
>
> 4 is just ok. One could do 1 if he really bothers, but there is no
> reason for that. Even though IA5 string allows for null character there
> is no reason for us to allow it. It is the null terminator for C strings
> thus allowing it can cause only problems and complicated code.

I agree.  I have applied the patch.  It is not sufficient alone: NUL in
SAN is not covered by that code path, but RedHat supplied a fix for the
hostname comparison functions.  What remains is to make sure printing a
certificate with NUL in SAN comes out OK.

/Simon




From simon at josefsson.org  Fri Aug  7 01:49:01 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Aug 2009 01:49:01 +0200
Subject: please test imminent 2.8.x release
In-Reply-To: <87skg4twfh.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 07 Aug 2009 00:22:10 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org>
	<87skg4twfh.fsf@mocca.josefsson.org>
Message-ID: <87hbwktseq.fsf_-_@mocca.josefsson.org>

Because of the NUL in CN/SAN issue we need to release a stable 2.8.x
update quickly.

Please test the release candidate:

http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz

This will be identical with the release unless I hear anything negative.

You can also help by reviewing the changes since 2.8.1:

http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x

I don't have more spare time to produce releases of older versions with
the patches (this problem came up at bad timing for me, plenty of paying
assignments to work on), but if someone else wants to spend time on
2.6.x or any older release, that would be welcome.  Note that in
addition to the patches that went into 2.8.x you also need to patch the
certificate printing output from gnutls-cli in src/common.c.  GnuTLS
2.8.x and later uses libgnutls to print certificate details instead.

You can use a self-tests from 2.9.x branch to check if your GnuTLS is
vulnerable, see:

http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c

Build and run it like this:

wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c
gcc -o nul-in-x509-names nul-in-x509-names.c -lgnutls
./nul-in-x509-names 

On a broken gnutls it will output:

gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN)
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN)

On a working gnutls it will output:

gnutls_x509_crt_check_hostname OK (NUL-IN-CN)
gnutls_x509_crt_check_hostname OK (NUL-IN-SAN)

/Simon




From simon at josefsson.org  Fri Aug  7 01:59:26 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Aug 2009 01:59:26 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <87k51hxvny.fsf@broken.deisui.org> (Daiki Ueno's message of "Thu, 
	06 Aug 2009 16:12:49 +0900")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
Message-ID: <87d478trxd.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87prbahee5.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> >> Also, what do you think about a 'gnutls_session_ticket_key_format_t'
>> >> parameter?  I think some people may want to export the key in
>> >> text-format rather than raw binary.
>> >
>> > As another option, how about making gnutls_session_ticket_key_t a public
>> > struct so that people can write custom export function?
>
>> Thinking about that, doesn't a gnutls_datum_t suffice?
>
> Sorry, perhaps I misunderstood what you meant with "text-format".  I had
> thought that the key is represented as a set of attributes such as
> cipher/mac keys and used algorithms in human readable form.
>
> It is simply an option to select output format in binary or base64,
> isn't it?

I changed my mind: rather than supporting different formats and crypto
agility, the entire API would become:

  int gnutls_session_ticket_key_generate (gnutls_datum_t *key);

The algorithm used are chosen by the library.  The app has to write its
own import/export stuff.  What do you think?

/Simon




From joe at manyfish.co.uk  Fri Aug  7 14:08:19 2009
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 7 Aug 2009 13:08:19 +0100
Subject: gnutls_certificate_verify_peers2 API
Message-ID: <20090807120819.GA16131@manyfish.co.uk>

This API is very awkward to use.

1) it is not clear from the API docs whether "failing to verify a cert" 
would be an error resulting in a non-zero return value, or success.

2) the use of the GNUTLS_CERT_INVALID status bit is unclear and 
inappropriate.  The header file say it means:

  /* will be set if the certificate was not verified */

the HTML docs say it means:

  The certificate is not signed by one of the known authorities, or the 
  signature is invalid. 

which are different things.  If the latter is supposed to be true, it is 
unclear why GNUTLS_CERT_SIGNER_NOT_FOUND exists as well.

In practice, all verification failures emitted seem to be ORed with 
CERT_INVALID, which implies it is redundant.  I need to be able to 
safely map a given verification failure into a API/UI, which allows 
users to override specific errors.

If I get the verification error bits:

   GNUTLS_CERT_INVALID | GNUTLS_CERT_SIGNER_NOT_FOUND

does that mean simply a cert signed by a unknown CA?  Or possibly, the 
cert is signed by an unknown CA *and* there is some other verification 
error?  It's hard to tell.

3) for future-extensibility, it is necessary to be able to map a failure 
bit (or bitmask) into an error string, so I can present meaningful 
errors beyond "cert verification failed with GnuTLS failure bit 2^10".

Regards, Joe




From tim.kosse at filezilla-project.org  Fri Aug  7 20:20:45 2009
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Fri, 07 Aug 2009 20:20:45 +0200
Subject: please test imminent 2.8.x release
In-Reply-To: <87hbwktseq.fsf_-_@mocca.josefsson.org>
References: <4A43C7FE.9090108@gnutls.org>
	<87bpmwpohh.fsf@mocca.josefsson.org>	<4A77C5D0.9060901@gnutls.org>
	<87ab2flrrj.fsf@mocca.josefsson.org>	<87zlaefqvf.fsf@mocca.josefsson.org>
	<4A79CE90.8020706@gnutls.org>	<87skg4twfh.fsf@mocca.josefsson.org>
	<87hbwktseq.fsf_-_@mocca.josefsson.org>
Message-ID: <4A7C707D.8020308@filezilla-project.org>

Hi,

> Please test the release candidate:
> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz

works like a charm, I can no longer reproduce the issues I had with 2.8.1

Just one minor detail, the fixes to the EGAIN problems aren't mentioned
in the NEWS file.

Thanks,
Tim

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

From nmav at gnutls.org  Sat Aug  8 00:42:29 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 8 Aug 2009 01:42:29 +0300
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A79DE56.9030508@x2a.org>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>
	<4A79DE56.9030508@x2a.org>
Message-ID: <c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>

On Wed, Aug 5, 2009 at 10:32 PM, Jonathan
Bastien-Filiatrault<joe at x2a.org> wrote:

>> ?If I understand well you propose using something similar to skb's in
>> linux? ?Can you give me an example of your proposal? Say in the TCP case
>> we received a handshake message in 3 different packets and one is not
>> yet received. How the processing will go before the 4th is received and
>> how after that?
>
> The handshake framing layer would determine how many more bytes it needs
> (header present in the first few packets) and compare that with the
> number of bytes available in the record FIFO.

I should add the obvious here that it should check the number of
bytes available in the packets of same type (handshake packets).

> It would return a code
> such as EAGAIN until it has enough data available. When the last packet
> is received, it would dequeue the record packets (possibly splitting a
> partial record packet in two) and memcpy them into a handshake buffer
> and queue the handshake packet in the handshake FIFO. Just to be clear,
> there would be a record FIFO for each upper-layer protocol (demultiplex
> sub-layer).
> Skb's tend to reduce copying to a minimum. In the implementation I
> suggest I don't see how I can get away with less that one memcpy per
> layer transition (unless I implement some zero-copy record-slicing
> code-fu; something I want to avoid).
> Right, encryption is a few orders of magnitude more costly than memcpy,
> ?in theory I could therefore get away with more memcpy without a
> significant performance degradation (I won't push this too far, hopefully).

Indeed but don't underestimate memcpy. Both for low latency and high
speed links (especially with crypto accelerators) that could be the
bottleneck. Keep that in mind in your design. In any case it doesn't
look easy task but that's always in the eye of the beholder.

regards,
Nikos




From ametzler at downhill.at.eu.org  Sat Aug  8 14:56:46 2009
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 8 Aug 2009 14:56:46 +0200
Subject: gnutls version checking too strict (was: Bug#540449: needs a
	versioned dependency on libtasn1-3)
In-Reply-To: <20090808074058.GA3254@downhill.g.la>
References: <20090808024733.GA31539@bongo.bofh.it>
	<20090808074058.GA3254@downhill.g.la>
Message-ID: <20090808125646.GB3254@downhill.g.la>

On 2009-08-08 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
[...]
> Upstream seems to have changed the code to require installation of
> both gcrypt and tasn versions that greater or equal version gnutls
> was built against.

> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=ce23654ab3b8097241c1639ebe3e853c4f67b6d7
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=35bd51b3b42dd437a9914a908af45d78fec76856
[...]
> (See http://bugs.debian.org/495473 for comparison.)

Hello,
The gnutls 2.8 series will absolutely fail to work if the currently
installed version of libtasn1 or libgcrypt is not greater or equal
than the version gnutls was built against. This is much too cautious
since the libtasn1 ABI has not changed at all since 1.6. A gnutls
binary built against libtasn1 2.3 will work perfectly fiine with e.g.
libtasn1 2.0.

It also makes our (Debian and probably other distributors) life
unnecessary difficult, without any benefit for us, we already track
ABI through dependencies.

Please undo these changes, proposed patch against GIT HEAD attached.
thanks, cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposed.patch
Type: text/x-diff
Size: 1816 bytes
Desc: not available
URL: </pipermail/attachments/20090808/47d1c17b/attachment.patch>

From joe at x2a.org  Sat Aug  8 19:39:29 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Sat, 08 Aug 2009 13:39:29 -0400
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>	
	<4A79DE56.9030508@x2a.org>
	<c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>
Message-ID: <4A7DB851.4020600@x2a.org>

Nikos Mavrogiannopoulos wrote:
> On Wed, Aug 5, 2009 at 10:32 PM, Jonathan
> Bastien-Filiatrault<joe at x2a.org> wrote:
[snip]
>> Skb's tend to reduce copying to a minimum. In the implementation I
>> suggest I don't see how I can get away with less that one memcpy per
>> layer transition (unless I implement some zero-copy record-slicing
>> code-fu; something I want to avoid).
>> Right, encryption is a few orders of magnitude more costly than memcpy,
>>  in theory I could therefore get away with more memcpy without a
>> significant performance degradation (I won't push this too far, hopefully).
> 
> Indeed but don't underestimate memcpy. Both for low latency and high
> speed links (especially with crypto accelerators) that could be the
> bottleneck. Keep that in mind in your design. In any case it doesn't
> look easy task but that's always in the eye of the beholder.

Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for 
preliminary work. I have squashed _gnutls_io_write_buffered and down to 
less than a screenful each. The mbuffers code is now handling partial 
socket writes without problem (and regressions). The code is still 
missing some comments, but you should find it clear after a little 
while. The main benefit at this point is that the buffer logic is 
abstracted away in the mbuffers code and is kept out of the code that 
uses mbuffers.

Your input is very important to me at this point.
> 
> regards,
> Nikos

Cheers,
Jonathan




From ueno at unixuser.org  Sun Aug  9 08:48:29 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Sun, 09 Aug 2009 15:48:29 +0900
Subject: [PATCH] session ticket support
In-Reply-To: <87d478trxd.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 07 Aug 2009 01:59:26 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
Message-ID: <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>

>>>>> In <87d478trxd.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> I changed my mind: rather than supporting different formats and crypto
> agility, the entire API would become:

OK, I see.

>   int gnutls_session_ticket_key_generate (gnutls_datum_t *key);

> The algorithm used are chosen by the library.  The app has to write its
> own import/export stuff.  What do you think?

Sounds nice to me.  Here is the new patch, with changes from the
previous version:

* Internal session state format is used instead of the RFC
  recommendation.

* Fallback to full handshake if the decryption of tickets is failed.

* The key management interfaces are drawn togeter into a single function
  `gnutls_session_ticket_key_generate'

* tests/session_ticket.c is merged into tests/resume.c.

* The doc-comments for the new interface functions are added.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: session-ticket-2009-08-09.diff.gz
Type: application/octet-stream
Size: 9907 bytes
Desc: not available
URL: </pipermail/attachments/20090809/841a18ef/attachment.obj>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From nmav at gnutls.org  Sun Aug  9 18:21:22 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 09 Aug 2009 19:21:22 +0300
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A7DB851.4020600@x2a.org>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>	
	<4A79DE56.9030508@x2a.org>
	<c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>
	<4A7DB851.4020600@x2a.org>
Message-ID: <4A7EF782.7070806@gnutls.org>

Jonathan Bastien-Filiatrault wrote:

>> Indeed but don't underestimate memcpy. Both for low latency and high
>> speed links (especially with crypto accelerators) that could be the
>> bottleneck. Keep that in mind in your design. In any case it doesn't
>> look easy task but that's always in the eye of the beholder.
> 
> Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for
> preliminary work. I have squashed _gnutls_io_write_buffered and down to
> less than a screenful each. The mbuffers code is now handling partial
> socket writes without problem (and regressions). The code is still
> missing some comments, but you should find it clear after a little
> while. The main benefit at this point is that the buffer logic is
> abstracted away in the mbuffers code and is kept out of the code that
> uses mbuffers.
> 
> Your input is very important to me at this point.

Hello Jonathan,
 I like the overall change due to simplicity it introduces. Some comments:

- You could use const gnutls_datum* to pass datums that will not be
changed, just to save few bytes from stack.

- I don't like the malloc for each mbuffer_st being added. I'd suggest
to be avoided even if it results to some fixed number of mbuffers per
session (which seems quite realistic requirement).

Further I'd suggest to avoid the _gnutls_mbuffer_enqueue_copy() in
io_write_buffered() by passing a datum to the latter as well as flag on
whether this datum can be assigned without copy to an mbuffer. Thus in
gnutls_record.c you could convert
      ret = _gnutls_io_write_buffered (session, cipher, cipher_size);
      gnutls_free (cipher);
to something like:
	gnutls_datum tmp = {cipher, cipher_size};
	ret = _gnutls_io_write_buffered (session, &tmp, 1);
	if (ret < 0) {
		gnutls_free(cipher);
	}

and will allow the reuse of the already allocated data.

regards,
Nikos




From joe at x2a.org  Sun Aug  9 20:23:32 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Sun, 09 Aug 2009 14:23:32 -0400
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A7EF782.7070806@gnutls.org>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>	
	<4A79DE56.9030508@x2a.org>
	<c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>
	<4A7DB851.4020600@x2a.org> <4A7EF782.7070806@gnutls.org>
Message-ID: <4A7F1424.4090901@x2a.org>

Nikos Mavrogiannopoulos wrote:
> Jonathan Bastien-Filiatrault wrote:
> 
>>> Indeed but don't underestimate memcpy. Both for low latency and high
>>> speed links (especially with crypto accelerators) that could be the
>>> bottleneck. Keep that in mind in your design. In any case it doesn't
>>> look easy task but that's always in the eye of the beholder.
>> Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for
>> preliminary work. I have squashed _gnutls_io_write_buffered and down to
>> less than a screenful each. The mbuffers code is now handling partial
>> socket writes without problem (and regressions). The code is still
>> missing some comments, but you should find it clear after a little
>> while. The main benefit at this point is that the buffer logic is
>> abstracted away in the mbuffers code and is kept out of the code that
>> uses mbuffers.
>>
>> Your input is very important to me at this point.
> 
> Hello Jonathan,
>  I like the overall change due to simplicity it introduces. Some comments:
Thanks !
> 
> - You could use const gnutls_datum* to pass datums that will not be
> changed, just to save few bytes from stack.
No problem, I will do this.
> 
> - I don't like the malloc for each mbuffer_st being added. I'd suggest
> to be avoided even if it results to some fixed number of mbuffers per
> session (which seems quite realistic requirement).
So do we just allocate a series of maximum-sized buffers (2^14+2048 for 
regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free 
list and realloc if we need more memory ? I do not want to reimplement 
malloc... Is the added complexity worth it ? In the general case, 
mbuffer chains should not be very long...
> 
> Further I'd suggest to avoid the _gnutls_mbuffer_enqueue_copy() in
> io_write_buffered() by passing a datum to the latter as well as flag on
> whether this datum can be assigned without copy to an mbuffer. Thus in
> gnutls_record.c you could convert
>       ret = _gnutls_io_write_buffered (session, cipher, cipher_size);
>       gnutls_free (cipher);
> to something like:
> 	gnutls_datum tmp = {cipher, cipher_size};
> 	ret = _gnutls_io_write_buffered (session, &tmp, 1);
> 	if (ret < 0) {
> 		gnutls_free(cipher);
> 	}
Yes, I agree. I avoided this modification in order to keep the internal 
API constant for now. I will apply this modification.
> 
> and will allow the reuse of the already allocated data.
> 
> regards,
> Nikos

Thanks for your input,
Jonathan




From nmav at gnutls.org  Sun Aug  9 21:49:07 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 09 Aug 2009 22:49:07 +0300
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A7F1424.4090901@x2a.org>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>	
	<4A79DE56.9030508@x2a.org>
	<c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>
	<4A7DB851.4020600@x2a.org> <4A7EF782.7070806@gnutls.org>
	<4A7F1424.4090901@x2a.org>
Message-ID: <4A7F2833.9050002@gnutls.org>

Jonathan Bastien-Filiatrault wrote:

>> - I don't like the malloc for each mbuffer_st being added. I'd suggest
>> to be avoided even if it results to some fixed number of mbuffers per
>> session (which seems quite realistic requirement).
> So do we just allocate a series of maximum-sized buffers (2^14+2048 for
> regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free
> list and realloc if we need more memory ? I do not want to reimplement
> malloc... Is the added complexity worth it ? In the general case,
> mbuffer chains should not be very long...

No actually I was referring to the mbuffer_st structure. As far as I
understand this small structure is getting allocated once we are sending
a message (at least when io_write_buffered() is called). What I suggest
here is that we could avoid that allocation by having some constant
number of them for sending data.

If you want to keep the allocation for the mbuffer_t which will keep the
code simple maybe you can make the callers (now _gnutls_send_int) queue
an mbuffer_t directly. Thus the send_int() will allocate data for
mbuffer_t and the payload using a function such as(example):

mbuffer_st * allocate_with_payload(size_t payload_size)
{
	mbuffer_st * st;

	st = gnutls_malloc(payload_size+sizeof(mbuffer_st));

	//payload points after the mbuffer_st structure
	st->msg.data = st+sizeof(mbuffer_st);
	st->msg.size = payload_size;
}

and will fill in the payload and queue it directly down. Once the node
is freed the payload will be freed as well.

Maybe I'm insisting too much here, but I think that your current design
need not to be worse-performance wise from the current one.

Anyway consider my suggestions merely as suggestions. The design looks
good already.

I'll be unavailable for the next few weeks so all best!

Nikos




From joe at x2a.org  Sun Aug  9 22:30:12 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Sun, 09 Aug 2009 16:30:12 -0400
Subject: [RFC] Suggestion for the improvement of the buffering layer
In-Reply-To: <4A7F2833.9050002@gnutls.org>
References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org>	
	<4A79DE56.9030508@x2a.org>
	<c331d99a0908071542m3286f0b9s3080451a5a52e484@mail.gmail.com>
	<4A7DB851.4020600@x2a.org> <4A7EF782.7070806@gnutls.org>
	<4A7F1424.4090901@x2a.org> <4A7F2833.9050002@gnutls.org>
Message-ID: <4A7F31D4.3040309@x2a.org>

Nikos Mavrogiannopoulos wrote:
> Jonathan Bastien-Filiatrault wrote:
> 
>>> - I don't like the malloc for each mbuffer_st being added. I'd suggest
>>> to be avoided even if it results to some fixed number of mbuffers per
>>> session (which seems quite realistic requirement).
>> So do we just allocate a series of maximum-sized buffers (2^14+2048 for
>> regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free
>> list and realloc if we need more memory ? I do not want to reimplement
>> malloc... Is the added complexity worth it ? In the general case,
>> mbuffer chains should not be very long...
> 
> No actually I was referring to the mbuffer_st structure. As far as I
> understand this small structure is getting allocated once we are sending
> a message (at least when io_write_buffered() is called). What I suggest
> here is that we could avoid that allocation by having some constant
> number of them for sending data.

Oh, right. The chain nodes are a small and constant size and as you say, 
that overhead could be reduced.

> 
> If you want to keep the allocation for the mbuffer_t which will keep the
> code simple maybe you can make the callers (now _gnutls_send_int) queue
> an mbuffer_t directly. Thus the send_int() will allocate data for
> mbuffer_t and the payload using a function such as(example):
> 
> mbuffer_st * allocate_with_payload(size_t payload_size)
> {
> 	mbuffer_st * st;
> 
> 	st = gnutls_malloc(payload_size+sizeof(mbuffer_st));
> 
> 	//payload points after the mbuffer_st structure
> 	st->msg.data = st+sizeof(mbuffer_st);
> 	st->msg.size = payload_size;
> }
> 
> and will fill in the payload and queue it directly down. Once the node
> is freed the payload will be freed as well.

I like this, I will see what I can do...

> Maybe I'm insisting too much here, but I think that your current design
> need not to be worse-performance wise from the current one.

Not problem at all. My current objective is more code simplicity than 
performance at the moment, but I am doing my best to think about 
performance at the same time. Hopefully simpler and smaller code will 
result in less instruction cache misses in the buffer code ;P.

> Anyway consider my suggestions merely as suggestions. The design looks
> good already.
> 
> I'll be unavailable for the next few weeks so all best!

My vacation is ending today... sigh

> Nikos

Take care,
Jonathan




From simon at josefsson.org  Mon Aug 10 13:30:05 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Aug 2009 13:30:05 +0200
Subject: please test imminent 2.8.x release
In-Reply-To: <4A7C707D.8020308@filezilla-project.org> (Tim Kosse's message of
	"Fri, 07 Aug 2009 20:20:45 +0200")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org>
	<87skg4twfh.fsf@mocca.josefsson.org>
	<87hbwktseq.fsf_-_@mocca.josefsson.org>
	<4A7C707D.8020308@filezilla-project.org>
Message-ID: <874osfhpoi.fsf@mocca.josefsson.org>

Tim Kosse <tim.kosse at filezilla-project.org> writes:

> Hi,
>
>> Please test the release candidate:
>> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz
>
> works like a charm, I can no longer reproduce the issues I had with 2.8.1

Great.

> Just one minor detail, the fixes to the EGAIN problems aren't mentioned
> in the NEWS file.

Oops.  I think I made a proposal on what it should say, I'll try to find
in some e-mail..

I'll do the release shortly.

/Simon




From simon at josefsson.org  Mon Aug 10 14:33:00 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Aug 2009 14:33:00 +0200
Subject: gnutls version checking too strict
In-Reply-To: <20090808125646.GB3254@downhill.g.la> (Andreas Metzler's message
	of "Sat, 8 Aug 2009 14:56:46 +0200")
References: <20090808024733.GA31539@bongo.bofh.it>
	<20090808074058.GA3254@downhill.g.la>
	<20090808125646.GB3254@downhill.g.la>
Message-ID: <87tz0fg877.fsf@mocca.josefsson.org>

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

> On 2009-08-08 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> [...]
>> Upstream seems to have changed the code to require installation of
>> both gcrypt and tasn versions that greater or equal version gnutls
>> was built against.
>
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=ce23654ab3b8097241c1639ebe3e853c4f67b6d7
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=35bd51b3b42dd437a9914a908af45d78fec76856
> [...]
>> (See http://bugs.debian.org/495473 for comparison.)
>
> Hello,
> The gnutls 2.8 series will absolutely fail to work if the currently
> installed version of libtasn1 or libgcrypt is not greater or equal
> than the version gnutls was built against. This is much too cautious
> since the libtasn1 ABI has not changed at all since 1.6. A gnutls
> binary built against libtasn1 2.3 will work perfectly fiine with e.g.
> libtasn1 2.0.
>
> It also makes our (Debian and probably other distributors) life
> unnecessary difficult, without any benefit for us, we already track
> ABI through dependencies.
>
> Please undo these changes, proposed patch against GIT HEAD attached.
> thanks, cu andreas

Hi.  Just in time for the 2.8.2 release. :-)

I applied it somewhat differently, see:
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b

Thanks,
/Simon




From thoger at redhat.com  Mon Aug 10 15:02:32 2009
From: thoger at redhat.com (Tomas Hoger)
Date: Mon, 10 Aug 2009 13:02:32 +0000 (UTC)
Subject: please test imminent 2.8.x release
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org>
	<87skg4twfh.fsf@mocca.josefsson.org>
	<87hbwktseq.fsf_-_@mocca.josefsson.org>
Message-ID: <loom.20090810T125315-795@post.gmane.org>

Hi Simon!

Simon Josefsson <simon <at> josefsson.org> writes:

> Because of the NUL in CN/SAN issue we need to release a stable 2.8.x
> update quickly.
> 
> Please test the release candidate:
> 
> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz
> 
> This will be identical with the release unless I hear anything negative.
> 
> You can also help by reviewing the changes since 2.8.1:
> 
> http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x

Is it intentional that 2.8.2 does contain 21bc1439e5, but does not contain
9b0dc81885 and c9dba57f8d?  Moreover, is 21bc1439e5 still needed with 74b6d92f96
applied?  It seems that if there is NUL, GNUTLS_E_ASN1_DER_ERROR is returned
earlier or res is passed through _gnutls_x509_data2hex() and hence should not
contain NULs any more.

th.





From simon at josefsson.org  Mon Aug 10 15:43:44 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Aug 2009 15:43:44 +0200
Subject: GnuTLS 2.8.2
Message-ID: <87k51bg4xb.fsf@mocca.josefsson.org>

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

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

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

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

** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
into 1) not printing the entire CN/SAN field value when printing a
certificate and 2) cause incorrect positive matches when matching a
hostname against a certificate.  Some CAs apparently have poor
checking of CN/SAN values and issue these (arguable invalid)
certificates.  Combined, this can be used by attackers to become a
MITM on server-authenticated TLS sessions.  The problem is mitigated
since attackers needs to get one certificate per site they want to
attack, and the attacker reveals his tracks by applying for a
certificate at the CA.  It does not apply to client authenticated TLS
sessions.  Research presented independently by Dan Kaminsky and Moxie
Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
for providing one part of the patch.  [GNUTLS-SA-2009-4].

** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
Before it always returned false.  Reported by Peter Hendrickson
<pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.

** libgnutls: Fix off-by-one size computation error in unknown DN printing.
The error resulted in truncated strings when printing unknown OIDs in
X.509 certificate DNs.  Reported by Tim Kosse
<tim.kosse at filezilla-project.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.

** libgnutls: Return correct bit lengths of some MPIs.
gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
gnutls_dh_get_peers_public_bits.  Before the reported value was
overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.

** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
and
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.

** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
Before we required that the runtime library used the same (or more
recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
that the runtime usage is above the minimum required.  Reported by
Marco d'Itri <md at linux.it> via Andreas Metzler
<ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.

** minitasn1: Internal copy updated to libtasn1 v2.3.

** tests: Fix failure in "chainverify" because a certificate have expired.

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

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

eea59fb972e7d566679645a564a56b58aeffe10b  gnutls-2.8.2.tar.bz2

048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a  gnutls-2.8.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-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer includes
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2.

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

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

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

18fc15825832606123284dd5d7a77d402bf14101  gnutls-2.8.2.exe
9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3  gnutls-2.8.2.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.8.2.zip (5.3MB)
  http://josefsson.org/gnutls4win/gnutls-2.8.2.zip.sig

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

af492d1c31ef4ecc27724839ce62f5a334731b26  gnutls-2.8.2.zip
ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c  gnutls-2.8.2.zip

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.2-1_all.deb (4.8MB)

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

4d591773c387be1409fb000ff1a9eae3c3c19756  mingw32-gnutls_2.8.2-1_all.deb
fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57  mingw32-gnutls_2.8.2-1_all.deb

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

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Malay, Polish, Swedish, and Vietnamese.  We welcome the
addition of more translations.

Support
=======

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

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090810/607fbd3d/attachment.pgp>

From simon at josefsson.org  Mon Aug 10 15:55:47 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Aug 2009 15:55:47 +0200
Subject: please test imminent 2.8.x release
In-Reply-To: <loom.20090810T125315-795@post.gmane.org> (Tomas Hoger's message
	of "Mon, 10 Aug 2009 13:02:32 +0000 (UTC)")
References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org>
	<4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org>
	<87skg4twfh.fsf@mocca.josefsson.org>
	<87hbwktseq.fsf_-_@mocca.josefsson.org>
	<loom.20090810T125315-795@post.gmane.org>
Message-ID: <87fxbzg4d8.fsf@mocca.josefsson.org>

Tomas Hoger <thoger at redhat.com> writes:

> Hi Simon!
>
> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> Because of the NUL in CN/SAN issue we need to release a stable 2.8.x
>> update quickly.
>> 
>> Please test the release candidate:
>> 
>> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz
>> 
>> This will be identical with the release unless I hear anything negative.
>> 
>> You can also help by reviewing the changes since 2.8.1:
>> 
>> http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x
>
> Is it intentional that 2.8.2 does contain 21bc1439e5, but does not
> contain 9b0dc81885 and c9dba57f8d?  Moreover, is 21bc1439e5 still
> needed with 74b6d92f96 applied?  It seems that if there is NUL,
> GNUTLS_E_ASN1_DER_ERROR is returned earlier or res is passed through
> _gnutls_x509_data2hex() and hence should not contain NULs any more.

You are right.  21bc1439e5 is no longer needed and should not have been
in 2.8.x.  I wonder why the self-tests didn't catch that, by reading the
code it would seem to trigger an out-of-bounds read in some situations.

I'm wondering whether I need to release a 2.8.3 now...  or whether the
out-of-bounds read never happens in the 2.8.x branch for some other
reason.

See fixes at:
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=c12e7507562d5f168330acf1dd7db7cc2079cdf0
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=e52cbea94e67334c2c8e64c4bbb13d84c9d4433a

Thanks,
/Simon




From tmraz at redhat.com  Mon Aug 10 16:16:59 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 10 Aug 2009 16:16:59 +0200
Subject: please test imminent 2.8.x release
In-Reply-To: <87fxbzg4d8.fsf@mocca.josefsson.org>
References: <4A43C7FE.9090108@gnutls.org>
	<87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org>
	<87ab2flrrj.fsf@mocca.josefsson.org>
	<87zlaefqvf.fsf@mocca.josefsson.org>
	<4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org>
	<87hbwktseq.fsf_-_@mocca.josefsson.org>
	<loom.20090810T125315-795@post.gmane.org>
	<87fxbzg4d8.fsf@mocca.josefsson.org>
Message-ID: <1249913819.14237.21.camel@vespa.frost.loc>

On Mon, 2009-08-10 at 15:55 +0200, Simon Josefsson wrote:
> Tomas Hoger <thoger at redhat.com> writes:
> 
> > Hi Simon!
> >
> > Simon Josefsson <simon <at> josefsson.org> writes:
> >
> >> Because of the NUL in CN/SAN issue we need to release a stable 2.8.x
> >> update quickly.
> >> 
> >> Please test the release candidate:
> >> 
> >> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz
> >> 
> >> This will be identical with the release unless I hear anything negative.
> >> 
> >> You can also help by reviewing the changes since 2.8.1:
> >> 
> >> http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x
> >
> > Is it intentional that 2.8.2 does contain 21bc1439e5, but does not
> > contain 9b0dc81885 and c9dba57f8d?  Moreover, is 21bc1439e5 still
> > needed with 74b6d92f96 applied?  It seems that if there is NUL,
> > GNUTLS_E_ASN1_DER_ERROR is returned earlier or res is passed through
> > _gnutls_x509_data2hex() and hence should not contain NULs any more.
> 
> You are right.  21bc1439e5 is no longer needed and should not have been
> in 2.8.x.  I wonder why the self-tests didn't catch that, by reading the
> code it would seem to trigger an out-of-bounds read in some situations.
> 
> I'm wondering whether I need to release a 2.8.3 now...  or whether the
> out-of-bounds read never happens in the 2.8.x branch for some other
> reason.
> 
> See fixes at:
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=c12e7507562d5f168330acf1dd7db7cc2079cdf0
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=e52cbea94e67334c2c8e64c4bbb13d84c9d4433a

Unfortunately this seems to be exposed through public API so 2.8.3 seems
to be necessary.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From ametzler at downhill.at.eu.org  Mon Aug 10 19:03:48 2009
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 10 Aug 2009 19:03:48 +0200
Subject: gnutls version checking too strict
In-Reply-To: <87tz0fg877.fsf@mocca.josefsson.org>
References: <20090808024733.GA31539@bongo.bofh.it>
	<20090808074058.GA3254@downhill.g.la>
	<20090808125646.GB3254@downhill.g.la>
	<87tz0fg877.fsf@mocca.josefsson.org>
Message-ID: <20090810170348.GA3282@downhill.g.la>

On 2009-08-10 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > The gnutls 2.8 series will absolutely fail to work if the currently
> > installed version of libtasn1 or libgcrypt is not greater or equal
> > than the version gnutls was built against. This is much too cautious
[...]
> Hi.  Just in time for the 2.8.2 release. :-)

> I applied it somewhat differently, see:
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b

Thanks for fixing this very quickly.

I will try to find time for a (2.8.3, probably ;-) upload tomorrow.

cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'




From simon at josefsson.org  Mon Aug 10 21:47:43 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Aug 2009 21:47:43 +0200
Subject: Bug#540449: gnutls version checking too strict
In-Reply-To: <20090810170348.GA3282@downhill.g.la> (Andreas Metzler's message
	of "Mon, 10 Aug 2009 19:03:48 +0200")
References: <20090808024733.GA31539@bongo.bofh.it>
	<20090808074058.GA3254@downhill.g.la>
	<20090808125646.GB3254@downhill.g.la>
	<87tz0fg877.fsf@mocca.josefsson.org>
	<20090810170348.GA3282@downhill.g.la>
Message-ID: <87fxbzjvs0.fsf@mocca.josefsson.org>

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

> On 2009-08-10 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>> > The gnutls 2.8 series will absolutely fail to work if the currently
>> > installed version of libtasn1 or libgcrypt is not greater or equal
>> > than the version gnutls was built against. This is much too cautious
> [...]
>> Hi.  Just in time for the 2.8.2 release. :-)
>
>> I applied it somewhat differently, see:
>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b
>
> Thanks for fixing this very quickly.
>
> I will try to find time for a (2.8.3, probably ;-) upload tomorrow.

Right, please wait a day or two for 2.8.3 to avoid the double work.

I think lenny (and etch?) needs upgraded packages, though, for the
security problem.

/Simon




From simon at josefsson.org  Tue Aug 11 03:14:33 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Aug 2009 03:14:33 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> (Daiki
	Ueno's message of "Sun, 09 Aug 2009 15:48:29 +0900")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
	<363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>
Message-ID: <87prb3i22u.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> Sounds nice to me.  Here is the new patch, with changes from the
> previous version:

Thank you.

Once the papers have arrived, I think it is good enough to go in.  I'll
do a more careful review when I'm pushing it.

Meanwhile, it would be nice with some more self-tests.  How about also
testing:

* What happens if the client provides a garbage session ticket?

  - Does the RFC specify what should happen?  I'd assume that the
    handshake continues as normal, but I'm not sure.

* What happens if the client has a session ticket but the server has
  disabled session ticket support?

/Simon




From Jeff.Cai at Sun.COM  Wed Aug 12 10:43:51 2009
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Wed, 12 Aug 2009 16:43:51 +0800
Subject: GnuTLS 2.8.2
In-Reply-To: <87k51bg4xb.fsf@mocca.josefsson.org>
References: <87k51bg4xb.fsf@mocca.josefsson.org>
Message-ID: <1250066631.3868.8.camel@marathon>


> What's New
> ==========
> 
> ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
> By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
> into 1) not printing the entire CN/SAN field value when printing a
> certificate and 2) cause incorrect positive matches when matching a
> hostname against a certificate.  Some CAs apparently have poor
> checking of CN/SAN values and issue these (arguable invalid)
> certificates.  Combined, this can be used by attackers to become a
> MITM on server-authenticated TLS sessions.  The problem is mitigated
> since attackers needs to get one certificate per site they want to
> attack, and the attacker reveals his tracks by applying for a
> certificate at the CA.  It does not apply to client authenticated TLS
> sessions.  Research presented independently by Dan Kaminsky and Moxie
> Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
> for providing one part of the patch.  [GNUTLS-SA-2009-4].

How is it affecting old versions of gnutls like 2.6 and 2.4? Do they
also need a patch applied if not upgrading them?

Jeff

> 
> ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
> Before it always returned false.  Reported by Peter Hendrickson
> <pdh at wiredyne.com> in
> <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.
> 
> ** libgnutls: Fix off-by-one size computation error in unknown DN printing.
> The error resulted in truncated strings when printing unknown OIDs in
> X.509 certificate DNs.  Reported by Tim Kosse
> <tim.kosse at filezilla-project.org> in
> <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.
> 
> ** libgnutls: Return correct bit lengths of some MPIs.
> gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
> gnutls_dh_get_peers_public_bits.  Before the reported value was
> overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
> <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.
> 
> ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
> Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
> <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
> and
> <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.
> 
> ** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
> Before we required that the runtime library used the same (or more
> recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
> that the runtime usage is above the minimum required.  Reported by
> Marco d'Itri <md at linux.it> via Andreas Metzler
> <ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.
> 
> ** minitasn1: Internal copy updated to libtasn1 v2.3.
> 
> ** tests: Fix failure in "chainverify" because a certificate have expired.
> 
> ** API and ABI modifications:
> No changes since last version.
> 
> Getting the Software
> ====================
> 
> GnuTLS may be downloaded from one of the mirror sites or direct from
> <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
> <http://www.gnu.org/software/gnutls/download.html>.
> 
> Here are the BZIP2 compressed sources (6.0MB):
> 
>   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2
>   http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2
> 
> Here are OpenPGP detached signatures signed using key 0xB565716F:
> 
>   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig
>   http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.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.8.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: 2010-04-21]
>       Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
> uid                  Simon Josefsson <simon at josefsson.org>
> uid                  Simon Josefsson <jas at extundo.com>
> sub   1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21]
> 
> The key is available from:
>   http://josefsson.org/key.txt
>   dns:b565716f.josefsson.org?TYPE=CERT
> 
> Alternatively, after successfully verifying the OpenPGP signature of
> this announcement, you could verify that the files match the following
> checksum values.  The values are for SHA-1 and SHA-224 respectively:
> 
> eea59fb972e7d566679645a564a56b58aeffe10b  gnutls-2.8.2.tar.bz2
> 
> 048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a  gnutls-2.8.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-dev mailing list, see:
> 
>   http://lists.gnu.org/mailman/listinfo/gnutls-devel
> 
> Windows installer
> =================
> 
> GnuTLS has been ported to the Windows operating system, and a binary
> installer is available.  The installer contains DLLs for application
> development, manuals, examples, and source code.  The installer includes
> libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2.
> 
> For more information about GnuTLS for Windows:
>   http://josefsson.org/gnutls4win/
> 
> The Windows binary installer and PGP signature:
>   http://josefsson.org/gnutls4win/gnutls-2.8.2.exe (15MB)
>   http://josefsson.org/gnutls4win/gnutls-2.8.2.exe.sig
> 
> The checksum values for SHA-1 and SHA-224 are:
> 
> 18fc15825832606123284dd5d7a77d402bf14101  gnutls-2.8.2.exe
> 9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3  gnutls-2.8.2.exe
> 
> A ZIP archive containing the Windows binaries:
>   http://josefsson.org/gnutls4win/gnutls-2.8.2.zip (5.3MB)
>   http://josefsson.org/gnutls4win/gnutls-2.8.2.zip.sig
> 
> The checksum values for SHA-1 and SHA-224 are:
> 
> af492d1c31ef4ecc27724839ce62f5a334731b26  gnutls-2.8.2.zip
> ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c  gnutls-2.8.2.zip
> 
> A Debian mingw32 package is also available:
>   http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.2-1_all.deb (4.8MB)
> 
> The checksum values for SHA-1 and SHA-224 are:
> 
> 4d591773c387be1409fb000ff1a9eae3c3c19756  mingw32-gnutls_2.8.2-1_all.deb
> fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57  mingw32-gnutls_2.8.2-1_all.deb
> 
> Internationalization
> ====================
> 
> The GnuTLS library messages have been translated into Czech, Dutch,
> French, German, Malay, Polish, Swedish, and Vietnamese.  We welcome the
> addition of more translations.
> 
> Support
> =======
> 
> Improving GnuTLS is costly, but you can help!  We are looking for
> organizations that find GnuTLS useful and wish to contribute back.  You
> can contribute by reporting bugs, improve the software, or donate money
> or equipment.
> 
> Commercial support contracts for GnuTLS are available, and they help
> finance continued maintenance.  Simon Josefsson Datakonsult AB, a
> Stockholm based privately held company, is currently funding GnuTLS
> maintenance.  We are always looking for interesting development
> projects.  See http://josefsson.org/ for more details.
> 
> The GnuTLS service directory is available at:
> 
>   http://www.gnu.org/software/gnutls/commercial.html
> 
> Happy Hacking,
> Simon
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel





From Jeff.Cai at Sun.COM  Thu Aug 13 04:36:39 2009
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Thu, 13 Aug 2009 10:36:39 +0800
Subject: GnuTLS 2.8.2
In-Reply-To: <1250066631.3868.8.camel@marathon>
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon>
Message-ID: <1250130999.4606.1.camel@marathon>

Simon,

Could you provide a patch for 2.6.6 or release 2.6.8 to fix this issue?

Thanks

Jeff

On Wed, 2009-08-12 at 16:43 +0800, Jeff Cai wrote:
> > What's New
> > ==========
> > 
> > ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
> > By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
> > into 1) not printing the entire CN/SAN field value when printing a
> > certificate and 2) cause incorrect positive matches when matching a
> > hostname against a certificate.  Some CAs apparently have poor
> > checking of CN/SAN values and issue these (arguable invalid)
> > certificates.  Combined, this can be used by attackers to become a
> > MITM on server-authenticated TLS sessions.  The problem is mitigated
> > since attackers needs to get one certificate per site they want to
> > attack, and the attacker reveals his tracks by applying for a
> > certificate at the CA.  It does not apply to client authenticated TLS
> > sessions.  Research presented independently by Dan Kaminsky and Moxie
> > Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
> > for providing one part of the patch.  [GNUTLS-SA-2009-4].
> 
> How is it affecting old versions of gnutls like 2.6 and 2.4? Do they
> also need a patch applied if not upgrading them?
> 
> Jeff
> 
> > 
> > ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
> > Before it always returned false.  Reported by Peter Hendrickson
> > <pdh at wiredyne.com> in
> > <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.
> > 
> > ** libgnutls: Fix off-by-one size computation error in unknown DN printing.
> > The error resulted in truncated strings when printing unknown OIDs in
> > X.509 certificate DNs.  Reported by Tim Kosse
> > <tim.kosse at filezilla-project.org> in
> > <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.
> > 
> > ** libgnutls: Return correct bit lengths of some MPIs.
> > gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
> > gnutls_dh_get_peers_public_bits.  Before the reported value was
> > overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
> > <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.
> > 
> > ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
> > Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
> > <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
> > and
> > <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.
> > 
> > ** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
> > Before we required that the runtime library used the same (or more
> > recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
> > that the runtime usage is above the minimum required.  Reported by
> > Marco d'Itri <md at linux.it> via Andreas Metzler
> > <ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.
> > 
> > ** minitasn1: Internal copy updated to libtasn1 v2.3.
> > 
> > ** tests: Fix failure in "chainverify" because a certificate have expired.
> > 
> > ** API and ABI modifications:
> > No changes since last version.
> > 
> > Getting the Software
> > ====================
> > 
> > GnuTLS may be downloaded from one of the mirror sites or direct from
> > <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
> > <http://www.gnu.org/software/gnutls/download.html>.
> > 
> > Here are the BZIP2 compressed sources (6.0MB):
> > 
> >   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2
> >   http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2
> > 
> > Here are OpenPGP detached signatures signed using key 0xB565716F:
> > 
> >   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig
> >   http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.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.8.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: 2010-04-21]
> >       Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
> > uid                  Simon Josefsson <simon at josefsson.org>
> > uid                  Simon Josefsson <jas at extundo.com>
> > sub   1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21]
> > 
> > The key is available from:
> >   http://josefsson.org/key.txt
> >   dns:b565716f.josefsson.org?TYPE=CERT
> > 
> > Alternatively, after successfully verifying the OpenPGP signature of
> > this announcement, you could verify that the files match the following
> > checksum values.  The values are for SHA-1 and SHA-224 respectively:
> > 
> > eea59fb972e7d566679645a564a56b58aeffe10b  gnutls-2.8.2.tar.bz2
> > 
> > 048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a  gnutls-2.8.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-dev mailing list, see:
> > 
> >   http://lists.gnu.org/mailman/listinfo/gnutls-devel
> > 
> > Windows installer
> > =================
> > 
> > GnuTLS has been ported to the Windows operating system, and a binary
> > installer is available.  The installer contains DLLs for application
> > development, manuals, examples, and source code.  The installer includes
> > libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2.
> > 
> > For more information about GnuTLS for Windows:
> >   http://josefsson.org/gnutls4win/
> > 
> > The Windows binary installer and PGP signature:
> >   http://josefsson.org/gnutls4win/gnutls-2.8.2.exe (15MB)
> >   http://josefsson.org/gnutls4win/gnutls-2.8.2.exe.sig
> > 
> > The checksum values for SHA-1 and SHA-224 are:
> > 
> > 18fc15825832606123284dd5d7a77d402bf14101  gnutls-2.8.2.exe
> > 9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3  gnutls-2.8.2.exe
> > 
> > A ZIP archive containing the Windows binaries:
> >   http://josefsson.org/gnutls4win/gnutls-2.8.2.zip (5.3MB)
> >   http://josefsson.org/gnutls4win/gnutls-2.8.2.zip.sig
> > 
> > The checksum values for SHA-1 and SHA-224 are:
> > 
> > af492d1c31ef4ecc27724839ce62f5a334731b26  gnutls-2.8.2.zip
> > ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c  gnutls-2.8.2.zip
> > 
> > A Debian mingw32 package is also available:
> >   http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.2-1_all.deb (4.8MB)
> > 
> > The checksum values for SHA-1 and SHA-224 are:
> > 
> > 4d591773c387be1409fb000ff1a9eae3c3c19756  mingw32-gnutls_2.8.2-1_all.deb
> > fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57  mingw32-gnutls_2.8.2-1_all.deb
> > 
> > Internationalization
> > ====================
> > 
> > The GnuTLS library messages have been translated into Czech, Dutch,
> > French, German, Malay, Polish, Swedish, and Vietnamese.  We welcome the
> > addition of more translations.
> > 
> > Support
> > =======
> > 
> > Improving GnuTLS is costly, but you can help!  We are looking for
> > organizations that find GnuTLS useful and wish to contribute back.  You
> > can contribute by reporting bugs, improve the software, or donate money
> > or equipment.
> > 
> > Commercial support contracts for GnuTLS are available, and they help
> > finance continued maintenance.  Simon Josefsson Datakonsult AB, a
> > Stockholm based privately held company, is currently funding GnuTLS
> > maintenance.  We are always looking for interesting development
> > projects.  See http://josefsson.org/ for more details.
> > 
> > The GnuTLS service directory is available at:
> > 
> >   http://www.gnu.org/software/gnutls/commercial.html
> > 
> > Happy Hacking,
> > Simon
> > _______________________________________________
> > Gnutls-devel mailing list
> > Gnutls-devel at gnu.org
> > http://lists.gnu.org/mailman/listinfo/gnutls-devel
> 
> 
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel





From simon at josefsson.org  Thu Aug 13 12:11:17 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Aug 2009 12:11:17 +0200
Subject: GnuTLS 2.8.2
In-Reply-To: <1250130999.4606.1.camel@marathon> (Jeff Cai's message of "Thu,
	13 Aug 2009 10:36:39 +0800")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
Message-ID: <878whodnwa.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> Simon,
>
> Could you provide a patch for 2.6.6 or release 2.6.8 to fix this issue?

I'm releasing an updated 2.8.3 shortly, and will post patches against
2.8.1 to solve the problem -- hopefully they will apply to 2.6.x as
well.  There is an issue that gnutls-cli before 2.8.x used its own
certificate printing functions, but that is only a display problem.

/Simon




From simon at josefsson.org  Thu Aug 13 12:32:01 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Aug 2009 12:32:01 +0200
Subject: GnuTLS 2.8.3
Message-ID: <871vngdmxq.fsf@mocca.josefsson.org>

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

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

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

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

** libgnutls: Fix patch for NUL in CN/SAN in last release.
Code intended to be removed would lead to an read-out-bound error in
some situations.  Reported by Tomas Hoger <thoger at redhat.com>.  A CVE
code have been allocated for the vulnerability: [CVE-2009-2730].

** libgnutls: Fix rare failure in gnutls_x509_crt_import.
The function may fail incorrectly when an earlier certificate was
imported to the same gnutls_x509_crt_t structure.

** libgnutls-extra, libgnutls-openssl: Fix MinGW cross-compiling build error.

** tests: Made self-test mini-eagain take less time.

** doc: Typo fixes.

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

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (6.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.3.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.3.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.8.3.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2010-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21]

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

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

c25fb354258777f9ee34b79b08eb87c024cada75  gnutls-2.8.3.tar.bz2
dff4d774ec9339a1e94711fc9c3762d36df1e77c0b1c1a591ea190aa  gnutls-2.8.3.tar.bz2

Documentation
=============

The manual is available online at:

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

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

For developers interested in improving code quality, we publish
Cyclomatic code complexity charts that help you find code that may need
review and improvements:

  http://www.gnu.org/software/gnutls/cyclo/

Also useful are code coverage charts which indicate parts of the source
code that needs to be tested better by the included self-tests:

  http://www.gnu.org/software/gnutls/coverage/

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer includes
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.3.

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

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

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

6c6503cbd357d71595a320502ce3e32fe5598d64  gnutls-2.8.3.exe
f75988a6efe8306bf4ba4827ff49a2fd39f3f6d9730ddffcca1f3254  gnutls-2.8.3.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.8.3.zip (5.3MB)
  http://josefsson.org/gnutls4win/gnutls-2.8.3.zip.sig

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

4c4829495d7277b3fec69a975084e1144e805e0d  gnutls-2.8.3.zip
515dcbe98b739db7419ae25db1a2d59d3cea60683ca1bfd424c348b3  gnutls-2.8.3.zip

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.3-1_all.deb (4.8MB)

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

8cf060268369f1d261b10731840cf0392e625210  mingw32-gnutls_2.8.3-1_all.deb
0f99a5a356cd1a03cc0a3cce9f19b7615772d4486fea0d06e68f3ef6  mingw32-gnutls_2.8.3-1_all.deb

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

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Malay, Polish, Swedish, and Vietnamese.  We welcome the
addition of more translations.

Support
=======

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

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090813/d401f5dd/attachment.pgp>

From simon at josefsson.org  Thu Aug 13 12:48:38 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Aug 2009 12:48:38 +0200
Subject: Bug#540449: gnutls version checking too strict
In-Reply-To: <87fxbzjvs0.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 10 Aug 2009 21:47:43 +0200")
References: <20090808024733.GA31539@bongo.bofh.it>
	<20090808074058.GA3254@downhill.g.la>
	<20090808125646.GB3254@downhill.g.la>
	<87tz0fg877.fsf@mocca.josefsson.org>
	<20090810170348.GA3282@downhill.g.la>
	<87fxbzjvs0.fsf@mocca.josefsson.org>
Message-ID: <87tz0cc7ll.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>
>> On 2009-08-10 Simon Josefsson <simon at josefsson.org> wrote:
>>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>> [...]
>>> > The gnutls 2.8 series will absolutely fail to work if the currently
>>> > installed version of libtasn1 or libgcrypt is not greater or equal
>>> > than the version gnutls was built against. This is much too cautious
>> [...]
>>> Hi.  Just in time for the 2.8.2 release. :-)
>>
>>> I applied it somewhat differently, see:
>>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b
>>
>> Thanks for fixing this very quickly.
>>
>> I will try to find time for a (2.8.3, probably ;-) upload tomorrow.
>
> Right, please wait a day or two for 2.8.3 to avoid the double work.

Now released!

> I think lenny (and etch?) needs upgraded packages, though, for the
> security problem.

I'm working on publishing minimal patches for 2.8.x, which hopefully
won't be that difficult to back-port to 2.6.x or earlier versions.

/Simon




From Jeff.Cai at Sun.COM  Fri Aug 14 10:11:55 2009
From: Jeff.Cai at Sun.COM (Jeff Cai)
Date: Fri, 14 Aug 2009 16:11:55 +0800
Subject: GnuTLS 2.8.2
In-Reply-To: <878whodnwa.fsf@mocca.josefsson.org>
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
Message-ID: <1250237515.5919.1.camel@marathon>

Simon,

I didn't find that patch. Could you please tell me where it is? Thanks
in advance. :)

Then will you release a new package like 2.6.7 to fix this issue?

Thanks

Jeff

On Thu, 2009-08-13 at 12:11 +0200, Simon Josefsson wrote:
> Jeff Cai <Jeff.Cai at Sun.COM> writes:
> 
> > Simon,
> >
> > Could you provide a patch for 2.6.6 or release 2.6.8 to fix this issue?
> 
> I'm releasing an updated 2.8.3 shortly, and will post patches against
> 2.8.1 to solve the problem -- hopefully they will apply to 2.6.x as
> well.  There is an issue that gnutls-cli before 2.8.x used its own
> certificate printing functions, but that is only a display problem.
> 
> /Simon
> 
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel





From simon at josefsson.org  Fri Aug 14 12:02:27 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Aug 2009 12:02:27 +0200
Subject: NUL bytes in X.509 CN/SAN fields [GNUTLS-SA-2009-4] [CVE-2009-2730]
Message-ID: <87ws56pvbg.fsf@mocca.josefsson.org>

Research presented independently by Dan Kaminsky and Moxie Marlinspike
at BlackHat09 demonstrated a vulnerability related to NUL bytes in X.509
certificate name fields.  Attackers needs to go to a CA and acquire a
certificate for an invalid name.  To attack GnuTLS, the attacker needs
to acquire such an invalid certificate for each TLS server to be
attacked.  The attacker is then able to use the certificate to become a
man-in-the-middle on server authenticated channels.  The client will
receive the attacker's certificate, so the attack leaves traces with the
client.  The attack does not work for client-authenticated TLS channels.

To make client notice the attack and reject it, a few separate aspects
needs to be resolved:

1) When displaying a certificate to the user, GnuTLS needs to be fixed
so that it does not truncate strings in CN/SAN fields to the first NUL.

2) When comparing the CN/SAN fields to a hostname, it has to make sure
it compares the entire string, and not only up until the first NUL.

We recommend all users to upgrade to version 2.8.3 which solves these
concerns.

For people using older releases, or wants to read the minimal patch
required to solve the problem, I have prepared patches that applies to
version 2.8.1 -- the last stable releases that didn't have this
vulnerability.

To solve 1) apply PATCH 1 included below.  The patches in git
corresponding to this patch is (they have to be applied in order):

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=a431be86124f900c4082e82d32917f86fcce461a
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=74b6d92f9675ce4e03642c4d6ced4a3a614b07f6
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=40081594e3de518b998f3e5177ed5a9f7707f2e8

To solve 2) apply PATCH 2 included below.  This patch was supplied by
Tomas Hoger <thoger at redhat.com>.  The patches in git corresponding to
this patch is (they have to be applied in order):

http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=5a58e9d33448235377afd5fbfcee1683dc70eae3
http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=1ea190d216767dd4ab93b87361cbcb9d4fb3aafc

I have verified that the patches work for v2.6.6 as well if you manually
resolve one failed hunk.

/Simon

PATCH 1

diff -ur gnutls-2.8.1.orig/lib/x509/common.c gnutls-2.8.1/lib/x509/common.c
--- gnutls-2.8.1.orig/lib/x509/common.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/x509/common.c	2009-08-14 11:56:17.000000000 +0200
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation
+ * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation
  *
  * Author: Nikos Mavrogiannopoulos
  *
@@ -242,6 +242,10 @@
     {
       str[len] = 0;
 
+      /* Refuse to deal with strings containing NULs. */
+      if (strlen (str) != len)
+	return GNUTLS_E_ASN1_DER_ERROR;
+
       if (res)
 	_gnutls_str_cpy (res, *res_size, str);
       *res_size = len;
@@ -291,25 +295,27 @@
 	    non_printable = 0;
 	}
 
-      if (res)
+      if (non_printable == 0)
 	{
-	  if (non_printable == 0)
-	    {
-	      str[len] = 0;
-	      _gnutls_str_cpy (res, *res_size, str);
-	      *res_size = len;
-	    }
-	  else
+	  str[len] = 0;
+
+	  /* Refuse to deal with strings containing NULs. */
+	  if (strlen (str) != len)
+	    return GNUTLS_E_ASN1_DER_ERROR;
+
+	  if (res)
+	    _gnutls_str_cpy (res, *res_size, str);
+	  *res_size = len;
+	}
+      else
+	{
+	  result = _gnutls_x509_data2hex (str, len, res, res_size);
+	  if (result < 0)
 	    {
-	      result = _gnutls_x509_data2hex (str, len, res, res_size);
-	      if (result < 0)
-		{
-		  gnutls_assert ();
-		  return result;
-		}
+	      gnutls_assert ();
+	      return result;
 	    }
 	}
-
     }
 
   return 0;
diff -ur gnutls-2.8.1.orig/lib/x509/output.c gnutls-2.8.1/lib/x509/output.c
--- gnutls-2.8.1.orig/lib/x509/output.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/x509/output.c	2009-08-14 11:56:17.000000000 +0200
@@ -354,6 +354,17 @@
 	  return;
 	}
 
+      if ((err == GNUTLS_SAN_DNSNAME
+	   || err == GNUTLS_SAN_RFC822NAME
+	   || err == GNUTLS_SAN_URI) &&
+	  strlen (buffer) != size)
+	{
+	  adds (str, _("warning: distributionPoint contains an embedded NUL, "
+		       "replacing with '!'\n"));
+	  while (strlen (buffer) < size)
+	    buffer[strlen (buffer)] = '!';
+	}
+
       switch (err)
 	{
 	case GNUTLS_SAN_DNSNAME:
@@ -552,6 +563,17 @@
 	  return;
 	}
 
+      if ((err == GNUTLS_SAN_DNSNAME
+	   || err == GNUTLS_SAN_RFC822NAME
+	   || err == GNUTLS_SAN_URI) &&
+	  strlen (buffer) != size)
+	{
+	  adds (str, _("warning: SAN contains an embedded NUL, "
+		       "replacing with '!'\n"));
+	  while (strlen (buffer) < size)
+	    buffer[strlen (buffer)] = '!';
+	}
+
       switch (err)
 	{
 	case GNUTLS_SAN_DNSNAME:
@@ -623,8 +645,18 @@
 	      }
 
 	    if (err == GNUTLS_SAN_OTHERNAME_XMPP)
-	      addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix,
-		    (int) size, buffer);
+	      {
+		if (strlen (buffer) != size)
+		  {
+		    adds (str, _("warning: SAN contains an embedded NUL, "
+				 "replacing with '!'\n"));
+		    while (strlen (buffer) < size)
+		      buffer[strlen (buffer)] = '!';
+		  }
+
+		addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix,
+		      (int) size, buffer);
+	      }
 	    else
 	      {
 		addf (str, _("%s\t\t\totherName OID: %.*s\n"), prefix,


PATCH 2

diff -ur gnutls-2.8.1.orig/lib/gnutls_str.c gnutls-2.8.1/lib/gnutls_str.c
--- gnutls-2.8.1.orig/lib/gnutls_str.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/gnutls_str.c	2009-08-14 11:40:45.000000000 +0200
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2002, 2004, 2005, 2007, 2008  Free Software Foundation
+ * Copyright (C) 2002, 2004, 2005, 2007, 2008, 2009  Free Software Foundation
  *
  * Author: Nikos Mavrogiannopoulos
  *
@@ -363,17 +363,22 @@
 
 /* compare hostname against certificate, taking account of wildcards
  * return 1 on success or 0 on error
+ *
+ * note: certnamesize is required as X509 certs can contain embedded NULs in
+ * the strings such as CN or subjectAltName
  */
 int
-_gnutls_hostname_compare (const char *certname, const char *hostname)
+_gnutls_hostname_compare (const char *certname,
+			  size_t certnamesize,
+			  const char *hostname)
 {
   /* find the first different character */
   for (; *certname && *hostname && toupper (*certname) == toupper (*hostname);
-       certname++, hostname++)
+       certname++, hostname++, certnamesize--)
     ;
 
   /* the strings are the same */
-  if (strlen (certname) == 0 && strlen (hostname) == 0)
+  if (certnamesize == 0 && *hostname == '\0')
     return 1;
 
   if (*certname == '*')
@@ -381,15 +386,16 @@
       /* a wildcard certificate */
 
       certname++;
+      certnamesize--;
 
       while (1)
 	{
 	  /* Use a recursive call to allow multiple wildcards */
-	  if (_gnutls_hostname_compare (certname, hostname))
-	    {
-	      return 1;
-	    }
-	  /* wildcards are only allowed to match a single domain component or component fragment */
+	  if (_gnutls_hostname_compare (certname, certnamesize, hostname))
+	    return 1;
+
+	  /* wildcards are only allowed to match a single domain
+	     component or component fragment */
 	  if (*hostname == '\0' || *hostname == '.')
 	    break;
 	  hostname++;
diff -ur gnutls-2.8.1.orig/lib/gnutls_str.h gnutls-2.8.1/lib/gnutls_str.h
--- gnutls-2.8.1.orig/lib/gnutls_str.h	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/gnutls_str.h	2009-08-14 11:40:45.000000000 +0200
@@ -79,7 +79,7 @@
 int _gnutls_hex2bin (const opaque * hex_data, int hex_size, opaque * bin_data,
 		     size_t * bin_size);
 
-int _gnutls_hostname_compare (const char *certname, const char *hostname);
+int _gnutls_hostname_compare (const char *certname, size_t certnamesize, const char *hostname);
 #define MAX_CN 256
 
 #endif
diff -ur gnutls-2.8.1.orig/lib/openpgp/pgp.c gnutls-2.8.1/lib/openpgp/pgp.c
--- gnutls-2.8.1.orig/lib/openpgp/pgp.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/openpgp/pgp.c	2009-08-14 11:40:45.000000000 +0200
@@ -570,7 +570,7 @@
 
       if (ret == 0)
 	{
-	  if (_gnutls_hostname_compare (dnsname, hostname))
+	  if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	    return 1;
 	}
     }
diff -ur gnutls-2.8.1.orig/lib/x509/rfc2818_hostname.c gnutls-2.8.1/lib/x509/rfc2818_hostname.c
--- gnutls-2.8.1.orig/lib/x509/rfc2818_hostname.c	2009-06-02 20:59:32.000000000 +0200
+++ gnutls-2.8.1/lib/x509/rfc2818_hostname.c	2009-08-14 11:40:45.000000000 +0200
@@ -74,7 +74,7 @@
       if (ret == GNUTLS_SAN_DNSNAME)
 	{
 	  found_dnsname = 1;
-	  if (_gnutls_hostname_compare (dnsname, hostname))
+	  if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	    {
 	      return 1;
 	    }
@@ -84,7 +84,7 @@
 	  found_dnsname = 1;	/* RFC 2818 is unclear whether the CN
 				   should be compared for IP addresses
 				   too, but we won't do it.  */
-	  if (_gnutls_hostname_compare (dnsname, hostname))
+	  if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	    {
 	      return 1;
 	    }
@@ -104,7 +104,7 @@
 	  return 0;
 	}
 
-      if (_gnutls_hostname_compare (dnsname, hostname))
+      if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname))
 	{
 	  return 1;
 	}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090814/7f81d2ea/attachment.pgp>

From simon at josefsson.org  Fri Aug 14 12:04:07 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Aug 2009 12:04:07 +0200
Subject: GnuTLS 2.8.2
In-Reply-To: <1250237515.5919.1.camel@marathon> (Jeff Cai's message of "Fri,
	14 Aug 2009 16:11:55 +0800")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
Message-ID: <87skfupv8o.fsf@mocca.josefsson.org>

Jeff Cai <Jeff.Cai at Sun.COM> writes:

> Simon,
>
> I didn't find that patch. Could you please tell me where it is? Thanks
> in advance. :)

Just posted. ;)

> Then will you release a new package like 2.6.7 to fix this issue?

I don't have time/resources to produce releases for older branches.  If
someone else wants to volunteer to work on fixing older releases, that
would be appreciated.

/Simon




From simon at josefsson.org  Fri Aug 14 12:14:21 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Aug 2009 12:14:21 +0200
Subject: How to check if your GnuTLS is vulnerable to NUL-in-CN/SAN issue
Message-ID: <87my62purm.fsf@mocca.josefsson.org>

Here is how you test if your GnuTLS library is vulnerable to the
NUL-in-CN/SAN issue (i.e., [GNUTLS-SA-2009-4] [CVE-2009-2730]).

Download and build:
http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c

For example:

jas at mocca:~$ wget -q http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c
jas at mocca:~$ gcc -o nul-in-x509-names nul-in-x509-names.c -lgnutls
jas at mocca:~$ ./nul-in-x509-names 
gnutls_x509_crt_check_hostname OK (NUL-IN-CN)
gnutls_x509_crt_check_hostname OK (NUL-IN-SAN)
jas at mocca:~$

If your library have not yet been patched, the output will look like:

gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN)
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN)

If you have a locally installed GnuTLS version and wants to check your
system library version, on GNU/Linux system you can use the LD_PRELOAD
variable to point at the exact library version to test.  For example on
my Debian system:

jas at mocca:~$ LD_PRELOAD=/usr/lib/libgnutls.so ./nul-in-x509-names 
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN)
gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN)
jas at mocca:~$ 

To verify that displaying of certificates works correctly, you can use
two sample certificates provided by Tomas Hoger <thoger at redhat.com>.

To test whether NUL in CN is handled properly, here is how you do it:

jas at mocca:~$ cat>nul-cn.pem
-----BEGIN CERTIFICATE-----
MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJHQjES
MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N
eSBDb21wYW55IEx0ZDELMAkGA1UECxMCQ0ExGTAXBgNVBAMTEE5VTEwtZnJpZW5k
bHkgQ0EwHhcNMDkwODA0MDczMzQzWhcNMTkwODAyMDczMzQzWjAjMSEwHwYDVQQD
Exh3d3cuYmFuay5jb20ALmJhZGd1eS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDNJnCWqaZdPpztDwgVWnwXJWhorxO5rUH6ElTihHJ9WNHiQELB
We0FPaoQU3AAiDp3oMBWnqx9ISpxRFEIvBcH2qijdtxRvBuK9gIaVb9GtERrJ16+
5ReLVrLGgjYRg6i/9y8NF/bNR7VvK6ZBto0zX+rqi7Ea4pk4/1lbCqFxE8o3P7mw
HpGayJM1DErgnfTSYcdOW0EKfDFUmdv1Zc6A08ICN2T9VBJ76qyFWVwX4S720Kjy
0C6UWS/Cpl/aB957LhQH7eQnJDedCS6x+VpIuYAkQ+bLx24139VpNP/m1p7odmZu
X1kBPJY77HILPB6VD85oE5wi3Ru1RChQSgV/AgMBAAGjezB5MAkGA1UdEwQCMAAw
LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G
A1UdDgQWBBQzFSS+2mY6BovZJzQ6r2JA5JVmXTAfBgNVHSMEGDAWgBQKaTlfnTAE
GAguAg7m6p2yJvbiajANBgkqhkiG9w0BAQUFAAOCAQEAMmUjH8jZU4SC0ArrFFEk
A7xsGypa/hvw6GkMKxmGz38ydtgr0s+LxNG2W5xgo5kuknIGzt6L0qLSiXwTqQtO
vhIJ5dYoOqynJlaUfxPuZH3elGB1wbxVl9SqE44C2LCwcFOuGFPOqrIshT7j8+Em
8/pc7vh7C8Y5tQQzXq64Xg5mzKjAag3sYMHF2TnqvRuPHH0WOLHoyDcBqkuZ3+QP
EL5h7prPzScFRgBg2Gp0CDI8i5ABagczDGyQ2+r7ahcadrtzFCfhpH7V3TCxXfIO
qtSy1Uz2T5EqB/Q3wc9IGcX+fpKWqN9QajGSo7EU/kHMSWKYTerFugUtScMicu9B
CQ==
-----END CERTIFICATE-----
jas at mocca:~$ certtool -i < nul-cn.pem 
...
	Subject: CN=#13187777772e62616e6b2e636f6d002e6261646775792e636f6d
...

Notice how the Subject line is LDAP escaped when it contains a NUL
value.

Buggy versions would display the cert like this:

	Subject: CN=www.bank.com

To test whether NUL in CN is handled properly, here is how you do it:

jas at mocca:~$ cat>nul-san.pem
-----BEGIN CERTIFICATE-----
MIIDrTCCApWgAwIBAgIBADANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJHQjES
MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N
eSBDb21wYW55IEx0ZDELMAkGA1UECxMCQ0ExGTAXBgNVBAMTEE5VTEwtZnJpZW5k
bHkgQ0EwHhcNMDkwODA0MDY1MzA1WhcNMTkwODAyMDY1MzA1WjAZMRcwFQYDVQQD
Ew53d3cuYmFkZ3V5LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AM0mcJappl0+nO0PCBVafBclaGivE7mtQfoSVOKEcn1Y0eJAQsFZ7QU9qhBTcACI
OnegwFaerH0hKnFEUQi8FwfaqKN23FG8G4r2AhpVv0a0RGsnXr7lF4tWssaCNhGD
qL/3Lw0X9s1HtW8rpkG2jTNf6uqLsRrimTj/WVsKoXETyjc/ubAekZrIkzUMSuCd
9NJhx05bQQp8MVSZ2/VlzoDTwgI3ZP1UEnvqrIVZXBfhLvbQqPLQLpRZL8KmX9oH
3nsuFAft5CckN50JLrH5Wki5gCRD5svHbjXf1Wk0/+bWnuh2Zm5fWQE8ljvscgs8
HpUPzmgTnCLdG7VEKFBKBX8CAwEAAaOBpDCBoTAJBgNVHRMEAjAAMCwGCWCGSAGG
+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU
MxUkvtpmOgaL2Sc0Oq9iQOSVZl0wHwYDVR0jBBgwFoAUCmk5X50wBBgILgIO5uqd
sib24mowJgYDVR0RBB8wHYIbd3d3LmJhbmsuY29tAHd3dy5iYWRndXkuY29tMA0G
CSqGSIb3DQEBBQUAA4IBAQAnbn2zqYZSV2qgxjBsHpQJp2+t/hGfvjKNAXuLlGbX
fLaxkPzk9bYyvGxxI7EYiNZHvNoHx15GcTrmQG7Bfx1WlnBl2FGp3J6lBgCY5x4Q
vIK6AOVOog8+7Irdb8bJweztbXwxPmaHR6GLFTwhfuwheD0hcHK6cMNk+B1P2dAn
PD5+olmuvprTAESncjrjP8ibxY+xlP4AD264FIjxA1CRUa/wHve4WqRXNS3xrciu
3SlhFH3q0TSAXBv960PcIW3GRPk7VHbEkVuspI5y59gk/6dawO8nw9fk+X9VjQ0w
7KLZbch29L6UPRIySpFP28PndgdaEpcYtxUAmFkhiT41
-----END CERTIFICATE-----
jas at mocca:~$ certtool -i < nul-san.pem 
...
		Subject Alternative Name (not critical):
warning: SAN contains an embedded NUL, replacing with '!'
			DNSname: www.bank.com!www.badguy.com
...

Notice the warning and the full output.

Buggy versions would display the cert like this:

		Subject Alternative Name (not critical):
			DNSname: www.bank.com

I hope this helps you test your system!

/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/20090814/eb35e38e/attachment.pgp>

From tgc at jupiterrise.com  Fri Aug 14 16:03:34 2009
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Fri, 14 Aug 2009 16:03:34 +0200
Subject: Buildreport for GnuTLS 2.8.3
Message-ID: <20090814140334.GA30319@ares.tgcnet>

I grabbed GnuTLS 2.8.3 and tried building it on IRIX 5.3 and 6.2.

It builds and passes the testsuite on IRIX 6.2.
However I'm still seeing these during the build:
In file included from ../gnutls_int.h:29,
                 from opencdk.h:30,
                 from main.c:36:
../config.h:367:1: warning: "SIZE_MAX" redefined
In file included from ./../gl/stdlib.h:52,
                 from ./../gl/unistd.h:40,
                 from main.c:30:
./../gl/stdint.h:473:1: warning: this is the location of the previous definition

Bruno committed a fix for this to size_max.m4 when it was brought up on
bug-gnulib a few months ago but the copies included in gnutls are
too old and don't have the fix.

It fails to build on IRIX 5.3 due to missing siginterrupt function:
ld: ERROR 33: Unresolved text symbol "siginterrupt" -- 1st referenced by
tests.o.

Since gnulib does not provide a siginterrupt replacement I instead added
the replacement used by bash 4.0 to tests.c:
static int
siginterrupt (sig, flag)
     int sig, flag;
{
  struct sigaction act;

  sigaction (sig, (struct sigaction *)NULL, &act);

  if (flag)
    act.sa_flags &= ~SA_RESTART;
  else
    act.sa_flags |= SA_RESTART;

  return (sigaction (sig, &act, (struct sigaction *)NULL));
}

With that added the build completes and passes the testsuite.

-tgc




From simon at yubico.com  Fri Aug 14 16:03:18 2009
From: simon at yubico.com (Simon Josefsson)
Date: Fri, 14 Aug 2009 16:03:18 +0200
Subject: GnuTLS 2.9.2
Message-ID: <87vdkqxzkp.fsf@mocca.josefsson.org>

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

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

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

Windows build:
  http://josefsson.org/gnutls4win/gnutls-2.9.2.exe
  http://josefsson.org/gnutls4win/gnutls-2.9.2.exe.sig
  http://josefsson.org/gnutls4win/gnutls-2.9.2.zip
  http://josefsson.org/gnutls4win/gnutls-2.9.2.zip.sig
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.2-1_all.deb

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

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

/Simon

* Version 2.9.2 (released 2009-08-14)

** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
into 1) not printing the entire CN/SAN field value when printing a
certificate and 2) cause incorrect positive matches when matching a
hostname against a certificate.  Some CAs apparently have poor
checking of CN/SAN values and issue these (arguable invalid)
certificates.  Combined, this can be used by attackers to become a
MITM on server-authenticated TLS sessions.  The problem is mitigated
since attackers needs to get one certificate per site they want to
attack, and the attacker reveals his tracks by applying for a
certificate at the CA.  It does not apply to client authenticated TLS
sessions.  Research presented independently by Dan Kaminsky and Moxie
Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
for providing one part of the patch.  [GNUTLS-SA-2009-4] [CVE-2009-2730].

** libgnutls: Fix rare failure in gnutls_x509_crt_import.
The function may fail incorrectly when an earlier certificate was
imported to the same gnutls_x509_crt_t structure.

** minitasn1: Internal copy updated to libtasn1 v2.3.

** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
Before it always returned false.  Reported by Peter Hendrickson
<pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.

** libgnutls: Fix off-by-one size computation error in unknown DN printing.
The error resulted in truncated strings when printing unknown OIDs in
X.509 certificate DNs.  Reported by Tim Kosse
<tim.kosse at filezilla-project.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.

** libgnutls: Fix PKCS#12 decryption from password.
The encryption key derived from the password was incorrect for (on
average) 1 in every 128 input for random inputs.  Reported by "Kukosa,
Tomas" <tomas.kukosa at siemens-enterprise.com> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1663>.

** libgnutls: Return correct bit lengths of some MPIs.
gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
gnutls_dh_get_peers_public_bits.  Before the reported value was
overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.

** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
and
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.

** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
Before we required that the runtime library used the same (or more
recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
that the runtime usage is above the minimum required.  Reported by
Marco d'Itri <md at linux.it> via Andreas Metzler
<ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.

** tests: Added new self-test pkcs12_s2k_pem to detect MPI bit length error.

** tests: Improved test vectors in self-test pkcs12_s2k.

** tests: Added new self-test dn2 to detect off-by-one size error.

** tests: Fix failure in "chainverify" because a certificate have expired.

** API and ABI modifications:
No changes since last version.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090814/1be402a8/attachment.pgp>

From jamie at canonical.com  Fri Aug 14 23:35:38 2009
From: jamie at canonical.com (Jamie Strandboge)
Date: Fri, 14 Aug 2009 16:35:38 -0500
Subject: GnuTLS CVE-2009-2730 Patches (Was Re: GnuTLS 2.8.2)
In-Reply-To: <87skfupv8o.fsf@mocca.josefsson.org>
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon>
	<1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
Message-ID: <20090814213538.GA3469@severus.strandboge.com>

On Fri, 14 Aug 2009, Simon Josefsson wrote:

> I don't have time/resources to produce releases for older branches.  If
> someone else wants to volunteer to work on fixing older releases, that
> would be appreciated.
> 

Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported
from the advisory[1]. This is a first pass, have only been very lightly
tested and have not been thoroughly looked at (you've been warned). They
are not intended for production use yet, but hopefully others will be
able to use them and provide feedback.

2.0.4 and 1.2.9 needed an additional patch[2] which adds wide wildcard
hostname matching. Ubuntu will likely carry this patch, but it may not
be appropriate for everyone. 2.x passes the nul-in-x509-names.c test
mentioned in the advisory. 1.2.9 does not pass the CN test yet, though
at first glance certtool output looks comparable to the others. These
patches are against Ubuntu sources and not clean tarballs.

Jamie

[1] http://lists.gnu.org/archive/html/help-gnutls/2009-08/msg00011.html
[2] http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=177e7ddb761999cd8b439e14a2bf43590756e230

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVE-2009-2730_2.4.1.patch
Type: text/x-diff
Size: 8098 bytes
Desc: not available
URL: </pipermail/attachments/20090814/228828a7/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVE-2009-2730_2.0.4.patch
Type: text/x-diff
Size: 19482 bytes
Desc: not available
URL: </pipermail/attachments/20090814/228828a7/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVE-2009-2730_1.2.9.patch
Type: text/x-diff
Size: 7273 bytes
Desc: not available
URL: </pipermail/attachments/20090814/228828a7/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090814/228828a7/attachment.pgp>

From simon at josefsson.org  Sat Aug 15 10:14:48 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 15 Aug 2009 10:14:48 +0200
Subject: GnuTLS CVE-2009-2730 Patches
In-Reply-To: <20090814213538.GA3469@severus.strandboge.com> (Jamie
	Strandboge's message of "Fri, 14 Aug 2009 16:35:38 -0500")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
	<20090814213538.GA3469@severus.strandboge.com>
Message-ID: <87ws55mr2f.fsf@mocca.josefsson.org>

Jamie Strandboge <jamie-Z7WLFzj8eWMS+FvcfC7Uqw at public.gmane.org> writes:

> On Fri, 14 Aug 2009, Simon Josefsson wrote:
>
>> I don't have time/resources to produce releases for older branches.  If
>> someone else wants to volunteer to work on fixing older releases, that
>> would be appreciated.
>> 
>
> Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported
> from the advisory[1].

Thank you!

I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be
built and tested by the daily autobuilder from now on.  I've tested that
the nul-in-x509-names self-test works as expected with the 2.4 library.
So in theory, it should be easy for me to make a v2.4.4 release from
that branch.  I wonder if this would helps anyone, though?  I'd imagine
that most people concerned with older releases are distributions that
have to support older GnuTLS releases.  And you aren't likely to use a
new upstream release anyway, since you just apply the patches to your
version.

I'm also concerned that there have been plenty of _other_ serious
problems in these old GnuTLS releases (check the security vulnerability
page), and I haven't back-ported the fixes to those problems to these
old branches.  So if I make a release on that branch, I'd have to check
what other serious problems would needs to be fixed for that branch to
be secure -- which sounds like real work (for little gain).

For these two reasons, I'd prefer to help you establish trust in the
patches you developed rather than make releases on old branches.

I also added a link to your post on
<http://www.gnu.org/software/gnutls/security.html> so others can find it
easily.

/Simon




From simon at josefsson.org  Mon Aug 17 15:58:44 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Aug 2009 15:58:44 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <20090814140334.GA30319@ares.tgcnet> (Tom G. Christensen's
	message of "Fri, 14 Aug 2009 16:03:34 +0200")
References: <20090814140334.GA30319@ares.tgcnet>
Message-ID: <87k512k0dn.fsf@mocca.josefsson.org>

"Tom G. Christensen" <tgc at jupiterrise.com> writes:

> I grabbed GnuTLS 2.8.3 and tried building it on IRIX 5.3 and 6.2.
>
> It builds and passes the testsuite on IRIX 6.2.
> However I'm still seeing these during the build:
> In file included from ../gnutls_int.h:29,
>                  from opencdk.h:30,
>                  from main.c:36:
> ../config.h:367:1: warning: "SIZE_MAX" redefined
> In file included from ./../gl/stdlib.h:52,
>                  from ./../gl/unistd.h:40,
>                  from main.c:30:
> ./../gl/stdint.h:473:1: warning: this is the location of the previous definition
>
> Bruno committed a fix for this to size_max.m4 when it was brought up on
> bug-gnulib a few months ago but the copies included in gnutls are
> too old and don't have the fix.

I pushed the updated size_max.m4 file from gnulib into the gnutls_2_8_x
branch.  Please test tomorrow's daily snapshot to make sure it fixes
your problem.  I assume it is fixed in 2.9.x already.

Thanks,
/Simon




From vivek at collabora.co.uk  Mon Aug 17 17:55:17 2009
From: vivek at collabora.co.uk (Vivek Dasmohapatra)
Date: Mon, 17 Aug 2009 16:55:17 +0100 (BST)
Subject: gnutls_handshake fails after EAGAIN 
Message-ID: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>

Hi, I've noticed a problem with gnutls_handshake when called with
a non-blocking push/pull function pair: It looks to me like a bug in
_gnutls_send_finished : full description and a proposed patch here:

http://savannah.gnu.org/support/?106979

[ I didn't see this problem in the bug tracker, and the code in 2.8.x
   is the same as the code in 2.6.x, so I assume it's still iffy in
   the 2.8.x version ]

Any chance this patch [assuming it's the right way to fix things] could
be adopted?

Apologies if this is a known issue and a fix is already on the way -
In either case, what would the approximate timeline or the expected
version number of a fixed library be?

-- 
Vivek




From tim.kosse at filezilla-project.org  Mon Aug 17 18:52:32 2009
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Mon, 17 Aug 2009 18:52:32 +0200
Subject: gnutls_handshake fails after EAGAIN
In-Reply-To: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>
References: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>
Message-ID: <4A898AD0.4040001@filezilla-project.org>

Hi,

Vivek Dasmohapatra wrote:
> Hi, I've noticed a problem with gnutls_handshake when called with
> a non-blocking push/pull function pair: [...]
> http://savannah.gnu.org/support/?106979

this has actually been fixed in 2.8.2 already, I've stumbled upon the
same problem recently. Both your patch as well as mine fix the problem,
they change functionality the same way.

References:
http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670 and
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=28fb34099edaf62e5472cc6e5e2749fed369ea01

Regards,
Tim


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

From vivek at collabora.co.uk  Mon Aug 17 19:38:05 2009
From: vivek at collabora.co.uk (Vivek Dasmohapatra)
Date: Mon, 17 Aug 2009 18:38:05 +0100 (BST)
Subject: gnutls_handshake fails after EAGAIN
In-Reply-To: <4A898AD0.4040001@filezilla-project.org>
References: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>
	<4A898AD0.4040001@filezilla-project.org>
Message-ID: <alpine.DEB.2.00.0908171837190.4526@noise.cbg.collabora.co.uk>

Ah, I see, yes, the calling function has been changed rather than the 
called function - did not spot that. Thanks.





From jamie at canonical.com  Tue Aug 18 01:29:45 2009
From: jamie at canonical.com (Jamie Strandboge)
Date: Mon, 17 Aug 2009 18:29:45 -0500
Subject: GnuTLS CVE-2009-2730 Patches (Was Re: GnuTLS 2.8.2)
In-Reply-To: <20090814213538.GA3469@severus.strandboge.com>
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon>
	<1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
	<20090814213538.GA3469@severus.strandboge.com>
Message-ID: <20090817232945.GC6531@severus.strandboge.com>

On Fri, 14 Aug 2009, Jamie Strandboge wrote:

> 1.2.9 does not pass the CN test yet, though
> at first glance certtool output looks comparable to the others.

1.2.9 also needed:
http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=7b80620f99f4d43f5eda692eefc5c969bb4263c0

Attached is an updated patch for 1.2.9 (still only lightly tested, but
verified to pass the test program). This and the 2.0.4 patch previously
posted now behave the same, but different from 2.4 and higher.
Specifically, when using:

$ certtool -i --infile /tmp/badguy-nul-cn.crt

We have:
|<1>| Found OID: '2.5.4.3' with value '13187777772e62616e6b2e636f6d002e6261646775792e636f6d'
X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 01
	Issuer: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd,OU=CA,CN=NULL-friendly CA
	Validity:
		Not Before: Tue Aug  4 07:33:43 UTC 2009
		Not After: Fri Aug  2 07:33:43 UTC 2019
error: get_dn: ASN1 parser: Error in DER parsing.
...


This is in contrast to 2.4 and higher which has:
X.509 Certificate Information:
	Version: 3
	Serial Number (hex): 01
	Issuer: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd,OU=CA,CN=NULL-friendly CA
	Validity:
		Not Before: Tue Aug 04 07:33:43 UTC 2009
		Not After: Fri Aug 02 07:33:43 UTC 2019
	Subject: CN=#13187777772e62616e6b2e636f6d002e6261646775792e636f6
...


Jamie

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVE-2009-2730_1.2.9.patch
Type: text/x-diff
Size: 7580 bytes
Desc: not available
URL: </pipermail/attachments/20090817/bc5b3ed4/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090817/bc5b3ed4/attachment.pgp>

From jamie at canonical.com  Tue Aug 18 01:33:53 2009
From: jamie at canonical.com (Jamie Strandboge)
Date: Mon, 17 Aug 2009 18:33:53 -0500
Subject: GnuTLS CVE-2009-2730 Patches
In-Reply-To: <87ws55mr2f.fsf@mocca.josefsson.org>
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon>
	<1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
	<20090814213538.GA3469@severus.strandboge.com>
	<87ws55mr2f.fsf@mocca.josefsson.org>
Message-ID: <20090817233353.GD6531@severus.strandboge.com>

On Sat, 15 Aug 2009, Simon Josefsson wrote:

> Jamie Strandboge <jamie-Z7WLFzj8eWMS+FvcfC7Uqw at public.gmane.org> writes:
> 
> > On Fri, 14 Aug 2009, Simon Josefsson wrote:
> >
> > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported
> > from the advisory[1].
> 
> Thank you!
> 
> I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be
> built and tested by the daily autobuilder from now on.  I've tested that
> the nul-in-x509-names self-test works as expected with the 2.4 library.
> So in theory, it should be easy for me to make a v2.4.4 release from
> that branch.  I wonder if this would helps anyone, though?  I'd imagine
> that most people concerned with older releases are distributions that
> have to support older GnuTLS releases.  And you aren't likely to use a
> new upstream release anyway, since you just apply the patches to your
> version.
> 
> I'm also concerned that there have been plenty of _other_ serious
> problems in these old GnuTLS releases (check the security vulnerability
> page), and I haven't back-ported the fixes to those problems to these
> old branches.  So if I make a release on that branch, I'd have to check
> what other serious problems would needs to be fixed for that branch to
> be secure -- which sounds like real work (for little gain).
> 
> For these two reasons, I'd prefer to help you establish trust in the
> patches you developed rather than make releases on old branches.
> 

I'd agree with this. Vendors have likely backported all those other
fixes. However, having a place for people to get patches for older
releases would likely be beneficial going forward (like you are doing
with this one). This is especially true when considering your
aforementioned lack of resources.

> I also added a link to your post on
> <http://www.gnu.org/software/gnutls/security.html> so others can find it
> easily.
> 

Thanks!

Jamie

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: </pipermail/attachments/20090817/0b34694a/attachment.pgp>

From simon at josefsson.org  Tue Aug 18 14:52:48 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Aug 2009 14:52:48 +0200
Subject: gnutls_handshake fails after EAGAIN
In-Reply-To: <alpine.DEB.2.00.0908171837190.4526@noise.cbg.collabora.co.uk>
	(Vivek Dasmohapatra's message of "Mon, 17 Aug 2009 18:38:05 +0100
	(BST)")
References: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>
	<4A898AD0.4040001@filezilla-project.org>
	<alpine.DEB.2.00.0908171837190.4526@noise.cbg.collabora.co.uk>
Message-ID: <87fxbpffmn.fsf@mocca.josefsson.org>

Vivek Dasmohapatra <vivek at collabora.co.uk> writes:

> Ah, I see, yes, the calling function has been changed rather than the
> called function - did not spot that. Thanks.

Good to see it solved -- I closed the bug tracker for this.  Let me know
if you think your patch is better, or if some other code improvement
could be made here.

/Simon




From simon at josefsson.org  Tue Aug 18 15:58:03 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Aug 2009 15:58:03 +0200
Subject: GnuTLS CVE-2009-2730 Patches
In-Reply-To: <20090817233353.GD6531@severus.strandboge.com> (Jamie
	Strandboge's message of "Mon, 17 Aug 2009 18:33:53 -0500")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
	<20090814213538.GA3469@severus.strandboge.com>
	<87ws55mr2f.fsf@mocca.josefsson.org>
	<20090817233353.GD6531@severus.strandboge.com>
Message-ID: <87y6phdy1g.fsf@mocca.josefsson.org>

Jamie Strandboge <jamie at canonical.com> writes:

> On Sat, 15 Aug 2009, Simon Josefsson wrote:
>
>> Jamie Strandboge <jamie-Z7WLFzj8eWMS+FvcfC7Uqw at public.gmane.org> writes:
>> 
>> > On Fri, 14 Aug 2009, Simon Josefsson wrote:
>> >
>> > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported
>> > from the advisory[1].
>> 
>> Thank you!
>> 
>> I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be
>> built and tested by the daily autobuilder from now on.  I've tested that
>> the nul-in-x509-names self-test works as expected with the 2.4 library.
>> So in theory, it should be easy for me to make a v2.4.4 release from
>> that branch.  I wonder if this would helps anyone, though?  I'd imagine
>> that most people concerned with older releases are distributions that
>> have to support older GnuTLS releases.  And you aren't likely to use a
>> new upstream release anyway, since you just apply the patches to your
>> version.
>> 
>> I'm also concerned that there have been plenty of _other_ serious
>> problems in these old GnuTLS releases (check the security vulnerability
>> page), and I haven't back-ported the fixes to those problems to these
>> old branches.  So if I make a release on that branch, I'd have to check
>> what other serious problems would needs to be fixed for that branch to
>> be secure -- which sounds like real work (for little gain).
>> 
>> For these two reasons, I'd prefer to help you establish trust in the
>> patches you developed rather than make releases on old branches.
>> 
>
> I'd agree with this. Vendors have likely backported all those other
> fixes. However, having a place for people to get patches for older
> releases would likely be beneficial going forward (like you are doing
> with this one). This is especially true when considering your
> aforementioned lack of resources.

Right.  If you and others provide patches for older versions, I can
apply them on the git branches.  Someone could even volunteer to become
old-releases-maintainer and do it for me.  It would indeed be useful if
all vendors could look into the git repository to find the recommended
patch for any version, rather than everyone having to spend time on
identifying and testing patches by themselves.  Alas, I don't have
resources to do this, and I believe my time is best spent on maintaining
the stable and development branches.

/Simon




From tgc at jupiterrise.com  Tue Aug 18 21:26:23 2009
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Tue, 18 Aug 2009 21:26:23 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <87k512k0dn.fsf@mocca.josefsson.org>
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
Message-ID: <20090818192623.GA5635@ares.tgcnet>

On Mon, Aug 17, 2009 at 03:58:44PM +0200, Simon Josefsson wrote:
> I pushed the updated size_max.m4 file from gnulib into the gnutls_2_8_x
> branch.  Please test tomorrow's daily snapshot to make sure it fixes
> your problem.  I assume it is fixed in 2.9.x already.
> 
I built the daily snapshot but lib/m4/size_max.m4 is still downrev.

The log was submitted to autobuild.josefsson.org.

-tgc




From simon at josefsson.org  Tue Aug 18 23:45:47 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Aug 2009 23:45:47 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <87prb3i22u.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 11 Aug 2009 03:14:33 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
	<363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>
	<87prb3i22u.fsf@mocca.josefsson.org>
Message-ID: <878whgdcdw.fsf@mocca.josefsson.org>

Ueno-san,

Your FSF papers have arrived so we should push your patch into the
official repository.  Do you have an updated patch, or should I use the
last one you posted?  Having more self-tests would be nice, but not
essential.

/Simon




From simon at josefsson.org  Wed Aug 19 00:11:38 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Aug 2009 00:11:38 +0200
Subject: [PATCH][PULL] Add explicit feature checks
In-Reply-To: <871vntrqa1.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 03 Aug 2009 15:16:38 +0200")
References: <4A7470B8.1090909@x2a.org> <871vntrqa1.fsf@mocca.josefsson.org>
Message-ID: <87r5v8bwmd.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
>
>> As promised, I have added functions for explicit feature checks.
>
> Thank you.  I'll apply as soon as the FSF copyright papers have arrived.
> I'll review them when my 'git clone' finishes downloading your
> repository...

Hi!  Your papers have arrived, so we should be able to push your patch
now.  Could you send a patch against master?

Thanks,
/Simon




From joe at x2a.org  Wed Aug 19 04:55:30 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Tue, 18 Aug 2009 22:55:30 -0400
Subject: [PATCH] Replace explicit version checks with feature checks
Message-ID: <4A8B69A2.9010905@x2a.org>

The following changes since commit 47cd212fda611873b72bf70df48b7de3563a3276:
  Jonathan Bastien-Filiatrault (1):
        Remove hardcoded version checks in auth_cert.c.

are available in the git repository at:

  git://x2a.org/gnutls.git version-checks

Alternatively, you may find the patch attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: version-checks.patch
Type: text/x-diff
Size: 9811 bytes
Desc: not available
URL: </pipermail/attachments/20090818/e9e86820/attachment.patch>

From ueno at unixuser.org  Wed Aug 19 09:53:07 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Wed, 19 Aug 2009 16:53:07 +0900
Subject: [PATCH] session ticket support
In-Reply-To: <878whgdcdw.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 18 Aug 2009 23:45:47 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
	<363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>
	<87prb3i22u.fsf@mocca.josefsson.org>
	<878whgdcdw.fsf@mocca.josefsson.org>
Message-ID: <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org>

(Sorry, please ignore the previous incomplete message I've sent by
mistake.)

>>>>> In <878whgdcdw.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> Your FSF papers have arrived so we should push your patch into the
> official repository.  Do you have an updated patch, or should I use the
> last one you posted?  Having more self-tests would be nice, but not
> essential.

Yes, please use the attached one.  The following changes from the
previous patch have been applied:

* Support rehandshake when _gnutls_send_new_session_ticket() is
interrupted.

* Remove a bunch of compiler warnings when configured with
--enable-gcc-warnings.

* Add one of the self-tests as you suggested:

> * What happens if the client has a session ticket but the server has
>   disabled session ticket support?

However, the other one has not yet not implemented since I couldn't find
an easy way to send arbitrary extension data from applications:

> * What happens if the client provides a garbage session ticket?
>
>   - Does the RFC specify what should happen?  I'd assume that the
>     handshake continues as normal, but I'm not sure.

It will be detected during MAC verification and reported as "decryption
failed", and then the full-handshake should take place.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: session-ticket-2009-08-19.diff.gz
Type: application/octet-stream
Size: 10748 bytes
Desc: not available
URL: </pipermail/attachments/20090819/25fdebed/attachment.obj>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From ueno at unixuser.org  Wed Aug 19 09:34:47 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Wed, 19 Aug 2009 16:34:47 +0900
Subject: [PATCH] session ticket support
In-Reply-To: <878whgdcdw.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 18 Aug 2009 23:45:47 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
	<363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>
	<87prb3i22u.fsf@mocca.josefsson.org>
	<878whgdcdw.fsf@mocca.josefsson.org>
Message-ID: <e0151797-e7f0-4b66-b4cb-90576162a9ec@broken.deisui.org>

>>>>> In <878whgdcdw.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> Your FSF papers have arrived so we should push your patch into the
> official repository.  Do you have an updated patch, or should I use the
> last one you posted?  Having more self-tests would be nice, but not
> essential.

Yes, please use the attached one.  The following changes from the
previous patch have been applied:

* Support rehandshake when _gnutls_send_new_session_ticket() is
interrupted.

* Remove a bunch of compiler warnings when configured with
--enable-gcc-warnings.

* Add more self-tests for 



-- 
Daiki Ueno




From ueno at unixuser.org  Wed Aug 19 13:09:23 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Wed, 19 Aug 2009 20:09:23 +0900
Subject: [PATCH] internals doc update
Message-ID: <6622c38a-26f5-4fe0-aaff-111352f98f8f@broken.deisui.org>

Hi,

When I wrote SessionTicket extension I referred to the manual node
"Adding a New TLS Extension", and noticed that it is not up to date.
So, here is a patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: internals-doc.diff
Type: text/x-diff
Size: 1462 bytes
Desc: not available
URL: </pipermail/attachments/20090819/a624a938/attachment.diff>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From simon at josefsson.org  Wed Aug 19 14:35:27 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Aug 2009 14:35:27 +0200
Subject: [PATCH] internals doc update
In-Reply-To: <6622c38a-26f5-4fe0-aaff-111352f98f8f@broken.deisui.org> (Daiki
	Ueno's message of "Wed, 19 Aug 2009 20:09:23 +0900")
References: <6622c38a-26f5-4fe0-aaff-111352f98f8f@broken.deisui.org>
Message-ID: <87tz047zhs.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> Hi,
>
> When I wrote SessionTicket extension I referred to the manual node
> "Adding a New TLS Extension", and noticed that it is not up to date.
> So, here is a patch.

Hi.  Thank you, pushed.

/Simon




From simon at josefsson.org  Wed Aug 19 15:13:55 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Aug 2009 15:13:55 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> (Daiki
	Ueno's message of "Wed, 19 Aug 2009 16:53:07 +0900")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
	<363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>
	<87prb3i22u.fsf@mocca.josefsson.org>
	<878whgdcdw.fsf@mocca.josefsson.org>
	<6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org>
Message-ID: <87pras7xpo.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> Yes, please use the attached one.

Thank you!  I fixed a few minor issues and pushed it.

/Simon




From simon at josefsson.org  Wed Aug 19 16:04:48 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Aug 2009 16:04:48 +0200
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <4A8B69A2.9010905@x2a.org> (Jonathan Bastien-Filiatrault's
	message of "Tue, 18 Aug 2009 22:55:30 -0400")
References: <4A8B69A2.9010905@x2a.org>
Message-ID: <8763cj99xb.fsf@mocca.josefsson.org>

Hi Jonathan.  Thank you, I have pushed the patch.

/Simon




From joe at x2a.org  Wed Aug 19 17:35:36 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Wed, 19 Aug 2009 11:35:36 -0400
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <8763cj99xb.fsf@mocca.josefsson.org>
References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org>
Message-ID: <4A8C1BC8.6070901@x2a.org>

Simon Josefsson wrote:
> Hi Jonathan.  Thank you, I have pushed the patch.
> 
> /Simon

Yay ! Thanks !

Could you please have a look at my buffers-redux branch. So far it seems 
to suit Nikos. I have taken care of most of the send path, discarding 
old code with much shorter and simpler new code (and adding a bunch of 
generic code).

The read path is next and I would like to finalize the write side as 
much as possible. Also, I would like to remove the need to peek data 
from sockets. This complicates the read side by an order of magnitude. 
Is this because there is no other way to notify the application to do 
another read (via select) ?

http://x2a.org/git/gnutls/log/?h=buffers-redux
git://x2a.org/gnutls.git buffers-redux

Thanks !




From vivek at collabora.co.uk  Wed Aug 19 18:12:50 2009
From: vivek at collabora.co.uk (Vivek Dasmohapatra)
Date: Wed, 19 Aug 2009 17:12:50 +0100 (BST)
Subject: gnutls_handshake fails after EAGAIN
In-Reply-To: <87fxbpffmn.fsf@mocca.josefsson.org>
References: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>
	<4A898AD0.4040001@filezilla-project.org>
	<alpine.DEB.2.00.0908171837190.4526@noise.cbg.collabora.co.uk>
	<87fxbpffmn.fsf@mocca.josefsson.org>
Message-ID: <alpine.DEB.2.00.0908191708220.4526@noise.cbg.collabora.co.uk>

On Tue, 18 Aug 2009, Simon Josefsson wrote:

> Good to see it solved -- I closed the bug tracker for this.  Let me know
> if you think your patch is better, or if some other code improvement
> could be made here.

I don't think there's much to choose between them: it's a static function
called only from one place, so it doesn't matter much whether the change
is made in the caller or the callee.

Probably worth checking that other functions with a similar calling 
convention (once with data, then with NULL for each EAGAIN) are also 
handled suitably, since it's an easy mistake to make, and won't be picked
up if the tests use blocking push-pull functions.





From tim.kosse at filezilla-project.org  Wed Aug 19 18:40:28 2009
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Wed, 19 Aug 2009 18:40:28 +0200
Subject: gnutls_handshake fails after EAGAIN
In-Reply-To: <alpine.DEB.2.00.0908191708220.4526@noise.cbg.collabora.co.uk>
References: <alpine.DEB.2.00.0908171647250.4526@noise.cbg.collabora.co.uk>
	<4A898AD0.4040001@filezilla-project.org>
	<alpine.DEB.2.00.0908171837190.4526@noise.cbg.collabora.co.uk>
	<87fxbpffmn.fsf@mocca.josefsson.org>
	<alpine.DEB.2.00.0908191708220.4526@noise.cbg.collabora.co.uk>
Message-ID: <4A8C2AFC.9020009@filezilla-project.org>

Hi,

Vivek Dasmohapatra wrote:
> Probably worth checking that other functions with a similar calling
> convention (once with data, then with NULL for each EAGAIN) are also
> handled suitably, since it's an easy mistake to make, and won't be picked
> up if the tests use blocking push-pull functions.

actually there has been another bug in 2.8.0 and 2.8.1 which was also
triggered when the push function returned EAGAIN:

http://lists.gnu.org/archive/html/gnutls-devel/2009-06/msg00022.html
http://lists.gnu.org/archive/html/gnutls-devel/2009-07/msg00000.html

The fix is in
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=c7e003ad9427c655a1b559baff1239a2c1907f32

The GnuTLS developers also added a test case that should hopefully
detect future problems like this, see tests/mini-eagain.c

Regards,
Tim


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

From simon at josefsson.org  Wed Aug 19 22:49:36 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Aug 2009 22:49:36 +0200
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <4A8C1BC8.6070901@x2a.org> (Jonathan Bastien-Filiatrault's
	message of "Wed, 19 Aug 2009 11:35:36 -0400")
References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org>
	<4A8C1BC8.6070901@x2a.org>
Message-ID: <87fxbn5y1r.fsf@mocca.josefsson.org>

Jonathan Bastien-Filiatrault <joe at x2a.org> writes:

> Simon Josefsson wrote:
>> Hi Jonathan.  Thank you, I have pushed the patch.
>>
>> /Simon
>
> Yay ! Thanks !
>
> Could you please have a look at my buffers-redux branch. So far it
> seems to suit Nikos. I have taken care of most of the send path,
> discarding old code with much shorter and simpler new code (and adding
> a bunch of generic code).
>
> The read path is next and I would like to finalize the write side as
> much as possible. Also, I would like to remove the need to peek data
> from sockets. This complicates the read side by an order of
> magnitude. Is this because there is no other way to notify the
> application to do another read (via select) ?
>
> http://x2a.org/git/gnutls/log/?h=buffers-redux
> git://x2a.org/gnutls.git buffers-redux

How do I create a patch between your branch and master, to review it?  I
haven't worked with multiple repositories, but willing to learn.

/Simon




From simon at josefsson.org  Wed Aug 19 23:30:40 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Aug 2009 23:30:40 +0200
Subject: GnuTLS 2.9.3
Message-ID: <87tz034hkv.fsf@mocca.josefsson.org>

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

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

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

Windows build:
  http://josefsson.org/gnutls4win/gnutls-2.9.3.exe
  http://josefsson.org/gnutls4win/gnutls-2.9.3.exe.sig
  http://josefsson.org/gnutls4win/gnutls-2.9.3.zip
  http://josefsson.org/gnutls4win/gnutls-2.9.3.zip.sig
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.3-1_all.deb

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

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

/Simon

* Version 2.9.3 (released 2009-08-19)

** libgnutls: Support for TLS tickets was contributed by Daiki Ueno.
The new APIs are gnutls_session_ticket_enable_client,
gnutls_session_ticket_enable_server, and
gnutls_session_ticket_key_generate.

** gnutls-cli, gnutls-serv: New parameter --noticket to disable TLS tickets.

** API and ABI modifications:
gnutls_session_ticket_key_generate: ADDED.
gnutls_session_ticket_enable_client: ADDED.
gnutls_session_ticket_enable_server: ADDED.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090819/5b10efda/attachment.pgp>

From simon at josefsson.org  Thu Aug 20 00:07:54 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Aug 2009 00:07:54 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <20090818192623.GA5635@ares.tgcnet> (Tom G. Christensen's message
	of "Tue, 18 Aug 2009 21:26:23 +0200")
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
Message-ID: <87my5v4fut.fsf@mocca.josefsson.org>

"Tom G. Christensen" <tgc at jupiterrise.com> writes:

> On Mon, Aug 17, 2009 at 03:58:44PM +0200, Simon Josefsson wrote:
>> I pushed the updated size_max.m4 file from gnulib into the gnutls_2_8_x
>> branch.  Please test tomorrow's daily snapshot to make sure it fixes
>> your problem.  I assume it is fixed in 2.9.x already.
>> 
> I built the daily snapshot but lib/m4/size_max.m4 is still downrev.
>
> The log was submitted to autobuild.josefsson.org.

Could you check if the size_max.m4 files in your build have 'serial 9'
in the first line?  Maybe you tested before the packages was updated.
You could test the 2.9.3 release now.

It seems that either Bruno's solution didn't work, or something else
needs to be back-ported as well, but I'm not sure what.

/Simon




From ueno at unixuser.org  Thu Aug 20 03:33:00 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Thu, 20 Aug 2009 10:33:00 +0900
Subject: GnuTLS 2.9.3
In-Reply-To: <87tz034hkv.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 19 Aug 2009 23:30:40 +0200")
References: <87tz034hkv.fsf@mocca.josefsson.org>
Message-ID: <edd1458f-9bfd-4282-9aa6-22d15d61aabe@broken.deisui.org>

>>>>> In <87tz034hkv.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> * Version 2.9.3 (released 2009-08-19)

> ** libgnutls: Support for TLS tickets was contributed by Daiki Ueno.

Thanks for the new release!

Now I run make check and found several memleaks.  One is in
cdk_keydb_get_pk, and others are in tests (including session ticket
test...sorry).

Here is a patch to fix them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests-memleak.diff
Type: text/x-diff
Size: 2126 bytes
Desc: not available
URL: </pipermail/attachments/20090820/dd2ea92b/attachment.diff>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From simon at josefsson.org  Thu Aug 20 10:05:26 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Aug 2009 10:05:26 +0200
Subject: GnuTLS 2.9.3
In-Reply-To: <edd1458f-9bfd-4282-9aa6-22d15d61aabe@broken.deisui.org> (Daiki
	Ueno's message of "Thu, 20 Aug 2009 10:33:00 +0900")
References: <87tz034hkv.fsf@mocca.josefsson.org>
	<edd1458f-9bfd-4282-9aa6-22d15d61aabe@broken.deisui.org>
Message-ID: <87ws4y3o6x.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87tz034hkv.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> * Version 2.9.3 (released 2009-08-19)
>
>> ** libgnutls: Support for TLS tickets was contributed by Daiki Ueno.
>
> Thanks for the new release!
>
> Now I run make check and found several memleaks.  One is in
> cdk_keydb_get_pk, and others are in tests (including session ticket
> test...sorry).
>
> Here is a patch to fix them.

Applied, thank you.

/Simon




From simon at josefsson.org  Thu Aug 20 16:18:46 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Aug 2009 16:18:46 +0200
Subject: GnuTLS CVE-2009-2730 Patches
In-Reply-To: <20090820123918.GA6964@severus.strandboge.com> (Jamie
	Strandboge's message of "Thu, 20 Aug 2009 07:39:18 -0500")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
	<20090814213538.GA3469@severus.strandboge.com>
	<87ws55mr2f.fsf@mocca.josefsson.org>
	<20090817233353.GD6531@severus.strandboge.com>
	<87y6phdy1g.fsf@mocca.josefsson.org>
	<20090820123918.GA6964@severus.strandboge.com>
Message-ID: <87r5v6y3eh.fsf@mocca.josefsson.org>

Btw, I just notice a problem with RedHat's patch, it appears to break
OpenPGP connections:

gnutls-cli -p 5556 test.gnutls.org --priority NORMAL:+CTYPE-OPENPGP:-CTYPE-X509

I get an error:

- The hostname in the certificate does NOT match 'test.gnutls.org'

But this is incorrect, the names do match.

Please test if that command works on your versions, otherwise you will
need this patch too:

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=9eed44b4ef9538117cc134956b32bc8fd39534fd

I'll write a self-test to check this regression too.

/Simon




From simon at josefsson.org  Thu Aug 20 19:03:23 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Aug 2009 19:03:23 +0200
Subject: GnuTLS CVE-2009-2730 Patches
In-Reply-To: <87r5v6y3eh.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 20 Aug 2009 16:18:46 +0200")
References: <87k51bg4xb.fsf@mocca.josefsson.org>
	<1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon>
	<878whodnwa.fsf@mocca.josefsson.org>
	<1250237515.5919.1.camel@marathon>
	<87skfupv8o.fsf@mocca.josefsson.org>
	<20090814213538.GA3469@severus.strandboge.com>
	<87ws55mr2f.fsf@mocca.josefsson.org>
	<20090817233353.GD6531@severus.strandboge.com>
	<87y6phdy1g.fsf@mocca.josefsson.org>
	<20090820123918.GA6964@severus.strandboge.com>
	<87r5v6y3eh.fsf@mocca.josefsson.org>
Message-ID: <87r5v6v2n8.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Btw, I just notice a problem with RedHat's patch, it appears to break
> OpenPGP connections:
>
> gnutls-cli -p 5556 test.gnutls.org --priority NORMAL:+CTYPE-OPENPGP:-CTYPE-X509
>
> I get an error:
>
> - The hostname in the certificate does NOT match 'test.gnutls.org'
>
> But this is incorrect, the names do match.
>
> Please test if that command works on your versions, otherwise you will
> need this patch too:
>
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=9eed44b4ef9538117cc134956b32bc8fd39534fd
>
> I'll write a self-test to check this regression too.

Now finished, and here is another way to check if your library is OK or
not:

wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/hostname-check.c
wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/utils.c
wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/utils.h
gcc -o hostname-check hostname-check.c utils.c -I. -lgnutls
./hostname-check

It should finish with 0 errors.

Maybe we'll need a 2.8.4 to fix this...

/Simon




From joe at x2a.org  Fri Aug 21 02:19:08 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Thu, 20 Aug 2009 20:19:08 -0400
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <87fxbn5y1r.fsf@mocca.josefsson.org>
References: <4A8B69A2.9010905@x2a.org>
	<8763cj99xb.fsf@mocca.josefsson.org>	<4A8C1BC8.6070901@x2a.org>
	<87fxbn5y1r.fsf@mocca.josefsson.org>
Message-ID: <4A8DE7FC.5030405@x2a.org>

Simon Josefsson wrote:
> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
> 
>> Simon Josefsson wrote:
> How do I create a patch between your branch and master, to review it?  I
> haven't worked with multiple repositories, but willing to learn.
> 
> /Simon

Alright, here is what you need to do:

 - Use a somewhat-pristine git repository cloned from savannah or whatever.
 - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ;
this adds an entry in the .git/config file and fetches refs and objects
from my repository.
 - Create a local branch tracking my remote repository: git branch
--track buffers-redux jonathan/buffers-redux
 - Now you can git checkout buffers-redux to switch to that branch or do
a git diff master..buffers-redux . If you had not created a local branch
you could instead do git diff master..jonathan/buffers-redux

Hope this helps,
Jonathan




From simon at josefsson.org  Fri Aug 21 10:34:18 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 21 Aug 2009 10:34:18 +0200
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <4A8DE7FC.5030405@x2a.org> (Jonathan Bastien-Filiatrault's
	message of "Thu, 20 Aug 2009 20:19:08 -0400")
References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org>
	<4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org>
	<4A8DE7FC.5030405@x2a.org>
Message-ID: <8763chtvjp.fsf@mocca.josefsson.org>

Jonathan Bastien-Filiatrault <joe at x2a.org> writes:

> Simon Josefsson wrote:
>> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
>> 
>>> Simon Josefsson wrote:
>> How do I create a patch between your branch and master, to review it?  I
>> haven't worked with multiple repositories, but willing to learn.
>> 
>> /Simon
>
> Alright, here is what you need to do:
>
>  - Use a somewhat-pristine git repository cloned from savannah or whatever.
>  - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ;
> this adds an entry in the .git/config file and fetches refs and objects
> from my repository.
>  - Create a local branch tracking my remote repository: git branch
> --track buffers-redux jonathan/buffers-redux
>  - Now you can git checkout buffers-redux to switch to that branch or do
> a git diff master..buffers-redux . If you had not created a local branch
> you could instead do git diff master..jonathan/buffers-redux

Excellent, thank you!

Quick comments:

* Please add a comment describing what dump_bytes does, and preferrably
  make it use _gnutls_bin2hex for hex encoding.  Is there a fixed-size
  limit of 128 in the function?  If so, it would be nice to fix that.

* What does the 'bufel' variable name refers to?  It looks non-english
  to me, so I'd prefer using 'buf'.

* Some comments at the top of gnutls_mbuffers.? what it does would be
  good.

More later.

/Simon




From gareuselesinge at libero.it  Fri Aug 21 11:55:36 2009
From: gareuselesinge at libero.it (Enrico Tassi)
Date: Fri, 21 Aug 2009 11:55:36 +0200
Subject: Help with multithreading
Message-ID: <20090821095536.GA6248@birba>

I'm facing a problem that seems to be related to the multithreading
aspect of gnutls+curl, but digging the mailing list was not enough to
find an answer, so I'm posting hoping someone has some hints for me.

This is the way I initialize gcrypt/gnutls, and I'm doing it at the very 
beginning of the main() function:

        if (!gcry_control (GCRYCTL_ANY_INITIALIZATION_P)) {
                /* No other library has already initialized libgcrypt. */
                if (!gcry_check_version("1.2.2")) {
                        fprintf(stderr, "gcrypt version older than 1.2.2\n");
                        exit(1);
                }
                gcry_control(GCRYCTL_SET_THREAD_CBS,&gcry_threads_pthread);
                gcry_control (GCRYCTL_DISABLE_SECMEM, 0);
                gcry_control (GCRYCTL_INITIALIZATION_FINISHED);
        }

According to the mailing list, this should be correct. After that I call
the cURL initialization function (that is compiled against gnutls).

        curl_global_init(CURL_GLOBAL_ALL);

Here is the gdb backtrace, that seems to suggest there is something wrong with
threads (there were 2 threads, doing exactly the same, i.e. opening an SSL
connection). This is the backtrace of the thread that issued the assertion
failure:

  (gdb) core-file core 
  [New Thread 9930]
  [New Thread 9932]
  warning: Can't read pathname for load map: Input/output error.
  Reading symbols from /lib/libdl.so.2...done.
  Loaded symbols for /lib/libdl.so.2
  Reading symbols from /lib/libm.so.6...done.
  Loaded symbols for /lib/libm.so.6
  Reading symbols from /lib/libpthread.so.0...done.
  Loaded symbols for /lib/libpthread.so.0
  Reading symbols from /usr/lib/libcrypto.so.0.9.8...done.
  Loaded symbols for /usr/lib/libcrypto.so.0.9.8
  Reading symbols from /usr/lib/libcurl-gnutls.so.4...Reading symbols from /usr/lib/debug/usr/lib/libcurl-gnutls.so.4.1.1...done.
  done.
  Loaded symbols for /usr/lib/libcurl-gnutls.so.4
  Reading symbols from /usr/lib/libexpat.so.1...done.
  Loaded symbols for /usr/lib/libexpat.so.1
  Reading symbols from /lib/libc.so.6...done.
  Loaded symbols for /lib/libc.so.6
  Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
  Loaded symbols for /lib64/ld-linux-x86-64.so.2
  Reading symbols from /usr/lib/libz.so.1...done.
  Loaded symbols for /usr/lib/libz.so.1
  Reading symbols from /usr/lib/libidn.so.11...done.
  Loaded symbols for /usr/lib/libidn.so.11
  Reading symbols from /usr/lib/liblber-2.4.so.2...done.
  Loaded symbols for /usr/lib/liblber-2.4.so.2
  Reading symbols from /usr/lib/libldap_r-2.4.so.2...done.
  Loaded symbols for /usr/lib/libldap_r-2.4.so.2
  Reading symbols from /lib/librt.so.1...done.
  Loaded symbols for /lib/librt.so.1
  Reading symbols from /usr/lib/libgssapi_krb5.so.2...done.
  Loaded symbols for /usr/lib/libgssapi_krb5.so.2
  Reading symbols from /usr/lib/libgnutls.so.26...Reading symbols from /usr/lib/debug/usr/lib/libgnutls.so.26.14.10...done.
  done.
  Loaded symbols for /usr/lib/libgnutls.so.26
  Reading symbols from /usr/lib/libgcrypt.so.11...Reading symbols from /usr/lib/debug/usr/lib/libgcrypt.so.11.5.2...done.
  done.
  Loaded symbols for /usr/lib/libgcrypt.so.11
  Reading symbols from /lib/libresolv.so.2...done.
  Loaded symbols for /lib/libresolv.so.2
  Reading symbols from /usr/lib/libsasl2.so.2...done.
  Loaded symbols for /usr/lib/libsasl2.so.2
  Reading symbols from /usr/lib/libkrb5.so.3...done.
  Loaded symbols for /usr/lib/libkrb5.so.3
  Reading symbols from /usr/lib/libk5crypto.so.3...done.
  Loaded symbols for /usr/lib/libk5crypto.so.3
  Reading symbols from /lib/libcom_err.so.2...done.
  Loaded symbols for /lib/libcom_err.so.2
  Reading symbols from /usr/lib/libkrb5support.so.0...done.
  Loaded symbols for /usr/lib/libkrb5support.so.0
  Reading symbols from /lib/libkeyutils.so.1...done.
  Loaded symbols for /lib/libkeyutils.so.1
  Reading symbols from /usr/lib/libtasn1.so.3...done.
  Loaded symbols for /usr/lib/libtasn1.so.3
  Reading symbols from /usr/lib/libgpg-error.so.0...done.
  Loaded symbols for /usr/lib/libgpg-error.so.0
  Reading symbols from /lib/libnss_files.so.2...done.
  Loaded symbols for /lib/libnss_files.so.2
  Reading symbols from /lib/libnss_mdns4_minimal.so.2...done.
  Loaded symbols for /lib/libnss_mdns4_minimal.so.2
  Reading symbols from /lib/libnss_dns.so.2...done.
  Loaded symbols for /lib/libnss_dns.so.2
  Core was generated by `freepopsd -w'.
  Program terminated with signal 6, Aborted.
  #0  0x00007f3864238d25 in raise () from /lib/libc.so.6
  (gdb) bt
  #0  0x00007f3864238d25 in raise () from /lib/libc.so.6
  #1  0x00007f386423bde1 in abort () from /lib/libc.so.6
  #2  0x00007f3864231f99 in __assert_fail () from /lib/libc.so.6
  #3  0x00007f3863024ecb in _gcry_ath_mutex_lock (lock=0x7f3863289390)
      at ath.c:193
  #4  0x00007f38630300af in md_digest_length (algorithm=1) at md.c:1070
  #5  0x00007f38632c968f in wrap_gcry_mac_output (src_ctx=0x2787110, 
      digest=0x7f3861cd87f0, digestsize=16) at mac-libgcrypt.c:150
  #6  0x00007f38632aeeb9 in _gnutls_hash_deinit (handle=0x26ca, digest=0x26cb)
      at gnutls_hash_int.c:168
  #7  0x00007f38632a6afd in _gnutls_finished (session=0x277f8d0, type=2, 
      ret=0x7f3861cd8860) at gnutls_handshake.c:231
  #8  0x00007f38632a90c1 in _gnutls_send_finished (session=0x277f8d0, 
      init=<value optimized out>) at gnutls_handshake.c:560
  #9  _gnutls_send_handshake_final (session=0x277f8d0, 
      init=<value optimized out>) at gnutls_handshake.c:2489
  #10 0x00007f38632a9315 in _gnutls_handshake_common (session=0x277f8d0)
      at gnutls_handshake.c:2693
  #11 0x00007f38632aa9f2 in gnutls_handshake (session=0x277f8d0)
      at gnutls_handshake.c:2297
  #12 0x00007f38647b0860 in handshake () from /usr/lib/libcurl-gnutls.so.4
  #13 0x00007f38647b0ed6 in Curl_gtls_connect ()
     from /usr/lib/libcurl-gnutls.so.4
  #14 0x00007f38647b1e60 in Curl_ssl_connect () from /usr/lib/libcurl-gnutls.so.4
  #15 0x00007f3864790e2c in Curl_http_connect ()
     from /usr/lib/libcurl-gnutls.so.4
  #16 0x00007f3864797072 in Curl_protocol_connect ()
     from /usr/lib/libcurl-gnutls.so.4
  #17 0x00007f3864799e24 in Curl_connect () from /usr/lib/libcurl-gnutls.so.4
  #18 0x00007f38647a551b in Curl_perform () from /usr/lib/libcurl-gnutls.so.4
  #19 0x000000000040fdc6 in luacurl_easy_perform (L=0x23f6660) at lua-curl.c:509
  #20 0x0000000000424296 in luaD_precall (L=0x23f6660, func=0x24e3640, 
      nresults=2) at ldo.c:319
  #21 0x000000000042d991 in luaV_execute (L=0x23f6660, nexeccalls=5) at lvm.c:587
  ---Type <return> to continue, or q <return> to quit---
  #22 0x0000000000424805 in luaD_call (L=0x23f6660, func=0x2430cf0, nResults=1)
      at ldo.c:377
  #23 0x0000000000423ea7 in luaD_rawrunprotected (L=0x23f6660, 
      f=0x4218e0 <f_call>, ud=0x7f3861cd8f10) at ldo.c:116
  #24 0x0000000000423f25 in luaD_pcall (L=0x26ca, func=0x26cb, u=0x6, 
      old_top=-1, ef=41385872) at ldo.c:461
  #25 0x0000000000421722 in lua_pcall (L=0x23f6660, nargs=2, nresults=1, 
      errfunc=<value optimized out>) at lapi.c:817
  #26 0x00000000004205d1 in luay_call (s=0x23f6660, args=0x43acee "ps|d", 
      funcname=0x43ace9 "pass") at luay.c:282
  #27 0x000000000040a9e2 in freepops_pass (p=0x23f6490, 
      password=0x7f3861cd98e0 "ndr") at engine.c:259
  #28 0x0000000000414026 in pop3_POPSTATE_AUTH (data=<value optimized out>)
      at popserver.c:454
  #29 pop3_thread (data=<value optimized out>) at popserver.c:785
  #30 0x00007f3864d67f9a in start_thread () from /lib/libpthread.so.0
  #31 0x00007f38642d356d in clone () from /lib/libc.so.6
  #32 0x0000000000000000 in ?? ()
  (gdb) quit

While this other thread was (sleeping?) in a poll syscall:

  #0  0x00007f38642cad36 in poll () from /lib/libc.so.6
  #1  0x00007f38647b0286 in Curl_socket_ready ()
     from /usr/lib/libcurl-gnutls.so.4
  #2  0x00007f38647b08b6 in handshake () from /usr/lib/libcurl-gnutls.so.4
  #3  0x00007f38647b0ed6 in Curl_gtls_connect ()
     from /usr/lib/libcurl-gnutls.so.4
  #4  0x00007f38647b1e60 in Curl_ssl_connect () from /usr/lib/libcurl-gnutls.so.4
  #5  0x00007f3864790e2c in Curl_http_connect ()
     from /usr/lib/libcurl-gnutls.so.4
  #6  0x00007f3864797072 in Curl_protocol_connect ()
     from /usr/lib/libcurl-gnutls.so.4
  #7  0x00007f3864799e24 in Curl_connect () from /usr/lib/libcurl-gnutls.so.4
  #8  0x00007f38647a551b in Curl_perform () from /usr/lib/libcurl-gnutls.so.4
  #9  0x000000000040fdc6 in luacurl_easy_perform (L=0x2444870) at lua-curl.c:509
  #10 0x0000000000424296 in luaD_precall (L=0x2444870, func=0x24f0b10, 
      nresults=2) at ldo.c:319
  #11 0x000000000042d991 in luaV_execute (L=0x2444870, nexeccalls=5) at lvm.c:587
  #12 0x0000000000424805 in luaD_call (L=0x2444870, func=0x247f2b0, nResults=1)
      at ldo.c:377
  #13 0x0000000000423ea7 in luaD_rawrunprotected (L=0x2444870, 
      f=0x4218e0 <f_call>, ud=0x7f38614d7f10) at ldo.c:116
  #14 0x0000000000423f25 in luaD_pcall (L=0x7f38614d78c0, func=0x2, u=0x49282, 
      old_top=-1, ef=0) at ldo.c:461
  #15 0x0000000000421722 in lua_pcall (L=0x2444870, nargs=2, nresults=1, 
      errfunc=<value optimized out>) at lapi.c:817
  #16 0x00000000004205d1 in luay_call (s=0x2444870, args=0x43acee "ps|d", 
      funcname=0x43ace9 "pass") at luay.c:282
  #17 0x000000000040a9e2 in freepops_pass (p=0x2444470, 
      password=0x7f38614d88e0 "emc2") at engine.c:259
  #18 0x0000000000414026 in pop3_POPSTATE_AUTH (data=<value optimized out>)
      at popserver.c:454
  #19 pop3_thread (data=<value optimized out>) at popserver.c:785
  #20 0x00007f3864d67f9a in start_thread () from /lib/libpthread.so.0
  #21 0x00007f38642d356d in clone () from /lib/libc.so.6

Thanks in advance
-- 
Enrico Tassi




From xizhi.zhu at gmail.com  Thu Aug 20 13:15:31 2009
From: xizhi.zhu at gmail.com (Xizhi Zhu)
Date: Thu, 20 Aug 2009 14:15:31 +0300
Subject: Why not SHA256 in cipher suite?
Message-ID: <20090820141531.29f9fba5@zhu-laptop>

Hi,

I found that in GnuTLS, SHA256 is not used in any cipher suites (i.e.
not listed in gnutls-cli -l). However, they are defined in RFC 5246,
e.g. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x00,0x3C). I wonder why they are
not supported in GnuTLS as they can provide a higher security level.

Thanks for your answers!

Regards,
Xizhi




From tgc at jupiterrise.com  Fri Aug 21 17:55:46 2009
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Fri, 21 Aug 2009 17:55:46 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <87my5v4fut.fsf@mocca.josefsson.org>
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
	<87my5v4fut.fsf@mocca.josefsson.org>
Message-ID: <20090821155546.GA14150@ares.tgcnet>

On Thu, Aug 20, 2009 at 12:07:54AM +0200, Simon Josefsson wrote:
> Could you check if the size_max.m4 files in your build have 'serial 9'
> in the first line?  Maybe you tested before the packages was updated.
> You could test the 2.9.3 release now.
> 
I was initially using your daily-build script but then I noticed that
the gnutls snapshot has not been updated since Aug 13th.

$ sha1sum ../gnutls-2.9.3.tar.bz2
6e7157274df5c95984fd52c4d500a414a67b9d44  ../gnutls-2.9.3.tar.bz2
[gnutls-2.9.3]$ find . -name 'size_max.m4' | xargs head -1
==> ./gl/m4/size_max.m4 <==
# size_max.m4 serial 9

==> ./lib/m4/size_max.m4 <==
# size_max.m4 serial 6

Brunos fix should be fine, I see the toplevel config.h correctly
guarding the define with an ifndef SIZE_MAX.

-tgc




From joe at x2a.org  Sat Aug 22 20:31:33 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Sat, 22 Aug 2009 14:31:33 -0400
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <8763chtvjp.fsf@mocca.josefsson.org>
References: <4A8B69A2.9010905@x2a.org>
	<8763cj99xb.fsf@mocca.josefsson.org>	<4A8C1BC8.6070901@x2a.org>
	<87fxbn5y1r.fsf@mocca.josefsson.org>	<4A8DE7FC.5030405@x2a.org>
	<8763chtvjp.fsf@mocca.josefsson.org>
Message-ID: <4A903985.6090807@x2a.org>

Simon Josefsson wrote:
> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
> 
>> Simon Josefsson wrote:
>>> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
>>>
>>>> Simon Josefsson wrote:
>>> How do I create a patch between your branch and master, to review it?  I
>>> haven't worked with multiple repositories, but willing to learn.
>>>
>>> /Simon
>> Alright, here is what you need to do:
>>
>>  - Use a somewhat-pristine git repository cloned from savannah or whatever.
>>  - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ;
>> this adds an entry in the .git/config file and fetches refs and objects
>> from my repository.
>>  - Create a local branch tracking my remote repository: git branch
>> --track buffers-redux jonathan/buffers-redux
>>  - Now you can git checkout buffers-redux to switch to that branch or do
>> a git diff master..buffers-redux . If you had not created a local branch
>> you could instead do git diff master..jonathan/buffers-redux
> 
> Excellent, thank you!
> 
> Quick comments:
> 
> * Please add a comment describing what dump_bytes does, and preferrably
>   make it use _gnutls_bin2hex for hex encoding.  Is there a fixed-size
>   limit of 128 in the function?  If so, it would be nice to fix that.

I was not aware of the existence of the _gnutls_bin2hex function. The
fixed buffers in dump_bytes are emptied at the end of each line and
their maximum size is bounded by the number of bytes per line (16), so
it could in theory print  256^sizeof(size_t) bytes. I will fix
gnutls_buffers.c to use _gnutls_bin2hex.

> * What does the 'bufel' variable name refers to?  It looks non-english
>   to me, so I'd prefer using 'buf'.

A mbuffer is a chain of buffer elements. I use buf to refer to the whole
chain of buffers (mbuffer_head_st) and bufel to refer to a buffer
element (mbuffer_st). I don't mind changing the variable names if they
really bother you.

> * Some comments at the top of gnutls_mbuffers.? what it does would be
>   good.

Sure, I can do that. I was planning on adding those comments later on
anyway.

> More later.

I'll be waiting.
> 
> /Simon

Thanks !




From nmav at gnutls.org  Sun Aug 23 20:28:06 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Aug 2009 21:28:06 +0300
Subject: Help with multithreading
In-Reply-To: <20090821095536.GA6248@birba>
References: <20090821095536.GA6248@birba>
Message-ID: <4A918A36.4090304@gnutls.org>

Enrico Tassi wrote:
> I'm facing a problem that seems to be related to the multithreading
> aspect of gnutls+curl, but digging the mailing list was not enough to
> find an answer, so I'm posting hoping someone has some hints for me.
> 
> This is the way I initialize gcrypt/gnutls, and I'm doing it at the very 
> beginning of the main() function:

I'd suggest against doing the full initialization of libgcrypt and
allowing gnutls to do it. If you do what the manual says do you have the
same issue?

http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications

regards,
Nikos




From simon at josefsson.org  Mon Aug 24 23:06:18 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 24 Aug 2009 23:06:18 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <20090821155546.GA14150@ares.tgcnet> (Tom G. Christensen's
	message of "Fri, 21 Aug 2009 17:55:46 +0200")
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
	<87my5v4fut.fsf@mocca.josefsson.org>
	<20090821155546.GA14150@ares.tgcnet>
Message-ID: <87skfghqgl.fsf@mocca.josefsson.org>

"Tom G. Christensen" <tgc at jupiterrise.com> writes:

> On Thu, Aug 20, 2009 at 12:07:54AM +0200, Simon Josefsson wrote:
>> Could you check if the size_max.m4 files in your build have 'serial 9'
>> in the first line?  Maybe you tested before the packages was updated.
>> You could test the 2.9.3 release now.
>> 
> I was initially using your daily-build script but then I noticed that
> the gnutls snapshot has not been updated since Aug 13th.
>
> $ sha1sum ../gnutls-2.9.3.tar.bz2
> 6e7157274df5c95984fd52c4d500a414a67b9d44  ../gnutls-2.9.3.tar.bz2
> [gnutls-2.9.3]$ find . -name 'size_max.m4' | xargs head -1
> ==> ./gl/m4/size_max.m4 <==
> # size_max.m4 serial 9
>
> ==> ./lib/m4/size_max.m4 <==
> # size_max.m4 serial 6

Oops, the build robot haven't been able to build it since then, the
"resume" test is failing.  I suspect it is related to the TLS session
ticket support that went in recently.  Build log:

http://autobuild.josefsson.org/gnutls/log-200908241414540949000.txt

I'm working on it.

/Simon




From simon at josefsson.org  Mon Aug 24 23:46:41 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 24 Aug 2009 23:46:41 +0200
Subject: [PATCH] session ticket support
In-Reply-To: <87pras7xpo.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 19 Aug 2009 15:13:55 +0200")
References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org>
	<4A5F93EA.9050100@gnutls.org>
	<d709a4f1-b959-4337-95b0-3a8121e6fccf@broken.deisui.org>
	<4A6ACB0A.4030801@gnutls.org>
	<e36c1ebd-33a1-4d34-aa11-5d06c1b1801c@broken.deisui.org>
	<4A6C5385.9010504@gnutls.org>
	<c59d4e81-bdc7-4a83-8258-fc1d7366757a@broken.deisui.org>
	<87ws5jkc62.fsf@mocca.josefsson.org>
	<87vdl2rfmt.fsf@broken.deisui.org>
	<87prbahee5.fsf@mocca.josefsson.org>
	<87k51hxvny.fsf@broken.deisui.org>
	<87d478trxd.fsf@mocca.josefsson.org>
	<363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org>
	<87prb3i22u.fsf@mocca.josefsson.org>
	<878whgdcdw.fsf@mocca.josefsson.org>
	<6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org>
	<87pras7xpo.fsf@mocca.josefsson.org>
Message-ID: <87ab1ohola.fsf@mocca.josefsson.org>

The self-test "resume" crashes, presumably because of the session ticket
support or your memory leak fixes.  Valgrind complains so it should be
easy to debug.  Could you please take a look?

/Simon

jas at mocca:~/src/gnutls/tests master$ valgrind ./resume
==4609== Memcheck, a memory error detector.
==4609== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==4609== Using LibVEX rev 1884, a library for dynamic binary translation.
==4609== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==4609== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==4609== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==4609== For more details, rerun with: -v
==4609== 
try to resume from db
server: ready. Listening to port '5556'.
Launched, generating DH parameters...
server: connection from 127.0.0.1, port 58638
resume db storing... (32-451)
server: Handshake was completed
client: Handshake was completed
server: Peer has closed the GNUTLS connection
server: connection from 127.0.0.1, port 58639
resume db fetch... (32)
resume db fetch... return info
client: Handshake was completed
- Previous session was resumed
resume db storing... (32-451)
server: Handshake was completed
server: Peer has closed the GNUTLS connection
server: finished
global stop
==4612== Invalid free() / delete / delete[]
==4612==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4612==    by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so)
==4612==    by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so)
==4612==    by 0x4020402: _vgnU_freeres (vg_preloaded.c:60)
==4612==    by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so)
==4612==    by 0x804A4BA: doit (resume.c:463)
==4612==    by 0x804A59C: main (utils.c:148)
==4612==  Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd
==4612== 
==4612== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 1)
==4612== malloc/free: in use at exit: 2,336 bytes in 38 blocks.
==4612== malloc/free: 2,553 allocs, 2,516 frees, 405,822 bytes allocated.
==4612== For counts of detected errors, rerun with: -v
==4612== searching for pointers to 38 not-freed blocks.
==4612== checked 100,004 bytes.
==4612== 
==4612== LEAK SUMMARY:
==4612==    definitely lost: 0 bytes in 0 blocks.
==4612==      possibly lost: 0 bytes in 0 blocks.
==4612==    still reachable: 0 bytes in 0 blocks.
==4612==         suppressed: 2,336 bytes in 38 blocks.
global stop
try to resume from session ticket
server: ready. Listening to port '5556'.
Launched, generating DH parameters...
server: connection from 127.0.0.1, port 58640
server: Handshake was completed
client: Handshake was completed
server: Peer has closed the GNUTLS connection
server: connection from 127.0.0.1, port 58641
client: Handshake was completed
- Previous session was resumed
server: Handshake was completed
server: Peer has closed the GNUTLS connection
server: finished
global stop
==4622== Invalid free() / delete / delete[]
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47)
==4622==    by 0x8049A5E: global_stop (resume.c:323)
==4622==    by 0x804A4AE: doit (resume.c:462)
==4622==    by 0x804A59C: main (utils.c:148)
==4622==  Address 0x43164e0 is 0 bytes inside a block of size 8 free'd
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47)
==4622==    by 0x8049A5E: global_stop (resume.c:323)
==4622==    by 0x804A313: doit (resume.c:457)
==4622==    by 0x804A59C: main (utils.c:148)
==4622== 
==4622== Invalid read of size 4
==4622==    at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120)
==4622==    by 0x405A7E5: gnutls_dh_params_deinit (gnutls_dh_primes.c:136)
==4622==    by 0x8049A6B: global_stop (resume.c:325)
==4622==    by 0x804A4AE: doit (resume.c:462)
==4622==    by 0x804A59C: main (utils.c:148)
==4622==  Address 0x4316518 is 0 bytes inside a block of size 8 free'd
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4622==    by 0x8049A6B: global_stop (resume.c:325)
==4622==    by 0x804A313: doit (resume.c:457)
==4622==    by 0x804A59C: main (utils.c:148)
==4622== 
==4622== Invalid read of size 4
==4622==    at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120)
==4622==    by 0x405A7F0: gnutls_dh_params_deinit (gnutls_dh_primes.c:137)
==4622==    by 0x8049A6B: global_stop (resume.c:325)
==4622==    by 0x804A4AE: doit (resume.c:462)
==4622==    by 0x804A59C: main (utils.c:148)
==4622==  Address 0x431651c is 4 bytes inside a block of size 8 free'd
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4622==    by 0x8049A6B: global_stop (resume.c:325)
==4622==    by 0x804A313: doit (resume.c:457)
==4622==    by 0x804A59C: main (utils.c:148)
==4622== 
==4622== Invalid free() / delete / delete[]
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4622==    by 0x8049A6B: global_stop (resume.c:325)
==4622==    by 0x804A4AE: doit (resume.c:462)
==4622==    by 0x804A59C: main (utils.c:148)
==4622==  Address 0x4316518 is 0 bytes inside a block of size 8 free'd
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4622==    by 0x8049A6B: global_stop (resume.c:325)
==4622==    by 0x804A313: doit (resume.c:457)
==4622==    by 0x804A59C: main (utils.c:148)
==4622== 
==4622== Invalid free() / delete / delete[]
==4622==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4622==    by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so)
==4622==    by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so)
==4622==    by 0x4020402: _vgnU_freeres (vg_preloaded.c:60)
==4622==    by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so)
==4622==    by 0x804A4BA: doit (resume.c:463)
==4622==    by 0x804A59C: main (utils.c:148)
==4622==  Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd
==4622== 
==4622== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 21 from 1)
==4622== malloc/free: in use at exit: 2,336 bytes in 38 blocks.
==4622== malloc/free: 5,078 allocs, 5,043 frees, 847,546 bytes allocated.
==4622== For counts of detected errors, rerun with: -v
==4622== searching for pointers to 38 not-freed blocks.
==4622== checked 100,032 bytes.
==4622== 
==4622== LEAK SUMMARY:
==4622==    definitely lost: 0 bytes in 0 blocks.
==4622==      possibly lost: 0 bytes in 0 blocks.
==4622==    still reachable: 0 bytes in 0 blocks.
==4622==         suppressed: 2,336 bytes in 38 blocks.
global stop
try to resume from session ticket (server only)
server: ready. Listening to port '5556'.
Launched, generating DH parameters...
server: connection from 127.0.0.1, port 58642
server: Handshake was completed
client: Handshake was completed
server: Peer has closed the GNUTLS connection
server: connection from 127.0.0.1, port 58643
server: Handshake was completed
client: Handshake was completed
*** Previous session was NOT resumed
server: Peer has closed the GNUTLS connection
server: finished
global stop
==4625== Invalid free() / delete / delete[]
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47)
==4625==    by 0x8049A5E: global_stop (resume.c:323)
==4625==    by 0x804A4AE: doit (resume.c:462)
==4625==    by 0x804A59C: main (utils.c:148)
==4625==  Address 0x439f610 is 0 bytes inside a block of size 8 free'd
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47)
==4625==    by 0x8049A5E: global_stop (resume.c:323)
==4625==    by 0x804A313: doit (resume.c:457)
==4625==    by 0x804A59C: main (utils.c:148)
==4625== 
==4625== Invalid read of size 4
==4625==    at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120)
==4625==    by 0x405A7E5: gnutls_dh_params_deinit (gnutls_dh_primes.c:136)
==4625==    by 0x8049A6B: global_stop (resume.c:325)
==4625==    by 0x804A4AE: doit (resume.c:462)
==4625==    by 0x804A59C: main (utils.c:148)
==4625==  Address 0x439f648 is 0 bytes inside a block of size 8 free'd
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4625==    by 0x8049A6B: global_stop (resume.c:325)
==4625==    by 0x804A313: doit (resume.c:457)
==4625==    by 0x804A59C: main (utils.c:148)
==4625== 
==4625== Invalid read of size 4
==4625==    at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120)
==4625==    by 0x405A7F0: gnutls_dh_params_deinit (gnutls_dh_primes.c:137)
==4625==    by 0x8049A6B: global_stop (resume.c:325)
==4625==    by 0x804A4AE: doit (resume.c:462)
==4625==    by 0x804A59C: main (utils.c:148)
==4625==  Address 0x439f64c is 4 bytes inside a block of size 8 free'd
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4625==    by 0x8049A6B: global_stop (resume.c:325)
==4625==    by 0x804A313: doit (resume.c:457)
==4625==    by 0x804A59C: main (utils.c:148)
==4625== 
==4625== Invalid free() / delete / delete[]
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4625==    by 0x8049A6B: global_stop (resume.c:325)
==4625==    by 0x804A4AE: doit (resume.c:462)
==4625==    by 0x804A59C: main (utils.c:148)
==4625==  Address 0x439f648 is 0 bytes inside a block of size 8 free'd
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4625==    by 0x8049A6B: global_stop (resume.c:325)
==4625==    by 0x804A313: doit (resume.c:457)
==4625==    by 0x804A59C: main (utils.c:148)
==4625== 
==4625== Invalid free() / delete / delete[]
==4625==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4625==    by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so)
==4625==    by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so)
==4625==    by 0x4020402: _vgnU_freeres (vg_preloaded.c:60)
==4625==    by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so)
==4625==    by 0x804A4BA: doit (resume.c:463)
==4625==    by 0x804A59C: main (utils.c:148)
==4625==  Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd
==4625== 
==4625== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 21 from 1)
==4625== malloc/free: in use at exit: 2,336 bytes in 38 blocks.
==4625== malloc/free: 7,713 allocs, 7,678 frees, 1,301,048 bytes allocated.
==4625== For counts of detected errors, rerun with: -v
==4625== searching for pointers to 38 not-freed blocks.
==4625== checked 100,032 bytes.
==4625== 
==4625== LEAK SUMMARY:
==4625==    definitely lost: 0 bytes in 0 blocks.
==4625==      possibly lost: 0 bytes in 0 blocks.
==4625==    still reachable: 0 bytes in 0 blocks.
==4625==         suppressed: 2,336 bytes in 38 blocks.
global stop
try to resume from session ticket (client only)
server: ready. Listening to port '5556'.
Launched, generating DH parameters...
server: connection from 127.0.0.1, port 58644
server: Handshake was completed
client: Handshake was completed
server: Peer has closed the GNUTLS connection
server: connection from 127.0.0.1, port 58645
server: Handshake was completed
client: Handshake was completed
*** Previous session was NOT resumed
server: Peer has closed the GNUTLS connection
==4609== Invalid free() / delete / delete[]
==4609==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4609==    by 0x804A2F7: doit (resume.c:424)
==4609==    by 0x804A59C: main (utils.c:148)
==4609==  Address 0x4426510 is 0 bytes inside a block of size 64 free'd
==4609==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4609==    by 0x804A2F7: doit (resume.c:424)
==4609==    by 0x804A59C: main (utils.c:148)
server: finished
global stop
==4636== Invalid free() / delete / delete[]
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47)
==4636==    by 0x8049A5E: global_stop (resume.c:323)
==4636==    by 0x804A4AE: doit (resume.c:462)
==4636==    by 0x804A59C: main (utils.c:148)
==4636==  Address 0x4425d60 is 0 bytes inside a block of size 8 free'd
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47)
==4636==    by 0x8049A5E: global_stop (resume.c:323)
==4636==    by 0x804A313: doit (resume.c:457)
==4636==    by 0x804A59C: main (utils.c:148)
==4636== 
==4636== Invalid read of size 4
==4636==    at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120)
==4636==    by 0x405A7E5: gnutls_dh_params_deinit (gnutls_dh_primes.c:136)
==4636==    by 0x8049A6B: global_stop (resume.c:325)
==4636==    by 0x804A4AE: doit (resume.c:462)
==4636==    by 0x804A59C: main (utils.c:148)
==4636==  Address 0x4425d98 is 0 bytes inside a block of size 8 free'd
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4636==    by 0x8049A6B: global_stop (resume.c:325)
==4636==    by 0x804A313: doit (resume.c:457)
==4636==    by 0x804A59C: main (utils.c:148)
==4636== 
==4636== Invalid read of size 4
==4636==    at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120)
==4636==    by 0x405A7F0: gnutls_dh_params_deinit (gnutls_dh_primes.c:137)
==4636==    by 0x8049A6B: global_stop (resume.c:325)
==4636==    by 0x804A4AE: doit (resume.c:462)
==4636==    by 0x804A59C: main (utils.c:148)
==4636==  Address 0x4425d9c is 4 bytes inside a block of size 8 free'd
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4636==    by 0x8049A6B: global_stop (resume.c:325)
==4636==    by 0x804A313: doit (resume.c:457)
==4636==    by 0x804A59C: main (utils.c:148)
==4636== 
==4636== Invalid free() / delete / delete[]
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4636==    by 0x8049A6B: global_stop (resume.c:325)
==4636==    by 0x804A4AE: doit (resume.c:462)
==4636==    by 0x804A59C: main (utils.c:148)
==4636==  Address 0x4425d98 is 0 bytes inside a block of size 8 free'd
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139)
==4636==    by 0x8049A6B: global_stop (resume.c:325)
==4636==    by 0x804A313: doit (resume.c:457)
==4636==    by 0x804A59C: main (utils.c:148)
==4636== 
==4636== Invalid free() / delete / delete[]
==4636==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4636==    by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so)
==4636==    by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so)
==4636==    by 0x4020402: _vgnU_freeres (vg_preloaded.c:60)
==4636==    by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so)
==4636==    by 0x804A4BA: doit (resume.c:463)
==4636==    by 0x804A59C: main (utils.c:148)
==4636==  Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd
==4636== 
==4636== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 21 from 1)
==4636== malloc/free: in use at exit: 2,336 bytes in 38 blocks.
==4636== malloc/free: 10,330 allocs, 10,295 frees, 1,747,306 bytes allocated.
==4636== For counts of detected errors, rerun with: -v
==4636== searching for pointers to 38 not-freed blocks.
==4636== checked 100,032 bytes.
==4636== 
==4636== LEAK SUMMARY:
==4636==    definitely lost: 0 bytes in 0 blocks.
==4636==      possibly lost: 0 bytes in 0 blocks.
==4636==    still reachable: 0 bytes in 0 blocks.
==4636==         suppressed: 2,336 bytes in 38 blocks.
global stop
Self test `./resume' finished with 0 errors
==4609== 
==4609== Invalid free() / delete / delete[]
==4609==    at 0x4024E3A: free (vg_replace_malloc.c:323)
==4609==    by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so)
==4609==    by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so)
==4609==    by 0x4020402: _vgnU_freeres (vg_preloaded.c:60)
==4609==    by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so)
==4609==    by 0x417D7AC: (below main) (in /lib/i686/cmov/libc-2.9.so)
==4609==  Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd
==4609== 
==4609== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 21 from 1)
==4609== malloc/free: in use at exit: 2,336 bytes in 38 blocks.
==4609== malloc/free: 10,334 allocs, 10,298 frees, 1,753,420 bytes allocated.
==4609== For counts of detected errors, rerun with: -v
==4609== searching for pointers to 38 not-freed blocks.
==4609== checked 99,916 bytes.
==4609== 
==4609== LEAK SUMMARY:
==4609==    definitely lost: 0 bytes in 0 blocks.
==4609==      possibly lost: 0 bytes in 0 blocks.
==4609==    still reachable: 0 bytes in 0 blocks.
==4609==         suppressed: 2,336 bytes in 38 blocks.
jas at mocca:~/src/gnutls/tests master$ 




From ueno at unixuser.org  Mon Aug 24 23:46:38 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Tue, 25 Aug 2009 06:46:38 +0900
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <87skfghqgl.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 24 Aug 2009 23:06:18 +0200")
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
	<87my5v4fut.fsf@mocca.josefsson.org>
	<20090821155546.GA14150@ares.tgcnet>
	<87skfghqgl.fsf@mocca.josefsson.org>
Message-ID: <ddc97c76-3371-44e5-bf24-da05fdbc5b26@broken.deisui.org>

>>>>> In <87skfghqgl.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> Oops, the build robot haven't been able to build it since then, the
> "resume" test is failing.  I suspect it is related to the TLS session
> ticket support that went in recently.  Build log:

> http://autobuild.josefsson.org/gnutls/log-200908241414540949000.txt

> I'm working on it.

Oops, it seems that I installed a double-free bug along with memleak
fixes...  Sorry for taking your time.

Here is a patch to fix it:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: double-free-fix.diff
Type: text/x-diff
Size: 451 bytes
Desc: not available
URL: </pipermail/attachments/20090825/db94a065/attachment.diff>
-------------- next part --------------

Regerds,
-- 
Daiki Ueno

From simon at josefsson.org  Mon Aug 24 23:49:03 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 24 Aug 2009 23:49:03 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <ddc97c76-3371-44e5-bf24-da05fdbc5b26@broken.deisui.org> (Daiki
	Ueno's message of "Tue, 25 Aug 2009 06:46:38 +0900")
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
	<87my5v4fut.fsf@mocca.josefsson.org>
	<20090821155546.GA14150@ares.tgcnet>
	<87skfghqgl.fsf@mocca.josefsson.org>
	<ddc97c76-3371-44e5-bf24-da05fdbc5b26@broken.deisui.org>
Message-ID: <874orwhohc.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> Oops, it seems that I installed a double-free bug along with memleak
> fixes...  Sorry for taking your time.

You were too quick!  Thanks, confirmed working and pushed.  Now let's
hope the build robot continues..

/Simon




From ueno at unixuser.org  Tue Aug 25 14:34:49 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Tue, 25 Aug 2009 21:34:49 +0900
Subject: ECC cipher suites
Message-ID: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>

Hello,

I looked at the feature comparison table of TLS libraries and noticed
that GnuTLS still lacks ECC support:
http://www.gnu.org/software/gnutls/comparison.html

Is anyone working on this?  Otherwise, I would like to give it a try[1].

After a quick search on Gmane, the primary (technical) reason seems that
there is no way to compute ECDH with libgcrypt.  If so, how about simply
exporting the EC version of powm and curve selection API[2]?

Anyway, would it make sense?  Comments are appreciated.

Footnotes: 
[1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am
seeking for next interesting project.

[2] I have first considered a generic key-agreement interface in
libgcrypt, but I now think that it's too much - currently only DH
variants are used in practice.

Regards,
-- 
Daiki Ueno




From simon at josefsson.org  Wed Aug 26 00:24:43 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 26 Aug 2009 00:24:43 +0200
Subject: ECC cipher suites
In-Reply-To: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> (Daiki
	Ueno's message of "Tue, 25 Aug 2009 21:34:49 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
Message-ID: <87eiqzedlg.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> Hello,
>
> I looked at the feature comparison table of TLS libraries and noticed
> that GnuTLS still lacks ECC support:
> http://www.gnu.org/software/gnutls/comparison.html
>
> Is anyone working on this?  Otherwise, I would like to give it a try[1].

Nobody is working on it, but there are patent issues with ECC that has
to be resolved.  To avoid wasting time, we may want to approach the FSF
and the SFLC first to get a better understanding of what's involved here
(I've been deferring this since nobody has expressed interest in ECC).

> [1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am
> seeking for next interesting project.

Finishing the TLS 1.2 support and adding the new cipher suites is a
high-priority task and it shouldn't be too difficult since there are TLS
1.2 test servers out there to test with.

/Simon




From roland at digitalvampire.org  Thu Aug 27 00:22:14 2009
From: roland at digitalvampire.org (Roland Dreier)
Date: Wed, 26 Aug 2009 15:22:14 -0700
Subject: Problem with TLS 1.1 client connecting to TLS 1.0 server
Message-ID: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org>

I found what appears to be a small bug in how gnutls handles the case
where a TLS 1.1 client connects to a server that only supports TLS
1.0.  My particular case is using empathy, an IM client built on
telepathy-gabble, which in turn uses libloudmouth and finally uses
gnutls to talk to a jabber/XMPP server.  This setup defaults to trying
TLS 1.1, and in my case I'm using the client to talk to Webex Connect,
where there server seems to support only TLS 1.0.

So looking at the trace, I see a client hello sent with version 03 02,
and the server responds with a hello with version 03 01.  gnutls then
falls back to TLS 1.0 and future messages have version 03 01, but the
handshake fails after gnutls sends the client finished message -- the
server responds with a bad record MAC alert.

After a bunch of tracing through, I found the code in
_gnutls_gen_rsa_client_kx() in auth_rsa.c:

  ver = _gnutls_get_adv_version (session);

  if (session->internals.rsa_pms_version[0] == 0)
    {
      session->key->key.data[0] = _gnutls_version_get_major (ver);
      session->key->key.data[1] = _gnutls_version_get_minor (ver);

and when a client starts a TLS 1.1 session but falls back to TLS 1.0,
_gnutls_get_adv_version() still returns TLS 1.1, so the client uses
minor version 2 here, even though it is in the process of negotiating
a TLS 1.0 (minor 1) connection.

If I add a hack to overwrite session->key->key.data[1] with 1 after
the assignment of the minor, then the connection goes through OK.

So it seems that _gnutls_gen_rsa_client_kx() should be using the
active version here, but I'm not sure what the correct real fix within
the gnutls design is.  Can someone provide guidance on how to fix this?

Thanks,
  Roland




From ueno at unixuser.org  Thu Aug 27 13:29:18 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Thu, 27 Aug 2009 20:29:18 +0900
Subject: ECC cipher suites
In-Reply-To: <87eiqzedlg.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 26 Aug 2009 00:24:43 +0200")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
Message-ID: <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>

>>>>> In <87eiqzedlg.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> > I looked at the feature comparison table of TLS libraries and noticed
> > that GnuTLS still lacks ECC support:
> > http://www.gnu.org/software/gnutls/comparison.html
> >
> > Is anyone working on this?  Otherwise, I would like to give it a try[1].

> Nobody is working on it, but there are patent issues with ECC that has
> to be resolved.  To avoid wasting time, we may want to approach the FSF
> and the SFLC first to get a better understanding of what's involved here
> (I've been deferring this since nobody has expressed interest in ECC).

Good to know before stepping into further.  I hope that the situation
will change in the near future.

> Finishing the TLS 1.2 support and adding the new cipher suites is a
> high-priority task and it shouldn't be too difficult since there are TLS
> 1.2 test servers out there to test with.

Thanks for the hint.  I'll check which features of TLS 1.2 are not
implemented.  Adding HMAC-SHA256 cipher suites looks one thing to do.

Regards,
-- 
Daiki Ueno




From simon at josefsson.org  Thu Aug 27 15:12:16 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 27 Aug 2009 15:12:16 +0200
Subject: Poll: What do you want to see implemented in GnuTLS next?
In-Reply-To: <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> (Daiki
	Ueno's message of "Thu, 27 Aug 2009 20:29:18 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
Message-ID: <87fxbdjt8v.fsf_-_@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>> Finishing the TLS 1.2 support and adding the new cipher suites is a
>> high-priority task and it shouldn't be too difficult since there are TLS
>> 1.2 test servers out there to test with.
>
> Thanks for the hint.  I'll check which features of TLS 1.2 are not
> implemented.  Adding HMAC-SHA256 cipher suites looks one thing to do.

Actually TLS 1.2 is not working in GnuTLS now, the drafts changed how
the negotiation worked after I implemented it and I never found time to
update it to support the protocol defined by the final RFC.  I don't
expect finishing this would require major changes, so it would be a
great contribution to finish the TLS 1.2 support.  Definitely adding
SHA256 ciphers would be good.

Reading doc/TODO I couldn't find any other easily identifiable task that
is more important except possibly DTLS support (but Jonathan is working
on that already).

Maybe we can turn this into an open poll.  What do people want to see
happen next?

AES-GCM cipher suites would be nice.  There is also the OCSP extension,
which would be fairly easy to add.

/Simon




From simon at josefsson.org  Thu Aug 27 15:24:49 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 27 Aug 2009 15:24:49 +0200
Subject: Problem with TLS 1.1 client connecting to TLS 1.0 server
In-Reply-To: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> (Roland Dreier's
	message of "Wed, 26 Aug 2009 15:22:14 -0700")
References: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org>
Message-ID: <87bpm1jsny.fsf@mocca.josefsson.org>

Roland Dreier <roland at digitalvampire.org> writes:

> I found what appears to be a small bug in how gnutls handles the case
> where a TLS 1.1 client connects to a server that only supports TLS
> 1.0.  My particular case is using empathy, an IM client built on
> telepathy-gabble, which in turn uses libloudmouth and finally uses
> gnutls to talk to a jabber/XMPP server.  This setup defaults to trying
> TLS 1.1, and in my case I'm using the client to talk to Webex Connect,
> where there server seems to support only TLS 1.0.
>
> So looking at the trace, I see a client hello sent with version 03 02,
> and the server responds with a hello with version 03 01.  gnutls then
> falls back to TLS 1.0 and future messages have version 03 01, but the
> handshake fails after gnutls sends the client finished message -- the
> server responds with a bad record MAC alert.
>
> After a bunch of tracing through, I found the code in
> _gnutls_gen_rsa_client_kx() in auth_rsa.c:
>
>   ver = _gnutls_get_adv_version (session);
>
>   if (session->internals.rsa_pms_version[0] == 0)
>     {
>       session->key->key.data[0] = _gnutls_version_get_major (ver);
>       session->key->key.data[1] = _gnutls_version_get_minor (ver);
>
> and when a client starts a TLS 1.1 session but falls back to TLS 1.0,
> _gnutls_get_adv_version() still returns TLS 1.1, so the client uses
> minor version 2 here, even though it is in the process of negotiating
> a TLS 1.0 (minor 1) connection.
>
> If I add a hack to overwrite session->key->key.data[1] with 1 after
> the assignment of the minor, then the connection goes through OK.
>
> So it seems that _gnutls_gen_rsa_client_kx() should be using the
> active version here, but I'm not sure what the correct real fix within
> the gnutls design is.  Can someone provide guidance on how to fix this?

RFC 5246 says the PMS should contain the latest (newest) version
supported by the client:

      client_version
         The latest (newest) version supported by the client.  This is
         used to detect version rollback attacks.
...
   Note: The version number in the PreMasterSecret is the version
   offered by the client in the ClientHello.client_version, not the
   version negotiated for the connection.  This feature is designed to
   prevent rollback attacks.  Unfortunately, some old implementations
   use the negotiated version instead, and therefore checking the
   version number may lead to failure to interoperate with such
   incorrect client implementations.

   Client implementations MUST always send the correct version number in
   PreMasterSecret.  If ClientHello.client_version is TLS 1.1 or higher,
   server implementations MUST check the version number as described in
   the note below.  If the version number is TLS 1.0 or earlier, server
   implementations SHOULD check the version number, but MAY have a
   configuration option to disable the check.  Note that if the check
   fails, the PreMasterSecret SHOULD be randomized as described below.

Even RFC 2246, TLS 1.0, is clear on this:

       client_version
           The latest (newest) version supported by the client. This is
           used to detect version roll-back attacks. Upon receiving the
           premaster secret, the server should check that this value
           matches the value transmitted by the client in the client
           hello message.

I believe this means your server is broken and doesn't implement TLS 1.0
correctly.

Changing how GnuTLS works here by default doesn't work: it would make
the default break with working servers, which isn't a good idea.

So the next-best solution appears to allow applications say to GnuTLS to
work better with this particular server.  This is already supported, and
you can tell GnuTLS to only attempt to talk TLS 1.0 against the server.
This appears to be the simplest solution since your server doesn't
support anything more than TLS 1.0 anyway.  This should be a knob
somewhere in your application, and have to be propagated through the
libraries down into GnuTLS.  The following disables TLS 1.1:

  gnutls_priority_set_direct (session, "NORMAL:-VERS-TLS1.1", NULL);

There are other alternatives to solving this too (i.e., add a knob to
use another client_version value), but I'm not sure it is worth it as it
adds other problems and the problem here is really a broken server.

/Simon




From dkg at fifthhorseman.net  Thu Aug 27 22:30:53 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 27 Aug 2009 16:30:53 -0400
Subject: Why not SHA256 in cipher suite?
In-Reply-To: <20090820141531.29f9fba5@zhu-laptop>
References: <20090820141531.29f9fba5@zhu-laptop>
Message-ID: <4A96ECFD.6030907@fifthhorseman.net>

On 08/20/2009 07:15 AM, Xizhi Zhu wrote:
> I found that in GnuTLS, SHA256 is not used in any cipher suites (i.e.
> not listed in gnutls-cli -l). However, they are defined in RFC 5246,
> e.g. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x00,0x3C). I wonder why they are
> not supported in GnuTLS as they can provide a higher security level.

I think there is active development work starting on the SHA256 suites.
 Please see:

 http://lists.gnu.org/archive/html/gnutls-devel/2009-08/msg00109.html

hth,

	--dkg

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

From roland at digitalvampire.org  Thu Aug 27 07:47:34 2009
From: roland at digitalvampire.org (Roland Dreier)
Date: Wed, 26 Aug 2009 22:47:34 -0700
Subject: Problem with TLS 1.1 client connecting to TLS 1.0 server
In-Reply-To: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> (Roland Dreier's
	message of "Wed, 26 Aug 2009 15:22:14 -0700")
References: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org>
Message-ID: <87iqg9x0y1.fsf@shaolin.home.digitalvampire.org>

 > So it seems that _gnutls_gen_rsa_client_kx() should be using the
 > active version here, but I'm not sure what the correct real fix within
 > the gnutls design is.  Can someone provide guidance on how to fix this?

Never mind ... after reading the TLS spec more closely, I see that the
client is correct in using the highest version it offered in the
premaster secret.  This is a bug (and apparently a common bug -- it
appears in the ietf TLS interoperability draft) in the server, and I
will report it to the server people.

Sorry for the noise.

 - Roland
-- 
Roland Dreier  <roland at digitalvampire.org>  GPG Key: 1024D/E0EEFAC0
Fingerprint:     A89F B5E9 C185 F34D BD50  4009 37E2 25CC E0EE FAC0

 Sending >500KB attachments is forbidden by the Geneva Convention.
        Your country may be at risk if you fail to comply.




From dan at coneharvesters.com  Fri Aug 28 02:02:17 2009
From: dan at coneharvesters.com (Dan Fandrich)
Date: Thu, 27 Aug 2009 17:02:17 -0700
Subject: GnuTLS portability fixes
Message-ID: <20090828000216.GA14455@coneharvesters.com>

I tripped over a few issues, mainly mismatched types, when compiling GnuTLS 2.8.3
using the OpenWatcom 1.8 compiler on Linux. Attached is a patch to fix
those errors.

>>> Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.8.3.diff
Type: text/x-patch
Size: 5004 bytes
Desc: not available
URL: </pipermail/attachments/20090827/28af4ac3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 288 bytes
Desc: not available
URL: </pipermail/attachments/20090827/28af4ac3/attachment.pgp>

From simon at josefsson.org  Fri Aug 28 15:01:34 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 28 Aug 2009 15:01:34 +0200
Subject: GnuTLS portability fixes
In-Reply-To: <20090828000216.GA14455@coneharvesters.com> (Dan Fandrich's
	message of "Thu, 27 Aug 2009 17:02:17 -0700")
References: <20090828000216.GA14455@coneharvesters.com>
Message-ID: <87ab1k5byp.fsf@mocca.josefsson.org>

Dan Fandrich <dan at coneharvesters.com> writes:

> I tripped over a few issues, mainly mismatched types, when compiling GnuTLS 2.8.3
> using the OpenWatcom 1.8 compiler on Linux. Attached is a patch to fix
> those errors.

Thank you, applied.

/Simon




From tgc at jupiterrise.com  Wed Aug 26 18:23:43 2009
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Wed, 26 Aug 2009 18:23:43 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <874orwhohc.fsf@mocca.josefsson.org>
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
	<87my5v4fut.fsf@mocca.josefsson.org>
	<20090821155546.GA14150@ares.tgcnet>
	<87skfghqgl.fsf@mocca.josefsson.org>
	<ddc97c76-3371-44e5-bf24-da05fdbc5b26@broken.deisui.org>
	<874orwhohc.fsf@mocca.josefsson.org>
Message-ID: <20090826162343.GA21539@ares.tgcnet>

On Mon, Aug 24, 2009 at 11:49:03PM +0200, Simon Josefsson wrote:
> You were too quick!  Thanks, confirmed working and pushed.  Now let's
> hope the build robot continues..
> 
I see new datestamped tarballs appearing but no gnutls-latest?

Also size_max.m4 is still too old:
$ sha1sum ../gnutls-20090826.tar.bz2
ecdd0903a92dc2bb9fd77a83c2939a393b293fb4  ../gnutls-20090826.tar.bz2
[gnutls-2.9.4]$ find . -name size_max.m4 | xargs head -1
==> ./lib/m4/size_max.m4 <==
# size_max.m4 serial 6
==> ./gl/m4/size_max.m4 <==
# size_max.m4 serial 9

-tgc




From simon at josefsson.org  Fri Aug 28 18:32:23 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 28 Aug 2009 18:32:23 +0200
Subject: Buildreport for GnuTLS 2.8.3
In-Reply-To: <20090826162343.GA21539@ares.tgcnet> (Tom G. Christensen's
	message of "Wed, 26 Aug 2009 18:23:43 +0200")
References: <20090814140334.GA30319@ares.tgcnet>
	<87k512k0dn.fsf@mocca.josefsson.org>
	<20090818192623.GA5635@ares.tgcnet>
	<87my5v4fut.fsf@mocca.josefsson.org>
	<20090821155546.GA14150@ares.tgcnet>
	<87skfghqgl.fsf@mocca.josefsson.org>
	<ddc97c76-3371-44e5-bf24-da05fdbc5b26@broken.deisui.org>
	<874orwhohc.fsf@mocca.josefsson.org>
	<20090826162343.GA21539@ares.tgcnet>
Message-ID: <874orr527c.fsf@mocca.josefsson.org>

"Tom G. Christensen" <tgc at jupiterrise.com> writes:

> On Mon, Aug 24, 2009 at 11:49:03PM +0200, Simon Josefsson wrote:
>> You were too quick!  Thanks, confirmed working and pushed.  Now let's
>> hope the build robot continues..
>> 
> I see new datestamped tarballs appearing but no gnutls-latest?

Right, that was because I turned off *.tar.gz, and the script that
created the gnutls-latest ssymlink didn't understand *.bz2.  Fixed now.

> Also size_max.m4 is still too old:
> $ sha1sum ../gnutls-20090826.tar.bz2
> ecdd0903a92dc2bb9fd77a83c2939a393b293fb4  ../gnutls-20090826.tar.bz2
> [gnutls-2.9.4]$ find . -name size_max.m4 | xargs head -1
> ==> ./lib/m4/size_max.m4 <==
> # size_max.m4 serial 6
> ==> ./gl/m4/size_max.m4 <==
> # size_max.m4 serial 9

Ah, lib/m4/size_max.m4 is generated by gettext.  I have added an ugly
workaround to cfg.mk, please try the most recent snapshot.

/Simon




From fk at fabiankeil.de  Sat Aug 29 13:19:43 2009
From: fk at fabiankeil.de (Fabian Keil)
Date: Sat, 29 Aug 2009 13:19:43 +0200
Subject: Minor fixes for gnutls 2.9.4
Message-ID: <20090829131943.17b54e52@r500.local>

The attached patches fix a few minor issues in
gnutls-20090829.tar.bz2, most of them pointed out by clang.

The first three ones fix sanity checks in print_* functions,
then there's a patch to improve the code clarity in crypt.c,
one that marks what looks like a bug in _gnutls_srp_pwd_read_entry()
and finally a couple of patches for write-only variables and dead
stores which may or may not be intentional.

Patch 0005 removes an apparently unnecessary (and insufficient)
NULL pointer check, and while double checking the diff I also
noticed the following code:

fk at r500 ~/git/gnutls/gnutls-2.9.4 $cat -n lib/opencdk/misc.c | grep 12[34]
   123    for (node = root->next; node; node = node->next)
   124      return node;

and wonder if an if block wouldn't be more suitable here.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-In-print_crl-initialize-aki_idx-and-crl_nr-once-befo.patch
Type: text/x-patch
Size: 1041 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-In-print_crq-initialize-challenge-and-extensions-onc.patch
Type: text/x-patch
Size: 905 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-In-print_extensions-initialize-_idx-variables-once-b.patch
Type: text/x-patch
Size: 1369 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-In-print_extensions-declare-the-_idx-variables-as-in.patch
Type: text/x-patch
Size: 1148 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-In-cdk_strlist_next-root-is-expected-to-be-non-NULL-.patch
Type: text/x-patch
Size: 729 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-In-main-rename-salt-to-salt_size-and-don-t-bother-re.patch
Type: text/x-patch
Size: 1240 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Mark-what-looks-like-a-bug-in-in-_gnutls_srp_pwd_rea.patch
Type: text/x-patch
Size: 935 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Remove-duplicates.-Two-exact-ones-and-a-pretty-close.patch
Type: text/x-patch
Size: 1771 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0009-Remove-write-only-variable-tmp_size-in-_pkcs12_decod.patch
Type: text/x-patch
Size: 1046 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0010-Remove-write-only-variable-sep_ar_idx-in-split_multi.patch
Type: text/x-patch
Size: 1482 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0009.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0011-Remove-write-only-variable-info-in-gen_rsa_export_se.patch
Type: text/x-patch
Size: 1053 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0010.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0012-Remove-write-only-variable-info-in-_gnutls_proc_cert.patch
Type: text/x-patch
Size: 926 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0011.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0013-Remove-dead-store-in-pkcs12_info.patch
Type: text/x-patch
Size: 638 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0012.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0014-Remove-dead-store-in-pwd_put_values.patch
Type: text/x-patch
Size: 612 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0013.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0015-Remove-dead-store-in-gnutls_x509_crt_list_import.patch
Type: text/x-patch
Size: 663 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0014.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0016-Remove-dead-store-in-_gnutls_io_write_buffered.patch
Type: text/x-patch
Size: 661 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0015.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0017-Remove-dead-store-in-listen_socket.patch
Type: text/x-patch
Size: 638 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment-0016.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: </pipermail/attachments/20090829/b1e7dbfb/attachment.pgp>

From ueno at unixuser.org  Mon Aug 31 08:25:19 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Mon, 31 Aug 2009 15:25:19 +0900
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87fxbdjt8v.fsf_-_@mocca.josefsson.org> (Simon Josefsson's
	message of "Thu, 27 Aug 2009 15:12:16 +0200")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
Message-ID: <87my5gwldc.fsf_-_@broken.deisui.org>

>>>>> In <87fxbdjt8v.fsf_-_ at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> Daiki Ueno <ueno at unixuser.org> writes:

> >> Finishing the TLS 1.2 support and adding the new cipher suites is a
> >> high-priority task and it shouldn't be too difficult since there are TLS
> >> 1.2 test servers out there to test with.
> >
> > Thanks for the hint.  I'll check which features of TLS 1.2 are not
> > implemented.  Adding HMAC-SHA256 cipher suites looks one thing to do.

> Actually TLS 1.2 is not working in GnuTLS now, the drafts changed how
> the negotiation worked after I implemented it and I never found time to
> update it to support the protocol defined by the final RFC.

I just realized it ;-)

I'm attaching a set of patches to provide minimal fix for client side
TLS 1.2 support.  I've confirmed them working against Mike's test
server:

 $ gnutls-cli --debug 10 --protocols TLS1.2 -p 443 www.mikestoolbox.net

> I don't expect finishing this would require major changes, so it would
> be a great contribution to finish the TLS 1.2 support.

While server-side support would require a bit more work, for the moment
I would like to ask for comments on my approach.  The patches mainly
follow the changes regarding SignatureAndHashAlgorithm usage.  Here is a
summary of each patch:

* 0001-Add-functions-for-TLS-signature-algorithm.patch

This patch adds helper functions which convert SignatureAndHashAlgorithm
value from/to `gnutls_sign_algorithm_t'.

* 0002-Respect-TLS-signature-algorithm-in-server-KX.patch

The signature of DH params in Server Key Exchange is now a
"digitally-signed" struct.  This patch makes it read the algorithm IDs
at the beginning of the actual signature bytes.

* 0003-Use-SHA256-for-PRF-if-TLS-1.2.patch

TLS 1.2 mandates that the algorithm for the basis of PRF is SHA256, and
the same algorithm is used for the hash over handshake messages (to be
used to verify Finished message).  This patch makes it use SHA256 in
both places.

* 0004-Fix-parsing-Certificate-Request-for-TLS-1.2.patch

This patch fixes a logic to skip supported_signature_algorithms in
Certificate Request, whose type seemes to have changed from the draft.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-functions-for-TLS-signature-algorithm.patch
Type: text/x-diff
Size: 4756 bytes
Desc: not available
URL: </pipermail/attachments/20090831/bfd59df5/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Respect-TLS-signature-algorithm-in-server-KX.patch
Type: text/x-diff
Size: 6862 bytes
Desc: not available
URL: </pipermail/attachments/20090831/bfd59df5/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Use-SHA256-for-PRF-if-TLS-1.2.patch
Type: text/x-diff
Size: 2953 bytes
Desc: not available
URL: </pipermail/attachments/20090831/bfd59df5/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Fix-parsing-Certificate-Request-for-TLS-1.2.patch
Type: text/x-diff
Size: 885 bytes
Desc: not available
URL: </pipermail/attachments/20090831/bfd59df5/attachment-0003.patch>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From simon at josefsson.org  Mon Aug 31 13:00:36 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 13:00:36 +0200
Subject: Minor fixes for gnutls 2.9.4
In-Reply-To: <20090829131943.17b54e52@r500.local> (Fabian Keil's message of
	"Sat, 29 Aug 2009 13:19:43 +0200")
References: <20090829131943.17b54e52@r500.local>
Message-ID: <87bplwfdt7.fsf@mocca.josefsson.org>

Fabian Keil <fk at fabiankeil.de> writes:

> The attached patches fix a few minor issues in
> gnutls-20090829.tar.bz2, most of them pointed out by clang.

Thank you, I have applied them all except for 0005 which I decided to
solve differently.

> fk at r500 ~/git/gnutls/gnutls-2.9.4 $cat -n lib/opencdk/misc.c | grep 12[34]
>    123    for (node = root->next; node; node = node->next)
>    124      return node;
>
> and wonder if an if block wouldn't be more suitable here.

Or why not just 'return root->next'?  The code looks strange to me, but
I don't want to change it without a selftest that uses that code.

/Simon




From simon at josefsson.org  Mon Aug 31 13:31:25 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 13:31:25 +0200
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87my5gwldc.fsf_-_@broken.deisui.org> (Daiki Ueno's message of
	"Mon, 31 Aug 2009 15:25:19 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
Message-ID: <87zl9gdxte.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> I'm attaching a set of patches to provide minimal fix for client side
> TLS 1.2 support.  I've confirmed them working against Mike's test
> server:
>
>  $ gnutls-cli --debug 10 --protocols TLS1.2 -p 443 www.mikestoolbox.net

Great!

>  static const gnutls_sign_entry sign_algorithms[] = {
>    {"RSA-SHA", SIG_RSA_SHA1_OID, GNUTLS_SIGN_RSA_SHA1, GNUTLS_PK_RSA,
> -   GNUTLS_MAC_SHA1},
> +   GNUTLS_MAC_SHA1, {2, 1}},
>    {"RSA-SHA256", SIG_RSA_SHA256_OID, GNUTLS_SIGN_RSA_SHA256, GNUTLS_PK_RSA,
> -   GNUTLS_MAC_SHA256},
> +   GNUTLS_MAC_SHA256, {4, 1}},

Please define some constants here instead of using hard coded values.

Otherwise it looks good, I'll apply and test more carefully once you
have fixed the above.

/Simon




From simon at josefsson.org  Mon Aug 31 13:38:50 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 13:38:50 +0200
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <4A903985.6090807@x2a.org> (Jonathan Bastien-Filiatrault's
	message of "Sat, 22 Aug 2009 14:31:33 -0400")
References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org>
	<4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org>
	<4A8DE7FC.5030405@x2a.org> <8763chtvjp.fsf@mocca.josefsson.org>
	<4A903985.6090807@x2a.org>
Message-ID: <87skf8dxh1.fsf@mocca.josefsson.org>

Jonathan Bastien-Filiatrault <joe at x2a.org> writes:

> Simon Josefsson wrote:
>> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
>> 
>>> Simon Josefsson wrote:
>>>> Jonathan Bastien-Filiatrault <joe at x2a.org> writes:
>>>>
>>>>> Simon Josefsson wrote:
>>>> How do I create a patch between your branch and master, to review it?  I
>>>> haven't worked with multiple repositories, but willing to learn.
>>>>
>>>> /Simon
>>> Alright, here is what you need to do:
>>>
>>>  - Use a somewhat-pristine git repository cloned from savannah or whatever.
>>>  - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ;
>>> this adds an entry in the .git/config file and fetches refs and objects
>>> from my repository.
>>>  - Create a local branch tracking my remote repository: git branch
>>> --track buffers-redux jonathan/buffers-redux
>>>  - Now you can git checkout buffers-redux to switch to that branch or do
>>> a git diff master..buffers-redux . If you had not created a local branch
>>> you could instead do git diff master..jonathan/buffers-redux
>> 
>> Excellent, thank you!
>> 
>> Quick comments:
>> 
>> * Please add a comment describing what dump_bytes does, and preferrably
>>   make it use _gnutls_bin2hex for hex encoding.  Is there a fixed-size
>>   limit of 128 in the function?  If so, it would be nice to fix that.
>
> I was not aware of the existence of the _gnutls_bin2hex function. The
> fixed buffers in dump_bytes are emptied at the end of each line and
> their maximum size is bounded by the number of bytes per line (16), so
> it could in theory print  256^sizeof(size_t) bytes. I will fix
> gnutls_buffers.c to use _gnutls_bin2hex.

Great.

>> * What does the 'bufel' variable name refers to?  It looks non-english
>>   to me, so I'd prefer using 'buf'.
>
> A mbuffer is a chain of buffer elements. I use buf to refer to the whole
> chain of buffers (mbuffer_head_st) and bufel to refer to a buffer
> element (mbuffer_st). I don't mind changing the variable names if they
> really bother you.

No, that's fine.  I just didn't understand the "buffer element"
shortening to bufel.  I suggest putting in a short comment at the top of
gnutls_mbuffers.c about this in case others wonder.

>> * Some comments at the top of gnutls_mbuffers.? what it does would be
>>   good.
>
> Sure, I can do that. I was planning on adding those comments later on
> anyway.

Please add them and post an updated patch.  I think it is close to being
pushed.

Btw, do you expect more changes to the buffer handling for DTLS?  I'm
thinking that maybe we should release GnuTLS 2.10.0 once the TLS 1.2
support is working, which may happen soon, and I'm not sure how many of
these patches makes sense in a GnuTLS 2.10.0 that wouldn't support DTLS.
Of course, if you can finish DTLS support, that would be great, but I
think complete TLS 1.2 is important enough to warrant a new stable
release in the near future.

/Simon




From ueno at unixuser.org  Mon Aug 31 14:14:14 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Mon, 31 Aug 2009 21:14:14 +0900
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87zl9gdxte.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 31 Aug 2009 13:31:25 +0200")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
	<87zl9gdxte.fsf@mocca.josefsson.org>
Message-ID: <8763c4npt5.fsf@broken.deisui.org>

>>>>> In <87zl9gdxte.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> >  static const gnutls_sign_entry sign_algorithms[] = {
> >    {"RSA-SHA", SIG_RSA_SHA1_OID, GNUTLS_SIGN_RSA_SHA1, GNUTLS_PK_RSA,
> > -   GNUTLS_MAC_SHA1},
> > +   GNUTLS_MAC_SHA1, {2, 1}},
> >    {"RSA-SHA256", SIG_RSA_SHA256_OID, GNUTLS_SIGN_RSA_SHA256, GNUTLS_PK_RSA,
> > -   GNUTLS_MAC_SHA256},
> > +   GNUTLS_MAC_SHA256, {4, 1}},

> Please define some constants here instead of using hard coded values.

OK, here it is:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Define-constants-for-known-SignatureAndHashAlgorithm.patch
Type: text/x-diff
Size: 2332 bytes
Desc: not available
URL: </pipermail/attachments/20090831/cda821ee/attachment.patch>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From simon at josefsson.org  Mon Aug 31 14:22:36 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 14:22:36 +0200
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <8763c4npt5.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 
	31 Aug 2009 21:14:14 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
	<87zl9gdxte.fsf@mocca.josefsson.org>
	<8763c4npt5.fsf@broken.deisui.org>
Message-ID: <87d46cdvg3.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87zl9gdxte.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> >  static const gnutls_sign_entry sign_algorithms[] = {
>> >    {"RSA-SHA", SIG_RSA_SHA1_OID, GNUTLS_SIGN_RSA_SHA1, GNUTLS_PK_RSA,
>> > -   GNUTLS_MAC_SHA1},
>> > +   GNUTLS_MAC_SHA1, {2, 1}},
>> >    {"RSA-SHA256", SIG_RSA_SHA256_OID, GNUTLS_SIGN_RSA_SHA256, GNUTLS_PK_RSA,
>> > -   GNUTLS_MAC_SHA256},
>> > +   GNUTLS_MAC_SHA256, {4, 1}},
>
>> Please define some constants here instead of using hard coded values.
>
> OK, here it is:

Thanks.

> +#define TLS_SIGN_AID_RSA_SHA1 {2, 1}
> +#define TLS_SIGN_AID_RSA_SHA256 {4, 1}
> +#define TLS_SIGN_AID_RSA_SHA384 {5, 1}
> +#define TLS_SIGN_AID_RSA_SHA512 {6, 1}
> +#define TLS_SIGN_AID_DSA_SHA1 {2, 2}
> +#define TLS_SIGN_AID_RSA_MD5 {1, 2}

Where does these "magic" values come from?  It was these values that I
would prefer to use symbolic names for.

/Simon




From ueno at unixuser.org  Mon Aug 31 14:33:07 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Mon, 31 Aug 2009 21:33:07 +0900
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87d46cdvg3.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 31 Aug 2009 14:22:36 +0200")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
	<87zl9gdxte.fsf@mocca.josefsson.org>
	<8763c4npt5.fsf@broken.deisui.org>
	<87d46cdvg3.fsf@mocca.josefsson.org>
Message-ID: <871vmsnoxo.fsf@broken.deisui.org>

>>>>> In <87d46cdvg3.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> > +#define TLS_SIGN_AID_RSA_SHA1 {2, 1}
> > +#define TLS_SIGN_AID_RSA_SHA256 {4, 1}
> > +#define TLS_SIGN_AID_RSA_SHA384 {5, 1}
> > +#define TLS_SIGN_AID_RSA_SHA512 {6, 1}
> > +#define TLS_SIGN_AID_DSA_SHA1 {2, 2}
> > +#define TLS_SIGN_AID_RSA_MD5 {1, 2}

> Where does these "magic" values come from?  It was these values that I
> would prefer to use symbolic names for.

RFC5246 7.4.1.4.1. defines those values as:

      enum {
          none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
          sha512(6), (255)
      } HashAlgorithm;

      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
        SignatureAlgorithm;

I first thought of redefining GNUTLS_SIGN_* with pairs of those values
(like cipher suites definitions), but it will break the ABI...

Regards,
-- 
Daiki Ueno




From ueno at unixuser.org  Mon Aug 31 14:45:19 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Mon, 31 Aug 2009 21:45:19 +0900
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <871vmsnoxo.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 
	31 Aug 2009 21:33:07 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
	<87zl9gdxte.fsf@mocca.josefsson.org>
	<8763c4npt5.fsf@broken.deisui.org>
	<87d46cdvg3.fsf@mocca.josefsson.org>
	<871vmsnoxo.fsf@broken.deisui.org>
Message-ID: <87vdk4m9sw.fsf@broken.deisui.org>

> > Where does these "magic" values come from?  It was these values that I
> > would prefer to use symbolic names for.

Ah, sorry.  Perhaps the attached might be better (it uses separate
symbolic names for sign/hash algorithms).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Define-constants-for-known-SignatureAndHashAlgorithm.patch
Type: text/x-diff
Size: 2673 bytes
Desc: not available
URL: </pipermail/attachments/20090831/93d78ba3/attachment.patch>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From simon at josefsson.org  Mon Aug 31 15:04:10 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 15:04:10 +0200
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <871vmsnoxo.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 
	31 Aug 2009 21:33:07 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
	<87zl9gdxte.fsf@mocca.josefsson.org>
	<8763c4npt5.fsf@broken.deisui.org>
	<87d46cdvg3.fsf@mocca.josefsson.org>
	<871vmsnoxo.fsf@broken.deisui.org>
Message-ID: <874orodtit.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87d46cdvg3.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> > +#define TLS_SIGN_AID_RSA_SHA1 {2, 1}
>> > +#define TLS_SIGN_AID_RSA_SHA256 {4, 1}
>> > +#define TLS_SIGN_AID_RSA_SHA384 {5, 1}
>> > +#define TLS_SIGN_AID_RSA_SHA512 {6, 1}
>> > +#define TLS_SIGN_AID_DSA_SHA1 {2, 2}
>> > +#define TLS_SIGN_AID_RSA_MD5 {1, 2}
>
>> Where does these "magic" values come from?  It was these values that I
>> would prefer to use symbolic names for.
>
> RFC5246 7.4.1.4.1. defines those values as:
>
>       enum {
>           none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
>           sha512(6), (255)
>       } HashAlgorithm;
>
>       enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
>         SignatureAlgorithm;

Thanks, I pushed your patches and added a comment explaining this.

> I first thought of redefining GNUTLS_SIGN_* with pairs of those values
> (like cipher suites definitions), but it will break the ABI...

Right, it is not worth it.

/Simon




From simon at josefsson.org  Mon Aug 31 15:10:22 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 15:10:22 +0200
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87my5gwldc.fsf_-_@broken.deisui.org> (Daiki Ueno's message of
	"Mon, 31 Aug 2009 15:25:19 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
Message-ID: <87zl9gceo1.fsf@mocca.josefsson.org>

Some part was missing, for example the definition of the
_gnutls_version_has_selectable_sighash function.

/Simon




From simon at josefsson.org  Mon Aug 31 15:11:47 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 15:11:47 +0200
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87zl9gceo1.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 31 Aug 2009 15:10:22 +0200")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
	<87zl9gceo1.fsf@mocca.josefsson.org>
Message-ID: <87vdk4celo.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Some part was missing, for example the definition of the
> _gnutls_version_has_selectable_sighash function.

Never mind, I added a '#include <gnutls_algorithms.h>' and it compiled
fine.  Now testing...

/Simon




From simon at josefsson.org  Mon Aug 31 15:33:54 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 31 Aug 2009 15:33:54 +0200
Subject: [PATCH] client-side TLS 1.2 support
In-Reply-To: <87my5gwldc.fsf_-_@broken.deisui.org> (Daiki Ueno's message of
	"Mon, 31 Aug 2009 15:25:19 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
	<71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>
	<87fxbdjt8v.fsf_-_@mocca.josefsson.org>
	<87my5gwldc.fsf_-_@broken.deisui.org>
Message-ID: <87r5uscdkt.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87fxbdjt8v.fsf_-_ at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> Daiki Ueno <ueno at unixuser.org> writes:
>
>> >> Finishing the TLS 1.2 support and adding the new cipher suites is a
>> >> high-priority task and it shouldn't be too difficult since there are TLS
>> >> 1.2 test servers out there to test with.
>> >
>> > Thanks for the hint.  I'll check which features of TLS 1.2 are not
>> > implemented.  Adding HMAC-SHA256 cipher suites looks one thing to do.
>
>> Actually TLS 1.2 is not working in GnuTLS now, the drafts changed how
>> the negotiation worked after I implemented it and I never found time to
>> update it to support the protocol defined by the final RFC.
>
> I just realized it ;-)
>
> I'm attaching a set of patches to provide minimal fix for client side
> TLS 1.2 support.  I've confirmed them working against Mike's test
> server:
>
>  $ gnutls-cli --debug 10 --protocols TLS1.2 -p 443 www.mikestoolbox.net

Confirmed, also working against

https://tls.woodgrovebank.com/

Before we enable TLS 1.2 by default, I think what is missing are:

* Check server-side TLS 1.2
* Add SHA-2 ciphersuites
* Add self-test of TLS 1.2 ciphers/features

/Simon




From fk at fabiankeil.de  Mon Aug 31 20:32:23 2009
From: fk at fabiankeil.de (Fabian Keil)
Date: Mon, 31 Aug 2009 20:32:23 +0200
Subject: Minor fixes for gnutls 2.9.4
In-Reply-To: <87bplwfdt7.fsf@mocca.josefsson.org>
References: <20090829131943.17b54e52@r500.local>
	<87bplwfdt7.fsf@mocca.josefsson.org>
Message-ID: <20090831203223.7db86265@r500.local>

Simon Josefsson <simon at josefsson.org> wrote:

> Fabian Keil <fk at fabiankeil.de> writes:
> 
> > The attached patches fix a few minor issues in
> > gnutls-20090829.tar.bz2, most of them pointed out by clang.
> 
> Thank you, I have applied them all except for 0005 which I decided to
> solve differently.

Great.

> > fk at r500 ~/git/gnutls/gnutls-2.9.4 $cat -n lib/opencdk/misc.c | grep
> > 12[34] 123    for (node = root->next; node; node = node->next)
> >    124      return node;
> >
> > and wonder if an if block wouldn't be more suitable here.
> 
> Or why not just 'return root->next'?

Indeed.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: </pipermail/attachments/20090831/5b906d95/attachment.pgp>

From joe at x2a.org  Mon Aug 31 20:51:44 2009
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Mon, 31 Aug 2009 14:51:44 -0400
Subject: [PATCH] Replace explicit version checks with feature checks
In-Reply-To: <87skf8dxh1.fsf@mocca.josefsson.org>
References: <4A8B69A2.9010905@x2a.org>
	<8763cj99xb.fsf@mocca.josefsson.org>	<4A8C1BC8.6070901@x2a.org>
	<87fxbn5y1r.fsf@mocca.josefsson.org>	<4A8DE7FC.5030405@x2a.org>
	<8763chtvjp.fsf@mocca.josefsson.org>	<4A903985.6090807@x2a.org>
	<87skf8dxh1.fsf@mocca.josefsson.org>
Message-ID: <4A9C1BC0.1030407@x2a.org>

Simon Josefsson wrote:
>>>
>>> Quick comments:
>>>
>>> * Please add a comment describing what dump_bytes does, and preferrably
>>>   make it use _gnutls_bin2hex for hex encoding.  Is there a fixed-size
>>>   limit of 128 in the function?  If so, it would be nice to fix that.
>> I was not aware of the existence of the _gnutls_bin2hex function. The
>> fixed buffers in dump_bytes are emptied at the end of each line and
>> their maximum size is bounded by the number of bytes per line (16), so
>> it could in theory print  256^sizeof(size_t) bytes. I will fix
>> gnutls_buffers.c to use _gnutls_bin2hex.
> 
> Great.
> 
>>> * What does the 'bufel' variable name refers to?  It looks non-english
>>>   to me, so I'd prefer using 'buf'.
>> A mbuffer is a chain of buffer elements. I use buf to refer to the whole
>> chain of buffers (mbuffer_head_st) and bufel to refer to a buffer
>> element (mbuffer_st). I don't mind changing the variable names if they
>> really bother you.
> 
> No, that's fine.  I just didn't understand the "buffer element"
> shortening to bufel.  I suggest putting in a short comment at the top of
> gnutls_mbuffers.c about this in case others wonder.
> 
>>> * Some comments at the top of gnutls_mbuffers.? what it does would be
>>>   good.
>> Sure, I can do that. I was planning on adding those comments later on
>> anyway.
> 
> Please add them and post an updated patch.  I think it is close to being
> pushed.

Expect something soon on that end. I will notify you when I update my 
buffers branch with something viable.

> Btw, do you expect more changes to the buffer handling for DTLS?  I'm
> thinking that maybe we should release GnuTLS 2.10.0 once the TLS 1.2
> support is working, which may happen soon, and I'm not sure how many of
> these patches makes sense in a GnuTLS 2.10.0 that wouldn't support DTLS.
> Of course, if you can finish DTLS support, that would be great, but I
> think complete TLS 1.2 is important enough to warrant a new stable
> release in the near future.

Yes, there are more changes on the way, there is still the read() path 
that needs a whole lot of cleaning (with industrial grade bleach). The 
clean buffers interface is much nicer regardless of whether DTLS is 
there or not. The library user will of course see no change in the API 
with the brand new buffers. In other words the new buffers and DTLS are 
pretty much independent and can be merged in two steps with no problem 
at all.

> /Simon

Take care,
Jonathan