From nmav at gnutls.org  Thu May  1 10:17:47 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 01 May 2008 11:17:47 +0300
Subject: Camellia block cipher don't work on current developers' releases
 2.3.x.
In-Reply-To: <4816E809.6030108@csg.is.titech.ac.jp>
References: <4816E809.6030108@csg.is.titech.ac.jp>
Message-ID: <48197CAB.50105@gnutls.org>

Yoshisato YANAGISAWA wrote:
> Hello,
> 
> I noticed two problems that prevent camellia block cipher working.
> One problem is that it becomes invalid cipher even with camellia-enabled
> gnutls.  To repeat the problem, just you execute gnutls-cli with:
> % gnutls-cli --ciphers camellia -p 5556 test.gnutls.org
> You will see following error:
> | *** Fatal error: GnuTLS internal error.
> | *** Handshake has failed
> | GNUTLS ERROR: GnuTLS internal error.
> It is cauesd by a bug in lgl/gc-libgcrypt.c.
> 
> I put the patch to fix the problem:
> https://savannah.gnu.org/support/index.php?106314

Thank you for the patch. I've just applied it.

> The other problem is that camellia block cipher is disabled by configure
> script even if the user using libgcrypt with camellia block cipher and
> configured with --enable-camellia option.  You can repeat the problem by
> installing libgcrypt to no default directory such as /tmp/test, and then
> pointing the directory with --with-libgcrypt-prefix=/tmp/test as option
> of the configure script.

This is quite strange. As I see the configure file does:
test -n "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"
to check for camellia. Was the correct libgcrypt detected by the
configure script?

regards,
Nikos




From ametzler at downhill.at.eu.org  Thu May  1 15:02:32 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 1 May 2008 15:02:32 +0200
Subject: Handshake fails with Internal error in memory allocation
In-Reply-To: <874p9ld4a7.fsf@mocca.josefsson.org>
References: <874p9ld4a7.fsf@mocca.josefsson.org>
Message-ID: <20080501130232.GD3468@downhill.g.la>

On 2008-04-29 Simon Josefsson <simon at josefsson.org> wrote:
> This error has come up lately, see:

> http://bugs.debian.org/466477
> http://bugs.debian.org/478191

> The cause seems clear, the server sends a huge list of CA certs and
> GnuTLS runs into some fixed size buffer or something.  This reproduces
> it:

> gnutls-cli -p 25 -s mail3.mclemente.net
> ehlo foo
> starttls
> ^D

> Nikos, do you have any idea?  I could look at it, but have little time
> right now.

Hello,

isn't it a bug that gnutls *sends* this huge list of certificates in
the first place? (Noted by Florian Weimer)?

I think this is rather strange:

Start with this setup:
  - Server is using a self signed certificate and key.
  - Client is not using any certificate at all.

This works ...
*server* gnutls-serv --port 666 --x509certfile /etc/exim4/exim.crt \
    --x509keyfile /etc/exim4/exim.key
*client* gnutls-cli localhost -p 666

... but this suddenly doesn't (with
the old #define MAX_HANDSHAKE_PACKET_SIZE 16*1024):
*server*  gnutls-serv --port 666 --x509certfile /etc/exim4/exim.crt \
    --x509keyfile /etc/exim4/exim.key \
    --x509cafile /etc/ssl/certs/ca-certificates.crt
*client* gnutls-cli localhost -p 666

I do not understand why specifying a list of irrelevant trusted CAs
changes the the TLS dialogue at all. Afaict this is not the case for
openssl, this won't break gnutls:
 openssl s_server -accept 666 -cert /etc/exim4/exim.crt
   -key  /etc/exim4/exim.key -CAfile /etc/ssl/certs/ca-certificates.crt 

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'




From nmav at gnutls.org  Thu May  1 16:15:56 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 01 May 2008 17:15:56 +0300
Subject: Handshake fails with Internal error in memory allocation
In-Reply-To: <20080501130232.GD3468@downhill.g.la>
References: <874p9ld4a7.fsf@mocca.josefsson.org>
	<20080501130232.GD3468@downhill.g.la>
Message-ID: <4819D09C.7090207@gnutls.org>

Andreas Metzler wrote:
> On 2008-04-29 Simon Josefsson <simon at josefsson.org> wrote:
>> This error has come up lately, see:
> 
>> http://bugs.debian.org/466477
>> http://bugs.debian.org/478191
> 
>> The cause seems clear, the server sends a huge list of CA certs and
>> GnuTLS runs into some fixed size buffer or something.  This reproduces
>> it:
> 
>> gnutls-cli -p 25 -s mail3.mclemente.net
>> ehlo foo
>> starttls
>> ^D
>> Nikos, do you have any idea?  I could look at it, but have little time
>> right now.
> Hello,
> 
> isn't it a bug that gnutls *sends* this huge list of certificates in
> the first place? (Noted by Florian Weimer)?

Not really. In the TLS handshake, when the server requests a certificate
from the client, it has to indicate which CAs he trusts so the client
can send an appropriate certificate.

> I think this is rather strange:
> 
> Start with this setup:
>   - Server is using a self signed certificate and key.
>   - Client is not using any certificate at all.
> 
> This works ...
> *server* gnutls-serv --port 666 --x509certfile /etc/exim4/exim.crt \
>     --x509keyfile /etc/exim4/exim.key
> *client* gnutls-cli localhost -p 666

This is a case where the server (since no --x509cafile is specified)
does not advertize the CA certificates that he trusts.

> ... but this suddenly doesn't (with
> the old #define MAX_HANDSHAKE_PACKET_SIZE 16*1024):
> *server*  gnutls-serv --port 666 --x509certfile /etc/exim4/exim.crt \
>     --x509keyfile /etc/exim4/exim.key \
>     --x509cafile /etc/ssl/certs/ca-certificates.crt
> *client* gnutls-cli localhost -p 666

In this case the server trusts as many certificates as they are in
ca-certificates.crt. Thus the advertisement is quite long.

> I do not understand why specifying a list of irrelevant trusted CAs
> changes the the TLS dialogue at all. Afaict this is not the case for
> openssl, this won't break gnutls:
>  openssl s_server -accept 666 -cert /etc/exim4/exim.crt
>    -key  /etc/exim4/exim.key -CAfile /etc/ssl/certs/ca-certificates.crt 

gnutls has a maximum size for handshake message, which overflowed with
this long CA list (could be unlimited but is set to a specific value to
avoid possible denial of service). As far as I know this limit was
increased in the latest gnutls.

A server that trusts quite many CAs might use:
gnutls_certificate_free_ca_names(), to avoid sending all of the to the
client. In that case it might be desirable to do so, since the
information that they provide to the client is not really much.

regards,
Nikos






From simon at josefsson.org  Thu May  1 22:32:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 01 May 2008 22:32:29 +0200
Subject: Handshake fails with Internal error in memory allocation
In-Reply-To: <20080501130232.GD3468@downhill.g.la> (Andreas Metzler's message
	of "Thu, 1 May 2008 15:02:32 +0200")
References: <874p9ld4a7.fsf@mocca.josefsson.org>
	<20080501130232.GD3468@downhill.g.la>
Message-ID: <87bq3ppxya.fsf@mocca.josefsson.org>

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

> ... but this suddenly doesn't (with
> the old #define MAX_HANDSHAKE_PACKET_SIZE 16*1024):
> *server*  gnutls-serv --port 666 --x509certfile /etc/exim4/exim.crt \
>     --x509keyfile /etc/exim4/exim.key \
>     --x509cafile /etc/ssl/certs/ca-certificates.crt
> *client* gnutls-cli localhost -p 666
>
> I do not understand why specifying a list of irrelevant trusted CAs
> changes the the TLS dialogue at all.

It does change the TLS dialogue.

The problem may be that /etc/ssl/certs/ca-certificates.crt contains a
lot of CA certificates.  A setting of trusting all CAs shipped with
debian seems rather weird to me, I'd expect the default to be to not
trust any CA and that administrators can selectively add CAs.

> Afaict this is not the case for openssl, this won't break gnutls:
> openssl s_server -accept 666 -cert /etc/exim4/exim.crt -key
> /etc/exim4/exim.key -CAfile /etc/ssl/certs/ca-certificates.crt

But does openssl request a client certificate?  The list of CAs isn't
sent otherwise.

/Simon




From simon at josefsson.org  Thu May  1 22:36:30 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 01 May 2008 22:36:30 +0200
Subject: Camellia block cipher don't work on current developers'
	releases 2.3.x.
In-Reply-To: <48197CAB.50105@gnutls.org> (Nikos Mavrogiannopoulos's message of
	"Thu, 01 May 2008 11:17:47 +0300")
References: <4816E809.6030108@csg.is.titech.ac.jp> <48197CAB.50105@gnutls.org>
Message-ID: <877iedpxrl.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Yoshisato YANAGISAWA wrote:
>> Hello,
>> 
>> I noticed two problems that prevent camellia block cipher working.
>> One problem is that it becomes invalid cipher even with camellia-enabled
>> gnutls.  To repeat the problem, just you execute gnutls-cli with:
>> % gnutls-cli --ciphers camellia -p 5556 test.gnutls.org
>> You will see following error:
>> | *** Fatal error: GnuTLS internal error.
>> | *** Handshake has failed
>> | GNUTLS ERROR: GnuTLS internal error.
>> It is cauesd by a bug in lgl/gc-libgcrypt.c.
>> 
>> I put the patch to fix the problem:
>> https://savannah.gnu.org/support/index.php?106314
>
> Thank you for the patch. I've just applied it.

Btw, to improve the chances that Camellia will work in all future
releases, it can be a good idea to provide a self-test of this
functionality, to be run by 'make check'.  We never release anything
that fails a 'make check' self-test.

/Simon




From Brian.Cameron at Sun.COM  Thu May  1 22:58:06 2008
From: Brian.Cameron at Sun.COM (Brian Cameron)
Date: Thu, 01 May 2008 15:58:06 -0500
Subject: Problem building GnuTLS 2.2.2 on Solaris
Message-ID: <481A2EDE.1000402@sun.com>


To build on Solaris, it is necessary for the includes/gnutls/gnutlsxx.h 
file to add the following includes:

#include <stdio.h>
#include <string.h>

I am attaching a patch to add these, can this go upstream?

Thanks,

Brian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls-03-includes.diff
URL: </pipermail/attachments/20080501/8a4eef4d/attachment.asc>

From simon at josefsson.org  Fri May  2 11:55:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 02 May 2008 11:55:50 +0200
Subject: Problem building GnuTLS 2.2.2 on Solaris
In-Reply-To: <481A2EDE.1000402@sun.com> (Brian Cameron's message of "Thu, 01
	May 2008 15:58:06 -0500")
References: <481A2EDE.1000402@sun.com>
Message-ID: <87bq3pni6x.fsf@mocca.josefsson.org>

Brian Cameron <Brian.Cameron at Sun.COM> writes:

> To build on Solaris, it is necessary for the
> includes/gnutls/gnutlsxx.h file to add the following includes:
>
> #include <stdio.h>
> #include <string.h>
>
> I am attaching a patch to add these, can this go upstream?

Yes, I think we can solve this for the upcoming gnutls 2.2.3.

However, what error message do you get?

I thought stdio.h + string.h wasn't typically needed for C++.  Possibly
there is some other header file we should include instead.

Thanks,
Simon

> Thanks,
>
> Brian
> --- gnutls-2.2.2/includes/gnutls/gnutlsxx.h.old	2008-04-16 09:46:56.220441725 -0400
> +++ gnutls-2.2.2/includes/gnutls/gnutlsxx.h	2008-04-16 09:46:47.120145257 -0400
> @@ -1,6 +1,8 @@
>  #ifndef GNUTLSXX_H
>  # define GNUTLSXX_H
>  
> +#include <stdio.h>
> +#include <string.h>
>  #include <exception>
>  #include <vector>
>  #include <gnutls/gnutls.h>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From ametzler at downhill.at.eu.org  Fri May  2 11:56:58 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 2 May 2008 11:56:58 +0200
Subject: Handshake fails with Internal error in memory allocation
In-Reply-To: <87bq3ppxya.fsf@mocca.josefsson.org>
References: <874p9ld4a7.fsf@mocca.josefsson.org>
	<20080501130232.GD3468@downhill.g.la>
	<87bq3ppxya.fsf@mocca.josefsson.org>
Message-ID: <20080502095658.GA3056@downhill.g.la>

On 2008-05-01 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > Afaict this is not the case for openssl, this won't break gnutls:
> > openssl s_server -accept 666 -cert /etc/exim4/exim.crt -key
> > /etc/exim4/exim.key -CAfile /etc/ssl/certs/ca-certificates.crt

> But does openssl request a client certificate? 

I think so. Quoting gnutls-cli -d 10:

|<3>| HSK[8073c68]: CERTIFICATE REQUEST was received [9 bytes]

> The list of CAs isn't sent otherwise.

openssl s_server does not seem to send the list, gnutls-cli -d 10
output does not differ signficantly whether openssl s_server runs with 
or without -CAfile /etc/ssl/certs/ca-certificates.crt.

Thank's for the earlier explanations.
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 yanagisawa at csg.is.titech.ac.jp  Fri May  2 17:03:32 2008
From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA)
Date: Sat, 03 May 2008 00:03:32 +0900
Subject: Camellia block cipher don't work on current developers' releases
 2.3.x.
In-Reply-To: <48197CAB.50105@gnutls.org>
References: <4816E809.6030108@csg.is.titech.ac.jp> <48197CAB.50105@gnutls.org>
Message-ID: <481B2D44.7030005@csg.is.titech.ac.jp>

Nikos Mavrogiannopoulos wrote:
>> I put the patch to fix the problem:
>> https://savannah.gnu.org/support/index.php?106314
> 
> Thank you for the patch. I've just applied it.

Thank you.

>> The other problem is that camellia block cipher is disabled by configure
>> script even if the user using libgcrypt with camellia block cipher and
>> configured with --enable-camellia option.  You can repeat the problem by
>> installing libgcrypt to no default directory such as /tmp/test, and then
>> pointing the directory with --with-libgcrypt-prefix=/tmp/test as option
>> of the configure script.
> 
> This is quite strange. As I see the configure file does:
> test -n "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"
> to check for camellia. Was the correct libgcrypt detected by the
> configure script?

Not only this statements detects camellia block cipher but also m4
script in lgl/m4.  As far as I tested, gc-camellia.m4 in lgl/m4 also
affect enabling or disabling Camellia block cipher.  It try to compile
camellia block cipher in libgcrypt to decide whether to use camellia or
not.  Some part of this m4 script is also included in configure script like:
	cat >conftest.$ac_ext <<_ACEOF
/*confdefs.h. */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
/* end confdefs.h. */
#include <gcrypt.h>
int
main()
{
return gcry_cipher_open (NULL, GCRY_CIPHER_CAMELLIA128, 0, 0);
 ;
 return 0;
}
_ACEOF
....
Here the option of compiler defined by "ac_compile" does not have cflags
for libgcrypt and it fails to compile if libgcrypt is installed in no
default position such as /tmp/test.
Also notice that for testing, I just removed libgcrypt package, which
install libgcrypt into default directory and libgcrypt-config in
/tmp/test should be selected.

I think we should collect ac_compile in configure script somehow or just
change cflags given here.

Thank you in advance,
Yoshisato Yanagisawa.

-- 
Yoshisato Yanagisawa (Dr.Sc.) <yanagisawa at csg.is.titech.ac.jp>




From wk at gnupg.org  Fri May  2 20:19:37 2008
From: wk at gnupg.org (Werner Koch)
Date: Fri, 02 May 2008 20:19:37 +0200
Subject: Camellia block cipher don't work on current developers'
	releases 2.3.x.
In-Reply-To: <481B2D44.7030005@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's
	message of "Sat, 03 May 2008 00:03:32 +0900")
References: <4816E809.6030108@csg.is.titech.ac.jp> <48197CAB.50105@gnutls.org>
	<481B2D44.7030005@csg.is.titech.ac.jp>
Message-ID: <871w4ko9fq.fsf@wheatstone.g10code.de>

On Fri,  2 May 2008 17:03, yanagisawa at csg.is.titech.ac.jp said:

> Not only this statements detects camellia block cipher but also m4
> script in lgl/m4.  As far as I tested, gc-camellia.m4 in lgl/m4 also

Wouldn't it be easier to just drop these extra tests and require
libgcrypt 1.4.0?  There are no plans to ever drop Camellia from
libgcrypt.

The only case where it would not be available are builds for embedded
platforms with explicitly disabled support for some algorithms.  The
first test should catch this case.


Shalom-Salam,

   Werner


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





From nmav at gnutls.org  Sat May  3 17:39:05 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 03 May 2008 18:39:05 +0300
Subject: updates in mpi
Message-ID: <481C8719.40103@gnutls.org>

I've pushed into git the gnutls_with_ext_mpi branch. In this branch the
mpi (bigint) operations were moved to:
1. Internal API: gnutls_mpi.h -> gnutls_mpi.c
2. Backend: mpi-libgcrypt.c

the public key crypto ops to:
1. Internal API: gnutls_pk.h -> gnutls_pk.c
2. Backend: pk-libgcrypt.c

It is not fully workable yet.

regards,
Nikos




From ametzler at downhill.at.eu.org  Sun May  4 14:00:23 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 4 May 2008 14:00:23 +0200
Subject: [Patch] Non-permissive subjectAltName wildcard
In-Reply-To: <200805031449.58289.giga@le-pec.org>
References: <200805031449.58289.giga@le-pec.org>
Message-ID: <20080504120023.GB3238@downhill.g.la>


Hello,

this http://bugs.debian.org/479174 reported by Jean-Philippe Garcia
Ballester:

On 2008-05-03 Jean-Philippe Garcia Ballester <giga at le-pec.org> wrote:
> It seems too me that the subjectAltName wildcard matching has strong 
> constraints.

> First, it allows only one wildcard. Since a wildcard can only match
> a single domain component, multiple wildcards are useful (e.g.,
> *.*.example.org). I did not see in the rfc 2818 such restriction.

> Second, it only allows the wildcard to be at the beginning of the
> hostname.  Since the rfc 2818 gives ?f*.com? as an example, I
> believe this is a false assert.

> Third, it only allows the wildcard to be followed by a ?.?. This is
> not clearly stated in the rfc, but I believe it is reasonnable to
> assume that if ?f*.com? is allowed, then ?f*o.com? should be allowed
> as well.

> The attached patch fixes all these issues and add some tests.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls26-2.2.3~rc_subject_alt_name_permissive_wildcard.patch
Type: text/x-diff
Size: 13307 bytes
Desc: not available
URL: </pipermail/attachments/20080504/2cda47bd/attachment.patch>

From nmav at gnutls.org  Sun May  4 15:40:10 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 04 May 2008 16:40:10 +0300
Subject: updates in mpi
In-Reply-To: <481C8719.40103@gnutls.org>
References: <481C8719.40103@gnutls.org>
Message-ID: <481DBCBA.3050502@gnutls.org>

Nikos Mavrogiannopoulos wrote:
> I've pushed into git the gnutls_with_ext_mpi branch. In this branch the
> mpi (bigint) operations were moved to:
> 1. Internal API: gnutls_mpi.h -> gnutls_mpi.c
> 2. Backend: mpi-libgcrypt.c
> 
> the public key crypto ops to:
> 1. Internal API: gnutls_pk.h -> gnutls_pk.c
> 2. Backend: pk-libgcrypt.c
> 
> It is not fully workable yet.

I've finally finished it. The current interface in crypto.h allows
(1) to register specific ciphers (when a hw engine is present for some
cipher) at runtime, (2) to replace the whole engine for
cipher/mac/digest/bigint/public key both at runtime and compile time[0].

Currently what is left to be done is to rewrite opencdk to use the
gnutls internal api for accessing ciphers/mac/pk and write a test case
for _pkcs12_string_to_key() which was modified but not tested since then.


[0]. for compile time replacement check the *-libgcrypt.c files. Only
those need to be replaced.

regards,
Nikos




From nmav at gnutls.org  Sun May  4 15:48:40 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 04 May 2008 16:48:40 +0300
Subject: [Patch] Non-permissive subjectAltName wildcard
In-Reply-To: <20080504120023.GB3238@downhill.g.la>
References: <200805031449.58289.giga@le-pec.org>
	<20080504120023.GB3238@downhill.g.la>
Message-ID: <481DBEB8.7090704@gnutls.org>

Andreas Metzler wrote:
> Hello,
> 
> this http://bugs.debian.org/479174 reported by Jean-Philippe Garcia
> Ballester:
> 
> On 2008-05-03 Jean-Philippe Garcia Ballester <giga at le-pec.org> wrote:
>> It seems too me that the subjectAltName wildcard matching has strong 
>> constraints.
> 
>> First, it allows only one wildcard. Since a wildcard can only match
>> a single domain component, multiple wildcards are useful (e.g.,
>> *.*.example.org). I did not see in the rfc 2818 such restriction.

Thank you for the patch. I need some clarifications before including it
though. Having such as permissive wildcard is quite dangerous. Why would
one specify *.*.example.org instead of the much simpler *.example.org?

>> Second, it only allows the wildcard to be at the beginning of the
>> hostname.  Since the rfc 2818 gives ?f*.com? as an example, I
>> believe this is a false assert.

f*.com is not a good example :) I don't think that such a wildcard
certificate has a real world usage, and if any CA signs it would be at
error. Of course this applies to *.com as well...

Probably your point is for wildcards such as test*.gnutls.org?

>> Third, it only allows the wildcard to be followed by a ?.?. This is
>> not clearly stated in the rfc, but I believe it is reasonnable to
>> assume that if ?f*.com? is allowed, then ?f*o.com? should be allowed
>> as well.

What is your use case that does not work by the current simple wildcard?

regards,
Nikos




From dkg-debian.org at fifthhorseman.net  Mon May  5 00:43:14 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 04 May 2008 18:43:14 -0400
Subject: [Patch] Non-permissive subjectAltName wildcard
In-Reply-To: <481DBEB8.7090704@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun\, 04 May 2008 16\:48\:40 +0300")
References: <200805031449.58289.giga@le-pec.org>
	<20080504120023.GB3238@downhill.g.la> <481DBEB8.7090704@gnutls.org>
Message-ID: <87ve1tu1vh.fsf@squeak.fifthhorseman.net>

On Sun 2008-05-04 09:48:40 -0400, Nikos Mavrogiannopoulos wrote:

> Thank you for the patch. I need some clarifications before including
> it though. Having such as permissive wildcard is quite
> dangerous. Why would one specify *.*.example.org instead of the much
> simpler *.example.org?

foo.example.org matches the latter, but not the former.  If you wanted
to allow a server to match any four (or more?) segment domain ending
in example.org, but *not* any three-segment domain, you might prefer
the former.

> f*.com is not a good example :) I don't think that such a wildcard
> certificate has a real world usage, and if any CA signs it would be at
> error. Of course this applies to *.com as well...
>
> Probably your point is for wildcards such as test*.gnutls.org?

I agree with Nikos, this is a much better example!

>>> Third, it only allows the wildcard to be followed by a ?.?. This is
>>> not clearly stated in the rfc, but I believe it is reasonnable to
>>> assume that if ?f*.com? is allowed, then ?f*o.com? should be allowed
>>> as well.
>
> What is your use case that does not work by the current simple wildcard?

One example that might be useful would be:

 *dev.example.org

(by analogy with your test*.gnutls.org)

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080504/ce0ee1ac/attachment.pgp>

From giga at le-pec.org  Sun May  4 21:12:29 2008
From: giga at le-pec.org (Jean-Philippe Garcia Ballester)
Date: Sun, 4 May 2008 21:12:29 +0200
Subject: [Patch] Non-permissive subjectAltName wildcard
In-Reply-To: <481DBEB8.7090704@gnutls.org>
References: <200805031449.58289.giga@le-pec.org>
	<20080504120023.GB3238@downhill.g.la> <481DBEB8.7090704@gnutls.org>
Message-ID: <200805042112.39729.giga@le-pec.org>

On Sunday 04 May 2008, Nikos Mavrogiannopoulos wrote:
> Andreas Metzler wrote:
> > Hello,

  Hello,
  First, thanks for replying that quickly :)

> > this http://bugs.debian.org/479174 reported by Jean-Philippe Garcia
> > Ballester:
> >
> > On 2008-05-03 Jean-Philippe Garcia Ballester <giga at le-pec.org> wrote:
> >> It seems too me that the subjectAltName wildcard matching has strong
> >> constraints.
> >>
> >> First, it allows only one wildcard. Since a wildcard can only match
> >> a single domain component, multiple wildcards are useful (e.g.,
> >> *.*.example.org). I did not see in the rfc 2818 such restriction.
>
> Thank you for the patch. I need some clarifications before including it
> though. Having such as permissive wildcard is quite dangerous. Why would
> one specify *.*.example.org instead of the much simpler *.example.org?

  Because *.example.org does not match www.intranet.example.org, according to 
the RFC (and the current implementation).
  Of course, listing all the subdomains can be done, but the wildcard was 
introduced specifically to avoid re-issuing a new certificate each time a new 
sub-domain is used.

> >> Second, it only allows the wildcard to be at the beginning of the
> >> hostname.  Since the rfc 2818 gives ?f*.com? as an example, I
> >> believe this is a false assert.
>
> f*.com is not a good example :) I don't think that such a wildcard
> certificate has a real world usage, and if any CA signs it would be at
> error. Of course this applies to *.com as well...

  Obviously, but as you say, I believe it is the CA's job not to sign such a 
certificate, not the library's job.

> Probably your point is for wildcards such as test*.gnutls.org?

  The truth is that the real problem was the first thing above. While fixing 
this issue, I read the RFC and found the two others ?problems?.
  I do not a have a ?real world? example, since I don't have any use for this. 
I just thought that if the RFC allows it, then the software should.
  Maybe it could be of use for self-signed certificates used in private 
intranets.

> >> Third, it only allows the wildcard to be followed by a ?.?. This is
> >> not clearly stated in the rfc, but I believe it is reasonnable to
> >> assume that if ?f*.com? is allowed, then ?f*o.com? should be allowed
> >> as well.
>
> What is your use case that does not work by the current simple wildcard?

  Again, none. But I believe there are people in this world bizarre enough to 
have a use case for this. For example, people using suffix instead of 
sub-domain, e.g. ?www-intranet.example.org? (though I do not see any reason 
for doing so, maybe some people do).

  If you do not want to fix these issues, which I would totally understand 
because of my lack of arguments, please at least document it somewhere.
  It took me a while to figure out where the problem was, because I usually 
make the assumption that softwares correctly implement RFC (which might be a 
big mistake ;) ).

  Regards,

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

From nmav at gnutls.org  Mon May  5 07:19:06 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 05 May 2008 08:19:06 +0300
Subject: [Patch] Non-permissive subjectAltName wildcard
In-Reply-To: <200805042112.39729.giga@le-pec.org>
References: <200805031449.58289.giga@le-pec.org>
	<20080504120023.GB3238@downhill.g.la> <481DBEB8.7090704@gnutls.org>
	<200805042112.39729.giga@le-pec.org>
Message-ID: <481E98CA.90007@gnutls.org>

Jean-Philippe Garcia Ballester wrote:

>> Probably your point is for wildcards such as test*.gnutls.org?
> 
>   The truth is that the real problem was the first thing above. While fixing 
> this issue, I read the RFC and found the two others ?problems?.
>   I do not a have a ?real world? example, since I don't have any use for this. 
> I just thought that if the RFC allows it, then the software should.
>   Maybe it could be of use for self-signed certificates used in private 
> intranets.

I'm quite convinced and like this patch. I'll check the code and will
include it on the development branch I'm working on as soon.

regards,
Nikos




From simon at josefsson.org  Mon May  5 13:37:06 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 05 May 2008 13:37:06 +0200
Subject: Problem building GnuTLS 2.2.2 on Solaris
In-Reply-To: <87bq3pni6x.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 02 May 2008 11:55:50 +0200")
References: <481A2EDE.1000402@sun.com> <87bq3pni6x.fsf@mocca.josefsson.org>
Message-ID: <87od7lyobh.fsf@mocca.josefsson.org>

Hi Brian,

I'm about to release 2.2.2 this week, so if you want this change to make
it, we need the answers to the questions below.

Besides, any C++ programmers who can confirm that it is a good idea to
include C headers like stdio.h and string.h in C++ header files?

/Simon

Simon Josefsson <simon at josefsson.org> writes:

> Brian Cameron <Brian.Cameron at Sun.COM> writes:
>
>> To build on Solaris, it is necessary for the
>> includes/gnutls/gnutlsxx.h file to add the following includes:
>>
>> #include <stdio.h>
>> #include <string.h>
>>
>> I am attaching a patch to add these, can this go upstream?
>
> Yes, I think we can solve this for the upcoming gnutls 2.2.3.
>
> However, what error message do you get?
>
> I thought stdio.h + string.h wasn't typically needed for C++.  Possibly
> there is some other header file we should include instead.
>
> Thanks,
> Simon
>
>> Thanks,
>>
>> Brian
>> --- gnutls-2.2.2/includes/gnutls/gnutlsxx.h.old	2008-04-16 09:46:56.220441725 -0400
>> +++ gnutls-2.2.2/includes/gnutls/gnutlsxx.h	2008-04-16 09:46:47.120145257 -0400
>> @@ -1,6 +1,8 @@
>>  #ifndef GNUTLSXX_H
>>  # define GNUTLSXX_H
>>  
>> +#include <stdio.h>
>> +#include <string.h>
>>  #include <exception>
>>  #include <vector>
>>  #include <gnutls/gnutls.h>
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From andrew.w.nosenko at gmail.com  Mon May  5 14:48:28 2008
From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko)
Date: Mon, 5 May 2008 15:48:28 +0300
Subject: Problem building GnuTLS 2.2.2 on Solaris
In-Reply-To: <87od7lyobh.fsf@mocca.josefsson.org>
References: <481A2EDE.1000402@sun.com> <87bq3pni6x.fsf@mocca.josefsson.org>
	<87od7lyobh.fsf@mocca.josefsson.org>
Message-ID: <6161f3180805050548q1540a85fudab9d8b3cc7afc9d@mail.gmail.com>

On Mon, May 5, 2008 at 2:37 PM, Simon Josefsson <simon at josefsson.org> wrote:
>  Besides, any C++ programmers who can confirm that it is a good idea to
>  include C headers like stdio.h and string.h in C++ header files?

I would to recommend to include <cstdio> and <cstring> instead
(standard c++'ish counterpart for stdio.h and string.h).  But exact
answer depends on the given error.  May be there indeed need "raw"
C-header (very unlikely, but...)

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>




From simon at josefsson.org  Mon May  5 15:49:10 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 05 May 2008 15:49:10 +0200
Subject: Problem building GnuTLS 2.2.2 on Solaris
In-Reply-To: <6161f3180805050548q1540a85fudab9d8b3cc7afc9d@mail.gmail.com>
	(Andrew W. Nosenko's message of "Mon, 5 May 2008 15:48:28 +0300")
References: <481A2EDE.1000402@sun.com> <87bq3pni6x.fsf@mocca.josefsson.org>
	<87od7lyobh.fsf@mocca.josefsson.org>
	<6161f3180805050548q1540a85fudab9d8b3cc7afc9d@mail.gmail.com>
Message-ID: <8763ts7tex.fsf@mocca.josefsson.org>

"Andrew W. Nosenko" <andrew.w.nosenko at gmail.com> writes:

> On Mon, May 5, 2008 at 2:37 PM, Simon Josefsson <simon at josefsson.org> wrote:
>>  Besides, any C++ programmers who can confirm that it is a good idea to
>>  include C headers like stdio.h and string.h in C++ header files?
>
> I would to recommend to include <cstdio> and <cstring> instead
> (standard c++'ish counterpart for stdio.h and string.h).  But exact
> answer depends on the given error.  May be there indeed need "raw"
> C-header (very unlikely, but...)

Ok, thanks, that's what I thought as well.  We'll wait for the error
messages, to understand exactly what the problem is.

/Simon




From Brian.Cameron at Sun.COM  Mon May  5 21:17:24 2008
From: Brian.Cameron at Sun.COM (Brian Cameron)
Date: Mon, 05 May 2008 14:17:24 -0500
Subject: Problem building GnuTLS 2.2.2 on Solaris
In-Reply-To: <87bq3pni6x.fsf@mocca.josefsson.org>
References: <481A2EDE.1000402@sun.com> <87bq3pni6x.fsf@mocca.josefsson.org>
Message-ID: <481F5D44.7050703@sun.com>


Simon:

In further review, we have discovered that we do not need the patch
I provided to build GnuTLS 2.2.2 on Solaris.  The problems we were
seeing were actually caused by a broken build system.  This patch
was a workaround for the way our build system was broken.  After
fixing our build system, we see the patch is not needed.

Sorry for the noise, and thanks for asking us to follow up and
catch this.

Brian


> Brian Cameron <Brian.Cameron at Sun.COM> writes:
> 
>> To build on Solaris, it is necessary for the
>> includes/gnutls/gnutlsxx.h file to add the following includes:
>>
>> #include <stdio.h>
>> #include <string.h>
>>
>> I am attaching a patch to add these, can this go upstream?
> 
> Yes, I think we can solve this for the upcoming gnutls 2.2.3.
> 
> However, what error message do you get?
> 
> I thought stdio.h + string.h wasn't typically needed for C++.  Possibly
> there is some other header file we should include instead.
> 
> Thanks,
> Simon
> 
>> Thanks,
>>
>> Brian
>> --- gnutls-2.2.2/includes/gnutls/gnutlsxx.h.old	2008-04-16 09:46:56.220441725 -0400
>> +++ gnutls-2.2.2/includes/gnutls/gnutlsxx.h	2008-04-16 09:46:47.120145257 -0400
>> @@ -1,6 +1,8 @@
>>  #ifndef GNUTLSXX_H
>>  # define GNUTLSXX_H
>>  
>> +#include <stdio.h>
>> +#include <string.h>
>>  #include <exception>
>>  #include <vector>
>>  #include <gnutls/gnutls.h>
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel





From simon at josefsson.org  Tue May  6 12:37:55 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 May 2008 12:37:55 +0200
Subject: Problem building GnuTLS 2.2.2 on Solaris
In-Reply-To: <481F5D44.7050703@sun.com> (Brian Cameron's message of "Mon, 05
	May 2008 14:17:24 -0500")
References: <481A2EDE.1000402@sun.com> <87bq3pni6x.fsf@mocca.josefsson.org>
	<481F5D44.7050703@sun.com>
Message-ID: <874p9blnuk.fsf@mocca.josefsson.org>

Thanks for following up.  I think we are ready for 2.2.3 now, so I'll do
some final QA and then release it.

Thanks,
Simon

Brian Cameron <Brian.Cameron at Sun.COM> writes:

> Simon:
>
> In further review, we have discovered that we do not need the patch
> I provided to build GnuTLS 2.2.2 on Solaris.  The problems we were
> seeing were actually caused by a broken build system.  This patch
> was a workaround for the way our build system was broken.  After
> fixing our build system, we see the patch is not needed.
>
> Sorry for the noise, and thanks for asking us to follow up and
> catch this.
>
> Brian
>
>
>> Brian Cameron <Brian.Cameron at Sun.COM> writes:
>>
>>> To build on Solaris, it is necessary for the
>>> includes/gnutls/gnutlsxx.h file to add the following includes:
>>>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>> I am attaching a patch to add these, can this go upstream?
>>
>> Yes, I think we can solve this for the upcoming gnutls 2.2.3.
>>
>> However, what error message do you get?
>>
>> I thought stdio.h + string.h wasn't typically needed for C++.  Possibly
>> there is some other header file we should include instead.
>>
>> Thanks,
>> Simon
>>
>>> Thanks,
>>>
>>> Brian
>>> --- gnutls-2.2.2/includes/gnutls/gnutlsxx.h.old	2008-04-16 09:46:56.220441725 -0400
>>> +++ gnutls-2.2.2/includes/gnutls/gnutlsxx.h	2008-04-16 09:46:47.120145257 -0400
>>> @@ -1,6 +1,8 @@
>>>  #ifndef GNUTLSXX_H
>>>  # define GNUTLSXX_H
>>>  +#include <stdio.h>
>>> +#include <string.h>
>>>  #include <exception>
>>>  #include <vector>
>>>  #include <gnutls/gnutls.h>
>>> _______________________________________________
>>> Gnutls-devel mailing list
>>> Gnutls-devel at gnu.org
>>> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From simon at josefsson.org  Tue May  6 12:56:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 May 2008 12:56:29 +0200
Subject: Camellia block cipher don't work on current developers'
	releases 2.3.x.
In-Reply-To: <481B2D44.7030005@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's
	message of "Sat, 03 May 2008 00:03:32 +0900")
References: <4816E809.6030108@csg.is.titech.ac.jp> <48197CAB.50105@gnutls.org>
	<481B2D44.7030005@csg.is.titech.ac.jp>
Message-ID: <87zlr3k8f6.fsf@mocca.josefsson.org>

Yoshisato YANAGISAWA <yanagisawa at csg.is.titech.ac.jp> writes:

>>> The other problem is that camellia block cipher is disabled by configure
>>> script even if the user using libgcrypt with camellia block cipher and
>>> configured with --enable-camellia option.  You can repeat the problem by
>>> installing libgcrypt to no default directory such as /tmp/test, and then
>>> pointing the directory with --with-libgcrypt-prefix=/tmp/test as option
>>> of the configure script.
>> 
>> This is quite strange. As I see the configure file does:
>> test -n "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"
>> to check for camellia. Was the correct libgcrypt detected by the
>> configure script?
>
> Not only this statements detects camellia block cipher but also m4
> script in lgl/m4.  As far as I tested, gc-camellia.m4 in lgl/m4 also
> affect enabling or disabling Camellia block cipher.

How does it affect that?  With your patch now applied, I don't think the
gc-camellia.m4 test changes anything for how gnutls behaves.  In other
words, even if the gc-camellia.m4 test fails, camellia should still work
in gnutls.

Thanks,
Simon




From simon at josefsson.org  Tue May  6 14:40:59 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 May 2008 14:40:59 +0200
Subject: GnuTLS 2.2.3
Message-ID: <87abj361wk.fsf@mocca.josefsson.org>

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

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

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

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

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

* Version 2.2.3 (released 2008-05-06)

** Increase default handshake packet size limit to 48kb.
The old limit was 16kb and some servers send huge list of trusted CAs,
thus running into the limit.  FYI, applications can further increase
this limit using gnutls_handshake_set_max_packet_length.  Thanks to
Marc Haber <mh+debian-bugs at zugschlus.de> and "Marc F. Clemente"
<marc at mclemente.net> for reporting and providing test servers.

** Fix compilation error related to __FUNCTION__ on some systems.
Reported by Tim Mooney, see
<https://savannah.gnu.org/support/?106267>.

** Documented the --priority option to gnutls-cli and gnutls-serv.

** Fix fopen file descriptor leak in PSK server code.
Thanks to Laurence Withers <l at lwithers.me.uk>, see
<http://lists.gnu.org/archive/html/gnutls-devel/2008-04/msg00002.html>.

** Build Guile code with -fgnu89-inline only when supported.
Reported by Kris Karas <ktk at enterprise.bidmc.harvard.edu> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2708>.

** Make Camellia encryption work.
Reported by Yoshisato YANAGISAWA <yanagisawa at csg.is.titech.ac.jp> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2746>.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.3.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.2.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.2.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: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>

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:

285346586fa67c97c8c3d6f8a6bc22a55b188f76  gnutls-2.2.3.tar.bz2

05aad4b90b89fbd3aa22966dc4f08539ba3e579fd0fef9f10c0d32d0  gnutls-2.2.3.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-devel mailing list, see:
<http://lists.gnu.org/mailman/listinfo/gnutls-devel>.

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.2.3.

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

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

A ZIP file with the installed tree of binaries:
  http://josefsson.org/gnutls4win/gnutls-2.2.3.zip (4.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.3.zip.sig

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

e86df96993f5ef6017036c9e7db52992f38abedc  gnutls-2.2.3.exe
0c077a6cd8de514393d8a70d9c9648326277155970c693fc260e50f5  gnutls-2.2.3.exe

aba154fa97b35ea9844dc792f4ec53553e1bccf6  gnutls-2.2.3.zip
035b0a32413dd321f8fde749dfb1383e7962c81c0832bec1d26cbd76  gnutls-2.2.3.zip

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

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

From nmav at gnutls.org  Tue May  6 16:35:15 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 06 May 2008 17:35:15 +0300
Subject: crypto engine
In-Reply-To: <877if29boe.fsf@mocca.josefsson.org>
References: <47F53307.3030002@gnutls.org> <877if29boe.fsf@mocca.josefsson.org>
Message-ID: <48206CA3.6030001@gnutls.org>

Simon Josefsson wrote:

> #1:
> 
>   I think that avoiding struct's in the public API would be a good idea
>   (struct alignment always seem to cause problems on weirder platforms),
>   so how about instead of doing something like this:
> 
> typedef struct gnutls_crypto_rnd {
>   int (*init)( void** ctx);
>   int (*rnd) ( void* ctx, int /* gnutls_rnd_level_t */ level, void* data, int datasize);
>   void (*deinit)( void* ctx);
> } gnutls_crypto_rnd_st;
> 
> int gnutls_crypto_rnd_register( int priority, gnutls_crypto_rnd_st* s);
> 
>   do this instead:
> 
> typedef int (*gnutls_rng_init_func)( void** ctx);
> typedef int (*gnutls_rng_rnd_func) ( void* ctx, gnutls_rnd_level_t level, void* data, int datasize);
> typedef void (*gnutls_rng_deinit_func)( void* ctx);
> 
> int gnutls_crypto_rnd_register( int priority,
>                                 gnutls_rng_init_func init,
>                                 gnutls_rng_rnd_func rnd,
>                                 gnutls_rng_deinit_func deinit);

I'm really thinking doing this. The only bad thing is that because of
the many functions that need to be registered the API would be quite
ugly, but anyway it would allow us to maintain a stable api.


regards,
Nikos




From nmav at gnutls.org  Tue May  6 17:00:46 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 06 May 2008 18:00:46 +0300
Subject: crypto engine
In-Reply-To: <48206CA3.6030001@gnutls.org>
References: <47F53307.3030002@gnutls.org> <877if29boe.fsf@mocca.josefsson.org>
	<48206CA3.6030001@gnutls.org>
Message-ID: <4820729E.1010003@gnutls.org>

Nikos Mavrogiannopoulos wrote:

>>   do this instead:
>>
>> typedef int (*gnutls_rng_init_func)( void** ctx);
>> typedef int (*gnutls_rng_rnd_func) ( void* ctx, gnutls_rnd_level_t level, void* data, int datasize);
>> typedef void (*gnutls_rng_deinit_func)( void* ctx);
>>
>> int gnutls_crypto_rnd_register( int priority,
>>                                 gnutls_rng_init_func init,
>>                                 gnutls_rng_rnd_func rnd,
>>                                 gnutls_rng_deinit_func deinit);
> 
> I'm really thinking doing this. The only bad thing is that because of
> the many functions that need to be registered the API would be quite
> ugly, but anyway it would allow us to maintain a stable api.

And it is seems that the API is quite ugly and cumbersome to use (such
as a function with 24 arguments). I'll keep the current struct based API
but I'll added some versioning information in the registration functions
to avoid modifying a structure with different version.




From simon at josefsson.org  Wed May  7 13:37:47 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 May 2008 13:37:47 +0200
Subject: Suggested addition to the GnuTLS Windows installer
In-Reply-To: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
	(Tor Lillqvist's message of "Wed, 7 May 2008 08:32:50 +0300")
References: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
Message-ID: <87od7il4z8.fsf@mocca.josefsson.org>

Hi,

> It would be useful to include the lib/pkgconfig/gnutls.pc and
> bin/libgcrypt-config files also in the Windows installer of GnuTLS.
> Then the configury of other software ported from Unix that uses GnuTLS
> would work directly also on mingw+MSYS.

Ah, right.  They are in the *.ZIP file, but not installed by the
installer.

> The gnutls.pc you would distribute can be as generated by your build,
> it doesn't matter that the prefix in it points to some folder on your
> build machine that won't exist on the machines where gnutls.pc is
> used. pkg-config on Windows automatically replaces the prefix from the
> .pc file with one deduced from the location of the .pc file anyway, as
> long as the .pc file is in a "normal" location that ends with
> .../lib/pkgconfig.

Ok, I added all files to the binary installer.

> The libgcrypt-config file is a bit more problematic. The one I cooked
> up for myself has this in the beginning:
>
> prefix=`dirname $0`/..
> exec_prefix=${prefix}
> version=1.4.0
> includedir=${prefix}/include
> libdir=${prefix}/lib
> gpg_error_libs=-lgpg-error
> gpg_error_cflags=
>
> I don't know how easy it would be to automatically generate a
> libgcrypt-config file that would look like that, but otherwise use the
> normal @FOO@ Autoconf expansions for version numbers etc.

Patches welcome to achieve this. :) (Against the Makefile distributed at
http://josefsson.org/gnutls4win/ -- it should probably be moved into git
or similar.)

/Simon




From tml at iki.fi  Wed May  7 14:03:03 2008
From: tml at iki.fi (Tor Lillqvist)
Date: Wed, 7 May 2008 15:03:03 +0300
Subject: Suggested addition to the GnuTLS Windows installer
In-Reply-To: <87od7il4z8.fsf@mocca.josefsson.org>
References: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
	<87od7il4z8.fsf@mocca.josefsson.org>
Message-ID: <c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>

> Ah, right.  They are in the *.ZIP file, but not installed by the installer.

Ah OK.

>> I don't know how easy it would be to automatically generate a
>> libgcrypt-config file that would look like that, but otherwise use the
>> normal @FOO@ Autoconf expansions for version numbers etc.
>
> Patches welcome to achieve this. :)

OK, I could try at some point.

Btw, one thing I forgot: I think it is not useful, actually harmful,
to distribute the .la files. They just confuse libtool when building
GnuTLS-using software, as they contain pathnames from your build
machine. Distributing just the .a and .def files should be fine.

Cheers,
--tml




From tml at iki.fi  Wed May  7 14:19:03 2008
From: tml at iki.fi (Tor Lillqvist)
Date: Wed, 7 May 2008 15:19:03 +0300
Subject: Suggested addition to the GnuTLS Windows installer
In-Reply-To: <c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>
References: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
	<87od7il4z8.fsf@mocca.josefsson.org>
	<c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>
Message-ID: <c9b6d9a50805070519r39bbee12pa37a4be95d27eb1f@mail.gmail.com>

BTW, also the share/aclocal folder probably should be included with
the installer, too. Although now that you pointed me to the zip file I
guess that is what I should have used instead of the executable
installer, and it does include share/aclocal.

--tml




From simon at josefsson.org  Wed May  7 14:52:26 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 May 2008 14:52:26 +0200
Subject: Suggested addition to the GnuTLS Windows installer
In-Reply-To: <c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>
	(Tor Lillqvist's message of "Wed, 7 May 2008 15:03:03 +0300")
References: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
	<87od7il4z8.fsf@mocca.josefsson.org>
	<c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>
Message-ID: <87bq3ie0ol.fsf@mocca.josefsson.org>

"Tor Lillqvist" <tml at iki.fi> writes:

> Btw, one thing I forgot: I think it is not useful, actually harmful,
> to distribute the .la files. They just confuse libtool when building
> GnuTLS-using software, as they contain pathnames from your build
> machine. Distributing just the .a and .def files should be fine.

I think that problem is something the libtool people should handle, as
far as I know they still recommend distributing *.la files.  Maybe you
could ask them?

/Simon




From simon at josefsson.org  Wed May  7 14:56:11 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 May 2008 14:56:11 +0200
Subject: Suggested addition to the GnuTLS Windows installer
In-Reply-To: <c9b6d9a50805070519r39bbee12pa37a4be95d27eb1f@mail.gmail.com>
	(Tor Lillqvist's message of "Wed, 7 May 2008 15:19:03 +0300")
References: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
	<87od7il4z8.fsf@mocca.josefsson.org>
	<c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>
	<c9b6d9a50805070519r39bbee12pa37a4be95d27eb1f@mail.gmail.com>
Message-ID: <874p9ae0ic.fsf@mocca.josefsson.org>

"Tor Lillqvist" <tml at iki.fi> writes:

> BTW, also the share/aclocal folder probably should be included with
> the installer, too. Although now that you pointed me to the zip file I
> guess that is what I should have used instead of the executable
> installer, and it does include share/aclocal.

Yes, the ZIP file is probably easier to use as a developer.  Possibly
the binary installed should be for non-developers only, and can thus be
made much smaller.

Anyway, I added the aclocal files to the binary installer anyway.  An
updated 2.3.8 installer will be published soon.

Thanks,
/Simon




From simon at josefsson.org  Wed May  7 15:39:59 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 May 2008 15:39:59 +0200
Subject: Updated GnuTLS Windows CVS repository and 2.3.8 installer
In-Reply-To: <87bq3ie0ol.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 07 May 2008 14:52:26 +0200")
References: <c9b6d9a50805062232g212244faq20e711ba2579b5c9@mail.gmail.com>
	<87od7il4z8.fsf@mocca.josefsson.org>
	<c9b6d9a50805070503q52112842y5e17366ae8ea28f7@mail.gmail.com>
	<87bq3ie0ol.fsf@mocca.josefsson.org>
Message-ID: <87zlr2cjww.fsf_-_@mocca.josefsson.org>

I've moved the CVS repository for gnutls4win to savannah, and improved
it so that others should be able to reproduce the same binaries more
easily.  I've also re-built gnutls 2.3.8 using the new build system.
Check out:

http://josefsson.org/gnutls4win/

The CVS repository:

http://cvs.savannah.gnu.org/viewvc/gnutls4win/?root=gnutls
https://savannah.gnu.org/cvs/?group=gnutls

Thanks,
Simon




From yanagisawa at csg.is.titech.ac.jp  Fri May  9 20:24:40 2008
From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA)
Date: Sat, 10 May 2008 03:24:40 +0900
Subject: Camellia block cipher don't work on current developers' releases
 2.3.x.
In-Reply-To: <877iedpxrl.fsf@mocca.josefsson.org>
References: <4816E809.6030108@csg.is.titech.ac.jp> <48197CAB.50105@gnutls.org>
	<877iedpxrl.fsf@mocca.josefsson.org>
Message-ID: <482496E8.8010103@csg.is.titech.ac.jp>


> Btw, to improve the chances that Camellia will work in all future
> releases, it can be a good idea to provide a self-test of this
> functionality, to be run by 'make check'.  We never release anything
> that fails a 'make check' self-test.

How about doing self test to all ciphers listed in gnutls_cipher_list
function?  I suppose that this test can be implemented by modifying
tests/anonself.c.  The way of implementation is that executing
gnutls_cipher_set_priority function in each algorithm listed by
gnutls_cipher_list function before executing gnutls_handshake function.

I think this approach will find not only bugs related to Camellia but
also others.

-- 
Yoshisato Yanagisawa (Dr.Sc.) <yanagisawa at csg.is.titech.ac.jp>





From yanagisawa at csg.is.titech.ac.jp  Sat May 10 03:41:36 2008
From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA)
Date: Sat, 10 May 2008 10:41:36 +0900
Subject: Camellia block cipher don't work on current developers' releases
 2.3.x.
In-Reply-To: <87zlr3k8f6.fsf@mocca.josefsson.org>
References: <4816E809.6030108@csg.is.titech.ac.jp>
	<48197CAB.50105@gnutls.org>	<481B2D44.7030005@csg.is.titech.ac.jp>
	<87zlr3k8f6.fsf@mocca.josefsson.org>
Message-ID: <4824FD50.9080209@csg.is.titech.ac.jp>



>>>> The other problem is that camellia block cipher is disabled by configure
>>>> script even if the user using libgcrypt with camellia block cipher and
>>>> configured with --enable-camellia option.  You can repeat the problem by
>>>> installing libgcrypt to no default directory such as /tmp/test, and then
>>>> pointing the directory with --with-libgcrypt-prefix=/tmp/test as option
>>>> of the configure script.
>>> This is quite strange. As I see the configure file does:
>>> test -n "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"
>>> to check for camellia. Was the correct libgcrypt detected by the
>>> configure script?
>> Not only this statements detects camellia block cipher but also m4
>> script in lgl/m4.  As far as I tested, gc-camellia.m4 in lgl/m4 also
>> affect enabling or disabling Camellia block cipher.
> 
> How does it affect that?  With your patch now applied, I don't think the
> gc-camellia.m4 test changes anything for how gnutls behaves.  In other
> words, even if the gc-camellia.m4 test fails, camellia should still work
> in gnutls.

I misunderstood the situation.
It don't affect enabling or disabling Camellia but it shows wrong
message "checking for camellia in libgcrypt... no" even if Camellia is
enabled.

Is this script really required? That is because this script seems not to
affect anywhere.

-- 
Yoshisato Yanagisawa (Dr.Sc.) <yanagisawa at csg.is.titech.ac.jp>





From yanagisawa at csg.is.titech.ac.jp  Sat May 10 05:51:53 2008
From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA)
Date: Sat, 10 May 2008 12:51:53 +0900
Subject: Camellia block cipher don't work on current developers' releases
 2.3.x.
In-Reply-To: <871w4ko9fq.fsf@wheatstone.g10code.de>
References: <4816E809.6030108@csg.is.titech.ac.jp>
	<48197CAB.50105@gnutls.org>	<481B2D44.7030005@csg.is.titech.ac.jp>
	<871w4ko9fq.fsf@wheatstone.g10code.de>
Message-ID: <48251BD9.1070607@csg.is.titech.ac.jp>

On 2008/05/03 3:19, Werner Koch wrote:
> On Fri,  2 May 2008 17:03, yanagisawa at csg.is.titech.ac.jp said:
> 
>> Not only this statements detects camellia block cipher but also m4
>> script in lgl/m4.  As far as I tested, gc-camellia.m4 in lgl/m4 also
> 
> Wouldn't it be easier to just drop these extra tests and require
> libgcrypt 1.4.0?  There are no plans to ever drop Camellia from
> libgcrypt.

Although the script has nothing to do with enabling or disabling
Camellia, dropping the script should be a good idea.  Requiring
libgcrypt >= 1.4.0 will also simplify the m4 script like gc-md5.m4 if
gc-camellia.m4 remained.

> The only case where it would not be available are builds for embedded
> platforms with explicitly disabled support for some algorithms.  The
> first test should catch this case.

I agree with this.

-- 
Yoshisato Yanagisawa (Dr.Sc.) <yanagisawa at csg.is.titech.ac.jp>




From ben at 0x539.de  Tue May 13 20:44:05 2008
From: ben at 0x539.de (Benjamin Herr)
Date: Tue, 13 May 2008 20:44:05 +0200
Subject: old gnutlsxx defect still not fixed?
Message-ID: <4829E175.8010709@0x539.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

as described in [0], the C++ bindings to gnutlsxx still invoke undefined
behaviour because the pure virtual function gnutls::credentials::set_ptr
cannot be called virtually in the constructor of gnutls::credentials.

The result for me is a linker error whenever any subclass of
gnutls::credentials is instantiated, or when the library is built for
Windows using mingw32 as win32 shared libraries cannot have unresolved
symbols.

Does anyone actually use the gnutlsxx bindings? The patches provided in
[0] look somewhat sane, is there any reason they have not been applied yet?

Thanks for your time,

Benjamin Herr

[0]: http://lists.gnu.org/archive/html/gnutls-devel/2007-02/msg00017.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgp4XQACgkQ+LZgICPLK54gWwCgizeEpwP/S4PAy9wkAYF65NTH
pGwAn2wzn7Ve8lxV3mchugJGq/Glzpcq
=v/li
-----END PGP SIGNATURE-----




From jorton at redhat.com  Wed May 14 16:20:20 2008
From: jorton at redhat.com (Joe Orton)
Date: Wed, 14 May 2008 15:20:20 +0100
Subject: [Bug 446392] New: SSL error: Key usage violation
Message-ID: <20080514142020.GA5582@redhat.com>

I'm about to go on holiday so won't be able to look into this myself for 
a week or so; Fedora 9 ships with GnuTLS 2.0.4, but I can reproduce this 
with the slightly stale git checkout I had lying around, so I'd suspect 
this is a GnuTLS cert validation bug?

$ ./bin/gnutls-cli svn.eionet.europa.eu
Resolving 'svn.eionet.europa.eu'...
Connecting to '217.74.209.183:443'...
*** Fatal error: Key usage violation in certificate has been detected.
*** Handshake has failed

----- Forwarded message from bugzilla at redhat.com -----

From: bugzilla at redhat.com
To: jorton at redhat.com
Date: Wed, 14 May 2008 09:21:21 -0400
Subject: [Bug 446392] New: SSL error: Key usage violation

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.




https://bugzilla.redhat.com/show_bug.cgi?id=446392

           Summary: SSL error: Key usage violation
           Product: Fedora
           Version: 9
          Platform: i386
        OS/Version: Linux
            Status: NEW
          Severity: medium
          Priority: low
         Component: subversion
        AssignedTo: jorton at redhat.com
        ReportedBy: <elided>
         QAContact: extras-qa at fedoraproject.org
   Estimated Hours: 0.0


Description of problem: Doing 'svn update' to SSL-enabled http server with
selfsigned certificate generate error message: SSL error: Key usage violation in
certificate has been detected.


Version-Release number of selected component (if applicable):
subversion-1.4.6-7.i386

How reproducible:
Simply do:
svn co https://svn.eionet.europa.eu/repositories/Zope/trunk/Localizer
It is a public SVN repository


Steps to Reproduce:
1. svn co https://svn.eionet.europa.eu/repositories/Zope/trunk/Localizer
2.
3.
  
Actual results:
svn: PROPFIND request failed on '/repositories/Zope/trunk/Localizer'
svn: PROPFIND of '/repositories/Zope/trunk/Localizer': SSL negotiation failed:
SSL error: Key usage violation in certificate has been detected.
(https://svn.eionet.europa.eu)

Expected results:
Localizer product checked out

Additional info:
The certificate for svn.eionet.europa.eu has the X509v3 Key Usage set to: Key
Encipherment, which is normal for SSL servers.

The svn.eionet.europa.eu has been in use for years, about two years with the
current certificate, and no such issue has arisen before.

In case you need to take a look. The certificate is signed with this CA:
http://www.eionet.europa.eu/certificates/eionet-ca.cer

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

----- End forwarded message -----




From simon at josefsson.org  Wed May 14 17:19:10 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 14 May 2008 17:19:10 +0200
Subject: [Bug 446392] New: SSL error: Key usage violation
In-Reply-To: <20080514142020.GA5582@redhat.com> (Joe Orton's message of "Wed, 
	14 May 2008 15:20:20 +0100")
References: <20080514142020.GA5582@redhat.com>
Message-ID: <87prro52xd.fsf@mocca.josefsson.org>

Joe Orton <jorton at redhat.com> writes:

> I'm about to go on holiday so won't be able to look into this myself for 
> a week or so; Fedora 9 ships with GnuTLS 2.0.4, but I can reproduce this 
> with the slightly stale git checkout I had lying around, so I'd suspect 
> this is a GnuTLS cert validation bug?
>
> $ ./bin/gnutls-cli svn.eionet.europa.eu
> Resolving 'svn.eionet.europa.eu'...
> Connecting to '217.74.209.183:443'...
> *** Fatal error: Key usage violation in certificate has been detected.
> *** Handshake has failed

Hi.  Thanks for the report.  Without further information, I believe that
is the correct behavior.

jas at mocca:~/src/gnutls$ gnutls-cli -d 4711 svn.eionet.europa.eu 2>&1 |grep 'Selected cipher'
|<3>| HSK[8074078]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
jas at mocca:~/src/gnutls$ 

RFC 2246 and 4346:

      DHE_RSA                 RSA public key that can be used for
                              signing.
...
   All certificate profiles and key and cryptographic formats are
   defined by the IETF PKIX working group [PKIX].  When a key usage
   extension is present, the digitalSignature bit MUST be set for the
   key to be eligible for signing, as described above, and the
   keyEncipherment bit MUST be present to allow encryption, as described
   above.  The keyAgreement bit must be set on Diffie-Hellman
   certificates.

jas at mocca:~/src/gnutls$ certtool -i < cert.pem |grep 'Key Usage' -A 2
		Key Usage (not critical):
			Key encipherment.
		Subject Key Identifier (not critical):
jas at mocca:~/src/gnutls$ 

In other words, the certificate must have the digitalSignature bit
enabled to be usable as a TLS server certificate for this ciphersuite.

/Simon




From nmav at gnutls.org  Thu May 15 07:15:50 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 May 2008 08:15:50 +0300
Subject: old gnutlsxx defect still not fixed?
In-Reply-To: <4829E175.8010709@0x539.de>
References: <4829E175.8010709@0x539.de>
Message-ID: <482BC706.5070305@gnutls.org>

Benjamin Herr wrote:
> Hi,
> 
> as described in [0], the C++ bindings to gnutlsxx still invoke undefined
> behaviour because the pure virtual function gnutls::credentials::set_ptr
> cannot be called virtually in the constructor of gnutls::credentials.
> 
> The result for me is a linker error whenever any subclass of
> gnutls::credentials is instantiated, or when the library is built for
> Windows using mingw32 as win32 shared libraries cannot have unresolved
> symbols.
> 
> Does anyone actually use the gnutlsxx bindings? The patches provided in
> [0] look somewhat sane, is there any reason they have not been applied yet?

I just got aware even for the first posting of this issue. I'll check it
and let you know.

regards,
Nikos




From nmav at gnutls.org  Thu May 15 07:20:08 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 15 May 2008 08:20:08 +0300
Subject: [Modules] [mod_gnutls 0.4.3 / 0.5.1] GnuTLS internal error with
 Firefox 3
In-Reply-To: <1210692540.28991.14.camel@localhost.localdomain>
References: <1210692540.28991.14.camel@localhost.localdomain>
Message-ID: <482BC808.2020903@gnutls.org>

Romain LE DISEZ wrote:
> Hi,
> 
> I'm running mod_gnutls with success from few months now. When I updated
> my Fedora to Fedora 9, I got Firefox 3 (beta 5).
> 
> Firefox 3 can't access to my TLS website. It returns the error :
>> Secure Connection Failed
>>
>>   An error occurred during a connection to intranet.ledisez.net.
>>
>>   Peer reports it experienced an internal error.
>>
>>   (Error code: ssl_error_internal_error_alert)
> 
> On error.log from Apache :
>> GnuTLS: Handshake Failed (-59) 'GnuTLS internal error.'
> 
> I join gnutls_debug.
> 
> I'm not sure it's a firefox or gnutls bug but the error message 'GnuTLS
> internal error' makes me post here.

Indeed. Thank you for the report. It seems camellia is not enabled in
this build of gnutls. Can you try with gnutls 2.2.3?


regards,
Nikos




From simon at josefsson.org  Thu May 15 11:34:50 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 May 2008 11:34:50 +0200
Subject: AES128 or AES256 by default?
Message-ID: <87zlqrewqt.fsf@mocca.josefsson.org>

There is a debian bug:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476441

Which asks that we make AES-256 the default preferred cipher.  Right now
AES-128 is the default preferred cipher.  Of course, today AES-256 is
supported as well (it is the second preferred default cipher).

What do people think here?

I don't care strongly, but I find the arguments for AES-256 rather weak.
According to RFC 3766, to match a 256 bit symmetric key size, you need a
~15kb large RSA key or a ~500b large DSA key.  People don't use that
kind of public key sizes today as far as I know, as they become very
big.  The few who do should be able to tweak the GnuTLS cipher
preference accordingly.

/Simon




From romain.ledisez at netensia.fr  Thu May 15 09:24:05 2008
From: romain.ledisez at netensia.fr (Romain LE DISEZ)
Date: Thu, 15 May 2008 09:24:05 +0200
Subject: [Modules] [mod_gnutls 0.4.3 / 0.5.1] GnuTLS internal error
	with Firefox 3
In-Reply-To: <482BC808.2020903@gnutls.org>
References: <1210692540.28991.14.camel@localhost.localdomain>
	<482BC808.2020903@gnutls.org>
Message-ID: <1210836245.2671.2.camel@localhost.localdomain>

Excelent, I compiled gnutls 2.2.3 and mod_gnutls with the new gnutls :
it did the trick !

Thanks for your help.

Le jeudi 15 mai 2008 ? 08:20 +0300, Nikos Mavrogiannopoulos a ?crit :
> Romain LE DISEZ wrote:
> > Hi,
> > 
> > I'm running mod_gnutls with success from few months now. When I updated
> > my Fedora to Fedora 9, I got Firefox 3 (beta 5).
> > 
> > Firefox 3 can't access to my TLS website. It returns the error :
> >> Secure Connection Failed
> >>
> >>   An error occurred during a connection to intranet.ledisez.net.
> >>
> >>   Peer reports it experienced an internal error.
> >>
> >>   (Error code: ssl_error_internal_error_alert)
> > 
> > On error.log from Apache :
> >> GnuTLS: Handshake Failed (-59) 'GnuTLS internal error.'
> > 
> > I join gnutls_debug.
> > 
> > I'm not sure it's a firefox or gnutls bug but the error message 'GnuTLS
> > internal error' makes me post here.
> 
> Indeed. Thank you for the report. It seems camellia is not enabled in
> this build of gnutls. Can you try with gnutls 2.2.3?
> 
> 
> regards,
> Nikos
-- 
Romain LE DISEZ
Netensia





From simon at josefsson.org  Thu May 15 16:15:42 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 May 2008 16:15:42 +0200
Subject: GnuTLS 2.3.4.netconf.1
Message-ID: <87tzgzac1d.fsf@mocca.josefsson.org>

There is a branch 'gnutls_with_netconf' for the goal of implementing
support for Netconf over TLS-PSK as per this IETF draft:
<http://tools.ietf.org/html/draft-ietf-netconf-tls-01>.

This is the second release from this branch, and it adds support for
parsing the psk_identity_hint in the client.  What remains is to support
sending the psk_identity_hint in the server, and to add a section to the
manual.

The branch is currently based on gnutls 2.3.4, which explains the
version numbers in the tar archive filename.

The goal is to merge this with the development branch eventually.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.4.netconf.1.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.4.netconf.1.tar.bz2

Happy hacking,
Simon

* Version 2.3.4.netconf.1 (released 2008-05-15)

** Handle psk_identity_hint field in client.

** Change PSK key derivation logic.

** gnutls-cli: Fix so that PSK authentication works.
Back-ported from trunk.

** 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/20080515/9737d4c4/attachment.pgp>

From chip at corelands.com  Thu May 15 18:12:50 2008
From: chip at corelands.com (Paul Querna)
Date: Thu, 15 May 2008 09:12:50 -0700
Subject: AES128 or AES256 by default?
In-Reply-To: <87zlqrewqt.fsf@mocca.josefsson.org>
References: <87zlqrewqt.fsf@mocca.josefsson.org>
Message-ID: <4239a4320805150912v48c069bp68848e0820a50ff4@mail.gmail.com>

On Thu, May 15, 2008 at 2:34 AM, Simon Josefsson <simon at josefsson.org>
wrote:

> There is a debian bug:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476441
>
> Which asks that we make AES-256 the default preferred cipher.  Right now
> AES-128 is the default preferred cipher.  Of course, today AES-256 is
> supported as well (it is the second preferred default cipher).
>
> What do people think here?
>

Applications can expose a cipher priortity configuration option -- just as
mod_gnutls does -- and then you could configure dovecot to default to
AES-256.

I don't believe the concerns expressed in the debian bug should be a reason
to have libgnutls's default priorities changed.

-Paul

>
> I don't care strongly, but I find the arguments for AES-256 rather weak.
> According to RFC 3766, to match a 256 bit symmetric key size, you need a
> ~15kb large RSA key or a ~500b large DSA key.  People don't use that
> kind of public key sizes today as far as I know, as they become very
> big.  The few who do should be able to tweak the GnuTLS cipher
> preference accordingly.
>
> /Simon
>
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080515/781d437e/attachment.htm>

From nmav at gnutls.org  Fri May 16 07:23:36 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 16 May 2008 08:23:36 +0300
Subject: AES128 or AES256 by default?
In-Reply-To: <87zlqrewqt.fsf@mocca.josefsson.org>
References: <87zlqrewqt.fsf@mocca.josefsson.org>
Message-ID: <482D1A58.90003@gnutls.org>

Simon Josefsson wrote:
> There is a debian bug:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476441
> 
> Which asks that we make AES-256 the default preferred cipher.  Right now
> AES-128 is the default preferred cipher.  Of course, today AES-256 is
> supported as well (it is the second preferred default cipher).
> 
> What do people think here?

I also see no reason. Increasing the key size from 128bits to 256bits,
does not offer any additional security (given of course that AES is not
broken in other ways).




From simon at josefsson.org  Fri May 16 11:57:06 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 May 2008 11:57:06 +0200
Subject: Anyone using FunctionCheck?
Message-ID: <87d4nm4ln1.fsf@mocca.josefsson.org>

GnuTLS' configure checks for fc-config and libfc, but according to

http://sourceforge.net/forum/forum.php?forum_id=191647

development of FunctionCheck stopped around 2002.  The URL printed by
./configure doesn't work any more.  I can't find packages of it for
debian or redhat.  The name 'libfc' seems to be used by some XMMS
plugins [1] and parts of the linux kernel [2] for SCSI fibre channel
stuff.

Is anyone using it?

I'd like to remove the checks for this, to clean up the code.

/Simon

[1] http://rpmfind.net/linux/rpm2html/search.php?query=libfc.so

[2] http://archive.netbsd.se/?ml=linux-scsi&a=2008-02&t=6514608




From n.mavrogiannopoulos at gmail.com  Fri May 16 13:37:30 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 16 May 2008 14:37:30 +0300
Subject: Anyone using FunctionCheck?
In-Reply-To: <87d4nm4ln1.fsf@mocca.josefsson.org>
References: <87d4nm4ln1.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0805160437w42737045wea9f4e5fbad52cbe@mail.gmail.com>

On Fri, May 16, 2008 at 12:57 PM, Simon Josefsson <simon at josefsson.org> wrote:
> GnuTLS' configure checks for fc-config and libfc, but according to
>
> http://sourceforge.net/forum/forum.php?forum_id=191647
>
> development of FunctionCheck stopped around 2002.  The URL printed by
> ./configure doesn't work any more.  I can't find packages of it for
> debian or redhat.  The name 'libfc' seems to be used by some XMMS
> plugins [1] and parts of the linux kernel [2] for SCSI fibre channel
> stuff.
>
> Is anyone using it?

I was using it years ago. Since it is not maintained any more we can remove it.




From simon at josefsson.org  Fri May 16 13:54:58 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 May 2008 13:54:58 +0200
Subject: Anyone using FunctionCheck?
In-Reply-To: <c331d99a0805160437w42737045wea9f4e5fbad52cbe@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Fri, 16 May 2008 14:37:30
	+0300")
References: <87d4nm4ln1.fsf@mocca.josefsson.org>
	<c331d99a0805160437w42737045wea9f4e5fbad52cbe@mail.gmail.com>
Message-ID: <87zlqqzcod.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <n.mavrogiannopoulos at gmail.com> writes:

> On Fri, May 16, 2008 at 12:57 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> GnuTLS' configure checks for fc-config and libfc, but according to
>>
>> http://sourceforge.net/forum/forum.php?forum_id=191647
>>
>> development of FunctionCheck stopped around 2002.  The URL printed by
>> ./configure doesn't work any more.  I can't find packages of it for
>> debian or redhat.  The name 'libfc' seems to be used by some XMMS
>> plugins [1] and parts of the linux kernel [2] for SCSI fibre channel
>> stuff.
>>
>> Is anyone using it?
>
> I was using it years ago. Since it is not maintained any more we can remove it.

I have removed it, thanks.

/Simon




From simon at josefsson.org  Fri May 16 16:35:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 May 2008 16:35:03 +0200
Subject: GnuTLS 2.3.9
Message-ID: <87lk2awc4o.fsf@mocca.josefsson.org>

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

The goals for the 2.3.x branch are tracked at:

http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.9.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.9.tar.bz2

No Windows binaries because fchmod isn't available on Windows, and I
discovered this too late.  Will be fixed for the next release.

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

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

News in this release:

* Version 2.3.9 (released 2008-05-16)

** libgnutls: Fix build failures if SRP/OpenPGP is disabled.
Based on report and tiny patches from
<jared.jennings.ctr at eglin.af.mil>, see
<https://savannah.gnu.org/support/index.php?106342>.

** libgnutls: Translation fixes.

** gnutls-cli: Fix so that PSK authentication works.
Also improve manual to give example for gnutls-cli PSK authentication.

** certtool: Encrypting a private key now require a confirmed password.
Before './certtool -k -8' would merely ask for a password once.
Reported by Daniel 'NebuchadnezzaR' Dehennin
<nebuchadnezzar at asgardr.info> see
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364287>.

** certtool: When writing private keys to files, change permissions of file.
Now the file which the private key is saved to is chmod'ed 0600.
Reported by martin f krafft <madduck at debian.org> see
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373169>.

** guile: Fix -fgnu89-inline test.

** Removed --enable-profile-mode.
The code linked gnutls with the libfc project (Function Check) which
appears to have been stalled since around 2002.

** Clean up header file checks by ./configure.

** Update of gnulib files.

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

/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/20080516/558d3431/attachment.pgp>

From nmav at gnutls.org  Sat May 17 08:05:43 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 17 May 2008 09:05:43 +0300
Subject: old gnutlsxx defect still not fixed?
In-Reply-To: <4829E175.8010709@0x539.de>
References: <4829E175.8010709@0x539.de>
Message-ID: <482E75B7.9070809@gnutls.org>

Benjamin Herr wrote:
> Hi,

> as described in [0], the C++ bindings to gnutlsxx still invoke undefined
> behaviour because the pure virtual function gnutls::credentials::set_ptr
> cannot be called virtually in the constructor of gnutls::credentials.
> The result for me is a linker error whenever any subclass of
> gnutls::credentials is instantiated, or when the library is built for
> Windows using mingw32 as win32 shared libraries cannot have unresolved
> symbols.

Would the attached patch solve this issue? It is a port of the old patch
to newer gnutls.

> Does anyone actually use the gnutlsxx bindings? The patches provided in
> [0] look somewhat sane, is there any reason they have not been applied yet?
> 
> Thanks for your time,
> 
> Benjamin Herr
> 
> [0]: http://lists.gnu.org/archive/html/gnutls-devel/2007-02/msg00017.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: </pipermail/attachments/20080517/684a8abe/attachment.asc>

From nmav at gnutls.org  Sat May 17 08:24:49 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 17 May 2008 09:24:49 +0300
Subject: gnutls C++ API
Message-ID: <482E7A31.1040403@gnutls.org>

I'd like to remind to everybody that the gnutls C++ library maintainer's
position is blank for the moment! If you are willing to improve this API
and willing to contribute, we'll be happy to include your patches,
improvements. As you might have already notice the current API is only a
quick hack and quite limited in functionality. It was intended as a
starting point.


regards,
Nikos




From simon at josefsson.org  Mon May 19 14:00:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 14:00:43 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
Message-ID: <87ve1a4i6s.fsf@mocca.josefsson.org>

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

This release fixes three serious bugs that can crash the GnuTLS library.
We invite more detailed analysis of the problem, following our general
security advisory approach explained on:

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

Particularly, it would be useful to answer the question of whether these
bugs can be exploited remotely to execute arbitrary code.  It is
certainly possible to cause the server to crash.  We don't have
resources to investigate this problem more ourselves currently.

Please send your analysis to gnutls-dev at gnupg.org and I'll update the
security advisory web page pointing to it.  Be sure to check the web
page first to get updates on what has been done so far.

Below is attached our own security advisory and patch.  The file has
been verified to apply to the latest stable release of the recent stable
branches: version 1.4.5, 1.6.3, 2.0.4, and 2.2.3.  The patch will also
work with version 1.2.11 but you will need to apply it manually.  The
patch also apply to the latest development version 2.3.9 but keep in
mind that this version is not intended for production systems.

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

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

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

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

* Version 2.2.4 (released 2008-05-19)

** Fix three security vulnerabilities.  [GNUTLS-SA-2008-1]
Thanks to CERT-FI for finding the bugs and providing detailed reports,
which allowed the bugs to be reproduced and fixed easily.  Patches
developed by Simon Josefsson and Nikos Mavrogiannopoulos.  Any updates
with more details about these vulnerabilities will be added to
<http://www.gnu.org/software/gnutls/security.html>

*** [GNUTLS-SA-2008-1-1]
*** libgnutls: Fix crash when sending invalid server name.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
cause gnutls to store more session resumption data than what was
allocated for, thus overwriting unallocated memory.

*** [GNUTLS-SA-2008-1-2]
*** libgnutls: Fix crash when sending repeated client hellos.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
triggers a null-pointer dereference.

*** [GNUTLS-SA-2008-1-3]
*** libgnutls: Fix crash in cipher padding decoding for invalid record lengths.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
cause gnutls to read memory beyond the end of the received record.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/pub/gnutls/gnutls-2.2.4.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.2.4.tar.bz2.sig

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

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

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

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

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

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:

3b5d8138e3ce78b3a25f8d0491da438bb8ef6a4e  gnutls-2.2.4.tar.bz2

85b29eab286bb55d48d1454bfcf5bebba63581159c9dd0850a32a4c3  gnutls-2.2.4.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-devel mailing list, see:
<http://lists.gnu.org/mailman/listinfo/gnutls-devel>.

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.2.4.

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

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

A ZIP file with the installed tree of binaries:
  http://josefsson.org/gnutls4win/gnutls-2.2.4.zip (4.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.4.zip.sig

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

331a70b9cb64954d3187c880c1bb6994b4511775  gnutls-2.2.4.exe
9d1a58db1683673f92d1ed1611b4dfd416b0d447a1d393993cf4b494 gnutls-2.2.4.exe

df7478d51ce338844496b2bb1a888c4931e3e88f  gnutls-2.2.4.zip
c7c4bf3ea70ab24c070ee50a4497d403a44dada2b52b80d6bb413b49  gnutls-2.2.4.zip

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080519/ca52caaf/attachment.pgp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls-sa-2008-01.txt.asc
URL: </pipermail/attachments/20080519/ca52caaf/attachment.asc>

From simon at josefsson.org  Mon May 19 14:42:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 14:42:03 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <87ve1a4i6s.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 19 May 2008 14:00:43 +0200")
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
Message-ID: <87r6byv52c.fsf@mocca.josefsson.org>

Two silly typos in the announcement:

> Please send your analysis to gnutls-dev at gnupg.org and I'll update the

Of course, that should be gnutls-devel at gnu.org.

> lead to a Daniel of Service attack to disable the server.  The bug

That would be 'Denial of Service'... thanks Daniel for noticing this! :)

/Simon




From simon at josefsson.org  Mon May 19 19:12:47 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 19:12:47 +0200
Subject: GnuTLS 2.3.10
Message-ID: <8763ta2p68.fsf@mocca.josefsson.org>

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

The goals for the 2.3.x branch are tracked at:

http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.10.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.10.tar.bz2

Here is the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.3.10.exe
  http://josefsson.org/gnutls4win/gnutls-2.3.10.zip

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

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

News in this release:

* Version 2.3.10 (released 2008-05-19)

** Added wide wildcard hostname matching.
Tiny patch by Jean-Philippe Garcia Ballester.

** Fix three security vulnerabilities.  [GNUTLS-SA-2008-1]
Thanks to CERT-FI for finding the bugs and providing detailed reports,
which allowed the bugs to be reproduced and fixed easily.  Patches
developed by Simon Josefsson and Nikos Mavrogiannopoulos.  Any updates
with more details about these vulnerabilities will be added to
<http://www.gnu.org/software/gnutls/security.html>

*** [GNUTLS-SA-2008-1-1]
*** libgnutls: Fix crash when sending invalid server name.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
cause gnutls to store more session resumption data than what was
allocated for, thus overwriting unallocated memory.

*** [GNUTLS-SA-2008-1-2]
*** libgnutls: Fix crash when sending repeated client hellos.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
triggers a null-pointer dereference.

*** [GNUTLS-SA-2008-1-3]
*** libgnutls: Fix crash in cipher padding decoding for invalid record lengths.
The crash can be triggered remotely before authentication, which can
lead to a Daniel of Service attack to disable the server.  The bug
cause gnutls to read memory beyond the end of the received record.

** libgnutlsxx: Updated API according to patches from Eduardo 
Villanueva Che (discussion at
<http://lists.gnu.org/archive/html/gnutls-devel/2007-02/msg00017.html>)

** Use umask to restrict permissions to owner before creating a file.

/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/20080519/f08c8af2/attachment.pgp>

From simon at josefsson.org  Mon May 19 19:50:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 19:50:17 +0200
Subject: old gnutlsxx defect still not fixed?
In-Reply-To: <482E75B7.9070809@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 17 May 2008 09:05:43 +0300")
References: <4829E175.8010709@0x539.de> <482E75B7.9070809@gnutls.org>
Message-ID: <87bq32tc86.fsf@mocca.josefsson.org>

FYI,

I've not been able to build the C++ library using MinGW because of this
problem:

/bin/bash ../libtool --tag=CXX   --mode=compile i586-mingw32msvc-g++ -DHAVE_CONFIG_H -I. -I../../../src/gnutls-2.3.10/lib -I..  -DLOCALEDIR=\"/home/jas/gnutls4win/inst/share/locale\" -I../../../src/gnutls-2.3.10/lgl -I../lgl -I../../../src/gnutls-2.3.10/includes -I../includes -I../../../src/gnutls-2.3.10/lib/x509 -I../../../src/gnutls-2.3.10/libextra -I../../../src/gnutls-2.3.10/lib/openpgp/ -I/home/jas/gnutls4win/inst/include -I../../../src/gnutls-2.3.10/lib/opencdk -I../../../src/gnutls-2.3.10/lib/opencdk  -I/home/jas/gnutls4win/inst/include  -I../../../src/gnutls-2.3.10/includes/ -g -O2 -MT gnutlsxx.lo -MD -MP -MF .deps/gnutlsxx.Tpo -c -o gnutlsxx.lo ../../../src/gnutls-2.3.10/lib/gnutlsxx.cpp
 i586-mingw32msvc-g++ -DHAVE_CONFIG_H -I. -I../../../src/gnutls-2.3.10/lib -I.. -DLOCALEDIR=\"/home/jas/gnutls4win/inst/share/locale\" -I../../../src/gnutls-2.3.10/lgl -I../lgl -I../../../src/gnutls-2.3.10/includes -I../includes -I../../../src/gnutls-2.3.10/lib/x509 -I../../../src/gnutls-2.3.10/libextra -I../../../src/gnutls-2.3.10/lib/openpgp/ -I/home/jas/gnutls4win/inst/include -I../../../src/gnutls-2.3.10/lib/opencdk -I../../../src/gnutls-2.3.10/lib/opencdk -I/home/jas/gnutls4win/inst/include -I../../../src/gnutls-2.3.10/includes/ -g -O2 -MT gnutlsxx.lo -MD -MP -MF .deps/gnutlsxx.Tpo -c ../../../src/gnutls-2.3.10/lib/gnutlsxx.cpp  -DDLL_EXPORT -DPIC -o .libs/gnutlsxx.o
In file included from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/ctime:51,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/cwchar:52,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/bits/postypes.h:46,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/iosfwd:49,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/bits/stl_algobase.h:70,
                 from /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/vector:66,
                 from ../../../src/gnutls-2.3.10/includes/gnutls/gnutlsxx.h:5,
                 from ../../../src/gnutls-2.3.10/lib/gnutlsxx.cpp:1:
../lgl/time.h:74: error: expected ',' or '...' before '__timer'
../lgl/time.h:76: error: expected ',' or '...' before '__timer'
make[3]: *** [gnutlsxx.lo] Error 1
make[3]: Leaving directory `/home/jas/gnutls4win/build/gnutls-2.3.10/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jas/gnutls4win/build/gnutls-2.3.10/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jas/gnutls4win/build/gnutls-2.3.10'
make: *** [all] Error 2
jas at mocca:~/gnutls4win/build/gnutls-2.3.10$ 

Any ideas?

It may be that the 'restrict' keyword isn't understood by g++.  Any
ideas how to solve it?  Possibly gnulib's -I../lgl/ shouldn't be used
for the C++ library?  Yeah, this seems to do the trick:

diff --git a/lib/Makefile.am b/lib/Makefile.am
index 660782c..624263a 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -146,6 +146,8 @@ endif
 # C++ library
 
 if ENABLE_CXX
+libgnutlsxx_la_CPPFLAGS = -I$(top_srcdir)/includes -I../includes
+
 CPP_OBJECTS = gnutlsxx.cpp
 
 AM_CXXFLAGS = -I$(top_srcdir)/includes/

I'm pushing it.

/Simon




From ametzler at downhill.at.eu.org  Mon May 19 20:01:01 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 19 May 2008 20:01:01 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <87ve1a4i6s.fsf@mocca.josefsson.org>
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
Message-ID: <20080519180101.GA4581@downhill.g.la>

On 2008-05-19 Simon Josefsson <simon at josefsson.org> wrote:
> We are pleased to announce a new stable GnuTLS release: Version 2.2.4.
[...]
> *** [GNUTLS-SA-2008-1-3]
> *** libgnutls: Fix crash in cipher padding decoding for invalid record lengths.
> The crash can be triggered remotely before authentication, which can
> lead to a Daniel of Service attack to disable the server.  The bug
> cause gnutls to read memory beyond the end of the received record.

Hello,
The fix for this one (gnutls_cipher.c) breaks clean end of session:

Using 2.2.3:
(SID)ametzler at argenau:/tmp/GNUTLS/gnutls26-2.2.4$ gnutls-cli -p 443 www.gnutls.org
Resolving 'www.gnutls.org'...
[...]
- Handshake was completed

- Simple Client Mode:

get x
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
[...]
</BODY></HTML>
- Peer has closed the GNUTLS connection


Now with 2.2.4:
(SID)ametzler at argenau:/tmp/GNUTLS/gnutls26-2.2.4$ gnutls-cli -p 443 www.gnutls.org
Resolving 'www.gnutls.org'...
- Handshake was completed

- Simple Client Mode:

get x
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
[...]
</BODY></HTML>
*** Fatal error: Decryption has failed.
*** Server has terminated the connection abnormally.

thanks, cu andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20080519/f1e9bf49/attachment.pgp>

From simon at josefsson.org  Mon May 19 20:26:23 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 20:26:23 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <20080519180101.GA4581@downhill.g.la> (Andreas Metzler's message
	of "Mon, 19 May 2008 20:01:01 +0200")
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
	<20080519180101.GA4581@downhill.g.la>
Message-ID: <87prri2lrk.fsf@mocca.josefsson.org>

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

> Hello,
> The fix for this one (gnutls_cipher.c) breaks clean end of session:

Hi,

Sigh!  If you add -d 4711 what does it say?  I'm trying to reproduce
this now.

I don't understand why the self-tests didn't catch something like this
though.

/Simon




From ametzler at downhill.at.eu.org  Mon May 19 20:43:16 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 19 May 2008 20:43:16 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <87prri2lrk.fsf@mocca.josefsson.org>
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
	<20080519180101.GA4581@downhill.g.la>
	<87prri2lrk.fsf@mocca.josefsson.org>
Message-ID: <20080519184316.GB4581@downhill.g.la>

On 2008-05-19 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> > The fix for this one (gnutls_cipher.c) breaks clean end of session:

> Sigh!  If you add -d 4711 what does it say?  I'm trying to reproduce
> this now.

Hello,

I am attaching logs for both 2.2.3 and 2.2.4 for easy comparison.

hth and thanks, cu andreas
-------------- next part --------------
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[8073cb8]: Sending extension CERT_TYPE
|<2>| EXT[8073cb8]: Sending extension SERVER_NAME
|<3>| HSK[8073cb8]: CLIENT HELLO was send [111 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8073cb8]: Sending Packet[0] Handshake(22) with length: 111
|<7>| WRITE: Will write 116 bytes to 4.
|<7>| WRITE: wrote 116 bytes to 4. Left 0 bytes. Total 116 bytes.
|<7>| 0000 - 16 03 02 00 6f 01 00 00 6b 03 02 48 31 c9 9d c2 
|<7>| 0001 - 7d 23 a2 71 9d b6 15 b8 f2 ab 2a e9 97 aa 81 30 
|<7>| 0002 - 17 7c 92 f1 1f 23 dc 7b cd fd 62 00 00 24 00 33 
|<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 
|<7>| 0004 - 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 
|<7>| 0005 - 00 04 01 00 00 1e 00 09 00 03 02 00 01 00 00 00 
|<7>| 0006 - 13 00 11 00 00 0e 77 77 77 2e 67 6e 75 74 6c 73 
|<7>| 0007 - 2e 6f 72 67 
|<4>| REC[8073cb8]: Sent Packet[1] Handshake(22) with length: 116
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 2a 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[0] Handshake(22) with length: 42
|<7>| READ: Got 42 bytes from 4
|<7>| READ: read 42 bytes from 4
|<7>| 0000 - 02 00 00 26 03 01 48 31 c9 9b b4 88 2a dd 51 50 
|<7>| 0001 - db 95 3f 0a 3d 42 cc 7c 8e e3 4c 8f 7a c9 12 b6 
|<7>| 0002 - c3 bb 68 2e 19 da 00 00 33 00 
|<7>| RB: Have 5 bytes into buffer. Adding 42 bytes.
|<7>| RB: Requested 47 bytes
|<4>| REC[8073cb8]: Decrypted Packet[0] Handshake(22) with length: 42
|<6>| BUF[HSK]: Inserted 42 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: SERVER HELLO was received [42 bytes]
|<6>| BUF[REC][HD]: Read 38 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 38 bytes of Data
|<3>| HSK[8073cb8]: Server's version: 3.1
|<3>| HSK[8073cb8]: SessionID length: 0
|<3>| HSK[8073cb8]: SessionID: 
|<3>| HSK[8073cb8]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:165
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 06 37 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[1] Handshake(22) with length: 1591
|<7>| READ: Got 1388 bytes from 4
|<7>| READ: Got 203 bytes from 4
|<7>| READ: read 1591 bytes from 4
|<7>| 0000 - 0b 00 06 33 00 06 30 00 02 9d 30 82 02 99 30 82 
|<7>| 0001 - 02 02 02 01 02 30 0d 06 09 2a 86 48 86 f7 0d 01 
|<7>| 0002 - 01 04 05 00 30 81 90 31 0b 30 09 06 03 55 04 06 
|<7>| 0003 - 13 02 53 45 31 12 30 10 06 03 55 04 08 13 09 53 
|<7>| 0004 - 74 6f 63 6b 68 6f 6c 6d 31 12 30 10 06 03 55 04 
|<7>| 0005 - 07 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 0c 30 0a 
|<7>| 0006 - 06 03 55 04 0a 13 03 59 58 41 31 0b 30 09 06 03 
|<7>| 0007 - 55 04 0b 13 02 43 41 31 18 30 16 06 03 55 04 03 
|<7>| 0008 - 13 0f 79 78 61 2e 65 78 74 75 6e 64 6f 2e 63 6f 
|<7>| 0009 - 6d 31 24 30 22 06 09 2a 86 48 86 f7 0d 01 09 01 
|<7>| 000a - 16 15 73 74 61 66 66 40 79 78 61 2e 65 78 74 75 
|<7>| 000b - 6e 64 6f 2e 63 6f 6d 30 1e 17 0d 30 34 30 35 32 
|<7>| 000c - 33 30 39 33 36 32 39 5a 17 0d 32 33 30 37 32 33 
|<7>| 000d - 30 39 33 36 32 39 5a 30 81 98 31 0b 30 09 06 03 
|<7>| 000e - 55 04 06 13 02 53 45 31 12 30 10 06 03 55 04 08 
|<7>| 000f - 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 12 30 10 06 
|<7>| 0010 - 03 55 04 07 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 
|<7>| 0011 - 0c 30 0a 06 03 55 04 0a 13 03 59 58 41 31 13 30 
|<7>| 0012 - 11 06 03 55 04 0b 13 0a 57 65 62 20 73 65 72 76 
|<7>| 0013 - 65 72 31 18 30 16 06 03 55 04 03 13 0f 79 78 61 
|<7>| 0014 - 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 31 24 30 22 
|<7>| 0015 - 06 09 2a 86 48 86 f7 0d 01 09 01 16 15 73 74 61 
|<7>| 0016 - 66 66 40 79 78 61 2e 65 78 74 75 6e 64 6f 2e 63 
|<7>| 0017 - 6f 6d 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 
|<7>| 0018 - 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 a0 
|<7>| 0019 - 59 95 c1 18 7f 71 77 af 93 da 0a 83 2e 22 80 cc 
|<7>| 001a - cf 09 e5 dd 95 93 fc 61 9a 02 01 30 8d 4e 4d 21 
|<7>| 001b - 15 1f a9 45 79 2e 92 13 92 06 df f7 ff 65 ee d0 
|<7>| 001c - 61 f8 19 b9 55 60 6a c5 0d 81 7a d5 8e 6a 08 46 
|<7>| 001d - 50 5a 7f 18 e9 70 9a df c1 3a 35 3a 77 de 2e f0 
|<7>| 001e - d5 b7 c5 02 7e 54 f7 a3 0d c1 c6 f0 06 04 00 84 
|<7>| 001f - 12 d9 e2 40 1a 07 60 43 20 0a 32 5c 9a a9 80 d7 
|<7>| 0020 - fc 5b a6 5c 3d 1d 1b c4 13 aa a6 35 60 c3 c5 02 
|<7>| 0021 - 03 01 00 01 30 0d 06 09 2a 86 48 86 f7 0d 01 01 
|<7>| 0022 - 04 05 00 03 81 81 00 9c 25 73 6f cc ac 6e e3 63 
|<7>| 0023 - bb 8e e5 79 47 f6 ca 55 bd 47 51 89 92 ca 92 8e 
|<7>| 0024 - 35 7a 65 80 8c 9d 08 9e 06 21 d8 7f 9f 5f 0d 7f 
|<7>| 0025 - eb ed f4 1c a3 7b 39 a8 e0 05 93 fd dc 03 51 5b 
|<7>| 0026 - 39 6f 67 3d 84 67 2e f3 2f 64 98 98 a9 93 d6 6e 
|<7>| 0027 - 49 4f c7 66 fa e4 4a a3 73 24 55 9a 86 05 0c 4b 
|<7>| 0028 - 29 49 3e eb b0 46 fc a7 95 59 c2 20 fe 48 ea a6 
|<7>| 0029 - bb 61 17 6a b1 64 82 c9 31 43 d3 cd fe 3b 3f e6 
|<7>| 002a - 8d bf f7 20 0e f1 b8 00 03 8d 30 82 03 89 30 82 
|<7>| 002b - 02 f2 a0 03 02 01 02 02 01 00 30 0d 06 09 2a 86 
|<7>| 002c - 48 86 f7 0d 01 01 04 05 00 30 81 90 31 0b 30 09 
|<7>| 002d - 06 03 55 04 06 13 02 53 45 31 12 30 10 06 03 55 
|<7>| 002e - 04 08 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 12 30 
|<7>| 002f - 10 06 03 55 04 07 13 09 53 74 6f 63 6b 68 6f 6c 
|<7>| 0030 - 6d 31 0c 30 0a 06 03 55 04 0a 13 03 59 58 41 31 
|<7>| 0031 - 0b 30 09 06 03 55 04 0b 13 02 43 41 31 18 30 16 
|<7>| 0032 - 06 03 55 04 03 13 0f 79 78 61 2e 65 78 74 75 6e 
|<7>| 0033 - 64 6f 2e 63 6f 6d 31 24 30 22 06 09 2a 86 48 86 
|<7>| 0034 - f7 0d 01 09 01 16 15 73 74 61 66 66 40 79 78 61 
|<7>| 0035 - 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 30 1e 17 0d 
|<7>| 0036 - 30 34 30 35 32 33 30 39 33 35 33 33 5a 17 0d 32 
|<7>| 0037 - 33 30 37 32 33 30 39 33 35 33 33 5a 30 81 90 31 
|<7>| 0038 - 0b 30 09 06 03 55 04 06 13 02 53 45 31 12 30 10 
|<7>| 0039 - 06 03 55 04 08 13 09 53 74 6f 63 6b 68 6f 6c 6d 
|<7>| 003a - 31 12 30 10 06 03 55 04 07 13 09 53 74 6f 63 6b 
|<7>| 003b - 68 6f 6c 6d 31 0c 30 0a 06 03 55 04 0a 13 03 59 
|<7>| 003c - 58 41 31 0b 30 09 06 03 55 04 0b 13 02 43 41 31 
|<7>| 003d - 18 30 16 06 03 55 04 03 13 0f 79 78 61 2e 65 78 
|<7>| 003e - 74 75 6e 64 6f 2e 63 6f 6d 31 24 30 22 06 09 2a 
|<7>| 003f - 86 48 86 f7 0d 01 09 01 16 15 73 74 61 66 66 40 
|<7>| 0040 - 79 78 61 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 30 
|<7>| 0041 - 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 
|<7>| 0042 - 00 03 81 8d 00 30 81 89 02 81 81 00 b2 8c 2b db 
|<7>| 0043 - c8 c9 f9 30 f2 06 19 25 1e 7a ed d3 dd c9 95 3f 
|<7>| 0044 - 1b 6d 48 68 86 67 b7 d4 55 f4 35 24 ac 2c 3a 84 
|<7>| 0045 - d2 d5 77 09 52 e6 5b 2e e0 c0 b6 9a 7e 36 b9 02 
|<7>| 0046 - 18 4c 94 6a 07 2c fa 68 64 09 4d 10 d9 e1 3b 05 
|<7>| 0047 - 18 47 d3 eb b0 38 0c 92 54 ca bb 94 db 48 09 66 
|<7>| 0048 - b0 61 2c 20 ee cf dd 82 6c a8 df c0 53 d0 f3 4e 
|<7>| 0049 - 6c e9 c6 4c c6 1e 69 de 71 51 93 77 da cb 42 c2 
|<7>| 004a - 7e f6 42 e1 ca 76 16 45 e1 23 0a a3 02 03 01 00 
|<7>| 004b - 01 a3 81 f0 30 81 ed 30 1d 06 03 55 1d 0e 04 16 
|<7>| 004c - 04 14 c7 29 c1 79 fa 28 b4 42 9b 96 ac 70 ce f5 
|<7>| 004d - 50 99 c4 87 c3 15 30 81 bd 06 03 55 1d 23 04 81 
|<7>| 004e - b5 30 81 b2 80 14 c7 29 c1 79 fa 28 b4 42 9b 96 
|<7>| 004f - ac 70 ce f5 50 99 c4 87 c3 15 a1 81 96 a4 81 93 
|<7>| 0050 - 30 81 90 31 0b 30 09 06 03 55 04 06 13 02 53 45 
|<7>| 0051 - 31 12 30 10 06 03 55 04 08 13 09 53 74 6f 63 6b 
|<7>| 0052 - 68 6f 6c 6d 31 12 30 10 06 03 55 04 07 13 09 53 
|<7>| 0053 - 74 6f 63 6b 68 6f 6c 6d 31 0c 30 0a 06 03 55 04 
|<7>| 0054 - 0a 13 03 59 58 41 31 0b 30 09 06 03 55 04 0b 13 
|<7>| 0055 - 02 43 41 31 18 30 16 06 03 55 04 03 13 0f 79 78 
|<7>| 0056 - 61 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 31 24 30 
|<7>| 0057 - 22 06 09 2a 86 48 86 f7 0d 01 09 01 16 15 73 74 
|<7>| 0058 - 61 66 66 40 79 78 61 2e 65 78 74 75 6e 64 6f 2e 
|<7>| 0059 - 63 6f 6d 82 01 00 30 0c 06 03 55 1d 13 04 05 30 
|<7>| 005a - 03 01 01 ff 30 0d 06 09 2a 86 48 86 f7 0d 01 01 
|<7>| 005b - 04 05 00 03 81 81 00 51 7d fc cf ea 70 00 2f ed 
|<7>| 005c - 00 73 21 47 a3 62 1f 8c e6 f3 d4 3c f9 4d ec 25 
|<7>| 005d - eb 76 37 c4 fc 49 a1 ce 28 96 57 d7 6b cb ec 53 
|<7>| 005e - a3 10 ec f3 c2 72 6d 4a 99 3c f4 1f 47 fb 6a e9 
|<7>| 005f - 73 a5 da 3b 61 11 80 0d c7 6e 40 46 c5 04 d6 82 
|<7>| 0060 - 6c 80 d1 7d 4c f6 58 31 9a 68 ac 21 ac c8 8c 10 
|<7>| 0061 - 5a 2a b8 17 9e b1 9d 6a bd 7b 85 73 6b ad e3 68 
|<7>| 0062 - 37 6b 34 f9 6d a8 4e 64 c4 74 f6 a9 92 79 22 30 
|<7>| 0063 - 00 96 99 f9 3e fb b6 
|<7>| RB: Have 5 bytes into buffer. Adding 1591 bytes.
|<7>| RB: Requested 1596 bytes
|<4>| REC[8073cb8]: Decrypted Packet[1] Handshake(22) with length: 1591
|<6>| BUF[HSK]: Inserted 1591 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: CERTIFICATE was received [1591 bytes]
|<6>| BUF[REC][HD]: Read 1587 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 42 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 1587 bytes of Data
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 01 8d 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[2] Handshake(22) with length: 397
|<7>| READ: Got 397 bytes from 4
|<7>| READ: read 397 bytes from 4
|<7>| 0000 - 0c 00 01 89 00 80 e6 96 9d 3d 49 5b e3 2c 7c f1 
|<7>| 0001 - 80 c3 bd d4 79 8e 91 b7 81 82 51 bb 05 5e 2a 20 
|<7>| 0002 - 64 90 4a 79 a7 70 fa 15 a2 59 cb d5 23 a6 a6 ef 
|<7>| 0003 - 09 c4 30 48 d5 a2 2f 97 1f 3c 20 12 9b 48 00 0e 
|<7>| 0004 - 6e dd 06 1c bc 05 3e 37 1d 79 4e 53 27 df 61 1e 
|<7>| 0005 - bb be 1b ac 9b 5c 60 44 cf 02 3d 76 e0 5e ea 9b 
|<7>| 0006 - ad 99 1b 13 a6 3c 97 4e 9e f1 83 9e b5 db 12 51 
|<7>| 0007 - 36 f7 26 2e 56 a8 87 15 38 df d8 23 c6 50 50 85 
|<7>| 0008 - e2 1f 0d d5 c8 6b 00 01 02 00 80 dd d0 01 4e 9a 
|<7>| 0009 - 14 d5 26 7e f7 53 59 8d 1d 57 79 b8 c0 96 5b 49 
|<7>| 000a - 21 6c ec 72 13 46 04 55 c0 da c7 ae 0f 92 04 5e 
|<7>| 000b - e7 e9 94 b5 dd 63 26 32 da 4a 17 db 07 3b 40 f4 
|<7>| 000c - 07 cb 5a 65 d3 fd e5 46 23 bd 33 9e 05 5b 7f c1 
|<7>| 000d - 1b 62 19 20 43 db 50 25 32 5f 96 7b 0c ce a3 65 
|<7>| 000e - ce b8 35 6f 50 0b fe d3 52 7a dd 32 87 51 a2 bb 
|<7>| 000f - 33 b6 a7 2d 4f 48 ce bc 12 e4 49 e0 c7 a7 a6 90 
|<7>| 0010 - 9d 47 84 1a 05 ae de dd ca 30 a3 00 80 33 c3 1d 
|<7>| 0011 - c8 5c ed 14 74 72 1d b9 48 7c 15 c9 6a f9 e9 a6 
|<7>| 0012 - 55 c0 3a c4 87 e8 51 75 a8 dc a7 72 1d fb 50 3e 
|<7>| 0013 - 10 79 14 4f 88 f7 7e 16 e6 f0 6e ca a1 c2 90 e4 
|<7>| 0014 - f9 d8 75 98 9a 25 bc 81 7f d0 2d 89 12 29 6a 78 
|<7>| 0015 - 94 ff 33 57 ac f8 e7 1e a5 2b 26 4f ba c0 c3 f6 
|<7>| 0016 - 5d d8 8a 04 40 c1 2e 6b b3 a5 d7 5e ee 52 6f 97 
|<7>| 0017 - c3 a6 91 ff 0d f4 d0 81 03 fc e7 b7 e9 c6 c5 91 
|<7>| 0018 - bd e8 e4 a4 2a de 33 69 c0 ae 3f a0 92 
|<7>| RB: Have 5 bytes into buffer. Adding 397 bytes.
|<7>| RB: Requested 402 bytes
|<4>| REC[8073cb8]: Decrypted Packet[2] Handshake(22) with length: 397
|<6>| BUF[HSK]: Inserted 397 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: SERVER KEY EXCHANGE was received [397 bytes]
|<6>| BUF[REC][HD]: Read 393 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 1591 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 393 bytes of Data
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 04 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[3] Handshake(22) with length: 4
|<7>| READ: Got 4 bytes from 4
|<7>| READ: read 4 bytes from 4
|<7>| 0000 - 0e 00 00 00 
|<7>| RB: Have 5 bytes into buffer. Adding 4 bytes.
|<7>| RB: Requested 9 bytes
|<4>| REC[8073cb8]: Decrypted Packet[3] Handshake(22) with length: 4
|<6>| BUF[HSK]: Inserted 4 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1100
|<6>| BUF[HSK]: Peeked 397 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<3>| HSK[8073cb8]: CLIENT KEY EXCHANGE was send [134 bytes]
|<6>| BUF[HSK]: Peeked 4 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8073cb8]: Sending Packet[1] Handshake(22) with length: 134
|<7>| WRITE: Will write 139 bytes to 4.
|<7>| WRITE: wrote 139 bytes to 4. Left 0 bytes. Total 139 bytes.
|<7>| 0000 - 16 03 01 00 86 10 00 00 82 00 80 a7 06 d5 30 e3 
|<7>| 0001 - c7 00 58 af f6 99 0b 03 a7 c5 99 e9 ae 99 34 43 
|<7>| 0002 - a4 d0 65 cc f0 eb 5e d5 4f 28 d7 c5 c7 fd 83 c6 
|<7>| 0003 - ff 30 43 4a 18 28 48 72 56 43 00 2f 7d fe df 0d 
|<7>| 0004 - 5a c2 93 c6 bf f3 d6 96 5f b0 3b 6e a9 61 45 34 
|<7>| 0005 - a9 8c f9 40 f6 70 4c e3 17 11 74 9e ba 87 a4 1b 
|<7>| 0006 - 9b 1a 2d 15 f5 90 d5 91 3d 4c c8 13 ac 9a 89 dc 
|<7>| 0007 - 84 00 dd 29 bc ae 41 e0 d9 f8 5f 1c cd 4d a2 08 
|<7>| 0008 - 81 c9 84 2e 3f 90 18 c3 57 d6 1d 
|<4>| REC[8073cb8]: Sent Packet[2] Handshake(22) with length: 139
|<3>| REC[8073cb8]: Sent ChangeCipherSpec
|<4>| REC[8073cb8]: Sending Packet[2] Change Cipher Spec(20) with length: 1
|<7>| WRITE: Will write 6 bytes to 4.
|<7>| WRITE: wrote 6 bytes to 4. Left 0 bytes. Total 6 bytes.
|<7>| 0000 - 14 03 01 00 01 01 
|<4>| REC[8073cb8]: Sent Packet[3] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[128]: 76d0d3a7e7e7c09b8d989e574b44f8ee3f356ede603b781b20b66c5bd0caf02a87a281ff42ad93c174b7924bf46b6c30a43e17fdf5b82069652384c69fdfb65fa479ab382e31c4063a542d32758cfd96310207723889498206a9edacfb130eb756282aa868bbec7256f267d3070d2b47dbb02fe2a09120634a2fbb467cf659ba
|<9>| INT: CLIENT RANDOM[32]: 4831c99dc27d23a2719db615b8f2ab2ae997aa8130177c92f11f23dc7bcdfd62
|<9>| INT: SERVER RANDOM[32]: 4831c99bb4882add5150db953f0a3d42cc7c8ee34c8f7ac912b6c3bb682e19da
|<9>| INT: MASTER SECRET: f25e226cb010cc9bad149edebda0ca472f4c828e5e51874e2b13a04dd9f3cf6881e4dc05b10ad73d71b40785454a9882
|<9>| INT: KEY BLOCK[104]: 4f9b6e4a1b568323116343cae0bb559af978fe104b17b1e421b0c01cdb23849f
|<9>| INT: CLIENT WRITE KEY [16]: 58a6780b33ea308102bbef4dacfd4f85
|<9>| INT: SERVER WRITE KEY [16]: 9bd8cdcad0f455419867ceb077483e9f
|<3>| HSK[8073cb8]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Initializing internal [write] cipher sessions
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<3>| HSK[8073cb8]: FINISHED was send [16 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8073cb8]: Sending Packet[0] Handshake(22) with length: 16
|<7>| WRITE: Will write 277 bytes to 4.
|<7>| WRITE: wrote 277 bytes to 4. Left 0 bytes. Total 277 bytes.
|<7>| 0000 - 16 03 01 01 10 f2 e3 de 12 58 33 ed d5 aa c7 93 
|<7>| 0001 - dc a1 4a 6f cc f3 f9 1e 56 bc 90 19 13 aa 50 d3 
|<7>| 0002 - 6d 36 3f 12 13 8f 5f d6 72 49 2b 3d a8 31 86 34 
|<7>| 0003 - bf a3 96 9e 0b 96 8c 83 24 f6 4e 07 3d 86 91 08 
|<7>| 0004 - 4a db 66 26 d2 0a cb b3 15 de 4f a7 08 30 ec 91 
|<7>| 0005 - 6d fd 10 1b 76 9b 17 a2 56 d7 b3 0b d9 47 30 55 
|<7>| 0006 - fc ac 11 5d 50 39 a7 6a f4 57 6f bb cd 13 d9 79 
|<7>| 0007 - 87 61 02 35 10 7c a8 15 a5 a4 1e 09 ae 43 9f fc 
|<7>| 0008 - 0e 00 ea 3b 89 0e 3f bd 90 c1 55 ea 4b f8 65 34 
|<7>| 0009 - ab 85 0d 4d 1d 02 c9 25 5b d8 2a f8 d0 62 21 f8 
|<7>| 000a - 99 36 1c bf 2c e4 fb 60 86 25 c8 42 fb a5 81 9f 
|<7>| 000b - 57 45 40 35 38 9f 35 7d 2e bb 09 af d3 25 18 35 
|<7>| 000c - 1a db de c3 95 35 ad e1 d0 ea be 1b d3 c2 72 32 
|<7>| 000d - 1d fd 0b 6e 3e 9a 3e 36 2c 8e 2e da df 16 0d 1d 
|<7>| 000e - 2a 8d 73 61 b8 a7 c6 fc 02 7b df 39 f4 b3 e8 eb 
|<7>| 000f - 8d bd a0 c5 ea 49 3f 7e 78 7a c9 e6 d1 11 af c4 
|<7>| 0010 - c9 fc e9 d7 29 60 25 dd eb 27 5a 33 71 14 ed a9 
|<7>| 0011 - e1 87 02 69 2a 
|<4>| REC[8073cb8]: Sent Packet[1] Handshake(22) with length: 277
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 14 03 01 00 01 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[4] Change Cipher Spec(20) with length: 1
|<4>| REC[8073cb8]: Received Packet[4] Change Cipher Spec(20) with length: 1
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 01 
|<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
|<7>| RB: Requested 6 bytes
|<4>| REC[8073cb8]: ChangeCipherSpec Packet was received
|<3>| HSK[8073cb8]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Initializing internal [read] cipher sessions
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 30 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[0] Handshake(22) with length: 48
|<7>| READ: Got 48 bytes from 4
|<7>| READ: read 48 bytes from 4
|<7>| 0000 - 01 4a ab 02 7b 0c 10 d9 4f d8 b5 1d 09 c0 e3 c6 
|<7>| 0001 - 37 64 2e 4c 9c 2a a3 ef be 3f 14 b3 c0 a1 6a a5 
|<7>| 0002 - 53 70 ab 48 0a c5 88 dd 6a df c7 ba 38 fe d6 d5 
|<7>| 0003 - 
|<7>| RB: Have 5 bytes into buffer. Adding 48 bytes.
|<7>| RB: Requested 53 bytes
|<4>| REC[8073cb8]: Decrypted Packet[0] Handshake(22) with length: 16
|<6>| BUF[HSK]: Inserted 16 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: FINISHED was received [16 bytes]
|<6>| BUF[REC][HD]: Read 12 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 12 bytes of Data
|<6>| BUF[HSK]: Cleared Data from buffer
|<2>| ASSERT: ext_server_name.c:244
Resolving 'www.gnutls.org'...
Connecting to '83.241.177.38:443'...
- Ephemeral DH using prime of 1032 bits, secret key of 1014 bits, and peer's public key is 1032 bits.
- Certificate type: X.509
 - Got a certificate list of 2 certificates.

 - Certificate[0] info:
 # The hostname in the certificate does NOT match 'www.gnutls.org'.
 # valid since: Sun May 23 09:36:29 UTC 2004
 # expires at: Sun Jul 23 09:36:29 UTC 2023
 # fingerprint: 81:55:19:D4:46:46:98:8A:E3:58:94:E7:BE:F9:BD:19
 # Subject's DN: C=SE,ST=Stockholm,L=Stockholm,O=YXA,OU=Web server,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com
 # Issuer's DN: C=SE,ST=Stockholm,L=Stockholm,O=YXA,OU=CA,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com

 - Certificate[1] info:
 # valid since: Sun May 23 09:35:33 UTC 2004
 # expires at: Sun Jul 23 09:35:33 UTC 2023
 # fingerprint: FC:76:D8:63:1A:C9:0B:3B:FA:40:FE:ED:47:7A:58:AE
 # Subject's DN: C=SE,ST=Stockholm,L=Stockholm,O=YXA,OU=CA,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com
 # Issuer's DN: C=SE,ST=Stockholm,L|<2>| ASSERT: verify.c:242
|<2>| ASSERT: verify.c:398
=Stockholm,O=YXA,OU=CA,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com


- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

|<4>| REC[8073cb8]: Sending Packet[1] Application Data(23) with length: 6
|<7>| WRITE: Will write 133 bytes to 4.
|<7>| WRITE: wrote 133 bytes to 4. Left 0 bytes. Total 133 bytes.
|<7>| 0000 - 17 03 01 00 80 dd 79 ee aa 77 f0 0b fe 8d ab 91 
|<7>| 0001 - 7a 05 0c da bc df 60 d8 4f e0 9d ff 86 d0 c8 a3 
|<7>| 0002 - 61 f1 a4 15 f5 91 a1 1e 31 53 67 4b 89 bf 9c 3e 
|<7>| 0003 - 53 d0 80 a4 55 09 22 29 98 4f 6a 45 23 a8 dc 2e 
|<7>| 0004 - 85 74 57 3e 7f 07 5b af dd 49 cb ff 64 94 cc 1b 
|<7>| 0005 - 3b 48 2f 0b 62 9d 8c b3 9b 51 c8 d6 9b b6 ce 8c 
|<7>| 0006 - b2 8d 27 8c ff 48 0b ff 56 8a d5 87 9f c2 ab 7c 
|<7>| 0007 - 46 44 11 c9 0f b3 be c3 38 96 18 64 fb a5 f0 43 
|<7>| 0008 - 58 4e 78 88 97 
|<4>| REC[8073cb8]: Sent Packet[2] Application Data(23) with length: 133
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 17 03 01 01 60 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[1] Application Data(23) with length: 4096
|<4>| REC[8073cb8]: Received Packet[1] Application Data(23) with length: 352
|<7>| READ: Got 351 bytes from 4
|<7>| READ: read 351 bytes from 4
|<7>| 0000 - 07 a6 93 25 85 24 a3 15 66 ee b8 8d 4c 93 1c 5b 
|<7>| 0001 - 1a be d9 50 c2 2f 5e f6 4e f7 63 15 8f 61 44 07 
|<7>| 0002 - c9 c1 48 55 a8 43 19 fe 8f 15 1c b6 82 e5 2b e6 
|<7>| 0003 - 38 a1 50 58 65 f3 05 65 06 45 28 34 84 d6 c2 b1 
|<7>| 0004 - 0c 8e 4e 99 43 78 ef 5f 4f bc 18 d6 7e e9 6a ca 
|<7>| 0005 - 50 40 c7 50 97 8f 56 d3 61 13 cc de 20 d8 ff 39 
|<7>| 0006 - a4 1c 02 cf c3 87 3b 6b db f3 3e 01 ae a8 3f 0b 
|<7>| 0007 - 8b 37 21 24 c6 b6 e8 11 20 fa 0e 9a ed a2 4c 2b 
|<7>| 0008 - 6c 15 5f 61 c6 1f b9 d2 a2 f9 e3 ee 29 a9 a0 9f 
|<7>| 0009 - 6f 78 84 f4 2d a4 7a 44 2e 40 ae ed bd 60 ca 4b 
|<7>| 000a - 0a e5 c4 17 fd 73 fe 26 ff 05 37 54 ba 45 09 6d 
|<7>| 000b - 59 77 45 d5 39 62 61 c5 bd 19 22 03 2a 70 4e 2e 
|<7>| 000c - 05 1d 56 ab 61 15 2a 6d 43 a7 e4 67 fd 8c 4f de 
|<7>| 000d - 16 c8 71 b3 3b c6 b0 3c f9 e8 76 5b ff 74 ad d9 
|<7>| 000e - e9 71 01 ca 98 e3 55 2d 0b 51 f8 ac 42 b5 5f 43 
|<7>| 000f - 91 17 a3 65 6a c9 95 d6 ec 05 86 85 20 31 c5 d2 
|<7>| 0010 - 65 24 88 af 0d 1a 82 77 17 ef 96 5c 1e 0f ea 41 
|<7>| 0011 - 82 0f 2a ed a8 ce 31 77 df b3 5b cf 70 f9 f2 ae 
|<7>| 0012 - 3a 3f 3c 37 c5 f7 5f 72 31 3e 6d a9 72 64 94 97 
|<7>| 0013 - 06 ec 1a 64 52 b0 ca 1d 02 eb c3 de ee 08 f8 51 
|<7>| 0014 - 26 07 b5 fd 66 06 f3 2c d1 f6 c5 8e ef 7a f9 9e 
|<7>| 0015 - 42 00 7c de 08 3e 2b e1 b3 a5 35 97 1a e0 fa 
|<7>| RB: Have 5 bytes into buffer. Adding 351 bytes.
|<7>| RB: Requested 357 bytes
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 2e 
|<7>| RB-PEEK: Read 1 bytes in PEEK MODE.
|<7>| RB-PEEK: Have 356 bytes into buffer. Adding 1 bytes.
RB: Requested 357 bytes
|<4>| REC[8073cb8]: Decrypted Packet[1] Application Data(23) with length: 320
|<6>| BUF[REC]: Inserted 320 bytes of Data(23)
|<6>| BUFFER[REC][AD]: Read 320 bytes of Data(23)
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 2e 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Invalid URI in request get x<P>
<HR>
<ADDRESS>Apache/1.3.33 Server at yxa.extundo.com Port 443</ADDRESS>
</BODY></HTML>
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 15 03 01 00 20 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[2] Application Data(23) with length: 4096
|<4>| REC[8073cb8]: Received Packet[2] Alert(21) with length: 32
|<7>| READ: Got 32 bytes from 4
|<7>| READ: read 32 bytes from 4
|<7>| 0000 - 59 90 6e c8 8e 3c e9 c1 db b0 78 f0 8f 6d 10 eb 
|<7>| 0001 - 6a 67 a8 62 9d e2 f0 c2 db 0e 15 93 63 1e 05 55 
|<7>| 0002 - 
|<7>| RB: Have 5 bytes into buffer. Adding 32 bytes.
|<7>| RB: Requested 37 bytes
|<4>| REC[8073cb8]: Decrypted Packet[2] Alert(21) with length: 2
|<4>| REC[8073cb8]: Alert[1|0] - Close notify - was received
- Peer has closed the GNUTLS connection
-------------- next part --------------
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8073cb8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[8073cb8]: Sending extension CERT_TYPE
|<2>| EXT[8073cb8]: Sending extension SERVER_NAME
|<3>| HSK[8073cb8]: CLIENT HELLO was send [111 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8073cb8]: Sending Packet[0] Handshake(22) with length: 111
|<7>| WRITE: Will write 116 bytes to 4.
|<7>| WRITE: wrote 116 bytes to 4. Left 0 bytes. Total 116 bytes.
|<7>| 0000 - 16 03 02 00 6f 01 00 00 6b 03 02 48 31 c9 0c 89 
|<7>| 0001 - 10 75 b6 82 05 c6 42 cc 14 1d 45 b3 3e e5 0e 71 
|<7>| 0002 - ad e0 ec 7b c4 56 e6 cd 29 37 c7 00 00 24 00 33 
|<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 
|<7>| 0004 - 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 
|<7>| 0005 - 00 04 01 00 00 1e 00 09 00 03 02 00 01 00 00 00 
|<7>| 0006 - 13 00 11 00 00 0e 77 77 77 2e 67 6e 75 74 6c 73 
|<7>| 0007 - 2e 6f 72 67 
|<4>| REC[8073cb8]: Sent Packet[1] Handshake(22) with length: 116
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 2a 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[0] Handshake(22) with length: 42
|<7>| READ: Got 42 bytes from 4
|<7>| READ: read 42 bytes from 4
|<7>| 0000 - 02 00 00 26 03 01 48 31 c9 0a b4 4c e5 b9 0b d4 
|<7>| 0001 - f5 2f 1b 9e 4a 1c ae 3d 41 a4 fb 1b 6b a5 d1 bc 
|<7>| 0002 - 1e e2 0f 5b df 00 00 00 33 00 
|<7>| RB: Have 5 bytes into buffer. Adding 42 bytes.
|<7>| RB: Requested 47 bytes
|<4>| REC[8073cb8]: Decrypted Packet[0] Handshake(22) with length: 42
|<6>| BUF[HSK]: Inserted 42 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: SERVER HELLO was received [42 bytes]
|<6>| BUF[REC][HD]: Read 38 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 38 bytes of Data
|<3>| HSK[8073cb8]: Server's version: 3.1
|<3>| HSK[8073cb8]: SessionID length: 0
|<3>| HSK[8073cb8]: SessionID: 
|<3>| HSK[8073cb8]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:165
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 06 37 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[1] Handshake(22) with length: 1591
|<7>| READ: Got 1388 bytes from 4
|<7>| READ: Got 203 bytes from 4
|<7>| READ: read 1591 bytes from 4
|<7>| 0000 - 0b 00 06 33 00 06 30 00 02 9d 30 82 02 99 30 82 
|<7>| 0001 - 02 02 02 01 02 30 0d 06 09 2a 86 48 86 f7 0d 01 
|<7>| 0002 - 01 04 05 00 30 81 90 31 0b 30 09 06 03 55 04 06 
|<7>| 0003 - 13 02 53 45 31 12 30 10 06 03 55 04 08 13 09 53 
|<7>| 0004 - 74 6f 63 6b 68 6f 6c 6d 31 12 30 10 06 03 55 04 
|<7>| 0005 - 07 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 0c 30 0a 
|<7>| 0006 - 06 03 55 04 0a 13 03 59 58 41 31 0b 30 09 06 03 
|<7>| 0007 - 55 04 0b 13 02 43 41 31 18 30 16 06 03 55 04 03 
|<7>| 0008 - 13 0f 79 78 61 2e 65 78 74 75 6e 64 6f 2e 63 6f 
|<7>| 0009 - 6d 31 24 30 22 06 09 2a 86 48 86 f7 0d 01 09 01 
|<7>| 000a - 16 15 73 74 61 66 66 40 79 78 61 2e 65 78 74 75 
|<7>| 000b - 6e 64 6f 2e 63 6f 6d 30 1e 17 0d 30 34 30 35 32 
|<7>| 000c - 33 30 39 33 36 32 39 5a 17 0d 32 33 30 37 32 33 
|<7>| 000d - 30 39 33 36 32 39 5a 30 81 98 31 0b 30 09 06 03 
|<7>| 000e - 55 04 06 13 02 53 45 31 12 30 10 06 03 55 04 08 
|<7>| 000f - 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 12 30 10 06 
|<7>| 0010 - 03 55 04 07 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 
|<7>| 0011 - 0c 30 0a 06 03 55 04 0a 13 03 59 58 41 31 13 30 
|<7>| 0012 - 11 06 03 55 04 0b 13 0a 57 65 62 20 73 65 72 76 
|<7>| 0013 - 65 72 31 18 30 16 06 03 55 04 03 13 0f 79 78 61 
|<7>| 0014 - 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 31 24 30 22 
|<7>| 0015 - 06 09 2a 86 48 86 f7 0d 01 09 01 16 15 73 74 61 
|<7>| 0016 - 66 66 40 79 78 61 2e 65 78 74 75 6e 64 6f 2e 63 
|<7>| 0017 - 6f 6d 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 
|<7>| 0018 - 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 a0 
|<7>| 0019 - 59 95 c1 18 7f 71 77 af 93 da 0a 83 2e 22 80 cc 
|<7>| 001a - cf 09 e5 dd 95 93 fc 61 9a 02 01 30 8d 4e 4d 21 
|<7>| 001b - 15 1f a9 45 79 2e 92 13 92 06 df f7 ff 65 ee d0 
|<7>| 001c - 61 f8 19 b9 55 60 6a c5 0d 81 7a d5 8e 6a 08 46 
|<7>| 001d - 50 5a 7f 18 e9 70 9a df c1 3a 35 3a 77 de 2e f0 
|<7>| 001e - d5 b7 c5 02 7e 54 f7 a3 0d c1 c6 f0 06 04 00 84 
|<7>| 001f - 12 d9 e2 40 1a 07 60 43 20 0a 32 5c 9a a9 80 d7 
|<7>| 0020 - fc 5b a6 5c 3d 1d 1b c4 13 aa a6 35 60 c3 c5 02 
|<7>| 0021 - 03 01 00 01 30 0d 06 09 2a 86 48 86 f7 0d 01 01 
|<7>| 0022 - 04 05 00 03 81 81 00 9c 25 73 6f cc ac 6e e3 63 
|<7>| 0023 - bb 8e e5 79 47 f6 ca 55 bd 47 51 89 92 ca 92 8e 
|<7>| 0024 - 35 7a 65 80 8c 9d 08 9e 06 21 d8 7f 9f 5f 0d 7f 
|<7>| 0025 - eb ed f4 1c a3 7b 39 a8 e0 05 93 fd dc 03 51 5b 
|<7>| 0026 - 39 6f 67 3d 84 67 2e f3 2f 64 98 98 a9 93 d6 6e 
|<7>| 0027 - 49 4f c7 66 fa e4 4a a3 73 24 55 9a 86 05 0c 4b 
|<7>| 0028 - 29 49 3e eb b0 46 fc a7 95 59 c2 20 fe 48 ea a6 
|<7>| 0029 - bb 61 17 6a b1 64 82 c9 31 43 d3 cd fe 3b 3f e6 
|<7>| 002a - 8d bf f7 20 0e f1 b8 00 03 8d 30 82 03 89 30 82 
|<7>| 002b - 02 f2 a0 03 02 01 02 02 01 00 30 0d 06 09 2a 86 
|<7>| 002c - 48 86 f7 0d 01 01 04 05 00 30 81 90 31 0b 30 09 
|<7>| 002d - 06 03 55 04 06 13 02 53 45 31 12 30 10 06 03 55 
|<7>| 002e - 04 08 13 09 53 74 6f 63 6b 68 6f 6c 6d 31 12 30 
|<7>| 002f - 10 06 03 55 04 07 13 09 53 74 6f 63 6b 68 6f 6c 
|<7>| 0030 - 6d 31 0c 30 0a 06 03 55 04 0a 13 03 59 58 41 31 
|<7>| 0031 - 0b 30 09 06 03 55 04 0b 13 02 43 41 31 18 30 16 
|<7>| 0032 - 06 03 55 04 03 13 0f 79 78 61 2e 65 78 74 75 6e 
|<7>| 0033 - 64 6f 2e 63 6f 6d 31 24 30 22 06 09 2a 86 48 86 
|<7>| 0034 - f7 0d 01 09 01 16 15 73 74 61 66 66 40 79 78 61 
|<7>| 0035 - 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 30 1e 17 0d 
|<7>| 0036 - 30 34 30 35 32 33 30 39 33 35 33 33 5a 17 0d 32 
|<7>| 0037 - 33 30 37 32 33 30 39 33 35 33 33 5a 30 81 90 31 
|<7>| 0038 - 0b 30 09 06 03 55 04 06 13 02 53 45 31 12 30 10 
|<7>| 0039 - 06 03 55 04 08 13 09 53 74 6f 63 6b 68 6f 6c 6d 
|<7>| 003a - 31 12 30 10 06 03 55 04 07 13 09 53 74 6f 63 6b 
|<7>| 003b - 68 6f 6c 6d 31 0c 30 0a 06 03 55 04 0a 13 03 59 
|<7>| 003c - 58 41 31 0b 30 09 06 03 55 04 0b 13 02 43 41 31 
|<7>| 003d - 18 30 16 06 03 55 04 03 13 0f 79 78 61 2e 65 78 
|<7>| 003e - 74 75 6e 64 6f 2e 63 6f 6d 31 24 30 22 06 09 2a 
|<7>| 003f - 86 48 86 f7 0d 01 09 01 16 15 73 74 61 66 66 40 
|<7>| 0040 - 79 78 61 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 30 
|<7>| 0041 - 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 
|<7>| 0042 - 00 03 81 8d 00 30 81 89 02 81 81 00 b2 8c 2b db 
|<7>| 0043 - c8 c9 f9 30 f2 06 19 25 1e 7a ed d3 dd c9 95 3f 
|<7>| 0044 - 1b 6d 48 68 86 67 b7 d4 55 f4 35 24 ac 2c 3a 84 
|<7>| 0045 - d2 d5 77 09 52 e6 5b 2e e0 c0 b6 9a 7e 36 b9 02 
|<7>| 0046 - 18 4c 94 6a 07 2c fa 68 64 09 4d 10 d9 e1 3b 05 
|<7>| 0047 - 18 47 d3 eb b0 38 0c 92 54 ca bb 94 db 48 09 66 
|<7>| 0048 - b0 61 2c 20 ee cf dd 82 6c a8 df c0 53 d0 f3 4e 
|<7>| 0049 - 6c e9 c6 4c c6 1e 69 de 71 51 93 77 da cb 42 c2 
|<7>| 004a - 7e f6 42 e1 ca 76 16 45 e1 23 0a a3 02 03 01 00 
|<7>| 004b - 01 a3 81 f0 30 81 ed 30 1d 06 03 55 1d 0e 04 16 
|<7>| 004c - 04 14 c7 29 c1 79 fa 28 b4 42 9b 96 ac 70 ce f5 
|<7>| 004d - 50 99 c4 87 c3 15 30 81 bd 06 03 55 1d 23 04 81 
|<7>| 004e - b5 30 81 b2 80 14 c7 29 c1 79 fa 28 b4 42 9b 96 
|<7>| 004f - ac 70 ce f5 50 99 c4 87 c3 15 a1 81 96 a4 81 93 
|<7>| 0050 - 30 81 90 31 0b 30 09 06 03 55 04 06 13 02 53 45 
|<7>| 0051 - 31 12 30 10 06 03 55 04 08 13 09 53 74 6f 63 6b 
|<7>| 0052 - 68 6f 6c 6d 31 12 30 10 06 03 55 04 07 13 09 53 
|<7>| 0053 - 74 6f 63 6b 68 6f 6c 6d 31 0c 30 0a 06 03 55 04 
|<7>| 0054 - 0a 13 03 59 58 41 31 0b 30 09 06 03 55 04 0b 13 
|<7>| 0055 - 02 43 41 31 18 30 16 06 03 55 04 03 13 0f 79 78 
|<7>| 0056 - 61 2e 65 78 74 75 6e 64 6f 2e 63 6f 6d 31 24 30 
|<7>| 0057 - 22 06 09 2a 86 48 86 f7 0d 01 09 01 16 15 73 74 
|<7>| 0058 - 61 66 66 40 79 78 61 2e 65 78 74 75 6e 64 6f 2e 
|<7>| 0059 - 63 6f 6d 82 01 00 30 0c 06 03 55 1d 13 04 05 30 
|<7>| 005a - 03 01 01 ff 30 0d 06 09 2a 86 48 86 f7 0d 01 01 
|<7>| 005b - 04 05 00 03 81 81 00 51 7d fc cf ea 70 00 2f ed 
|<7>| 005c - 00 73 21 47 a3 62 1f 8c e6 f3 d4 3c f9 4d ec 25 
|<7>| 005d - eb 76 37 c4 fc 49 a1 ce 28 96 57 d7 6b cb ec 53 
|<7>| 005e - a3 10 ec f3 c2 72 6d 4a 99 3c f4 1f 47 fb 6a e9 
|<7>| 005f - 73 a5 da 3b 61 11 80 0d c7 6e 40 46 c5 04 d6 82 
|<7>| 0060 - 6c 80 d1 7d 4c f6 58 31 9a 68 ac 21 ac c8 8c 10 
|<7>| 0061 - 5a 2a b8 17 9e b1 9d 6a bd 7b 85 73 6b ad e3 68 
|<7>| 0062 - 37 6b 34 f9 6d a8 4e 64 c4 74 f6 a9 92 79 22 30 
|<7>| 0063 - 00 96 99 f9 3e fb b6 
|<7>| RB: Have 5 bytes into buffer. Adding 1591 bytes.
|<7>| RB: Requested 1596 bytes
|<4>| REC[8073cb8]: Decrypted Packet[1] Handshake(22) with length: 1591
|<6>| BUF[HSK]: Inserted 1591 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: CERTIFICATE was received [1591 bytes]
|<6>| BUF[REC][HD]: Read 1587 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 42 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 1587 bytes of Data
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 01 8d 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[2] Handshake(22) with length: 397
|<7>| READ: Got 397 bytes from 4
|<7>| READ: read 397 bytes from 4
|<7>| 0000 - 0c 00 01 89 00 80 e6 96 9d 3d 49 5b e3 2c 7c f1 
|<7>| 0001 - 80 c3 bd d4 79 8e 91 b7 81 82 51 bb 05 5e 2a 20 
|<7>| 0002 - 64 90 4a 79 a7 70 fa 15 a2 59 cb d5 23 a6 a6 ef 
|<7>| 0003 - 09 c4 30 48 d5 a2 2f 97 1f 3c 20 12 9b 48 00 0e 
|<7>| 0004 - 6e dd 06 1c bc 05 3e 37 1d 79 4e 53 27 df 61 1e 
|<7>| 0005 - bb be 1b ac 9b 5c 60 44 cf 02 3d 76 e0 5e ea 9b 
|<7>| 0006 - ad 99 1b 13 a6 3c 97 4e 9e f1 83 9e b5 db 12 51 
|<7>| 0007 - 36 f7 26 2e 56 a8 87 15 38 df d8 23 c6 50 50 85 
|<7>| 0008 - e2 1f 0d d5 c8 6b 00 01 02 00 80 12 7b 70 eb 09 
|<7>| 0009 - b2 b0 f9 aa 6e 5c 13 0a 71 90 19 83 84 b4 65 c2 
|<7>| 000a - df d3 f8 8e 71 0c 8f c5 93 f4 b7 24 73 01 42 81 
|<7>| 000b - 32 00 b2 2f 26 ff eb dc d0 34 3b 7a 69 34 e6 be 
|<7>| 000c - b3 04 64 f5 9a 13 64 6b 57 82 c8 f9 f9 aa 68 8b 
|<7>| 000d - 96 5f 53 76 73 be ab 72 f1 72 4a 3c 5c e6 0d d3 
|<7>| 000e - c9 e7 49 6e 47 2d 23 bc f9 6e d5 bb 6b 10 9f 87 
|<7>| 000f - 9b a0 b9 65 58 7c 3c 6b 8a f0 e6 2a 79 a1 46 5c 
|<7>| 0010 - 03 66 72 f2 a5 78 40 3b ea 2c 9e 00 80 06 74 f2 
|<7>| 0011 - 04 eb bd 93 d0 79 d1 4e cc 52 dc 53 d1 a9 85 e1 
|<7>| 0012 - ca ae d3 c2 e9 30 2c cf ef 2b 2d 18 d6 2c ce 20 
|<7>| 0013 - 2c 13 52 66 84 81 79 74 79 aa 46 47 8c 73 33 b1 
|<7>| 0014 - 09 72 44 2f 01 64 fb cf de 84 2b e8 20 59 80 37 
|<7>| 0015 - dc 61 39 ec 05 da 22 08 ea 25 45 3d c3 a6 79 89 
|<7>| 0016 - 5b e1 83 16 ac 76 2a 8c c3 d5 83 95 23 c2 d1 16 
|<7>| 0017 - 2c 0a 68 cb 4f 4f 63 e0 1f b4 7f 55 26 04 ab 06 
|<7>| 0018 - 6d 25 ff 51 87 db ba e8 1e 50 01 c3 25 
|<7>| RB: Have 5 bytes into buffer. Adding 397 bytes.
|<7>| RB: Requested 402 bytes
|<4>| REC[8073cb8]: Decrypted Packet[2] Handshake(22) with length: 397
|<6>| BUF[HSK]: Inserted 397 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: SERVER KEY EXCHANGE was received [397 bytes]
|<6>| BUF[REC][HD]: Read 393 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 1591 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 393 bytes of Data
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 04 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[3] Handshake(22) with length: 4
|<7>| READ: Got 4 bytes from 4
|<7>| READ: read 4 bytes from 4
|<7>| 0000 - 0e 00 00 00 
|<7>| RB: Have 5 bytes into buffer. Adding 4 bytes.
|<7>| RB: Requested 9 bytes
|<4>| REC[8073cb8]: Decrypted Packet[3] Handshake(22) with length: 4
|<6>| BUF[HSK]: Inserted 4 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1108
|<6>| BUF[HSK]: Peeked 397 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<3>| HSK[8073cb8]: CLIENT KEY EXCHANGE was send [134 bytes]
|<6>| BUF[HSK]: Peeked 4 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8073cb8]: Sending Packet[1] Handshake(22) with length: 134
|<7>| WRITE: Will write 139 bytes to 4.
|<7>| WRITE: wrote 139 bytes to 4. Left 0 bytes. Total 139 bytes.
|<7>| 0000 - 16 03 01 00 86 10 00 00 82 00 80 92 5f 62 82 47 
|<7>| 0001 - 8f b1 c2 8c 99 9f 3b 6a 32 17 d0 47 bf b3 e2 7c 
|<7>| 0002 - 87 7b c7 cc ed ff 8d b7 70 f8 04 26 e8 0e 24 09 
|<7>| 0003 - 20 43 20 fc 04 32 b0 1a cb d5 7b c1 9d e6 39 aa 
|<7>| 0004 - 34 a1 f0 2b 51 a9 d5 77 91 7b 06 10 0f fc 7c 50 
|<7>| 0005 - e8 66 1b 29 b7 57 9e 63 7d 2e 01 61 ec fd cb d7 
|<7>| 0006 - ae fc af 49 ea f6 36 37 f8 da f9 d4 8d e9 a3 39 
|<7>| 0007 - 68 47 83 01 69 c1 a8 d2 ac f9 ce d5 16 9a 50 17 
|<7>| 0008 - 45 05 97 10 de ac 67 4d 17 1c e0 
|<4>| REC[8073cb8]: Sent Packet[2] Handshake(22) with length: 139
|<3>| REC[8073cb8]: Sent ChangeCipherSpec
|<4>| REC[8073cb8]: Sending Packet[2] Change Cipher Spec(20) with length: 1
|<7>| WRITE: Will write 6 bytes to 4.
|<7>| WRITE: wrote 6 bytes to 4. Left 0 bytes. Total 6 bytes.
|<7>| 0000 - 14 03 01 00 01 01 
|<4>| REC[8073cb8]: Sent Packet[3] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[128]: aea27e89701f196c00fa7aa6fc40c127014a2f76eb5b6aaf72dd5edc3a9da4d4ed0b515a8e8117997c30c63931b5b2f105a7ca0fa96e0d3137fc336df4879f78edccfc7bc6e299e83b4a1a38ce16be96804bdea241429962641b8f0babe38f7b288aa651caff342dbdb277a052c942eb062cce6f709dc10625c33959e96bdbfc
|<9>| INT: CLIENT RANDOM[32]: 4831c90c891075b68205c642cc141d45b33ee50e71ade0ec7bc456e6cd2937c7
|<9>| INT: SERVER RANDOM[32]: 4831c90ab44ce5b90bd4f52f1b9e4a1cae3d41a4fb1b6ba5d1bc1ee20f5bdf00
|<9>| INT: MASTER SECRET: 50f8e26a1caa5e4461c0c19c2b18c794a100c588a97c4d1b810e510e5906523400ee242c16a43712892d8b17d42439c4
|<9>| INT: KEY BLOCK[104]: b2f3964c2560d48d5e38acb667694848c2c3d06adeb5bf6296cda7123053f027
|<9>| INT: CLIENT WRITE KEY [16]: 26165653e2fda51d64179f6fa16be925
|<9>| INT: SERVER WRITE KEY [16]: 13c08fc51b2c85ce4169ced12a057101
|<3>| HSK[8073cb8]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Initializing internal [write] cipher sessions
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<3>| HSK[8073cb8]: FINISHED was send [16 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8073cb8]: Sending Packet[0] Handshake(22) with length: 16
|<7>| WRITE: Will write 261 bytes to 4.
|<7>| WRITE: wrote 261 bytes to 4. Left 0 bytes. Total 261 bytes.
|<7>| 0000 - 16 03 01 01 00 16 8c 58 4d 7a ce 71 19 3d fc ff 
|<7>| 0001 - 59 d4 11 b0 6e 67 c7 07 6f 18 22 bf 44 c8 b9 2b 
|<7>| 0002 - cc f1 6c 4d 70 0b df 1f 09 23 80 f8 d3 8b d6 ec 
|<7>| 0003 - bf 66 7b f1 07 3b b9 16 87 cd 6b 2d 27 d0 ef 37 
|<7>| 0004 - 5d b4 68 a8 8d 8d 70 66 86 f3 43 93 ec 40 4b c8 
|<7>| 0005 - fd fb 2b a1 e1 87 d3 fd 3e 87 b8 d1 c5 ac 4f d4 
|<7>| 0006 - 37 b1 71 87 0a 76 ac 39 33 82 d6 09 43 33 e9 4d 
|<7>| 0007 - 12 40 a4 96 aa 95 ef 98 6b 2c 4c 4b eb cd fd 65 
|<7>| 0008 - d5 b9 9e 4c 90 50 3b f0 49 ad f1 0e 3c d6 0c 2d 
|<7>| 0009 - cb 18 d4 f0 4a f4 fe d0 24 c5 22 a2 99 43 d2 ea 
|<7>| 000a - 8c 8e 4e 8d d8 87 0f 57 d2 b2 dc f8 86 87 73 e3 
|<7>| 000b - 4e 4e a5 1f 96 d2 e9 a6 5f 46 b0 99 4f 75 c9 af 
|<7>| 000c - b2 b3 f4 85 50 15 b3 15 8a 1b 3c 4a 71 7a 36 b6 
|<7>| 000d - f1 9b a6 71 99 e2 ce 87 fc 43 f4 80 36 00 4b 30 
|<7>| 000e - 9a bc 2f 63 16 3d 68 64 04 e5 ec a6 eb d1 48 af 
|<7>| 000f - 65 8d a8 8f 12 48 c3 96 7b a0 ad f8 93 f3 c3 3d 
|<7>| 0010 - 53 5e 16 32 e5 
|<4>| REC[8073cb8]: Sent Packet[1] Handshake(22) with length: 261
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 14 03 01 00 01 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[4] Change Cipher Spec(20) with length: 1
|<4>| REC[8073cb8]: Received Packet[4] Change Cipher Spec(20) with length: 1
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 01 
|<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
|<7>| RB: Requested 6 bytes
|<4>| REC[8073cb8]: ChangeCipherSpec Packet was received
|<3>| HSK[8073cb8]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8073cb8]: Initializing internal [read] cipher sessions
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 30 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8073cb8]: Received Packet[0] Handshake(22) with length: 48
|<7>| READ: Got 48 bytes from 4
|<7>| READ: read 48 bytes from 4
|<7>| 0000 - dd e2 09 db b6 02 ff d7 e2 6d 0b 42 02 d5 19 ca 
|<7>| 0001 - 02 00 7e cc f1 bb 31 7c 65 19 a1 1c f7 20 8f 18 
|<7>| 0002 - b8 54 9e d7 dc 82 82 17 b9 f8 c6 d6 61 f2 3f 1a 
|<7>| 0003 - 
|<7>| RB: Have 5 bytes into buffer. Adding 48 bytes.
|<7>| RB: Requested 53 bytes
|<4>| REC[8073cb8]: Decrypted Packet[0] Handshake(22) with length: 16
|<6>| BUF[HSK]: Inserted 16 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8073cb8]: FINISHED was received [16 bytes]
|<6>| BUF[REC][HD]: Read 12 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 12 bytes of Data
|<6>| BUF[HSK]: Cleared Data from buffer
|<2>| ASSERT: ext_server_name.c:257
Resolving 'www.gnutls.org'...
Connecting to '83.241.177.38:443'...
- Ephemeral DH using prime of 1032 bits, secret key of 1015 bits, and peer's public key is 1024 bits.
- Certificate type: X.509
 - Got a certificate list of 2 certificates.

 - Certificate[0] info:
 # The hostname in the certificate does NOT match 'www.gnutls.org'.
 # valid since: Sun May 23 09:36:29 UTC 2004
 # expires at: Sun Jul 23 09:36:29 UTC 2023
 # fingerprint: 81:55:19:D4:46:46:98:8A:E3:58:94:E7:BE:F9:BD:19
 # Subject's DN: C=SE,ST=Stockholm,L=Stockholm,O=YXA,OU=Web server,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com
 # Issuer's DN: C=SE,ST=Stockholm,L=Stockholm,O=YXA,OU=CA,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com

 - Certificate[1] info:
 # valid since: Sun May 23 09:35:33 UTC 2004
 # expires at: Sun Jul 23 09:35:33 UTC 2023
 # fingerprint: FC:76:D8:63:1A:C9:0B:3B:FA:40:FE:ED:47:7A:58:AE
 # Subject's DN: C=SE,ST=Stockholm,L=Stockholm,O=YXA,OU=CA,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com
 # Issuer's DN: C=SE,ST=Stockholm,L|<2>| ASSERT: verify.c:242
|<2>| ASSERT: verify.c:398
=Stockholm,O=YXA,OU=CA,CN=yxa.extundo.com,EMAIL=staff at yxa.extundo.com


- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

|<4>| REC[8073cb8]: Sending Packet[1] Application Data(23) with length: 6
|<7>| WRITE: Will write 37 bytes to 4.
|<7>| WRITE: wrote 37 bytes to 4. Left 0 bytes. Total 37 bytes.
|<7>| 0000 - 17 03 01 00 20 3c 56 ce 2c ec de c6 53 8f 7a 83 
|<7>| 0001 - d2 2e cc 4a af 5f 31 b4 6c f3 cb 58 d2 18 52 a5 
|<7>| 0002 - 98 7e 95 58 aa 
|<4>| REC[8073cb8]: Sent Packet[2] Application Data(23) with length: 37
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 17 03 01 01 60 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[1] Application Data(23) with length: 4096
|<4>| REC[8073cb8]: Received Packet[1] Application Data(23) with length: 352
|<7>| READ: Got 351 bytes from 4
|<7>| READ: read 351 bytes from 4
|<7>| 0000 - fe 40 c3 75 a0 5a 31 5d 63 61 76 e1 1a 86 b5 52 
|<7>| 0001 - 36 b9 31 2b 3e fe 62 4c f1 36 2c e0 19 d7 84 eb 
|<7>| 0002 - 08 94 20 b9 be e0 0a 10 37 51 df 33 c2 02 ad 83 
|<7>| 0003 - 00 80 6c af 8a 60 76 15 11 28 b4 ec 96 39 08 bb 
|<7>| 0004 - 4f f0 01 5d f8 38 84 3a 14 e3 0c e2 1b c9 6b 84 
|<7>| 0005 - 3d fc 24 db 4d 95 21 89 9e 50 52 ac c0 ac b5 05 
|<7>| 0006 - 4f 73 4f 2b 0a ed 06 f2 c6 d1 09 db cc 51 9d 22 
|<7>| 0007 - 7a ce 3e 3f a5 2b b9 9e a1 9f 55 a2 15 63 d4 29 
|<7>| 0008 - 4c 95 4e f9 55 71 7a 04 0b 87 84 ab be fa 44 a1 
|<7>| 0009 - 4a c2 62 53 e2 aa 42 72 17 54 34 3d ea 27 c7 b5 
|<7>| 000a - 76 96 cf ab 69 74 54 24 80 da 51 ea c7 a9 c5 57 
|<7>| 000b - 71 37 14 39 b4 d8 2a 73 71 7e 31 d7 0a 2d 8e 4b 
|<7>| 000c - e1 01 46 3e 10 3f 31 de 20 87 f6 89 b0 34 f3 58 
|<7>| 000d - 43 af a0 6a 44 dd 65 a3 25 03 90 b6 41 4f f1 11 
|<7>| 000e - d2 d5 ad cf 62 37 cc 6d 9d 40 1c 5c 8e f6 57 0c 
|<7>| 000f - d6 94 7c 59 e7 d0 45 58 d8 93 8a 00 fc f8 3d 35 
|<7>| 0010 - 3a 11 1d c9 1d e8 fd 8f 82 03 7d 95 fc d0 2c 0e 
|<7>| 0011 - 2c 30 76 bd 40 2b c1 8c 5f a1 44 23 e4 e1 95 4a 
|<7>| 0012 - 66 c2 14 34 30 d1 57 64 f6 e1 1a e2 29 e8 a3 ff 
|<7>| 0013 - e9 52 be e6 ee 44 a1 b4 20 88 46 f2 8a 0b 2b 5f 
|<7>| 0014 - a5 7c b1 26 b3 c8 78 b9 ee 19 d9 2a d8 45 e4 59 
|<7>| 0015 - 97 c5 4d 04 22 a0 ef 08 40 8f 7e df 0d be 0e 
|<7>| RB: Have 5 bytes into buffer. Adding 351 bytes.
|<7>| RB: Requested 357 bytes
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 01 
|<7>| RB-PEEK: Read 1 bytes in PEEK MODE.
|<7>| RB-PEEK: Have 356 bytes into buffer. Adding 1 bytes.
RB: Requested 357 bytes
|<4>| REC[8073cb8]: Decrypted Packet[1] Application Data(23) with length: 320
|<6>| BUF[REC]: Inserted 320 bytes of Data(23)
|<6>| BUFFER[REC][AD]: Read 320 bytes of Data(23)
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 01 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Invalid URI in request get x<P>
<HR>
<ADDRESS>Apache/1.3.33 Server at yxa.extundo.com Port 443</ADDRESS>
</BODY></HTML>
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 15 03 01 00 20 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8073cb8]: Expected Packet[2] Application Data(23) with length: 4096
|<4>| REC[8073cb8]: Received Packet[2] Alert(21) with length: 32
|<7>| READ: Got 32 bytes from 4
|<7>| READ: read 32 bytes from 4
|<7>| 0000 - 77 bd ec 68 c2 88 65 38 98 28 9a c3 67 14 8a 57 
|<7>| 0001 - 62 f2 ec 15 42 55 47 68 3f 77 cc 2d 3a 72 c4 81 
|<7>| 0002 - 
|<7>| RB: Have 5 bytes into buffer. Adding 32 bytes.
|<7>| RB: Requested 37 bytes
|<4>| REC[8073cb8]: Short record length 32 < 16 + 20 (under attack?)
|<2>| ASSERT: gnutls_cipher.c:461
|<2>| ASSERT: gnutls_record.c:999
*** Fatal error: Decryption has failed.
*** Server has terminated the connection abnormally.

From simon at josefsson.org  Mon May 19 20:58:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 20:58:16 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <20080519184316.GB4581@downhill.g.la> (Andreas Metzler's message
	of "Mon, 19 May 2008 20:43:16 +0200")
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
	<20080519180101.GA4581@downhill.g.la>
	<87prri2lrk.fsf@mocca.josefsson.org>
	<20080519184316.GB4581@downhill.g.la>
Message-ID: <87lk262kaf.fsf@mocca.josefsson.org>

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

> On 2008-05-19 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>> > The fix for this one (gnutls_cipher.c) breaks clean end of session:
>
>> Sigh!  If you add -d 4711 what does it say?  I'm trying to reproduce
>> this now.
>
> Hello,
>
> I am attaching logs for both 2.2.3 and 2.2.4 for easy comparison.

Thanks!

> |<7>| RB: Have 5 bytes into buffer. Adding 32 bytes.
> |<7>| RB: Requested 37 bytes
> |<4>| REC[8073cb8]: Short record length 32 < 16 + 20 (under attack?)
> |<2>| ASSERT: gnutls_cipher.c:461
> |<2>| ASSERT: gnutls_record.c:999

Ok, the debug message printing check was incorrect.  Sigh...

The patch below still catch the exploit but works with a proper server
that sends a short reply.  Can you test this?

Thanks,
/Simon

diff --git a/lib/gnutls_cipher.c b/lib/gnutls_cipher.c
index f071710..e16ad1f 100644
--- a/lib/gnutls_cipher.c
+++ b/lib/gnutls_cipher.c
@@ -453,15 +453,6 @@ _gnutls_ciphertext2compressed (gnutls_session_t session,
       return GNUTLS_E_INTERNAL_ERROR;
     }
 
-  if (ciphertext.size < (unsigned) blocksize + hash_size)
-    {
-      _gnutls_record_log
-	("REC[%x]: Short record length %d < %d + %d (under attack?)\n",
-	 session, ciphertext.size, blocksize, hash_size);
-      gnutls_assert ();
-      return GNUTLS_E_DECRYPTION_FAILED;
-    }
-
   /* actual decryption (inplace)
    */
   switch (_gnutls_cipher_is_block
@@ -515,6 +506,9 @@ _gnutls_ciphertext2compressed (gnutls_session_t session,
       if ((int)pad > (int)ciphertext.size - hash_size)
 	{
 	  gnutls_assert ();
+	  _gnutls_record_log
+	    ("REC[%x]: Short record length %d > %d - %d (under attack?)\n",
+	     session, pad, ciphertext.size, hash_size);
 	  /* We do not fail here. We check below for the
 	   * the pad_failed. If zero means success.
 	   */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080519/d1b6bff7/attachment.pgp>

From simon at josefsson.org  Mon May 19 21:43:32 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 21:43:32 +0200
Subject: GnuTLS 2.2.4 - Security release [GNUTLS-SA-2008-1]
In-Reply-To: <87prri2lrk.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 19 May 2008 20:26:23 +0200")
References: <87ve1a4i6s.fsf@mocca.josefsson.org>
	<20080519180101.GA4581@downhill.g.la>
	<87prri2lrk.fsf@mocca.josefsson.org>
Message-ID: <87d4ni2i6z.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> I don't understand why the self-tests didn't catch something like this
> though.

I looked into this, and the reason is that the self tests uses TLS 1.1
and uses record padding.  The incorrect debug message check was only
triggered for incoming packet shorter than the hash size plus the
blocksize, which can happen if the server sends a short message.  If TLS
1.1 is used, an IV is always sent so the packet becomes longer, or if
padding is used, the packet typically also becomes longer.

My patch in the other message appears to be the right thing.  I'll
release 2.2.5 with it.

/Simon




From simon at josefsson.org  Mon May 19 22:54:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 22:54:43 +0200
Subject: GnuTLS 2.2.5 - Brown paper bag release
Message-ID: <87ve1aypyk.fsf@mocca.josefsson.org>

We are embarrassed to announce a new stable GnuTLS release: Version 2.2.5.

This release fixes a flaw in the patch for one of the security problems
fixed by version 2.2.4.  The updated advisory is included below.  As
always, further updates will be posted on:

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

I'd also like to take the opportunity to correct another mistake made
the announcement for v2.2.4: please send security analysis to
gnutls-devel at gnu.org and not to any other address.

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

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

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

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

* Version 2.2.5 (released 2008-05-19)

** Fix flaw in fix for GNUTLS-SA-2008-1-3.
The flaw would result in incorrectly terminated sessions with the
error "Decryption has failed" when the server sends a small packet
(typically when the session is closed).  Reported by Andreas Metzler
<ametzler at downhill.at.eu.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2807>.

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

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

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

Here are the BZIP2 compressed sources (4.8MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

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

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

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

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

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:

7620d092c790f0a5ac5486c3563786ca8777083d  gnutls-2.2.5.tar.bz2

d1cee353902a404a4b02fd0da981e8164c8b60356917abfc781b066c  gnutls-2.2.5.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-devel mailing list, see:
<http://lists.gnu.org/mailman/listinfo/gnutls-devel>.

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.6, libgcrypt 1.4.1, libtasn1 1.4, and GnuTLS 2.2.5.

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

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

A ZIP file with the installed tree of binaries:
  http://josefsson.org/gnutls4win/gnutls-2.2.5.zip (4.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.2.5.zip.sig

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

02a84f3844b9376f65edfbb6f6cc377a239a6264  gnutls-2.2.5.exe
1bff90ec17ad99bbf369d65719a1f25fa6d16cbe  gnutls-2.2.5.zip

0a1b1687d7b542e3c41abaa9c321946db32487f936b45ec7bdb0d563  gnutls-2.2.5.exe
8c07ceed8183efb561f99d393bcac6faf669a9c3936df5d5397686fe  gnutls-2.2.5.zip

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080519/2756016f/attachment.pgp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls-sa-2008-01.txt.asc
URL: </pipermail/attachments/20080519/2756016f/attachment.asc>

From bressers at redhat.com  Mon May 19 23:04:42 2008
From: bressers at redhat.com (Josh Bressers)
Date: Mon, 19 May 2008 17:04:42 -0400
Subject: GNUTLS-SA-2008-1 question
Message-ID: <19787.1211231082@devserv.devel.redhat.com>

Hello,

My name is Josh Bressers and I am a member of the Red Hat Security Response
Team.

I just found out about GNUTLS-SA-2008-1 and was wondering if you could
clear something up for me.

The advisory states it's a denial of service, but from reading the
advisory, GNUTLS-SA-2008-1-1, it sounds like it should be an exploitable
buffer overflow, not just a denial-of-service.  Are you willing to share
your reasoning for calling this a DoS rather than an arbitrary code
execution flaw?

Also, would you be willing to share the reproducer for this flaw?  We are
interested in it for QA purposes.

I'm also wondering if you'd be willing to give the Vendor Security group a
heads up on issues such as this in the future.  You can find more details
about the group here:
http://oss-security.openwall.org/wiki/mailinglists/vendor-sec

Thanks.

-- 
    JB




From simon at josefsson.org  Mon May 19 23:34:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 May 2008 23:34:41 +0200
Subject: GNUTLS-SA-2008-1 question
In-Reply-To: <19787.1211231082@devserv.devel.redhat.com> (Josh Bressers's
	message of "Mon, 19 May 2008 17:04:42 -0400")
References: <19787.1211231082@devserv.devel.redhat.com>
Message-ID: <873aoeasge.fsf@mocca.josefsson.org>

Josh Bressers <bressers at redhat.com> writes:

> Hello,
>
> My name is Josh Bressers and I am a member of the Red Hat Security Response
> Team.
>
> I just found out about GNUTLS-SA-2008-1 and was wondering if you could
> clear something up for me.

Hi!

Btw, be sure to check out the 2.2.5 announcement.

> The advisory states it's a denial of service, but from reading the
> advisory, GNUTLS-SA-2008-1-1, it sounds like it should be an exploitable
> buffer overflow, not just a denial-of-service.  Are you willing to share
> your reasoning for calling this a DoS rather than an arbitrary code
> execution flaw?

It may indeed be more than just a denial-of-service, but we don't have
resources to analyze this in more detail.  We just echo the report that
was submitted to us, and it was about segmentation faults.

> Also, would you be willing to share the reproducer for this flaw?  We are
> interested in it for QA purposes.

I'll attach my internal notes for reproducing the flaws to you in a
private email.

> I'm also wondering if you'd be willing to give the Vendor Security group a
> heads up on issues such as this in the future.  You can find more details
> about the group here:
> http://oss-security.openwall.org/wiki/mailinglists/vendor-sec

The vulnerability was submitted to us via CERT-FI, so I incorrectly
assumed they had communicated this to vendors.  I'll see if I can
subscribe to the list to be able to give an heads-up in the future.

Thanks,
/Simon




From simon at josefsson.org  Tue May 20 00:32:21 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 00:32:21 +0200
Subject: [Pkg-gnutls-maint] Bug#373169: fixed in 2.3.10
In-Reply-To: <873aoeezas.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 19 May 2008 17:53:15 -0400")
References: <871w3ycgc1.fsf@mocca.josefsson.org>
	<873aoeezas.fsf@squeak.fifthhorseman.net>
Message-ID: <87y7660vt6.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On Mon 2008-05-19 14:13:34 -0400, Simon Josefsson wrote:
>
>> Hi!  Thanks for security review of this.  v2.3.10 now uses umask
>> directly, so I think this should be solved:
>>
>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=d0629b2c7d20c32c746cc221e997485d63ee2d71
>
> Thanks for the fix, Simon.  That changelog is really noisy because of
> all the comments bouncing.  Are src/certtool-gaa.{c,h} files that are
> that's auto-generated from certtool.gaa?

Yes.

> If so, shouldn't they be removed from the repository as generated
> files, and new rules added to the Make subsystem to create them?
>
> That would make changesets like this one easier to interpret.

Yes, but would also requires everyone building from source to install
GAA which isn't widely available (not packaged for debian for example).
These files change quite infrequently, so my gut feeling is that the
cost of having rare unreadable patches is lower than having a lot of
people having to install GAA manually.  Nikos, what do you think?

> Also, is there a reason to not reset the umask after file creation?
> If certtool goes on to create another file, wouldn't it make more
> sense to leave the umask as you found it?  (e.g. if you were emitting
> the certificate into a different file than the key, you'd probably
> expect the key to be private, but the cert to be publicly readable)

Certtool only opens the --outfile file for writing, so there is only one
file to consider.  However, maybe at some point certtool will write more
than one file.  Is the following a good idea?

diff --git a/src/certtool.c b/src/certtool.c
index 1463a1f..bf0990f 100644
--- a/src/certtool.c
+++ b/src/certtool.c
@@ -821,14 +821,22 @@ update_signed_certificate (void)
 
 FILE* safe_open_rw(const char* file)
 {
-#ifdef HAVE_UMASK
-      if (info.privkey_op != 0) 
-        {
-	  umask(S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
-        }
-#endif
+  mode_t oldmask;
+  FILE *fh;
+
+  if (info.privkey_op != 0)
+    {
+      oldmask = umask (S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
+    }
+
+  fh = fopen (file, "wb");
+
+  if (info.privkey_op != 0)
+    {
+      umask (oldmask);
+    }
 
-      return fopen (file, "wb");
+  return fh;
 }
 
 void

/Simon




From dkg-debian.org at fifthhorseman.net  Tue May 20 04:16:41 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 19 May 2008 22:16:41 -0400
Subject: [Pkg-gnutls-maint] Bug#373169:  Bug#373169: fixed in 2.3.10
In-Reply-To: <87y7660vt6.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue\, 20 May 2008 00\:32\:21 +0200")
References: <871w3ycgc1.fsf@mocca.josefsson.org>
	<873aoeezas.fsf@squeak.fifthhorseman.net>
	<87y7660vt6.fsf@mocca.josefsson.org>
Message-ID: <87bq3167p2.fsf@squeak.fifthhorseman.net>

On Mon 2008-05-19 18:32:21 -0400, Simon Josefsson wrote:

> Certtool only opens the --outfile file for writing, so there is only
> one file to consider.  However, maybe at some point certtool will
> write more than one file.  Is the following a good idea?

Your proposed change seems reasonable to me (though maybe you want to
wrap the stanzas in #ifdef HAVE_UMASKs like the original).

     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080519/69233b92/attachment.pgp>

From smithj at freethemallocs.com  Tue May 20 01:05:53 2008
From: smithj at freethemallocs.com (Jonathan Smith)
Date: Mon, 19 May 2008 15:05:53 -0800
Subject: handling of the gnutls 2.2.4 security fixes
Message-ID: <483207D1.3030009@freethemallocs.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not sure which list (vendor-sec or oss-security) I should post this
to. I'm hoping not making it public means that maybe it'll get serious
attention and it won't be taken as flamebait. It isn't intended that
way. Really. I promise.

I'll be honest, I'm not that familiar with gnutls. I've never had a
chance to use it. I have no idea what, if anything, it provides that
isn't available in openssl. But Foresight Linux does ship it, and
apparently some apps we ship actually use it. So it being secure is
important to me.

The 2.2.4 release was not handled properly. Vendor-sec received an email
on the 14th of May stating that CERT-FI was going to send mail to us
about an upcoming release of gnutls. That mail never arrived. Vendor-sec
is *the* place to discuss non-public issues like this. Maybe this was
the fault of the CERT, but the gnutls team should, in the future, make
an attempt to contact us even if whatever CERT is dealing with the issue
also promises to.

Josh Bressers, who is quite active on this list, seems to have already
made some comments to this effect. I just wanted to clear up why it
would be beneficial to *you* to post here. Emailing us ensures that most
of your users actually get the fix on the day you release it, since most
of your users use the distro-provided packages. We coordinate sensitive
releases with projects such as openssl, kerberos, etc. Depending on the
scope of the changes, it may take distros weeks to integrate and QA
them, so giving us a bit of notice (10-14 days is typical) allows us all
to push the fixes at the same time, preventing the Bad Guys from using
the information in your advisory against the folks using the
distro-provided packages. It also allows folks who aren't part of the
upstream project to analyze the proposed fix, which sometimes leads to a
better patch being developed.

But, what troubles me more than the non-notification is that the gnutls
team doesn't seem to understand the impact of these flaws.
http://www.gnu.org/software/gnutls/security.html states "Currently the
core GnuTLS team do [sic] not have resources to analyse [sic] the
background and impact of security problems in as much detail as we would
want to." That statement *floored* me. One of my coworkers, who I will
leave nameless, but who is on this list, stated upon reading that "Words
fail me".

Maybe the statement is simply poorly worded, but it seems to be
consistent with today's release...

...In a cryptographic library, analyzing impact and understanding
security issues is of the *utmost* importance. It is more important that
than new features. It is more important than bugfixes. You guys, the
gnutls team, are the experts in this code. You guys are the most able to
diagnose causes and assess impact. You guys. Not, as you later state on
that same page, "Everyone is invited to analyse [sic] the impact of
discovered bugs". Yes, ok, openness is good. Anyone can examine the
code. Great. But anyone who publishes a *cryptographic library*
shouldn't rely on the unwashed masses to coordinate security issues.
There is a greater responsibility when dealing with code that could
compromise people's bank accounts or allow eavesdropping on sensitive
private conversations. You guys are the experts, and it would be great
if you used that knowledge where it is most needed. Crypto library
maintainers should be very deliberate and slow-moving, not rushing to
publish releases until everything is understood about those changes.

So. Now that I've gotten all that off my chest, let me reiterate. I
don't intend this to be insulting, or otherwise harmful.  I know gnutls
is a relatively new project, and so I'm just trying to let you know how
users of gnutls feel when blind-sighted with unresearched security
advisories, and maybe how to prevent it in the future.

	smithj

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgyB9AACgkQCG91qXPaRekw2QCeL8bBh+64kfpLgGHriyCABBN6
oeQAn3NUaqDJE5x2OVoCRc8/LrWwAEBz
=o8uP
-----END PGP SIGNATURE-----




From simon at josefsson.org  Tue May 20 07:01:05 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 07:01:05 +0200
Subject: [Pkg-gnutls-maint] Bug#373169:  Bug#373169: fixed in 2.3.10
In-Reply-To: <87bq3167p2.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 19 May 2008 22:16:41 -0400")
References: <871w3ycgc1.fsf@mocca.josefsson.org>
	<873aoeezas.fsf@squeak.fifthhorseman.net>
	<87y7660vt6.fsf@mocca.josefsson.org>
	<87bq3167p2.fsf@squeak.fifthhorseman.net>
Message-ID: <878wy5d0xa.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> On Mon 2008-05-19 18:32:21 -0400, Simon Josefsson wrote:
>
>> Certtool only opens the --outfile file for writing, so there is only
>> one file to consider.  However, maybe at some point certtool will
>> write more than one file.  Is the following a good idea?
>
> Your proposed change seems reasonable to me

Thanks, applied.

> (though maybe you want to wrap the stanzas in #ifdef HAVE_UMASKs like
> the original).

Actually, I have removed all HAVE_UMASK tests.  There is no system that
I know of that doesn't have umask, and disabling this code can have
security consequences so it is better if we get reports regarding
systems that doesn't have umask.  Even GNU CoreUtils uses umask
unconditionally, and it has been widely ported, so I don't expect many
problems.

/Simon




From vulncoord at ficora.fi  Tue May 20 09:15:57 2008
From: vulncoord at ficora.fi (CERT-FI Vulnerability Co-ordination)
Date: Tue, 20 May 2008 10:15:57 +0300
Subject: handling of the gnutls 2.2.4 security fixes
Message-ID: <48327AAD.8060806@ficora.fi>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 > The 2.2.4 release was not handled properly. Vendor-sec received an
 > email on the 14th of May stating that CERT-FI was going to send mail
 > to us about an upcoming release of gnutls. That mail never arrived.
 > Vendor-sec is *the* place to discuss non-public issues like this.
 > Maybe this was the fault of the CERT, but the gnutls team should, in
 > the future, make an attempt to contact us even if whatever CERT is
 > dealing with the issue also promises to.

Mea culpa. It seems I made an error when sending the announcement
to the vendor-sec list. As I don't see the list myself, I did not
realise that it never arrived. I'll try to be more precise with
this in the future.

- -Juhani Eronen / CERT-FI Vulnerability Co-ordination

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIMnpv/64aC2E+yK8RAj5AAKCEY+cH1YO3NL2F4h8yox8HFWroegCgoe1D
cGeeVcENxVHK8kAzMIlEzNg=
=n99z
-----END PGP SIGNATURE-----





From simon at josefsson.org  Tue May 20 11:44:32 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 11:44:32 +0200
Subject: handling of the gnutls 2.2.4 security fixes
In-Reply-To: <48327AAD.8060806@ficora.fi> (CERT-FI Vulnerability
	Co-ordination's message of "Tue, 20 May 2008 10:15:57 +0300")
References: <48327AAD.8060806@ficora.fi>
Message-ID: <87iqx99unz.fsf@mocca.josefsson.org>

CERT-FI Vulnerability Co-ordination <vulncoord at ficora.fi> writes:

>  > The 2.2.4 release was not handled properly. Vendor-sec received an
>  > email on the 14th of May stating that CERT-FI was going to send mail
>  > to us about an upcoming release of gnutls. That mail never arrived.
>  > Vendor-sec is *the* place to discuss non-public issues like this.
>  > Maybe this was the fault of the CERT, but the gnutls team should, in
>  > the future, make an attempt to contact us even if whatever CERT is
>  > dealing with the issue also promises to.
>
> Mea culpa. It seems I made an error when sending the announcement
> to the vendor-sec list. As I don't see the list myself, I did not
> realise that it never arrived. I'll try to be more precise with
> this in the future.

To update the public record regarding this (my replies to vendor-sec has
been private since the original email was intended to be private), you
did send it to the right address but vendor-sec's spam filter caught it.

/Simon




From simon at josefsson.org  Tue May 20 15:28:52 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 May 2008 15:28:52 +0200
Subject: GnuTLS 2.3.11
Message-ID: <878wy52jfv.fsf@mocca.josefsson.org>

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

The goals for the 2.3.x branch are tracked at:

http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4

Alas, the spammers have found our trac site so it is almost useless. :(
Hopefully I can move it to another host soon...  Is anyone interested in
helping to admin it?  Can anyone sponsor a VPS to run this on?  Help!

More ideas are welcome, just create a new ticket.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.11.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.11.tar.bz2

Here is the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.3.11.exe
  http://josefsson.org/gnutls4win/gnutls-2.3.11.zip

New in this release is that the Windows build contains the C++ library
and examples.  I verified that it was able to connect to a server, cool,
at least via Wine.  I have no idea how to use an external C++ DLL from
MSVS, but I guess people interested in that knows how to do it.

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

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

News in this release:

* Version 2.3.11 (released 2008-05-20)

** Fix flaw in fix for GNUTLS-SA-2008-1-3.
The flaw would result in incorrectly terminated sessions with the
error "Decryption has failed" when the server sends a small packet
(typically when the session is closed).  Reported by Andreas Metzler
<ametzler at downhill.at.eu.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2807>.

** Don't use gnulib headers when building C++ library.
Fixes builds under Windows.

** Make umask a requirement.
We don't know of any system that lacks it, even GNU CoreUtils use it
unconditionally.

** Update gnulib files.
Fixes a problem where it pulled in a replacement for memcmp under
MinGW, which caused the C++ example to fail to build.

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

/Simon




From alan at lxorguk.ukuu.org.uk  Tue May 20 10:40:10 2008
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue, 20 May 2008 09:40:10 +0100
Subject: [vendor-sec] handling of the gnutls 2.2.4 security fixes
In-Reply-To: <483207D1.3030009@freethemallocs.com>
References: <483207D1.3030009@freethemallocs.com>
Message-ID: <20080520094010.4e50a362@core>

> core GnuTLS team do [sic] not have resources to analyse [sic] the

You would get a little more respect from me if you did not go around
putting [sic] after non-US spellings of words you quote.





From yanagisawa at csg.is.titech.ac.jp  Thu May 22 13:38:28 2008
From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA)
Date: Thu, 22 May 2008 20:38:28 +0900
Subject: Camellia block cipher don't work on current developers' releases
 2.3.x.
In-Reply-To: <482496E8.8010103@csg.is.titech.ac.jp>
References: <4816E809.6030108@csg.is.titech.ac.jp>
	<48197CAB.50105@gnutls.org>	<877iedpxrl.fsf@mocca.josefsson.org>
	<482496E8.8010103@csg.is.titech.ac.jp>
Message-ID: <48355B34.90609@csg.is.titech.ac.jp>


Hi,

On 2008/05/10 3:24, Yoshisato YANAGISAWA wrote:
>> Btw, to improve the chances that Camellia will work in all future
>> releases, it can be a good idea to provide a self-test of this
>> functionality, to be run by 'make check'.  We never release anything
>> that fails a 'make check' self-test.

I implemented the self-test for most of ciphers.
This test can catch the bug that I mentioned.
Since some ciphers, such as RC2-40 and NULL, are deactivated, I just
avoid testing for those ciphers.

-- 
Yoshisato Yanagisawa (Dr.Sc.) <yanagisawa at csg.is.titech.ac.jp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cipher_test.c
URL: </pipermail/attachments/20080522/61393650/attachment.txt>

From jorton at redhat.com  Fri May 23 13:05:11 2008
From: jorton at redhat.com (Joe Orton)
Date: Fri, 23 May 2008 12:05:11 +0100
Subject: [Bug 446392] New: SSL error: Key usage violation
In-Reply-To: <87prro52xd.fsf@mocca.josefsson.org>
References: <20080514142020.GA5582@redhat.com>
	<87prro52xd.fsf@mocca.josefsson.org>
Message-ID: <20080523110511.GB16180@redhat.com>

On Wed, May 14, 2008 at 05:19:10PM +0200, Simon Josefsson wrote:
> Joe Orton <jorton at redhat.com> writes:
> 
> > I'm about to go on holiday so won't be able to look into this myself for 
> > a week or so; Fedora 9 ships with GnuTLS 2.0.4, but I can reproduce this 
> > with the slightly stale git checkout I had lying around, so I'd suspect 
> > this is a GnuTLS cert validation bug?
> >
> > $ ./bin/gnutls-cli svn.eionet.europa.eu
> > Resolving 'svn.eionet.europa.eu'...
> > Connecting to '217.74.209.183:443'...
> > *** Fatal error: Key usage violation in certificate has been detected.
> > *** Handshake has failed
> 
> Hi.  Thanks for the report.  Without further information, I believe that
> is the correct behavior.

Thanks a lot for looking into this!  The user has now fixed the server 
cert.

joe




From l at lwithers.me.uk  Sat May 24 11:59:59 2008
From: l at lwithers.me.uk (Laurence Withers)
Date: Sat, 24 May 2008 09:59:59 +0000
Subject: Patch to improve behaviour in gnutls_x509_crl_set_version() when
	`char' is unsigned
Message-ID: <200805240959.59496.l@lwithers.me.uk>

Hi,

On some platforms, char can be unsigned by default (in my case I'm using gcc 
3.4.5 on arm). When that's the case, I noticed a compilation warning in 
lib/x509/crl_write.c .

The attached patch fixes the warning, but also slightly changes the way the 
test is carried out.

The documentation for the function states that the supplied version parameter 
must be 1 or 2, and implies it can be higher but not 0. The patch explicitly 
checks that version >= 1 without performing any arithmetic in a char type. If 
the check fails, the function returns with GNUTLS_E_INVALID_REQUEST, which I 
guess is the right thing to do. If the check succeeds, the previous behaviour 
is used. However, a char value of 0 is never decremented, so there is never 
any possibility of an overflow.

If this behaviour isn't really wanted, and the exact previous semantics of the 
function should be preserved (version 0 -> 0, version 1 -> 0, version 2 -> 1 
etc.) then let me know and I'll rework the patch.

Hope this helps, and bye for now,
-- 
Laurence Withers, <l at lwithers.me.uk>  --  jabber:l at jabber.lwithers.me.uk
http://www.lwithers.me.uk/                             tel:+447753988197
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.2.5-unsigned-char-crl-version.patch
Type: text/x-diff
Size: 992 bytes
Desc: not available
URL: </pipermail/attachments/20080524/3dc4a9bf/attachment.patch>

From rmh at aybabtu.com  Sat May 24 12:08:54 2008
From: rmh at aybabtu.com (Robert Millan)
Date: Sat, 24 May 2008 12:08:54 +0200
Subject: [PATCH] RAND_pseudo_bytes() stub
Message-ID: <20080524100854.GA17127@thorin>


This patch adds a RAND_pseudo_bytes() stub for compatibility with OpenSSL.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call? if you are unable to speak?
(as seen on /.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rand_pseudo_bytes.diff
Type: text/x-diff
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20080524/39a581a2/attachment.diff>

From ametzler at downhill.at.eu.org  Sun May 25 10:04:28 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 25 May 2008 10:04:28 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
Message-ID: <20080525080428.GB3208@downhill.g.la>

Hello,

gnutls 2.3.11 dpoes not build correctly on sparc.

http://experimental.debian.net/fetch.php?&pkg=gnutls26&ver=2.3.11-1&arch=sparc&stamp=1211629418&file=log&as=raw

There is testsuite failure when running openpgpself. (Complete output
attached). From comparing the output with i386, it looks like i386
actually does not complete successfully, too - but the error is not
correctly reflected in the exit code:

--------------
client: Handshake failed
GNUTLS ERROR: A TLS packet with unexpected length was received.
--------------

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 --------------
client |<2>| Importing Openpgp key and using openpgp sub key: 837b6fb42e0fe176
client |<2>| Importing Openpgp cert and using openpgp sub key: 837b6fb42e0fe176
client |<2>| ASSERT: pgp.c:156
client |<2>| ASSERT: privkey.c:1058
client |<2>| Importing Openpgp key and using main openpgp key.
client |<2>| ASSERT: pgp.c:1461
client |<2>| Importing Openpgp cert and using main openpgp key
client |<2>| ASSERT: pgp.c:156
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
client |<3>| HSK[43df0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
client |<2>| EXT[43df0]: Sending extension CERT_TYPE
client |<3>| HSK[43df0]: CLIENT HELLO was send [88 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[43df0]: Sending Packet[0] Handshake(22) with length: 88
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 93 bytes to 5.
client |<7>| WRITE: wrote 93 bytes to 5. Left 0 bytes. Total 93 bytes.
client |<7>| 0000 - 16 03 02 00 58 01 00 00 54 03 02 48 39 1b 27 53 
client |<7>| 0001 - e2 81 a9 76 c0 17 e4 e8 b2 44 ce ef e8 24 50 74 
client |<7>| 0002 - fd 2a 9c f0 5a b8 55 ea 5b 2a ac 00 00 24 00 33 
client |<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 
client |<7>| 0004 - 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 
client |<7>| 0005 - 00 04 01 00 00 07 00 09 00 03 02 00 01 
client |<4>| REC[43df0]: Sent Packet[1] Handshake(22) with length: 93
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 16 03 02 00 58 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[43618]: Expected Packet[0] Handshake(22) with length: 1
server |<4>| REC[43618]: Received Packet[0] Handshake(22) with length: 88
server |<7>| READ: Got 88 bytes from 5
server |<7>| READ: read 88 bytes from 5
server |<7>| 0000 - 01 00 00 54 03 02 48 39 1b 27 53 e2 81 a9 76 c0 
server |<7>| 0001 - 17 e4 e8 b2 44 ce ef e8 24 50 74 fd 2a 9c f0 5a 
server |<7>| 0002 - b8 55 ea 5b 2a ac 00 00 24 00 33 00 45 00 39 00 
server |<7>| 0003 - 88 00 16 00 32 00 44 00 38 00 87 00 13 00 66 00 
server |<7>| 0004 - 2f 00 41 00 35 00 84 00 0a 00 05 00 04 01 00 00 
server |<7>| 0005 - 07 00 09 00 03 02 00 01 
server |<7>| RB: Have 5 bytes into buffer. Adding 88 bytes.
server |<7>| RB: Requested 93 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[43618]: Decrypted Packet[0] Handshake(22) with length: 88
server |<6>| BUF[HSK]: Inserted 88 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[43618]: CLIENT HELLO was received [88 bytes]
server |<6>| BUF[REC][HD]: Read 84 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 84 bytes of Data
server |<3>| HSK[43618]: Client's version: 3.2
server |<2>| ASSERT: gnutls_db.c:238
server |<2>| EXT[43618]: Received extension 'CERT_TYPE/9'
server |<2>| EXT[43618]: Received extension 'CERT_TYPE/9'
server |<2>| ASSERT: ext_cert_type.c:106
server |<2>| ASSERT: gnutls_x509.c:1077
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[43618]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_ARCFOUR_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_ARCFOUR_MD5
server |<3>| HSK[43618]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_AES_256_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[43618]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[43618]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[43618]: Selected Compression Method: NULL
server |<2>| EXT[43618]: Sending extension CERT_TYPE
server |<3>| HSK[43618]: SessionID: 757c0c3fb7b4de0754d2abddb8e73e17d8e3700ae9d1d90e1aee6bfdbb69a35a
server |<3>| HSK[43618]: SERVER HELLO was send [81 bytes]
server |<6>| BUF[HSK]: Peeked 88 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[0] Handshake(22) with length: 81
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 86 bytes to 5.
server |<7>| WRITE: wrote 86 bytes to 5. Left 0 bytes. Total 86 bytes.
server |<7>| 0000 - 16 03 02 00 51 02 00 00 4d 03 02 48 39 1b 27 23 
server |<7>| 0001 - a7 49 e7 b3 eb 6e 54 8b 34 76 db ef bf 40 88 e3 
server |<7>| 0002 - 0b 47 20 22 16 b4 f5 90 c8 11 60 20 75 7c 0c 3f 
server |<7>| 0003 - b7 b4 de 07 54 d2 ab dd b8 e7 3e 17 d8 e3 70 0a 
server |<7>| 0004 - e9 d1 d9 0e 1a ee 6b fd bb 69 a3 5a 00 33 00 00 
server |<7>| 0005 - 05 00 09 00 01 01 
server |<4>| REC[43618]: Sent Packet[1] Handshake(22) with length: 86
server |<3>| HSK[43618]: CERTIFICATE was send [1046 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[1] Handshake(22) with length: 1046
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 1051 bytes to 5.
server |<7>| WRITE: wrote 1051 bytes to 5. Left 0 bytes. Total 1051 bytes.
server |<7>| 0000 - 16 03 02 04 16 0b 00 04 12 00 04 0f 02 08 83 7b 
server |<7>| 0001 - 6f b4 2e 0f e1 76 00 04 02 99 00 d1 04 47 63 e8 
server |<7>| 0002 - 83 01 06 20 d7 48 47 8b b9 3d 1e 12 c0 00 d6 c2 
server |<7>| 0003 - 3f f3 b6 0b 68 8b b5 d5 6e 69 5f 6d 04 c7 a4 16 
server |<7>| 0004 - 05 c5 34 82 f3 ca 48 49 23 72 57 fa e0 9e 5a ae 
server |<7>| 0005 - 9d 83 fb ec 5e da 1c be 0a 51 17 8d de ff 6c 2b 
server |<7>| 0006 - 0d 35 c5 21 84 7e 8c 7f 26 69 6a 51 48 3a 09 5b 
server |<7>| 0007 - d3 8d d7 8b 7e 4b 95 20 19 c7 8f ed 8a 32 56 b1 
server |<7>| 0008 - 7b 3a 7b 23 1b 4f 69 35 e9 5d c4 9f f2 23 ae 56 
server |<7>| 0009 - ae d4 5f ba 7a b4 a6 e9 a4 a5 ce e4 68 26 7c 0f 
server |<7>| 000a - 3c 55 45 6f 18 1b 35 fc f4 29 58 a4 1d 1a b8 fe 
server |<7>| 000b - e8 8d d1 46 60 cd fe 19 da d6 31 94 fc dd b7 db 
server |<7>| 000c - 7d 07 6f 1f 9b bb b8 3d 72 f8 a2 4a 1d 74 ae 2e 
server |<7>| 000d - eb 74 38 55 27 ae ed 46 44 46 52 cc b7 5c ee 9d 
server |<7>| 000e - 58 2e c4 9b 36 65 10 ef 00 11 01 00 01 b4 10 74 
server |<7>| 000f - 65 73 74 33 2e 67 6e 75 74 6c 73 2e 6f 72 67 c2 
server |<7>| 0010 - c0 40 04 13 01 02 00 26 05 02 47 63 e8 83 02 1b 
server |<7>| 0011 - 03 05 09 09 66 01 80 06 0b 09 08 07 03 02 04 15 
server |<7>| 0012 - 02 08 03 04 16 02 03 01 02 1e 01 02 17 80 00 0a 
server |<7>| 0013 - 09 10 a0 21 e3 f8 08 99 90 51 f7 a4 06 1f 71 37 
server |<7>| 0014 - cf 29 c4 4e e4 12 df ef a1 18 cb cc 5e ad a6 0c 
server |<7>| 0015 - 97 93 d9 ef 3d eb 8c bf 89 f2 0e 06 9a f6 2b 68 
server |<7>| 0016 - ac b8 b6 27 ae d1 8a cb 18 be 66 9b 72 1e fe b2 
server |<7>| 0017 - 99 1d db 0e f8 a8 e7 47 23 9e 84 ff 58 ad 68 9e 
server |<7>| 0018 - 8b 0e 26 fb 62 8c 60 52 f9 4f e8 a2 ad e2 9b b1 
server |<7>| 0019 - 31 a5 e4 18 5d cf f3 a5 8b 17 3a 60 79 9b a0 6f 
server |<7>| 001a - 76 89 94 a7 63 cc a9 dc 6c 98 e3 e8 69 19 12 63 
server |<7>| 001b - 1e 51 d9 19 68 ff 3d dc b2 87 65 ea ca 77 93 8e 
server |<7>| 001c - b9 63 f8 e0 ec be 20 93 10 f3 5c 93 3e 09 2d 71 
server |<7>| 001d - 32 17 0e 17 48 01 86 9a 6a 2e 71 ba ef 1d 28 c3 
server |<7>| 001e - ce 3b 3f 27 6c b7 39 30 d2 c3 aa 79 d9 0b 3e e4 
server |<7>| 001f - 9c 68 73 67 94 05 90 ed 01 fa 99 b6 e9 a8 72 70 
server |<7>| 0020 - 7a 44 ce 8d 04 47 88 a5 7c 01 04 00 d2 26 7c d5 
server |<7>| 0021 - 65 f2 a4 b2 38 64 4d be 85 87 c1 0a 77 cc 55 f4 
server |<7>| 0022 - 05 fe f3 e0 bc 04 b1 87 0a e2 18 36 bd 65 cd 9f 
server |<7>| 0023 - fd 57 da 91 f3 62 c1 98 07 1f a8 82 7a 9a 47 06 
server |<7>| 0024 - 23 f6 8e 58 e7 6e e3 ac 2f a7 f5 47 ed 05 b2 7c 
server |<7>| 0025 - 93 57 01 db b8 45 3b 21 4d b2 f8 9d 3f b3 4c f7 
server |<7>| 0026 - c1 cc 7d b3 1f 13 ed ba cf e7 3e 45 da 17 5a 80 
server |<7>| 0027 - 1b 03 f5 81 46 0a 27 c7 0c 01 1e c3 89 a6 02 2b 
server |<7>| 0028 - 18 d2 2d 90 1d 52 2e 5c 91 63 e1 13 00 11 01 00 
server |<7>| 0029 - 01 c2 c0 c7 04 18 01 02 00 0f 05 02 47 88 a5 7c 
server |<7>| 002a - 02 1b 02 05 09 10 ea cf 80 00 a8 09 10 a0 21 e3 
server |<7>| 002b - f8 08 99 90 51 9d 20 04 19 01 02 00 06 05 02 47 
server |<7>| 002c - 88 a5 7c 00 0a 09 10 83 7b 6f b4 2e 0f e1 76 00 
server |<7>| 002d - 47 04 00 a0 23 84 ef 64 48 e1 3c 52 ec 04 38 a9 
server |<7>| 002e - 70 b1 62 fd 2d 45 12 90 72 63 73 f7 1a d1 ab 0b 
server |<7>| 002f - 01 ea f3 ac 7b 25 75 10 1c c0 26 d6 91 5c 41 04 
server |<7>| 0030 - 7c 92 c3 60 8b 16 3c e9 81 d5 e1 c1 1b 6c ca d3 
server |<7>| 0031 - 20 1d a6 a9 7c 03 db 8a 70 16 8c 23 c8 10 9c 76 
server |<7>| 0032 - 80 36 5e 66 74 e0 8b 80 d5 6d 99 f9 13 75 33 1c 
server |<7>| 0033 - 6c 8b eb d3 04 a1 7a f9 b7 eb e9 89 e9 90 15 df 
server |<7>| 0034 - e7 18 3f a1 fd 0d 80 ef aa 1d 82 f0 2b c9 1b d2 
server |<7>| 0035 - d5 2a 23 f1 b7 06 1e 35 1f 95 ac 97 18 e4 af 68 
server |<7>| 0036 - 3f 0f d9 5e 55 cf 48 52 f3 64 19 72 a5 b1 0f ca 
server |<7>| 0037 - 94 06 a6 dc 07 c6 ad a2 49 8e 21 8c 61 2b 24 66 
server |<7>| 0038 - 3b 9f 13 e4 c6 be 89 ac 41 4d 42 30 79 ef a9 05 
server |<7>| 0039 - 80 e0 74 7e 84 d9 d8 7d c4 b9 70 c3 36 4a 68 27 
server |<7>| 003a - 08 44 24 1c 39 b9 0b b0 c5 68 7d 92 68 fa 6d 17 
server |<7>| 003b - 7f cc c8 e7 b3 5e 40 5f a1 5c 98 56 ee 52 2b 5a 
server |<7>| 003c - 04 15 af c2 15 a7 f9 60 a3 be 9a 70 b1 df 2f fb 
server |<7>| 003d - 75 9f 43 61 83 8a f6 b2 bc f6 7e 93 f6 c3 99 5a 
server |<7>| 003e - 43 4a 88 99 82 e7 66 11 85 1d 4f ab 25 4c 85 68 
server |<7>| 003f - 77 e1 0f cf ec bc dd 8b b9 99 0e e7 bd 29 8d 5f 
server |<7>| 0040 - ca eb c1 1a 1e 71 1f 93 96 fc 8d 6b bf 7a ea 21 
server |<7>| 0041 - c1 c0 b0 7f 6d 0c d6 44 e8 dc 18 
server |<4>| REC[43618]: Sent Packet[2] Handshake(22) with length: 1051
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 00 51 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[0] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[0] Handshake(22) with length: 81
client |<7>| READ: Got 81 bytes from 5
client |<7>| READ: read 81 bytes from 5
client |<7>| 0000 - 02 00 00 4d 03 02 48 39 1b 27 23 a7 49 e7 b3 eb 
client |<7>| 0001 - 6e 54 8b 34 76 db ef bf 40 88 e3 0b 47 20 22 16 
client |<7>| 0002 - b4 f5 90 c8 11 60 20 75 7c 0c 3f b7 b4 de 07 54 
client |<7>| 0003 - d2 ab dd b8 e7 3e 17 d8 e3 70 0a e9 d1 d9 0e 1a 
client |<7>| 0004 - ee 6b fd bb 69 a3 5a 00 33 00 00 05 00 09 00 01 
client |<7>| 0005 - 01 
client |<7>| RB: Have 5 bytes into buffer. Adding 81 bytes.
client |<7>| RB: Requested 86 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[0] Handshake(22) with length: 81
client |<6>| BUF[HSK]: Inserted 81 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: SERVER HELLO was received [81 bytes]
client |<6>| BUF[REC][HD]: Read 77 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 77 bytes of Data
client |<3>| HSK[43df0]: Server's version: 3.2
client |<3>| HSK[43df0]: SessionID length: 32
client |<3>| HSK[43df0]: SessionID: 757c0c3fb7b4de0754d2abddb8e73e17d8e3700ae9d1d90e1aee6bfdbb69a35a
client |<3>| HSK[43df0]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
client |<2>| EXT[43df0]: Received extension 'CERT_TYPE/9'
client |<7>| READ: Got 5 bytes from 5
client |<7>| READ: read 5 bytes from 5
client |<7>| 0000 - 16 03 02 04 16 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[43df0]: Expected Packet[1] Handshake(22) with length: 1
client |<4>| REC[43df0]: Received Packet[1] Handshake(22) with length: 1046
client |<7>| READ: Got 1046 bytes from 5
client |<7>| READ: read 1046 bytes from 5
client |<7>| 0000 - 0b 00 04 12 00 04 0f 02 08 83 7b 6f b4 2e 0f e1 
client |<7>| 0001 - 76 00 04 02 99 00 d1 04 47 63 e8 83 01 06 20 d7 
client |<7>| 0002 - 48 47 8b b9 3d 1e 12 c0 00 d6 c2 3f f3 b6 0b 68 
client |<7>| 0003 - 8b b5 d5 6e 69 5f 6d 04 c7 a4 16 05 c5 34 82 f3 
client |<7>| 0004 - ca 48 49 23 72 57 fa e0 9e 5a ae 9d 83 fb ec 5e 
client |<7>| 0005 - da 1c be 0a 51 17 8d de ff 6c 2b 0d 35 c5 21 84 
client |<7>| 0006 - 7e 8c 7f 26 69 6a 51 48 3a 09 5b d3 8d d7 8b 7e 
client |<7>| 0007 - 4b 95 20 19 c7 8f ed 8a 32 56 b1 7b 3a 7b 23 1b 
client |<7>| 0008 - 4f 69 35 e9 5d c4 9f f2 23 ae 56 ae d4 5f ba 7a 
client |<7>| 0009 - b4 a6 e9 a4 a5 ce e4 68 26 7c 0f 3c 55 45 6f 18 
client |<7>| 000a - 1b 35 fc f4 29 58 a4 1d 1a b8 fe e8 8d d1 46 60 
client |<7>| 000b - cd fe 19 da d6 31 94 fc dd b7 db 7d 07 6f 1f 9b 
client |<7>| 000c - bb b8 3d 72 f8 a2 4a 1d 74 ae 2e eb 74 38 55 27 
client |<7>| 000d - ae ed 46 44 46 52 cc b7 5c ee 9d 58 2e c4 9b 36 
client |<7>| 000e - 65 10 ef 00 11 01 00 01 b4 10 74 65 73 74 33 2e 
client |<7>| 000f - 67 6e 75 74 6c 73 2e 6f 72 67 c2 c0 40 04 13 01 
client |<7>| 0010 - 02 00 26 05 02 47 63 e8 83 02 1b 03 05 09 09 66 
client |<7>| 0011 - 01 80 06 0b 09 08 07 03 02 04 15 02 08 03 04 16 
client |<7>| 0012 - 02 03 01 02 1e 01 02 17 80 00 0a 09 10 a0 21 e3 
client |<7>| 0013 - f8 08 99 90 51 f7 a4 06 1f 71 37 cf 29 c4 4e e4 
client |<7>| 0014 - 12 df ef a1 18 cb cc 5e ad a6 0c 97 93 d9 ef 3d 
client |<7>| 0015 - eb 8c bf 89 f2 0e 06 9a f6 2b 68 ac b8 b6 27 ae 
client |<7>| 0016 - d1 8a cb 18 be 66 9b 72 1e fe b2 99 1d db 0e f8 
client |<7>| 0017 - a8 e7 47 23 9e 84 ff 58 ad 68 9e 8b 0e 26 fb 62 
client |<7>| 0018 - 8c 60 52 f9 4f e8 a2 ad e2 9b b1 31 a5 e4 18 5d 
client |<7>| 0019 - cf f3 a5 8b 17 3a 60 79 9b a0 6f 76 89 94 a7 63 
client |<7>| 001a - cc a9 dc 6c 98 e3 e8 69 19 12 63 1e 51 d9 19 68 
client |<7>| 001b - ff 3d dc b2 87 65 ea ca 77 93 8e b9 63 f8 e0 ec 
client |<7>| 001c - be 20 93 10 f3 5c 93 3e 09 2d 71 32 17 0e 17 48 
client |<7>| 001d - 01 86 9a 6a 2e 71 ba ef 1d 28 c3 ce 3b 3f 27 6c 
client |<7>| 001e - b7 39 30 d2 c3 aa 79 d9 0b 3e e4 9c 68 73 67 94 
client |<7>| 001f - 05 90 ed 01 fa 99 b6 e9 a8 72 70 7a 44 ce 8d 04 
client |<7>| 0020 - 47 88 a5 7c 01 04 00 d2 26 7c d5 65 f2 a4 b2 38 
client |<7>| 0021 - 64 4d be 85 87 c1 0a 77 cc 55 f4 05 fe f3 e0 bc 
client |<7>| 0022 - 04 b1 87 0a e2 18 36 bd 65 cd 9f fd 57 da 91 f3 
client |<7>| 0023 - 62 c1 98 07 1f a8 82 7a 9a 47 06 23 f6 8e 58 e7 
client |<7>| 0024 - 6e e3 ac 2f a7 f5 47 ed 05 b2 7c 93 57 01 db b8 
client |<7>| 0025 - 45 3b 21 4d b2 f8 9d 3f b3 4c f7 c1 cc 7d b3 1f 
client |<7>| 0026 - 13 ed ba cf e7 3e 45 da 17 5a 80 1b 03 f5 81 46 
client |<7>| 0027 - 0a 27 c7 0c 01 1e c3 89 a6 02 2b 18 d2 2d 90 1d 
client |<7>| 0028 - 52 2e 5c 91 63 e1 13 00 11 01 00 01 c2 c0 c7 04 
client |<7>| 0029 - 18 01 02 00 0f 05 02 47 88 a5 7c 02 1b 02 05 09 
client |<7>| 002a - 10 ea cf 80 00 a8 09 10 a0 21 e3 f8 08 99 90 51 
client |<7>| 002b - 9d 20 04 19 01 02 00 06 05 02 47 88 a5 7c 00 0a 
client |<7>| 002c - 09 10 83 7b 6f b4 2e 0f e1 76 00 47 04 00 a0 23 
client |<7>| 002d - 84 ef 64 48 e1 3c 52 ec 04 38 a9 70 b1 62 fd 2d 
client |<7>| 002e - 45 12 90 72 63 73 f7 1a d1 ab 0b 01 ea f3 ac 7b 
client |<7>| 002f - 25 75 10 1c c0 26 d6 91 5c 41 04 7c 92 c3 60 8b 
client |<7>| 0030 - 16 3c e9 81 d5 e1 c1 1b 6c ca d3 20 1d a6 a9 7c 
client |<7>| 0031 - 03 db 8a 70 16 8c 23 c8 10 9c 76 80 36 5e 66 74 
client |<7>| 0032 - e0 8b 80 d5 6d 99 f9 13 75 33 1c 6c 8b eb d3 04 
client |<7>| 0033 - a1 7a f9 b7 eb e9 89 e9 90 15 df e7 18 3f a1 fd 
client |<7>| 0034 - 0d 80 ef aa 1d 82 f0 2b c9 1b d2 d5 2a 23 f1 b7 
client |<7>| 0035 - 06 1e 35 1f 95 ac 97 18 e4 af 68 3f 0f d9 5e 55 
client |<7>| 0036 - cf 48 52 f3 64 19 72 a5 b1 0f ca 94 06 a6 dc 07 
client |<7>| 0037 - c6 ad a2 49 8e 21 8c 61 2b 24 66 3b 9f 13 e4 c6 
client |<7>| 0038 - be 89 ac 41 4d 42 30 79 ef a9 05 80 e0 74 7e 84 
client |<7>| 0039 - d9 d8 7d c4 b9 70 c3 36 4a 68 27 08 44 24 1c 39 
client |<7>| 003a - b9 0b b0 c5 68 7d 92 68 fa 6d 17 7f cc c8 e7 b3 
client |<7>| 003b - 5e 40 5f a1 5c 98 56 ee 52 2b 5a 04 15 af c2 15 
client |<7>| 003c - a7 f9 60 a3 be 9a 70 b1 df 2f fb 75 9f 43 61 83 
client |<7>| 003d - 8a f6 b2 bc f6 7e 93 f6 c3 99 5a 43 4a 88 99 82 
client |<7>| 003e - e7 66 11 85 1d 4f ab 25 4c 85 68 77 e1 0f cf ec 
client |<7>| 003f - bc dd 8b b9 99 0e e7 bd 29 8d 5f ca eb c1 1a 1e 
client |<7>| 0040 - 71 1f 93 96 fc 8d 6b bf 7a ea 21 c1 c0 b0 7f 6d 
client |<7>| 0041 - 0c d6 44 e8 dc 18 
client |<7>| RB: Have 5 bytes into buffer. Adding 1046 bytes.
client |<7>| RB: Requested 1051 bytes
client |<2>| ASSERT: gnutls_cipher.c:205
client |<4>| REC[43df0]: Decrypted Packet[1] Handshake(22) with length: 1046
client |<6>| BUF[HSK]: Inserted 1046 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
client |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
client |<3>| HSK[43df0]: CERTIFICATE was received [1046 bytes]
client |<6>| BUF[REC][HD]: Read 1042 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 81 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 1042 bytes of Data
client |<2>| Importing Openpgp cert and using openpgp sub key: 837b6fb400000402
client |<2>| ASSERT: pgp.c:763
client |<2>| ASSERT: pgp.c:969
client |<2>| ASSERT: gnutls_openpgp.c:795
client |<2>| ASSERT: auth_cert.c:1197
client |<2>| ASSERT: gnutls_kx.c:717
client |<2>| ASSERT: gnutls_handshake.c:2345
client |<6>| BUF[HSK]: Cleared Data from buffer
client: Handshake failed
GNUTLS ERROR: Could not find OpenPGP subkey.
Launched, setting DH parameters...
server: ready. Listening to port '5556'.
Setting key files...
Connecting...
server |<3>| HSK[43618]: SERVER KEY EXCHANGE was send [397 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[2] Handshake(22) with length: 397
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 402 bytes to 5.
server |<7>| WRITE: wrote 402 bytes to 5. Left 0 bytes. Total 402 bytes.
server |<7>| 0000 - 16 03 02 01 8d 0c 00 01 89 00 80 b6 4c 70 da 39 
server |<7>| 0001 - 6c 54 2b 2b 7c ba b1 ac df 88 ac 5f f7 5b cb d5 
server |<7>| 0002 - 16 f0 f3 61 b2 e6 c6 2d 86 42 ff 6c fc f4 06 58 
server |<7>| 0003 - fd 5d f6 2d b6 3f 60 e9 ad f7 09 92 75 ad ec a8 
server |<7>| 0004 - 42 23 54 9a 62 c7 8e 40 82 08 01 83 fb f0 27 f2 
server |<7>| 0005 - 22 91 92 71 6f ef 4b c9 21 af 0d 2b 95 08 b2 78 
server |<7>| 0006 - 2b d0 80 5d ce 19 e1 8e 13 2c 1c c3 ea 10 4f 84 
server |<7>| 0007 - a6 14 e0 fb 1f 4b 26 25 ed 82 37 28 d8 a5 ec 41 
server |<7>| 0008 - 5d 0f c0 d2 66 d3 17 d4 0a 9b 57 00 01 05 00 80 
server |<7>| 0009 - 70 aa 22 40 b8 13 0c 5f 6e 24 d5 99 65 3d d5 68 
server |<7>| 000a - 6e f4 24 be dd 9e c6 12 1e 4a d5 db d4 09 67 20 
server |<7>| 000b - c6 16 bf 0b 6b fe 60 90 98 18 d8 f1 ae ca 2e 66 
server |<7>| 000c - 04 dc bb bc cd 3d 58 e3 e4 97 35 7a 95 15 c8 85 
server |<7>| 000d - 39 73 12 7e 7b 27 4f 12 b5 d2 1e 09 7c ff 5f cb 
server |<7>| 000e - 75 5e 83 63 67 89 91 a7 74 8f 3a af d7 c6 2e 00 
server |<7>| 000f - df d6 fe 9c 01 44 e5 a9 99 79 5e e6 11 d7 68 7e 
server |<7>| 0010 - 6c 72 3a d1 02 da 93 c8 60 b4 09 f1 e7 0b ea 91 
server |<7>| 0011 - 00 80 64 9c 8d 7b 76 51 bf 85 fc 90 00 c5 19 aa 
server |<7>| 0012 - cd 01 c8 d6 f2 5b cf 17 c5 a9 dc 19 e0 4a a7 b2 
server |<7>| 0013 - 3b d5 f3 d9 01 1b 1d 89 7c e0 98 87 af 8b da 41 
server |<7>| 0014 - 44 77 b7 20 6d 29 62 ba 3f 9d 78 c2 5f e4 7b 58 
server |<7>| 0015 - 0d ec 15 ad 76 85 3c 25 32 da 5d de 35 af 58 2e 
server |<7>| 0016 - ef 55 fa 6a 21 9d 51 4f be c1 8a ce 3c 17 ac 03 
server |<7>| 0017 - e3 60 30 be 61 52 7f c8 4d 9d 65 59 c8 85 78 21 
server |<7>| 0018 - 53 05 ed 98 d9 3e eb 65 f4 d6 a3 cd e6 cb ef ce 
server |<7>| 0019 - 69 2b 
server |<4>| REC[43618]: Sent Packet[3] Handshake(22) with length: 402
server |<3>| HSK[43618]: CERTIFICATE REQUEST was send [9 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[43618]: Sending Packet[3] Handshake(22) with length: 9
server |<2>| ASSERT: gnutls_cipher.c:205
server |<7>| WRITE: Will write 14 bytes to 5.

real	0m0.291s
user	0m0.248s
sys	0m0.016s
openpgpself exitcode was 141
-------------- next part --------------
Self test `./resume' finished with 0 errors
PASS: resume
client |<2>| Importing Openpgp key and using openpgp sub key: 837b6fb470ad0608
client |<2>| ASSERT: pgp.c:763
client |<2>| ASSERT: privkey.c:505
client |<2>| ASSERT: gnutls_openpgp.c:739
client |<2>| ASSERT: gnutls_openpgp.c:152
client |<2>| ASSERT: privkey.c:1058
client |<2>| Importing Openpgp key and using main openpgp key.
client |<2>| ASSERT: pgp.c:1461
client |<2>| Importing Openpgp cert and using main openpgp key
client |<2>| ASSERT: pgp.c:156
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
client |<3>| HSK[806afc8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
client |<3>| HSK[806afc8]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
client |<3>| HSK[806afc8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
client |<2>| EXT[806afc8]: Sending extension CERT_TYPE
client |<3>| HSK[806afc8]: CLIENT HELLO was send [88 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[806afc8]: Sending Packet[0] Handshake(22) with length: 88
client |<2>| ASSERT: gnutls_cipher.c:205
client |<7>| WRITE: Will write 93 bytes to 5.
client |<7>| WRITE: wrote 93 bytes to 5. Left 0 bytes. Total 93 bytes.
client |<7>| 0000 - 16 03 02 00 58 01 00 00 54 03 02 48 37 c1 ee 06 
client |<7>| 0001 - 5a c3 18 95 9e d6 e4 f4 ef 57 8d 03 e0 80 15 fa 
client |<7>| 0002 - eb 2a 0a 27 bc 58 9e 41 dc 90 db 00 00 24 00 33 
client |<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 
client |<7>| 0004 - 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 
client |<7>| 0005 - 00 04 01 00 00 07 00 09 00 03 02 00 01 
client |<4>| REC[806afc8]: Sent Packet[1] Handshake(22) with length: 93
server |<7>| READ: Got 5 bytes from 5
server |<7>| READ: read 5 bytes from 5
server |<7>| 0000 - 16 03 02 00 58 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[806ad98]: Expected Packet[0] Handshake(22) with length: 1
server |<4>| REC[806ad98]: Received Packet[0] Handshake(22) with length: 88
server |<7>| READ: Got 88 bytes from 5
server |<7>| READ: read 88 bytes from 5
server |<7>| 0000 - 01 00 00 54 03 02 48 37 c1 ee 06 5a c3 18 95 9e 
server |<7>| 0001 - d6 e4 f4 ef 57 8d 03 e0 80 15 fa eb 2a 0a 27 bc 
server |<7>| 0002 - 58 9e 41 dc 90 db 00 00 24 00 33 00 45 00 39 00 
server |<7>| 0003 - 88 00 16 00 32 00 44 00 38 00 87 00 13 00 66 00 
server |<7>| 0004 - 2f 00 41 00 35 00 84 00 0a 00 05 00 04 01 00 00 
server |<7>| 0005 - 07 00 09 00 03 02 00 01 
server |<7>| RB: Have 5 bytes into buffer. Adding 88 bytes.
server |<7>| RB: Requested 93 bytes
server |<2>| ASSERT: gnutls_cipher.c:205
server |<4>| REC[806ad98]: Decrypted Packet[0] Handshake(22) with length: 88
server |<6>| BUF[HSK]: Inserted 88 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
server |<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
server |<3>| HSK[806ad98]: CLIENT HELLO was received [88 bytes]
server |<6>| BUF[REC][HD]: Read 84 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 84 bytes of Data
server |<3>| HSK[806ad98]: Client's version: 3.2
server |<2>| ASSERT: gnutls_db.c:238
server |<2>| EXT[806ad98]: Received extension 'CERT_TYPE/9'
server |<2>| EXT[806ad98]: Received extension 'CERT_TYPE/9'
server |<2>| ASSERT: ext_cert_type.c:106
server |<2>| ASSERT: ext_cert_type.c:106
server |<2>| ASSERT: ext_cert_type.c:123
server |<2>| ASSERT: gnutls_handshake.c:2875
server |<1>| Could not find an appropriate certificate: Insufficient credentials for that request.
server |<3>| HSK[806ad98]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_ARCFOUR_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_ARCFOUR_MD5
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_AES_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_AES_256_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
server |<3>| HSK[806ad98]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
server |<2>| ASSERT: gnutls_handshake.c:706
server |<2>| ASSERT: gnutls_handshake.c:465
server |<2>| ASSERT: gnutls_handshake.c:2024
server |<2>| ASSERT: gnutls_handshake.c:2550
server |<6>| BUF[HSK]: Cleared Data from buffer
client |<7>| READ: Got 0 bytes from 5
client |<7>| READ: read 0 bytes from 5
client |<7>| 0000 - 
client |<2>| ASSERT: gnutls_buffers.c:638
client |<2>| ASSERT: gnutls_record.c:909
client |<2>| ASSERT: gnutls_buffers.c:1152
client |<2>| ASSERT: gnutls_handshake.c:1031
client |<2>| ASSERT: gnutls_handshake.c:2330
client |<6>| BUF[HSK]: Cleared Data from buffer
client: Handshake failed
GNUTLS ERROR: A TLS packet with unexpected length was received.
Launched, setting DH parameters...
server: ready. Listening to port '5556'.
Setting key files...
Connecting...
server: Handshake has failed (Could not negotiate a supported cipher suite.)

Launched, setting DH parameters...
server: ready. Listening to port '5556'.
server: connection from 127.0.0.1, port 55245
PASS: openpgpself

From simon at josefsson.org  Mon May 26 10:15:58 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 10:15:58 +0200
Subject: gnutls4win and Debian
In-Reply-To: <20080524125216.GA23057@garfield> (Enrico Tassi's message of
	"Sat, 24 May 2008 14:52:16 +0200")
References: <20080524125216.GA23057@garfield>
Message-ID: <87r6bpmqf5.fsf@mocca.josefsson.org>

Hi Enrico!

Many thanks for this, I have added your script to the gnutls4win
repository and hooked it into the build path.  So future release will be
distributed as debian packages from the gnutls4win site too.  I created
*.deb's for 2.2.5 and 2.3.11.

May I ask that you release the script under GPLv2 or later?  I can add
the license template to the file.

Let me know if you want CVS write access so you can maintain the script
and make improvements.  For example, is it possible to sign the *.deb
file?

Thanks,
/Simon

Enrico Tassi <gareuselesinge at debian.org> writes:

> Hi, I'm a croos-compiling addicted and I like your gnutls4win stuff.
> Since I'm using Debian too, I made a simple script to take one of your
> .zip files and create a .deb package that installs files in
> /usr/i586-mingw32msvc. This eases the task of having a clean buid env.
>
> In case you are interested in it, I attach it. Is is very simple and
> uses the equivs tool, and sould be possible to integrate it in your
> Makefile.
>
> Cheers
> -- 
> Enrico Tassi
>
> #!/bin/sh
>
> VERSION=2.2.5
> DEBIAN_REVISION=-1
> FILE=gnutls-$VERSION.zip
> TMP=tmp
>
> rm -rf $TMP
> mkdir $TMP
> cp $FILE $TMP/
> cd $TMP/
> unzip $FILE
> rm $FILE
> echo Section: libs >> control
> echo Priority: optional >> control
> echo Standards-Version: 3.6.2 >> control
> echo >> control
> echo Package: mingw32-gnutls >> control
> echo Version: $VERSION$DEBIAN_REVISION >> control
> echo Maintainer: "${DEBFULLNAME:-'foo'} <${DEBEMAIL:-'foo <foo at foo>'}>" >> control
> echo Architecture: all >> control
> echo Files: >> control
> for F in `find . -type f | grep -v ^./control$ | sed s/..//`; do
> 	echo "	$F /usr/i586-mingw32msvc/$F" >> control
> done
> echo Description: gnutls library for mingw32 >> control
> echo ' This package includes both dlls and .h files' >> control
> equivs-build control
> mv mingw32-gnutls_$VERSION${DEBIAN_REVISION}_all.deb ..
> cd ..
> rm -rf $TMP/




From simon at josefsson.org  Mon May 26 11:10:48 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 11:10:48 +0200
Subject: gnutls4win and Debian
In-Reply-To: <20080526084253.GA5769@garfield> (Enrico Tassi's message of "Mon, 
	26 May 2008 10:42:53 +0200")
References: <20080524125216.GA23057@garfield>
	<87r6bpmqf5.fsf@mocca.josefsson.org> <20080526084253.GA5769@garfield>
Message-ID: <87skw5ig6f.fsf@mocca.josefsson.org>

Enrico Tassi <gareuselesinge at debian.org> writes:

> On Mon, May 26, 2008 at 10:15:58AM +0200, Simon Josefsson wrote:
>> Hi Enrico!
>> 
>> Many thanks for this, I have added your script to the gnutls4win
>> repository and hooked it into the build path.  So future release will be
>> distributed as debian packages from the gnutls4win site too.  I created
>> *.deb's for 2.2.5 and 2.3.11.
>> 
>> May I ask that you release the script under GPLv2 or later?  I can add
>> the license template to the file.
>
> Yes, go for GPL, it is ok for me. 

Great, done.

>> Let me know if you want CVS write access so you can maintain the script
>> and make improvements.  
>
> no need to have CVS access, I would eventually send you patches 

Ok.

>> For example, is it possible to sign the *.deb
>
> IIRC, equivs has a -f switch, but then you will have to put a valid
> GPG identity in the Maintainer field and GPG will be called to sign the 
> .changes and .dsc files (that will be generated in that case).
>
> if you plan to make a repository, you may look at apt-ftparchive.

I'll leave this for later (or for someone else to contribute patches or
infrastructure to make this happen).

Thanks,
/Simon




From simon at josefsson.org  Mon May 26 11:37:59 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 11:37:59 +0200
Subject: gnutls 2.3.11 testsuite failure on sparc (openpgpself)
In-Reply-To: <20080525080428.GB3208@downhill.g.la> (Andreas Metzler's message
	of "Sun, 25 May 2008 10:04:28 +0200")
References: <20080525080428.GB3208@downhill.g.la>
Message-ID: <8763t1iex4.fsf@mocca.josefsson.org>

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

> Hello,
>
> gnutls 2.3.11 dpoes not build correctly on sparc.
>
> http://experimental.debian.net/fetch.php?&pkg=gnutls26&ver=2.3.11-1&arch=sparc&stamp=1211629418&file=log&as=raw
>
> There is testsuite failure when running openpgpself. (Complete output
> attached). From comparing the output with i386, it looks like i386
> actually does not complete successfully, too - but the error is not
> correctly reflected in the exit code:
>
> --------------
> client: Handshake failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.
> --------------

Indeed, the openpgpself test doesn't seem to work on any platform.
Nikos, could you take a look at this?

<thinking out loud>The *self tests are rather ugly and have poor error
handling... it would be nice to clean them up to provide a generic test
framework so it can test much more: all ciphers, all hashes, and so on.

/Simon




From simon at josefsson.org  Mon May 26 11:40:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 11:40:54 +0200
Subject: [PATCH] RAND_pseudo_bytes() stub
In-Reply-To: <20080524100854.GA17127@thorin> (Robert Millan's message of "Sat, 
	24 May 2008 12:08:54 +0200")
References: <20080524100854.GA17127@thorin>
Message-ID: <871w3pies9.fsf@mocca.josefsson.org>

Robert Millan <rmh at aybabtu.com> writes:

> This patch adds a RAND_pseudo_bytes() stub for compatibility with OpenSSL.

Added, thanks.

/Simon




From simon at josefsson.org  Mon May 26 12:53:25 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 12:53:25 +0200
Subject: Patch to improve behaviour in gnutls_x509_crl_set_version()
	when `char' is unsigned
In-Reply-To: <200805240959.59496.l@lwithers.me.uk> (Laurence Withers's message
	of "Sat, 24 May 2008 09:59:59 +0000")
References: <200805240959.59496.l@lwithers.me.uk>
Message-ID: <87bq2tuyje.fsf@mocca.josefsson.org>

Laurence Withers <l at lwithers.me.uk> writes:

> Hi,
>
> On some platforms, char can be unsigned by default (in my case I'm using gcc 
> 3.4.5 on arm). When that's the case, I noticed a compilation warning in 
> lib/x509/crl_write.c .
>
> The attached patch fixes the warning, but also slightly changes the way the 
> test is carried out.
>
> The documentation for the function states that the supplied version parameter 
> must be 1 or 2, and implies it can be higher but not 0. The patch explicitly 
> checks that version >= 1 without performing any arithmetic in a char type. If 
> the check fails, the function returns with GNUTLS_E_INVALID_REQUEST, which I 
> guess is the right thing to do. If the check succeeds, the previous behaviour 
> is used. However, a char value of 0 is never decremented, so there is never 
> any possibility of an overflow.
>
> If this behaviour isn't really wanted, and the exact previous semantics of the 
> function should be preserved (version 0 -> 0, version 1 -> 0, version 2 -> 1 
> etc.) then let me know and I'll rework the patch.

Hi!  Thanks for the report.  I think we need to preserve the old
behaviour for 0, so I reworked the patch slightly.

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

Did you notice any similar compilation warnings?  Which compilation
flags did you use?

/Simon





From simon at josefsson.org  Mon May 26 13:22:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 13:22:27 +0200
Subject: Patch to improve behaviour in gnutls_x509_crl_set_version()
	when `char' is unsigned
In-Reply-To: <200805261117.57926.l@lwithers.me.uk> (Laurence Withers's message
	of "Mon, 26 May 2008 11:17:57 +0000")
References: <200805240959.59496.l@lwithers.me.uk>
	<87bq2tuyje.fsf@mocca.josefsson.org>
	<200805261117.57926.l@lwithers.me.uk>
Message-ID: <87y75xtimk.fsf@mocca.josefsson.org>

Laurence Withers <l at lwithers.me.uk> writes:

>> Did you notice any similar compilation warnings?  Which compilation
>> flags did you use?
>
> No, I didn't notice any other warnings. Some generated tables have 
> the "extern" keyword in the definition, which seems wrong, but I haven't 
> investigated that yet.

Was this the lib/*_tab.c files?  This has been fixed in the 2.3.x
series.  Btw, you may want to try 2.3.x instead since it has been
improved and cleaned up in many ways.  Only the openpgp stuff is
somewhat unstable, the rest is assumed to work perfectly.

> I simply used -Os -g for cflags, there were no warning flags in there.

What exact warning did you get?  I'll see if I can trigger the same
warning.  Possibly it is only emitted in your particular environment.

/Simon




From l at lwithers.me.uk  Mon May 26 13:30:23 2008
From: l at lwithers.me.uk (Laurence Withers)
Date: Mon, 26 May 2008 11:30:23 +0000
Subject: Patch to improve behaviour in gnutls_x509_crl_set_version()
	when `char' is unsigned
In-Reply-To: <87y75xtimk.fsf@mocca.josefsson.org>
References: <200805240959.59496.l@lwithers.me.uk>
	<200805261117.57926.l@lwithers.me.uk>
	<87y75xtimk.fsf@mocca.josefsson.org>
Message-ID: <200805261130.23415.l@lwithers.me.uk>

On Monday 26 May 2008, Simon Josefsson wrote:
> Was this the lib/*_tab.c files?  This has been fixed in the 2.3.x
> series.  Btw, you may want to try 2.3.x instead since it has been
> improved and cleaned up in many ways.  Only the openpgp stuff is
> somewhat unstable, the rest is assumed to work perfectly.

pkix_asn1_tab.c:7: warning: `pkix_asn1_tab' initialized and declared `extern'
gnutls_asn1_tab.c:7: warning: `gnutls_asn1_tab' initialized and declared 
`extern'

I shall try the 2.3 series soon.

> > I simply used -Os -g for cflags, there were no warning flags in there.
>
> What exact warning did you get?  I'll see if I can trigger the same
> warning.  Possibly it is only emitted in your particular environment.

crl_write.c: In function `gnutls_x509_crl_set_version':
crl_write.c:72: warning: comparison is always false due to limited range of 
data type

I suspect it is emitted only in my environment, which is a gcc 3.4.5 
crosscompiler for arm-softfloat-linux-gnu.

Bye for now,
-- 
Laurence Withers, <l at lwithers.me.uk>  --  jabber:l at jabber.lwithers.me.uk
http://www.lwithers.me.uk/                             tel:+447753988197




From simon at josefsson.org  Mon May 26 13:36:47 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 13:36:47 +0200
Subject: Patch to improve behaviour in gnutls_x509_crl_set_version()
	when `char' is unsigned
In-Reply-To: <200805261130.23415.l@lwithers.me.uk> (Laurence Withers's message
	of "Mon, 26 May 2008 11:30:23 +0000")
References: <200805240959.59496.l@lwithers.me.uk>
	<200805261117.57926.l@lwithers.me.uk>
	<87y75xtimk.fsf@mocca.josefsson.org>
	<200805261130.23415.l@lwithers.me.uk>
Message-ID: <87tzglthyo.fsf@mocca.josefsson.org>

Laurence Withers <l at lwithers.me.uk> writes:

> On Monday 26 May 2008, Simon Josefsson wrote:
>> Was this the lib/*_tab.c files?  This has been fixed in the 2.3.x
>> series.  Btw, you may want to try 2.3.x instead since it has been
>> improved and cleaned up in many ways.  Only the openpgp stuff is
>> somewhat unstable, the rest is assumed to work perfectly.
>
> pkix_asn1_tab.c:7: warning: `pkix_asn1_tab' initialized and declared `extern'
> gnutls_asn1_tab.c:7: warning: `gnutls_asn1_tab' initialized and declared 
> `extern'
>
> I shall try the 2.3 series soon.

Those problems are fixed in 2.3.

>> > I simply used -Os -g for cflags, there were no warning flags in there.
>>
>> What exact warning did you get?  I'll see if I can trigger the same
>> warning.  Possibly it is only emitted in your particular environment.
>
> crl_write.c: In function `gnutls_x509_crl_set_version':
> crl_write.c:72: warning: comparison is always false due to limited range of 
> data type
>
> I suspect it is emitted only in my environment, which is a gcc 3.4.5 
> crosscompiler for arm-softfloat-linux-gnu.

Thanks,
Simon




From simon at josefsson.org  Mon May 26 16:31:31 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 16:31:31 +0200
Subject: Do we need to bump the shared library version for 2.4.0?
Message-ID: <87ej7prvb0.fsf@mocca.josefsson.org>

In 2.3.x we have moved several symbols from libgnutls-extra to libgnutls
(see complete explanation in the 2.4.0 release notes draft below), but
do we need to bump the shared library version?  No symbols have been
removed from any library libgnutls*, except for the symbols that have
been moved.  libgnutls-extra links to libgnutls.

I see several solutions here:

1) Increment the shared library version of libgnutls*.

   This will cause an unnecessary shared library version break for
   libgnutls, which have only had new functions added to it.  Given the
   problem described in 2) I'm not sure how it could be avoided though.

2) Separate the shared library versions for libgnutls and
   libgnutls-extra, and increment only the libgnutls-extra version.

   This may be the The Right Thing to do, but it causes a new problem:
   an application linking to libgnutls-extra.so.26 (2.2.x) may pull in
   libgnutls.so from 2.4.x, which won't work together.  Both
   libgnutls.so and libgnutls-extra.so would then provide the same
   symbols.  If the application uses the one from libgnutls.so all is
   fine, but it will break of the ones from libgnutls-extra.so is used.

3) Don't increment the shared library version at all.

   The justification would be that we haven't removed any symbols, all
   symbols in libgnutls-extra are still available via libgnutls and work
   the same way.  The only thing that would break here is if someone is
   dlopen'ing libgnutls-extra.so and calls the openpgp related
   functions.  Strictly speaking I'm not sure this is a valid approach,
   since we HAVE removed symbols from libgnutls-extra.

Thoughts?

I'm leaning towards 1) because of the problem in 2) and 3), however I do
realize this will generate a lot of work for our packagers.

Thanks,
Simon
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls23.txt
URL: </pipermail/attachments/20080526/38a83b3a/attachment.txt>

From simon at josefsson.org  Mon May 26 17:53:26 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 May 2008 17:53:26 +0200
Subject: Draft of GnuTLS 2.4.0 release notes
Message-ID: <87prr9qcy1.fsf@mocca.josefsson.org>

If you have any comments on what we should say in the 2.4.0 release
notes, now is the time to speak.  Here is how they look right now.  I
have only gone through *.so ABI function changes and NEWS entries during
2.3.x so I may have missed somethings...  will compare the *.h's soon.

/Simon

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

Major end-user visible changes compared to the v2.2 branch:

* The certtool --inder and --outder has been replaced by --inraw and --outraw.

  This aligns terminology with OpenPGP, which doesn't use DER
  encoding.  The old parameters will continue to work for some time.

* Certtool now confirm passwords and changes permissions of private key files.

* The default handshake size limit has been increased to 48kb.

  It appears as if some valid handshakes are large due to sending many
  CA certificates.  (The earlier limit was 16kb.)

* LZO compression is now disabled by default.

  The main reason is that LZO compression in TLS is not standardized,
  but license compatiblity issues with minilzo triggered us to make
  this decision now.

* Improvements for cross-compilation to Windows and OpenWRT.

* The look of the GTK-DOC manual has been improved.

Major developer visible changes compared to the v2.2 branch:

* Full OpenPGP support is part of libgnutls, licensed under the LGPL.

* New APIs to access the raw X.509 Subject and Issuer DN's and
  elements from the certificate credentials structure, thanks to Joe
  Orton.

* Names of constants to affect certificate printing changed.

  The constants are used for OpenPGP too, which the names didn't
  reflect, so the following change has been made:

            Old name                         New name
     GNUTLS_X509_CRT_FULL            GNUTLS_CRT_PRINT_FULL
     GNUTLS_X509_CRT_ONELINE         GNUTLS_CRT_PRINT_ONELINE
     GNUTLS_X509_CRT_UNSIGNED_FULL   GNUTLS_CRT_PRINT_UNSIGNED_FULL

  The old names will be mapped to the new names for some time.

* The function gnutls_openpgp_privkey_get_id has been renamed to
  gnutls_openpgp_privkey_get_key_id.

* Replaced all uses of alloca with malloc and free.

* We no longer build with -D_REENTRANT -D_THREAD_SAFE.

  We have been unable to find a documented rationale for this
  practice.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.4
=============================

All OpenPGP functions have been moved from libgnutls-extra to
libgnutls, and several new functions have been added to support
OpenPGP subkeys (see below).  Even though all programs that link to
libgnutls-extra for the OpenPGP symbols also links to libgnutls, we
felt that strictly speaking we have removed some symbols from the
libgnutls-extra library.  Removing a function from a shared library
requires you to increment the shared library version.  We are thus
increasing the shared library version of GnuTLS.  You need to
recompile all your programs linked with GnuTLS to make them work with
this GnuTLS release.

(We considered to bump the shared library version only for
libgnutls-extra, since again strictly speaking we have not removed any
functions from libgnutls, but that may lead to problems when a
libgnutls-extra from 2.2.x pulls in libgnutls from 2.4.x.  By
incrementing the version of both libraries, it is guaranteed that they
will only be linked with each other.)

This release adds a small set of new API functions:

  gnutls_x509_dn_deinit
  gnutls_x509_dn_export
  gnutls_x509_dn_import
  gnutls_x509_dn_init

    Used to handle X.509 Certificate DN's directly.

  gnutls_hex2bin

    Converts a data buffer to hex.  Useful for handling PSK/SRP shared
    secrets.

  gnutls_certificate_get_x509_cas
  gnutls_certificate_get_x509_crls
  gnutls_certificate_get_openpgp_keyring

    Direct access to credential elements.

  gnutls_openpgp_crt_get_auth_subkey
  gnutls_openpgp_crt_get_key_id
  gnutls_openpgp_crt_get_pk_dsa_raw
  gnutls_openpgp_crt_get_pk_rsa_raw
  gnutls_openpgp_crt_get_preferred_key_id
  gnutls_openpgp_crt_get_revoked_status
  gnutls_openpgp_crt_get_subkey_count
  gnutls_openpgp_crt_get_subkey_creation_time
  gnutls_openpgp_crt_get_subkey_expiration_time
  gnutls_openpgp_crt_get_subkey_id
  gnutls_openpgp_crt_get_subkey_idx
  gnutls_openpgp_crt_get_subkey_pk_algorithm
  gnutls_openpgp_crt_get_subkey_pk_dsa_raw
  gnutls_openpgp_crt_get_subkey_pk_rsa_raw
  gnutls_openpgp_crt_get_subkey_revoked_status
  gnutls_openpgp_crt_get_subkey_usage
  gnutls_openpgp_crt_print
  gnutls_openpgp_crt_set_preferred_key_id
  gnutls_openpgp_keyring_get_crt
  gnutls_openpgp_keyring_get_crt_count
  gnutls_openpgp_privkey_export
  gnutls_openpgp_privkey_export_dsa_raw
  gnutls_openpgp_privkey_export_rsa_raw
  gnutls_openpgp_privkey_export_subkey_dsa_raw
  gnutls_openpgp_privkey_export_subkey_rsa_raw
  gnutls_openpgp_privkey_get_fingerprint
  gnutls_openpgp_privkey_get_key_id
  gnutls_openpgp_privkey_get_pk_algorithm
  gnutls_openpgp_privkey_get_preferred_key_id
  gnutls_openpgp_privkey_get_revoked_status
  gnutls_openpgp_privkey_get_subkey_count
  gnutls_openpgp_privkey_get_subkey_creation_time
  gnutls_openpgp_privkey_get_subkey_expiration_time
  gnutls_openpgp_privkey_get_subkey_id
  gnutls_openpgp_privkey_get_subkey_idx
  gnutls_openpgp_privkey_get_subkey_pk_algorithm
  gnutls_openpgp_privkey_get_subkey_revoked_status
  gnutls_openpgp_privkey_set_preferred_key_id

    New OpenPGP related functions.

    The function gnutls_openpgp_crt_get_key_id is the same as the old
    from gnutls_openpgp_crt_get_id, see above.

The release also adds a new header file 'gnutls/crypto.h', however it
is currently not used.  During the next development branch, it will be
used to provide functions for applications to replace parts of the
default libgcrypt low-level crypto implementation.  (For example,
applications could provide its own random-number generator.)




From ametzler at downhill.at.eu.org  Mon May 26 20:23:24 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 26 May 2008 20:23:24 +0200
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <87ej7prvb0.fsf@mocca.josefsson.org>
References: <87ej7prvb0.fsf@mocca.josefsson.org>
Message-ID: <20080526182324.GA4136@downhill.g.la>

On 2008-05-26 Simon Josefsson <simon at josefsson.org> wrote:
> In 2.3.x we have moved several symbols from libgnutls-extra to libgnutls
> (see complete explanation in the 2.4.0 release notes draft below), but
> do we need to bump the shared library version?  No symbols have been
> removed from any library libgnutls*, except for the symbols that have
> been moved.  libgnutls-extra links to libgnutls.

> I see several solutions here:

> 1) Increment the shared library version of libgnutls*.

>    This will cause an unnecessary shared library version break for
>    libgnutls, which have only had new functions added to it.  Given the
>    problem described in 2) I'm not sure how it could be avoided though.

> 2) Separate the shared library versions for libgnutls and
>    libgnutls-extra, and increment only the libgnutls-extra version.

>    This may be the The Right Thing to do, but it causes a new problem:
>    an application linking to libgnutls-extra.so.26 (2.2.x) may pull in
>    libgnutls.so from 2.4.x, which won't work together.  Both
>    libgnutls.so and libgnutls-extra.so would then provide the same
>    symbols.  If the application uses the one from libgnutls.so all is
>    fine, but it will break of the ones from libgnutls-extra.so is used.

> 3) Don't increment the shared library version at all.

>    The justification would be that we haven't removed any symbols, all
>    symbols in libgnutls-extra are still available via libgnutls and work
>    the same way.  The only thing that would break here is if someone is
>    dlopen'ing libgnutls-extra.so and calls the openpgp related
>    functions.  Strictly speaking I'm not sure this is a valid approach,
>    since we HAVE removed symbols from libgnutls-extra.
[...]
> I'm leaning towards 1) because of the problem in 2) and 3), however I do
> realize this will generate a lot of work for our packagers.

Hello,

nicely summed up.

Is (or has it ever been in > 2.2.0) gnutls-extra useable on its own?
I.e. is there a cause to be made for anything only linking against
gnutls-extra directly but not against libgnutls main? If correct usage
of gnutls-extra requires linking/dlopening libgnutls I think there is
strong case for 3.

Packagers generally would slightly also prefer 2 over 1. The problem
you noted is easily avoided for packages, since co-installion of
the different libraries can be prevented by using package
dependencies/conflicts. For Debian packages specifically, 2 would create
a problem since I currenly do not track packages using libgnutls-extra
separately. - Therefore anything linking against it would be broken
until rebuilt. - I am only mentioning this for completeness sake, I
do not think Debian-specic issues should be an important point.

cu andreas
PS: I you bump so names, please also bump symbol versioning.
-- 
`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  Tue May 27 14:52:18 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 27 May 2008 14:52:18 +0200
Subject: Do we need to bump the shared library version for 2.4.0?
References: <87ej7prvb0.fsf@mocca.josefsson.org>
	<20080526182324.GA4136@downhill.g.la>
Message-ID: <87od6raozh.fsf@mocca.josefsson.org>

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

> Is (or has it ever been in > 2.2.0) gnutls-extra useable on its own?

No, you need to call gnutls_global_init() in -lgnutls before
gnutls-extra is useful.  Further, libgnutls-extra links to libgnutls.

> I.e. is there a cause to be made for anything only linking against
> gnutls-extra directly but not against libgnutls main? If correct usage
> of gnutls-extra requires linking/dlopening libgnutls I think there is
> strong case for 3.

You can't use libgnutls-extra without libgnutls.  The only function in
libgnutls-extra that doesn't require earlier calls to functions in
libgnutls is gnutls_extra_check_version.  That function will continue to
work fine, and doesn't even require initialization of libgnutls or
libgnutls-extra.

However, technically I'm not sure that is sufficient.  The rules when to
increment the shared library version is to do it when you remove a
symbol from a library.  And we have removed symbols from
libgnutls-extra.  What is unclear to me is whether it is safe to assume
no problem will happen because libgnutls-extra links to libgnutls, and
libgnutls contains the old symbols.

> Packagers generally would slightly also prefer 2 over 1. The problem
> you noted is easily avoided for packages, since co-installion of
> the different libraries can be prevented by using package
> dependencies/conflicts. For Debian packages specifically, 2 would create
> a problem since I currenly do not track packages using libgnutls-extra
> separately. - Therefore anything linking against it would be broken
> until rebuilt. - I am only mentioning this for completeness sake, I
> do not think Debian-specic issues should be an important point.

I don't think we as upstream can rely on this.  We need to work portably
for people that install both gnutls 2.2.x and gnutls 2.4.x manually.  So
the problem I described is valid, and I don't see a way to avoid it.
This leads to choosing 1.

> PS: I you bump so names, please also bump symbol versioning.

Why is that necessary?  I think we have discussed this before (for the
2.2.x abi break) but eventually decided not to increment the versioning.

/Simon




From ametzler at downhill.at.eu.org  Tue May 27 19:05:37 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 27 May 2008 19:05:37 +0200
Subject: Do we need to bump the shared library version for 2.4.0?
In-Reply-To: <87od6raozh.fsf@mocca.josefsson.org>
References: <87ej7prvb0.fsf@mocca.josefsson.org>
	<20080526182324.GA4136@downhill.g.la>
	<87od6raozh.fsf@mocca.josefsson.org>
Message-ID: <20080527170537.GA3485@downhill.g.la>

On 2008-05-27 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> > Is (or has it ever been in > 2.2.0) gnutls-extra useable on its own?

> No, you need to call gnutls_global_init() in -lgnutls before
> gnutls-extra is useful.  Further, libgnutls-extra links to libgnutls.
[...]
> However, technically I'm not sure that is sufficient.  The rules when to
> increment the shared library version is to do it when you remove a
> symbol from a library.  And we have removed symbols from
> libgnutls-extra.

> What is unclear to me is whether it is safe to assume
> no problem will happen because libgnutls-extra links to libgnutls, and
> libgnutls contains the old symbols.

Hello,
I have not tested it, but out of my head I cannot see how application
X could be broken, if symbols are moved between two libraries that
the application both is linked directly to. I can see that this a
pretty weak testimony, especially since I know next to nothing about 
non-linux platforms.

[...]
> > PS: I you bump so names, please also bump symbol versioning.

> Why is that necessary?  I think we have discussed this before (for the
> 2.2.x abi break) but eventually decided not to increment the versioning.

You did, after I nagged. ;-)
http://lists.gnu.org/archive/html/gnutls-devel/2007-10/msg00027.html

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 gareuselesinge at debian.org  Mon May 26 10:42:53 2008
From: gareuselesinge at debian.org (Enrico Tassi)
Date: Mon, 26 May 2008 10:42:53 +0200
Subject: gnutls4win and Debian
In-Reply-To: <87r6bpmqf5.fsf@mocca.josefsson.org>
References: <20080524125216.GA23057@garfield>
	<87r6bpmqf5.fsf@mocca.josefsson.org>
Message-ID: <20080526084253.GA5769@garfield>

On Mon, May 26, 2008 at 10:15:58AM +0200, Simon Josefsson wrote:
> Hi Enrico!
> 
> Many thanks for this, I have added your script to the gnutls4win
> repository and hooked it into the build path.  So future release will be
> distributed as debian packages from the gnutls4win site too.  I created
> *.deb's for 2.2.5 and 2.3.11.
> 
> May I ask that you release the script under GPLv2 or later?  I can add
> the license template to the file.

Yes, go for GPL, it is ok for me. 

> Let me know if you want CVS write access so you can maintain the script
> and make improvements.  

no need to have CVS access, I would eventually send you patches 

> For example, is it possible to sign the *.deb

IIRC, equivs has a -f switch, but then you will have to put a valid
GPG identity in the Maintainer field and GPG will be called to sign the 
.changes and .dsc files (that will be generated in that case).

if you plan to make a repository, you may look at apt-ftparchive.

Cheers
-- 
Enrico Tassi