From nmav at gnutls.org Mon Mar 3 17:25:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 3 17:25:02 2003 Subject: [gnutls-dev]gnutls 0.9.0 Message-ID: <20030303162716.GA29024@gnutls.org> I've uploaded the first snapshot of the gnutls unstable branch. It is on the devel/ directory to distinguish it from the normal releases. There will not be binary nor source compatibility in the 0.9.x branch. All the changes since 0.8.1 (more to come): - This version is not binary compatible with the previous ones. - The library notifies the application on empty and illegal SRP usernames, so that proper notification (via an alert) is sent to the peer. - Added ability to send some messages back to the application using the gnutls_global_set_log_function(). - gnutls_dh_params_generate() and gnutls_rsa_params_generate() now use gnutls_malloc() to allocate the output parameters. - Added support for MD2 algorithm in certificate signature verification. - The RSA and DH parameter generation interface was changed. Added ability to import and export from and to PKCS3 structures. This was needed to read parameters generated using the openssl dhparam tool. - Several changes in the temporary (DH/RSA) parameter codebase. No DH parameters are now included in the library. Also the credentials structure can now hold only one temporary parameter of a kind. - Added a new Certificate, CRL, Private key and PKCS7 structures handling API, defined in gnutls/x509.h - Added gnutls_certificate_set_verify_flags() function to allow setting the verification flags in the credentials structure. They will be used in the *verify_peers functions. - Added protection against the new TLS 1.0 record layer timing attack. - Added support for Certificate revocation lists. Functions defined in gnutls/x509.h - The only functions were removed are: gnutls_x509_certificate_to_xml() gnutls_x509_extract_dn_string() - Ported to libtasn1 0.2.x -- Nikos Mavroyanopoulos From ivo at o2w.nl Mon Mar 3 18:52:01 2003 From: ivo at o2w.nl (Ivo Timmermans) Date: Mon Mar 3 18:52:01 2003 Subject: [gnutls-dev][andreas.trottmann@werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha] Message-ID: <20030303175148.GB16706@juarez> FYI: ----- Forwarded message from "Andreas U. Trottmann" ----- Subject: Bug#183176: libgnutls5: Crypts wrong on alpha Reply-To: "Andreas U. Trottmann" , 183176 at bugs.debian.org From: "Andreas U. Trottmann" To: Debian Bug Tracking System Date: Mon, 03 Mar 2003 01:40:50 +0100 X-Spam-Status: No, hits=-6.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND,AWL version=2.20 Package: libgnutls5 Version: 0.8.1-0mywoody1 Severity: normal On (at least) alpha, gnutls seems to be broken. While it generally can communicate fine for short transactions, after a couple of kilobytes of data transferred it either generates something the other side can't decode, or it can't decode something received by the other side. I'm reporting the bug against a self-compiled backport of libgnutls5 0.8.1-1 to woody, but it also is present in (at least) the libgnutls3 shipped with woody, and presumably also with the "official" sid 0.8.1-1. I can't test this for lack of a sid alpha system, however. The bug can be reproduced easily, for example using one of the following methods: * read your mail on an alpha machine with mutt on an IMAP server over ssl. After some succesful reading you *will* get "tls_socket_read (Decryption of the TLS record packet has failed.)" and your IMAP connection will be aborted - or - * create a text file of some MB (for example uuencode your linux kernel > bigfile). Then, on an i386 machine, run "gnutls-serv". On an alpha machine, run "gnutls-cli -p 5556 < bigfile i386.host.name" You will get, after some successful data transmission, on the server: "*** gnutls error[-24]: Decryption of the TLS record packet has failed. (recv)" and on the client: "*** Received corrupted data(-10) - server has terminated the connection abnormally" - or - * on any machine (tested: i386 and alpha): create a example certificate, put it in a file "server.crt", then run "openssl s_server". Then, on your alpha machine, run "gnutls-cli -p 4433 < bigfile server.host.name" On the server you will soon get "21579:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:s3_pkt.c:457:" and on the client you will again get "*** Received corrupted data(-9) - server has terminated the connection abnormally" To me, the facts that gnutls(alpha) to gnutls(i386) fails as well as gnutls(alpha) to openssl(alpha) makes it look like gnutls has some issues on alpha, maybe regarding some effects of the 64 bit architecture. Interestingly, gnutls(alpha) to gnutls(alpha) seems to work fine. So, apparently, the bug seems to affect encoding and decoding equally. -- System Information Debian Release: 3.0 Architecture: alpha Kernel: Linux clockwork 2.2.22 #2 Mon Oct 7 12:16:31 CEST 2002 alpha Locale: LANG=de_CH.ISO-8859-1, LC_CTYPE=de_CH.ISO-8859-1 Versions of packages libgnutls5 depends on: ii libc6.1 2.2.5-11.2 GNU C Library: Shared libraries an ii libgcrypt1 1.1.12-0mywoody1 LGPL Crypto library - runtime libr ii liblzo1 1.07-1 A real-time data compression libra ii libopencdk4 1:0.4.2-0mywoody3 Open Crypto Development Kit (OpenC ii libpopt0 1.6.2-7 lib for parsing cmdline parameters ii libtasn1-0 0.1.2-0mywoody1 Manage ASN.1 structures (runtime) ii zlib1g 1:1.1.4-1 compression library - runtime ----- End forwarded message ----- Ivo -- No, I just like to run around and scream real loud! - Dee Dee From nmav at gnutls.org Mon Mar 3 19:06:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 3 19:06:02 2003 Subject: [gnutls-dev]gnutls 0.8.2 Message-ID: <20030303180740.GA29218@gnutls.org> I've just released gnutls 0.8.2 which fixes the new timing attack on the TLS 1.0 record layer. Except for that fix there are no other changes since 0.8.1. -- Nikos Mavroyanopoulos From ivo at o2w.nl Mon Mar 3 19:55:02 2003 From: ivo at o2w.nl (Ivo Timmermans) Date: Mon Mar 3 19:55:02 2003 Subject: [gnutls-dev]gnutls 0.8.2 In-Reply-To: <20030303180740.GA29218@gnutls.org> References: <20030303180740.GA29218@gnutls.org> Message-ID: <20030303185557.GA22826@juarez> Nikos Mavroyanopoulos wrote: > I've just released gnutls 0.8.2 which fixes the new timing attack > on the TLS 1.0 record layer. Except for that fix there are no > other changes since 0.8.1. This release was signed with key 45802A91, but I can't find that key anywhere? Ivo -- Hey, it compiles! Ship it! From nmav at gnutls.org Mon Mar 3 22:55:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 3 22:55:02 2003 Subject: [gnutls-dev][andreas.trottmann@werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha] In-Reply-To: <20030303175148.GB16706@juarez> References: <20030303175148.GB16706@juarez> Message-ID: <20030303215524.GA1421@gnutls.org> On Mon, Mar 03, 2003 at 06:51:48PM +0100, Ivo Timmermans wrote: Does the attached patch fix the problem? (it should) > ----- Forwarded message from "Andreas U. Trottmann" ----- > > Subject: Bug#183176: libgnutls5: Crypts wrong on alpha > Reply-To: "Andreas U. Trottmann" , > 183176 at bugs.debian.org > From: "Andreas U. Trottmann" > To: Debian Bug Tracking System > Date: Mon, 03 Mar 2003 01:40:50 +0100 > X-Spam-Status: No, hits=-6.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND,AWL version=2.20 > > Package: libgnutls5 > Version: 0.8.1-0mywoody1 > Severity: normal > > On (at least) alpha, gnutls seems to be broken. While it generally can > communicate fine for short transactions, after a couple of kilobytes of > data transferred it either generates something the other side can't > decode, or it can't decode something received by the other side. > > I'm reporting the bug against a self-compiled backport of libgnutls5 > 0.8.1-1 to woody, but it also is present in (at least) the libgnutls3 > shipped with woody, and presumably also with the "official" sid 0.8.1-1. > I can't test this for lack of a sid alpha system, however. > > > The bug can be reproduced easily, for example using one of the following > methods: > > * read your mail on an alpha machine with mutt on an IMAP server over ssl. > After some succesful reading you *will* get > "tls_socket_read (Decryption of the TLS record packet has failed.)" > and your IMAP connection will be aborted > > - or - > > * create a text file of some MB (for example uuencode your linux > kernel > bigfile). Then, on an i386 machine, run "gnutls-serv". > On an alpha machine, run "gnutls-cli -p 5556 < bigfile i386.host.name" > You will get, after some successful data transmission, on the server: > "*** gnutls error[-24]: Decryption of the TLS record packet has failed. > (recv)" > and on the client: > "*** Received corrupted data(-10) - server has terminated the connection > abnormally" > > > - or - > > * on any machine (tested: i386 and alpha): create a example certificate, > put it in a file "server.crt", then run "openssl s_server". > Then, on your alpha machine, run "gnutls-cli -p 4433 < bigfile > server.host.name" > On the server you will soon get > "21579:error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed > or bad record mac:s3_pkt.c:457:" > and on the client you will again get > "*** Received corrupted data(-9) - server has terminated the > connection abnormally" > > > > To me, the facts that gnutls(alpha) to gnutls(i386) fails as well as > gnutls(alpha) to openssl(alpha) makes it look like gnutls has some > issues on alpha, maybe regarding some effects of the 64 bit architecture. > > Interestingly, gnutls(alpha) to gnutls(alpha) seems to work fine. So, > apparently, the bug seems to affect encoding and decoding equally. > -- Nikos Mavroyanopoulos -------------- next part -------------- Index: defines.h =================================================================== RCS file: /cvs/gnutls/gnutls/lib/defines.h,v retrieving revision 2.22 diff -u -u -r2.22 defines.h --- defines.h 9 Jan 2003 21:52:41 -0000 2.22 +++ defines.h 3 Mar 2003 21:50:13 -0000 @@ -96,19 +96,12 @@ #define SIZEOF_UNSIGNED_LONG_INT SIZEOF_UNSIGNED_LONG -#if SIZEOF_UNSIGNED_LONG == 8 -# define HAVE_UINT64 -/* only used native uint64 in 64 bit machines */ -typedef unsigned long int uint64; -#else /* some systems had problems with long long int, thus, * it is not used. */ typedef struct { unsigned char i[8]; } uint64; -#endif - #if SIZEOF_UNSIGNED_LONG == 4 typedef unsigned long int uint32; Index: gnutls_num.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_num.c,v retrieving revision 2.13 diff -u -u -r2.13 gnutls_num.c --- gnutls_num.c 2 Dec 2002 07:13:35 -0000 2.13 +++ gnutls_num.c 3 Mar 2003 21:50:18 -0000 @@ -1,7 +1,7 @@ /* - * Copyright (C) 2000,2001,2002 Nikos Mavroyanopoulos + * Copyright (C) 2000,2001,2002,2003 Nikos Mavroyanopoulos * - * This file is part of GNUTLS. + * This file is part of GNUTLS. * * The GNUTLS library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -27,16 +27,8 @@ #include #include - -#ifndef HAVE_UINT64 - /* This function will set the uint64 x to zero */ -int _gnutls_uint64zero( uint64 *x) { - - memset( x->i, 0, 8); - return 0; -} /* This function will add one to uint64 x. * Returns 0 on success, or -1 if the uint64 max limit @@ -59,8 +51,6 @@ return 0; } -#endif /* HAVE_UINT64 */ - uint32 _gnutls_uint24touint32( uint24 num) { uint32 ret=0; @@ -163,34 +153,13 @@ #endif } -uint64 _gnutls_conv_uint64( const uint64* data) { -#ifdef HAVE_UINT64 -# ifndef WORDS_BIGENDIAN - return byteswap64(*data); -# else - return *data; -# endif /* WORDS_BIGENDIAN */ -#else - uint64 ret; - - memcpy( ret.i, data->i, 8); - return ret; -#endif /* HAVE_UINT64 */ -} - uint32 _gnutls_uint64touint32( const uint64* num) { uint32 ret; -#ifdef HAVE_UINT64 - ret = (uint32) *num; - -#else /* no native uint64 */ - memcpy( &ret, &num->i[4], 4); -# ifndef WORDS_BIGENDIAN +#ifndef WORDS_BIGENDIAN ret = byteswap32(ret); -# endif -#endif /* HAVE_UINT64 */ +#endif return ret; } Index: gnutls_num.h =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_num.h,v retrieving revision 2.13 diff -u -u -r2.13 gnutls_num.h --- gnutls_num.h 8 Sep 2002 20:48:30 -0000 2.13 +++ gnutls_num.h 3 Mar 2003 21:50:18 -0000 @@ -1,21 +1,21 @@ /* - * Copyright (C) 2000 Nikos Mavroyanopoulos + * Copyright (C) 2000,2003 Nikos Mavroyanopoulos * - * This file is part of GNUTLS. + * This file is part of GNUTLS. * - * GNUTLS is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. + * GNUTLS is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. * - * GNUTLS is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. + * GNUTLS is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA */ #include @@ -37,25 +37,12 @@ uint16 _gnutls_read_uint16( const opaque* data); uint32 _gnutls_conv_uint32( uint32 data); uint16 _gnutls_conv_uint16( uint16 data); -uint64 _gnutls_conv_uint64( const uint64 *data); uint32 _gnutls_read_uint24( const opaque* data); void _gnutls_write_uint24( uint32 num, opaque* data); void _gnutls_write_uint32( uint32 num, opaque* data); void _gnutls_write_uint16( uint16 num, opaque* data); uint32 _gnutls_uint64touint32( const uint64*); -#ifndef HAVE_UINT64 -int _gnutls_uint64zero( uint64 *); int _gnutls_uint64pp( uint64 *); +# define _gnutls_uint64zero(x) x.i[0] = x.i[1] = x.i[2] = x.i[3] = x.i[4] = x.i[5] = x.i[6] = x.i[7] = 0 # define UINT64DATA(x) x.i - -#else -# define UINT64DATA(x) &x -# define rotl64(x,n) (((x) << ((uint16)(n))) | ((x) >> (64 - (uint16)(n)))) -# define rotr64(x,n) (((x) >> ((uint16)(n))) | ((x) << (64 - (uint16)(n)))) -# define byteswap64(x) ((rotl64(x, 8) & 0x00ff00ff00ff00ffUL) | (rotr64(x, 8) & 0xff00ff00ff00ff00UL)) - -# define _gnutls_uint64pp(x) ((++(*x)==0) ? -1 : 0) -# define _gnutls_uint64zero(x) (*x) = 0 - -#endif From nmav at gnutls.org Mon Mar 3 22:57:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 3 22:57:02 2003 Subject: [gnutls-dev][andreas.trottmann@werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha] In-Reply-To: <20030303215524.GA1421@gnutls.org> References: <20030303175148.GB16706@juarez> <20030303215524.GA1421@gnutls.org> Message-ID: <20030303215818.GA2113@gnutls.org> On Mon, Mar 03, 2003 at 11:55:24PM +0200, Nikos Mavroyanopoulos wrote: > Does the attached patch fix the problem? (it should) Plus this one. Index: gnutls_cipher.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_cipher.c,v retrieving revision 2.65 diff -u -u -r2.65 gnutls_cipher.c --- gnutls_cipher.c 3 Mar 2003 16:08:21 -0000 2.65 +++ gnutls_cipher.c 3 Mar 2003 21:53:51 -0000 @@ -271,8 +271,6 @@ } c_length = _gnutls_conv_uint16(compressed.size); - seq_num = - _gnutls_conv_uint64(&session->connection_state.write_sequence_number); if (td != GNUTLS_MAC_FAILED) { /* actually when the algorithm in not the NULL one */ _gnutls_hmac(td, UINT64DATA(seq_num), 8); @@ -431,7 +429,6 @@ c_length = _gnutls_conv_uint16((uint16) length); - seq_num = _gnutls_conv_uint64( &session->connection_state.read_sequence_number); /* Pass the type, version, length and compressed through * MAC. -- Nikos Mavroyanopoulos From nmav at gnutls.org Mon Mar 3 23:02:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 3 23:02:02 2003 Subject: [gnutls-dev]gnutls 0.8.2 In-Reply-To: <20030303185557.GA22826@juarez> References: <20030303180740.GA29218@gnutls.org> <20030303185557.GA22826@juarez> Message-ID: <20030303220428.GA7420@gnutls.org> On Mon, Mar 03, 2003 at 07:55:57PM +0100, Ivo Timmermans wrote: > > I've just released gnutls 0.8.2 which fixes the new timing attack > > on the TLS 1.0 record layer. Except for that fix there are no > > other changes since 0.8.1. > This release was signed with key 45802A91, but I can't find that key > anywhere? I forgot. I've updated my key. The new one can be found on http://members.hellug.gr/nmav/pgpkeys.asc and the keyserver pgpkeys.eu.pgp.net. > Ivo > -- > Hey, it compiles! Ship it! -- Nikos Mavroyanopoulos From nmav at gnutls.org Mon Mar 3 23:07:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 3 23:07:02 2003 Subject: [gnutls-dev][andreas.trottmann@werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha] In-Reply-To: <20030303215524.GA1421@gnutls.org> References: <20030303175148.GB16706@juarez> <20030303215524.GA1421@gnutls.org> Message-ID: <20030303220637.GA12433@gnutls.org> On Mon, Mar 03, 2003 at 11:55:24PM +0200, Nikos Mavroyanopoulos wrote: > Does the attached patch fix the problem? (it should) No it shouldn't :) I attach a working patch. -- Nikos Mavroyanopoulos -------------- next part -------------- A non-text attachment was scrubbed... Name: diff.gz Type: application/octet-stream Size: 2230 bytes Desc: not available URL: From tss at iki.fi Tue Mar 4 01:41:01 2003 From: tss at iki.fi (Timo Sirainen) Date: Tue Mar 4 01:41:01 2003 Subject: [gnutls-dev]Erasing private certificate key from memory Message-ID: <1046738508.18310.1249.camel@hurina> Would it be possible to add support for it? I don't know much about SSL protocol, but I'm hoping it wouldn't be needed after initial handshake. This would be useful as a way to prevent attacker from getting hands on it too easily. Hmm. Didn't SSL protocol support re-handshaking in the middle of the connection? Does that require the private key? This brings to my mind other problem with async I/O. If I send alert message but it doesn't get fully sent, how do I know that I should call gnutls_record_send() again to finish it? And can there be some reasons for gnutls_record_send() to actually want to read something or gnutls_record_recv() to send something (eg. automatic handshaking)? OpenSSL API has WANT_READ and WANT_WRITE errors which can occur with either command. From andreas.trottmann at werft22.com Tue Mar 4 07:59:01 2003 From: andreas.trottmann at werft22.com (Andreas U. Trottmann) Date: Tue Mar 4 07:59:01 2003 Subject: [gnutls-dev][andreas.trottmann@werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha] In-Reply-To: <20030303220637.GA12433@gnutls.org> References: <20030303175148.GB16706@juarez> <20030303215524.GA1421@gnutls.org> <20030303220637.GA12433@gnutls.org> Message-ID: <20030303230902.GA11769@clockwork.aart.ch> On Tue, Mar 04, 2003 at 12:06:37AM +0200, Nikos Mavroyanopoulos wrote: > > Does the attached patch fix the problem? (it should) > No it shouldn't :) > > I attach a working patch. Thank you very much for your fast reaction! Unfortunately, it doesn't help... gnutls 0.5.1 patched with the attached patch compiles cleanly, but using the patched library results in immediate failure: Using gnutls-cli immediately exits (after the first connection) with *** Received alert [20]: Bad record MAC *** Handshake has failed GNUTLS ERROR: A TLS fatal alert has been received. while the server (unpatched, on i386) gives *** gnutls error[-24]: Decryption of the TLS record packet has failed. (handshake) -- Andreas Trottmann Ideen Werft22 GmbH Tel +41 (0)56 210 91 37 Fax +41 (0)56 210 91 34 Mobile +41 (0)79 229 88 55 Werft22 sdreamt auch an der CeBIT in Hannover vom 12.-19. M?rz 2003, Halle/Stand 011 F15 From nmav at gnutls.org Tue Mar 4 08:18:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue Mar 4 08:18:01 2003 Subject: [gnutls-dev]Erasing private certificate key from memory In-Reply-To: <1046738508.18310.1249.camel@hurina> References: <1046738508.18310.1249.camel@hurina> Message-ID: <20030304072021.GA8732@gnutls.org> On Tue, Mar 04, 2003 at 02:41:48AM +0200, Timo Sirainen wrote: > Would it be possible to add support for it? I don't know much about SSL > protocol, but I'm hoping it wouldn't be needed after initial handshake. > This would be useful as a way to prevent attacker from getting hands on > it too easily. > Hmm. Didn't SSL protocol support re-handshaking in the middle of the > connection? Does that require the private key? Yes. That is because there maybe multiple situations like, the first handshake is anonymous, the second is server only authenticated, and the third one is server and client authenticated. But this does not prevent us from adding an option to delete the private key and the certificates from the credentials structure. It will be included in the 0.9.x branch. > This brings to my mind other problem with async I/O. If I send alert > message but it doesn't get fully sent, how do I know that I should call > gnutls_record_send() again to finish it? And can there be some reasons You don't have to. Just call gnutls_alert_send() if the return value is GNUTLS_E_AGAIN, or INTERRUPTED. > for gnutls_record_send() to actually want to read something or > gnutls_record_recv() to send something (eg. automatic handshaking)? > OpenSSL API has WANT_READ and WANT_WRITE errors which can occur with > either command. This also is the case with all the *_send() and *_bye() functions in gnutls. They all call the low level record send function which returns the same error codes on errors. > > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev > -- Nikos Mavroyanopoulos From nmav at gnutls.org Tue Mar 4 15:50:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue Mar 4 15:50:01 2003 Subject: [gnutls-dev]gnutls 0.8.3 Message-ID: <20030304145130.GA6561@gnutls.org> Since finally the alpha problem was fixed, I released gnutls 0.8.3 which fixes just this problem. -- Nikos Mavroyanopoulos From andreas.trottmann at werft22.com Wed Mar 5 18:26:01 2003 From: andreas.trottmann at werft22.com (Andreas U. Trottmann) Date: Wed Mar 5 18:26:01 2003 Subject: [nmav@gnutls.org: Re: [gnutls-dev][andreas.trottmann@werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha]] Message-ID: <20030304113854.GB14852@clockwork.aart.ch> Hello, The attached patch from Nikos Mavroyanopoulos against gnutnls 0.8.1 (to be applied in the "lib" subdirectory) seems to fix the problems for me. I think it would be a good idea to make a new debian package incorporating it, until the patch (or something equivalent) is incorporated in a new upstream release. A big thanks to Nikos and Ivo for the fast resolution of the problem! -- Andreas Trottmann Ideen Werft22 GmbH Tel +41 (0)56 210 91 37 Fax +41 (0)56 210 91 34 Mobile +41 (0)79 229 88 55 Werft22 sdreamt auch an der CeBIT in Hannover vom 12.-19. M?rz 2003, Halle/Stand 011 F15 -------------- next part -------------- An embedded message was scrubbed... From: Nikos Mavroyanopoulos Subject: Re: [gnutls-dev][andreas.trottmann at werft22.com: Bug#183176: libgnutls5: Crypts wrong on alpha] Date: Tue, 4 Mar 2003 09:10:05 +0200 Size: 10658 URL: From itp at ximian.com Wed Mar 5 23:54:02 2003 From: itp at ximian.com (Ian Peters) Date: Wed Mar 5 23:54:02 2003 Subject: [gnutls-dev][PATCH] inappropriate buffer check in _gnutls_io_read_buffered Message-ID: <1046904656.19054.30.camel@filbert> Hi, I'm integrating GnuTLS support into our internal HTTP transfer library, and I was running into some problems with UNEXPECTED_PACKET_LENGTH errors. I eventually tracked these down to one place, in _gnutls_recv_int, which calls _gnutls_io_read_buffered. The first check in that function verifies that the received packet isn't larger than the MAX_RECV_SIZE, but the third condition appears to be bogus. Specifically, _gnutls_io_read_buffered will be recalled in cases where GNUTLS_E_AGAIN, which lead to the function incorrectly returning GNUTLS_E_INVALID_REQUEST. The attached patch seems to fix the issue. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-_gnutls_io_read_buffered.patch Type: text/x-patch Size: 582 bytes Desc: not available URL: From itp at ximian.com Thu Mar 6 09:06:01 2003 From: itp at ximian.com (Ian Peters) Date: Thu Mar 6 09:06:01 2003 Subject: [gnutls-dev][PATCH] fix libextra when using included libtasn1 Message-ID: <1046894630.7042.15.camel@filbert> This tiny patch is needed to make the libextra directory in gnutls build when using the included libtasn1. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-extra-build-with-included-tasn1.patch Type: text/x-patch Size: 412 bytes Desc: not available URL: From nmav at gnutls.org Thu Mar 6 09:34:39 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu Mar 6 09:34:39 2003 Subject: [gnutls-dev][PATCH] fix libextra when using included libtasn1 In-Reply-To: <1046894630.7042.15.camel@filbert> References: <1046894630.7042.15.camel@filbert> Message-ID: <20030306083627.GB781@gnutls.org> On Wed, Mar 05, 2003 at 03:03:51PM -0500, Ian Peters wrote: > This tiny patch is needed to make the libextra directory in gnutls build > when using the included libtasn1. Thank you. Just commited. > Ian -- Nikos Mavroyanopoulos From itp at ximian.com Thu Mar 6 17:13:01 2003 From: itp at ximian.com (Ian Peters) Date: Thu Mar 6 17:13:01 2003 Subject: [gnutls-dev][PATCH] inappropriate buffer check in _gnutls_io_read_buffered In-Reply-To: <20030306083437.GA781@gnutls.org> References: <1046904656.19054.30.camel@filbert> <20030306083437.GA781@gnutls.org> Message-ID: <1046967131.19053.35.camel@filbert> On Thu, 2003-03-06 at 03:34, Nikos Mavroyanopoulos wrote: > On Wed, Mar 05, 2003 at 05:50:56PM -0500, Ian Peters wrote: > > > Hi, > > I'm integrating GnuTLS support into our internal HTTP transfer library, > > and I was running into some problems with UNEXPECTED_PACKET_LENGTH > > errors. I eventually tracked these down to one place, in > > _gnutls_recv_int, which calls _gnutls_io_read_buffered. > > The first check in that function verifies that the received packet isn't > > larger than the MAX_RECV_SIZE, but the third condition appears to be > > bogus. Specifically, _gnutls_io_read_buffered will be recalled in cases > > where GNUTLS_E_AGAIN, which lead to the function incorrectly returning > > GNUTLS_E_INVALID_REQUEST. The attached patch seems to fix the issue. > Hello Ian. > I've quite changed that patch. Does the attached also solve the problem? With a little massaging to apply cleanly to my 0.8.3 tree, it works perfectly, thanks. FWIW, if you edit any of your source in lib/ or libextra/ of a distributed gnutls tarball, you have to comment out the all-local target in the Makefile to get it to stop trying to build the docs, as it's looking for ../doc/scripts/gdoc, which isn't distributed. Ian From nmav at gnutls.org Thu Mar 6 21:24:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu Mar 6 21:24:02 2003 Subject: [gnutls-dev][PATCH] inappropriate buffer check in _gnutls_io_read_buffered In-Reply-To: <1046967131.19053.35.camel@filbert> References: <1046904656.19054.30.camel@filbert> <20030306083437.GA781@gnutls.org> <1046967131.19053.35.camel@filbert> Message-ID: <20030306202618.GA14132@gnutls.org> On Thu, Mar 06, 2003 at 11:12:11AM -0500, Ian Peters wrote: > > > Hi, > > > I'm integrating GnuTLS support into our internal HTTP transfer library, > > > and I was running into some problems with UNEXPECTED_PACKET_LENGTH > > > errors. I eventually tracked these down to one place, in > > > _gnutls_recv_int, which calls _gnutls_io_read_buffered. > > > The first check in that function verifies that the received packet isn't > > > larger than the MAX_RECV_SIZE, but the third condition appears to be > > > bogus. Specifically, _gnutls_io_read_buffered will be recalled in cases > > > where GNUTLS_E_AGAIN, which lead to the function incorrectly returning > > > GNUTLS_E_INVALID_REQUEST. The attached patch seems to fix the issue. > > Hello Ian. > > I've quite changed that patch. Does the attached also solve the problem? > With a little massaging to apply cleanly to my 0.8.3 tree, it works > perfectly, thanks. > FWIW, if you edit any of your source in lib/ or libextra/ of a > distributed gnutls tarball, you have to comment out the all-local target > in the Makefile to get it to stop trying to build the docs, as it's > looking for ../doc/scripts/gdoc, which isn't distributed. I've commited the fix, and I've made the doc generation happen only when creating the distribution. > > Ian > -- Nikos Mavroyanopoulos From nmav at gnutls.org Mon Mar 10 19:37:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 10 19:37:01 2003 Subject: [gnutls-dev]gnutls 0.8.4 Message-ID: <20030310183936.GA6805@gnutls.org> I've just released gnutls 0.8.4 which fixes the problem reported by Ian Peters, last week. -- Nikos Mavroyanopoulos From itp at ximian.com Tue Mar 11 22:51:01 2003 From: itp at ximian.com (Ian Peters) Date: Tue Mar 11 22:51:01 2003 Subject: [gnutls-dev] [PATCH] error handling large CA files Message-ID: <1047418898.19053.64.camel@filbert> In lib/gnutls_x509.c, the functions read_cert_file, read_ca_file, and read_key_file all read into a stack-allocated buffer of MAX_FILE_SIZE, which is defined as 1024*100. The default CA file that comes with most web browsers exceeds this (it is closer to 245k). This means that the file is truncated, and parse_pem_cert_mem only sees part of the file, resulting in only some of the trusted certificates being loaded. Because of the pem file format, this is not a fatal error, and program execution continues, but some certificates that should be trusted are not. The attached patch fixes these three functions to read passed file into a heap-allocated buffer, parse the memory, and then free the buffer. You'll probably want to tweak things to fit into gnutls better stylistically. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-0.8.4-large-ca-file.patch Type: text/x-patch Size: 2804 bytes Desc: not available URL: From itp at ximian.com Tue Mar 11 22:55:02 2003 From: itp at ximian.com (Ian Peters) Date: Tue Mar 11 22:55:02 2003 Subject: [gnutls-dev] [PATCH] incredibly large RSA modulus not handled Message-ID: <1047419166.7042.70.camel@filbert> The default root CA pem file, as shipped with most browsers, includes a cert from Thawte that uses a 16384 bit RSA modulus. The value of MAX_PARAMETER_SIZE in gnutls_cert.h (1200) appears to have been set for an 8192 bit modulus, max, which was causing libtasn1 to return ASN1_E_MEMORY, eventually causing a fatal error in gnutls while parsing the ca file. This patch bumps that define up to 2400, which allows the successful parsing of the Thawte cert. I've attached a copy of the Thawte cert for testing purposes, as well. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-0.8.4-thawte-cert.patch Type: text/x-patch Size: 503 bytes Desc: not available URL: -------------- next part -------------- Thawte Universal CA Root ======================== MD5 Fingerprint: 17:AF:71:16:52:7B:73:65:22:05:29:28:84:71:9D:13 PEM Data: -----BEGIN CERTIFICATE----- MIIRIjCCCQoCAQAwDQYJKoZIhvcNAQEFBQAwVzEPMA0GA1UEChMGVGhhd3RlMSEw HwYDVQQLExhUaGF3dGUgVW5pdmVyc2FsIENBIFJvb3QxITAfBgNVBAMTGFRoYXd0 ZSBVbml2ZXJzYWwgQ0EgUm9vdDAeFw05OTEyMDUxMzU2MDVaFw0zNzA0MDMxMzU2 MDVaMFcxDzANBgNVBAoTBlRoYXd0ZTEhMB8GA1UECxMYVGhhd3RlIFVuaXZlcnNh bCBDQSBSb290MSEwHwYDVQQDExhUaGF3dGUgVW5pdmVyc2FsIENBIFJvb3Qwgggi MA0GCSqGSIb3DQEBAQUAA4IIDwAwgggKAoIIAQDiiQVtw3+tpok6/7vHzZ03seHS IR6bYSoV53tXT1U80Lv52T0+przstK1TmhYC6wty/Yryj0QFxevT5b22RDnm+0e/ ap4KlRjiaOLWltYhrYj99Rf109pCpZDtKZWWdTrah6HU9dOH3gVipuNmdJLPpby7 32j/cXVWQVk16zNaZlHy0qMKwYzOc1wRby2MlYyRsf3P5a1WlcyFkoOQVUHJwnft +aN0QgpoCPPQ0WX9Zyw0/yR/53nIBzslV92kDJg9vuDMGWXb8lSir0LUneKuhCMl CTMStWoedsSL2UkAbF66H/Ib2mfKJ6qjRCMbg4LO8qsz7VSk3MmrWWXROA7BPhtn j9Z1AeBVIt12d+yO3fTPeSJtuVcD9ZkIpzw+NPvEF64jWM0k8yPKagIolAGBNLRs a66LGsOj0gk8FlT1Nl8k459KoeJkxhbDpoF6JDZHjsFeDvv5FXgE1g5Z2Z1YZmLS lCkyMsh4uWb2tVbhbMYUS5ZSWZECJGpVR9c/tiMaYHeXLuJAr54EV56tEcXJQ3Dv SLRerBxpLi6C1VuLvoK+GRRe5w0ix1Eb/x6b8TCPcTEGszQnj196ZoJPii0Tq0LP IVael45mNg+Wm+Ur9AKpKmqMLMTDuHAsLSkeP1B3Hm0qVORVCpE4ocW1ZqJ2Wu4P v7Rn4ShuD+E2oYLRv9R34cRnMpN4yOdUU/4jeeZozCaQ9hBjXSpvkS2kczJRIfK7 Fd+qJAhIBt6hnia/uoO/fKTIoIy90v+8hGknEyQYxEUYIyZeGBTKLoiHYqNT5iG3 uIV7moW7FSZy+Ln3anQPST+SvqkFt5knv78JF0uZTK0REHzfdDH2jyZfqoiuOFfI VS3T+9gbUZm+JRs6usB9G+3O0km5z/PFfYmQgdhpSCAQo/jvklEYMosRGMA/G4VW zlfJ8oJkxt8CCS5KES+xJ203UvDwFmHxZ43fh3Kvh9rP+1CUbtSUheuKLOoh9ZZK RNXgzmp0RE3QBdOHFe020KSLZlVwk+5HBsF+LqUYeWfzKIXxcPcOg6R+VJ5adjLL ZRu4zfvIKAPSVJHRp8WFQwgXdqXmL2cI2KGigi0M+MGvY9RQd21rRkpBhdWQX3kt xOzXEYdAiuFo4mT4VTL7b5Ms2nfZIcEX5TYsTn6Qf6yUKzJnvjhQdriuQbnXIcUJ TGDIo1HENJtXN9/LyTNXi+v7dp8ZTcVqHypFrivtL42npQDLBPolYi50SBvKKoy6 27Z+9rsCfKnD21h4ob/w/hoQVRHO6GlOlmXGFwPWB2iMVIKuHCJVP/H0CZcowEb3 TgslHfcH1wkdOhhXODvoMwbnj3hGHlv1BrbsuKYN8boTS9YYIN1pM0ozFa64yJiK JyyTvC377jO/ZuZNurabBlVgl0u8RM1+9KHYqi/AAighFmJ42whU8vz0NOPGjxxD V86QGkvcLjsokYk/eto1HY4s7kns9DOtyVOojJ8EUz4kHFLJEvliV6O87izrQHwg I3ArlflzF4rRwRxpprc4mmf3cB16WgxAz2IPhTzCAk5+tfbFKimEsx83KuGqckLE 7Wsaj5IcXb7R8lvyq6qp0vW4pEErK5FuEkjKmNg3jcjtADC1tgROfpzahOzA+nvl HYikU0awlORcG6ElLA9IUneXCWzsWxgzgwLlgn7NhSEwEf0nT8/kHuw/pVds6Sow GSqI5cNpOKtvOXF/hOFBw+HMKokgUi6DD2w5P0stFqwt8CSsAHP0m7MGPwW4FIUf q55cPJ5inQ5tO4AJ/ALqopd0ysf541bhw8qlpprAkOAkElPSwovavu0CQ15n4YmY ee7LqsrDG9znpUalfGsWh7ZaKNfbJzxepb22Ud0fQ887Jsg6jSVhwUn0PBvJROqv HMIrlAEqDjDRW4srR+XD0QQDmw45LNYn1OZwWtl1zyrYyQAF5BOI7MM5+4dhMDZD A8ienKIGwi/F/PCAY7FUBKBMqS7G9XZ62NDk1JQR5RW1eAbcuICPmakgMz0QhUxl Cco+WF5gk5qqYl3AUQYcXWCgDZxLQ/anFiGkh6rywS7ukjC4nt/fEAGLhglw2Gyo t1AeFpa092f9NTohkCoyxwB7TQcQCbkvc9gYfmeZBE8G/FDHhZudQJ2zljf6pdyy ck7vTgks/ZH9Tfe7pqE+q3uiA0CmqVUn4vr5Gc6HdarxdTbz87iR+JHDi3UTjkxl mhY5auU06HqWWX81sAD9W2n8Qyb69Shu/ofZfiT7tKCCblSi/66/YrT0cgHCy5hH mOFMtReAgM6PpijuHkVq+9/xHfxaO9bq9GwdYklXO4qPhurwUwTOnBZo/7q5/IgP R/cCRHJAuMo7LVOd3DxWjFl7aBosjXG7bADHGs5vQJKxoy8P2UTyo3Aunu4OrjLQ Oz6LB+rmebNcKeJ9a6he+Vox6AiWoowDmEbxuH2QVCbtdmL+numabl7JScdcNFMp VNns5EbhgDt12d/7edWH8bqe6xnOTFJz5luHriVPOXnMxrj5EHvs8JtxpAWg0ynT Tn8f9C0oeMxVlXsekS/MVhhzi7LbvGkH5tDYT+2i/1iFo23gSlO3Z32NDFxbe3co AjVEegTTKEPIazAXXTK4KTW6dto7FEp2GFik+JI8nk0zb0ZrCNkxSGjd9PskVjSy z2lmvkjSimYizfJpzcJTE0UpQSLWXZgftqSyo8LuAi9RG9yDpOxwJajUCGEyb+Sh gS58Y3L6KWW8cETPXQIDAQABMA0GCSqGSIb3DQEBBQUAA4IIAQBVmjRqIgZpCUUz x66pXMcJTpuGvEGQ1JRS9s0jKZRLIs3ovf6dzVLyve2rh8mrq0YEtL2iPyIwR1DA S4x2DwP1ktKxLcR6NZzJc4frpp/eD3ON03+Z2LqPb8Tzvhqui6KUNpDi5euNBfT8 Zd+V8cSUTRdW1588j1A853e/lYYmZPtq/8ba6YyuQrtp5TPG2OkNxlUhScEMtKP5 m0tc3oNPQQPOKnloOH3wVEkg9bYQ/wjcM2aWm/8G3gCe185WQ5pR/HDN9vBRo7fN tFyFYs1xt8YrIyvdw25AQvo3/zcc9npXlIeFI9fUycdfwU0vyQ3XXOycJe6eMIKR lnK4dR34CWhXl7ItS+4l7HokKe5y1JwT26vcAwrYShTJCFdEXaG1U4A08hSXz1Le og6KEOkU79BgvmGh8SVd1RhzP5MQypbus0DS26NVz1dapQ5PdUff6veQmm31cC4d FBw3ZARZULDccoZvnDc9XSivc1Xv0u4kdHQT79zbMUn7P2P10wg+M6XnnQreUyxR jmfbm0FlQVC91KSWbIe8EuCUx9PA5MtzWACD4awnhdadU51cvQo+A0OcDJH1bXv4 QHJ1qxF2kSvhxqofcGl2cBUJ/pPQ1i23FWqbZ1y0aZ8lpn2K+30iqXHyzk6MuCEt 3v5BcQ3/nexzprsHT4gOWEcufqnCx3jdunqeTuAwTmNvhdQgQen6/kNF5/uverLO pAUdIppYht/kzkyp/tgWpW/72M5We/XWIO/kR81jJP+5vvFIo8EBcua9wK3tJg3K NJ/8Ai0gTwUgriE9DMIgPD/wBITcz4n9uSWRjtBD5rMgq1wt1UCeoEvY9LLMffFY Co6H7YisNpbkVqARivKa0LNXozS7Gas44XRrIsQxzgHVGzbjHjhMM5PfQONZV06s bnseWj3FHVusyBCCNQIisvx16BCRjcR9eJNHnhydrGtiAliM1hwj1q94woCcpKok VBS1FJjG+CsaJMtxMgrimw5pa91+jGTRLmPvDn+xPohMnVXlyW4XBLdB/72KQcsl MW9Edz9HsfyBiAeOBUkgtxHZaQMqA525M4Sa399640Zzo9iijFMZiFVMdLj2RIQr 0RQtTjkukmj/afyFYhvrVU/vJYRiRZnW2E5vP1MIfR0GlYGAf09OdDaYteKHcJjc 1/XcUhXmxtZ5ljl/j5XPq4BTrRsLRUAO1Bi9LN6Kd3b98kRHxiHQ5HTw2BgFyHww csff8bv8AjCp9EImWQ2TBYKhc+005ThdzVCQ/pT8E7y9/KiiiKdzxLKo0V2IxAKi evEEyf6MdMnvHWRBn6welmdkrKsoQced98CYG24HwmR9WoNmVig2nOf7HHcOKKDE 92t5OQQghMdXk7wboOq860LlqBH+/KxlzP34KIj0pZrlc1HgqJsNA3dO5eCYs4ja febGnnwUZsEuU0qSBzegfuk9CeQVfM/9uEGl755mncReBx2H+EGt6ucv0kFjGDf5 FONN0OX3Q/0V4/k2cwYm3wFPqcNO3iBGd5i0eiQrO3UrTliNm12kxxagvDKIP6GD 8wDI+NhY6WNdTCu18HJB2Kt3N9ZydK62NpzIpoNJS+DJVgspvgAwy93WyEKKANns FdE0cfJbZIf2J9K364awkL8p2yGeNozjIC+VI1FsG8Kk1ebYAkNnoP6bUANEf7vk ctXR5NqPkhRk+10UEBJKlQbJZQgpyiGjJjgRySffcGcE/cpIMn9jskV0MVBPh9kg cNIhcLHWEJ0zXXiDkW1Vguza5GJjx4FG1xllcipDGZC41yNNTBzgRKlmZ6zucXkn Jnhtcg71XUsjtXx8ZekXxjoLDd1eHlHDhrjsf8cnSqVG6GotGcGHo8uZk4dkolUU TLdDpZPX59JOeUDKZZlGPT96gHqIaswe5WszRvRQwNUfCbjNii6hJ+tdc6foawrl V4IqsPziVFJW8KupEsYjlgcknOC8RqW0IATaCZNj5dQuwn7FMe21FXSGF7mz8yaK HQJq2ho/6LrxBG2UUVTiWrRZgx1g0C1zzAe1Joz518aIke+Az10PoWDLRdRCItGx cB390LcwkDrGSG1n5TLaj9vjqOMdICWiHOFMuaT2xj9cWA27xrJ3ARaRnxcGDbdA PsyPjpxL4J1+mx4Fq4gi+tMoG1cUZEo+JCw4TSFpAHMu0FUtdPIV6JRDPkAqxsa5 alveoswYUFRdTiqFbPaSiykZfufqSuAiKyW892bPd5pBdPI8FA10afVQg83NLyHb IkaK0PdRGpVX8gWLGhntO0XoNsJufvtXIgAfBlOprpPGj3EqMUWS545t5pkiwIP8 79xXZndPojYx+6ETjeXKo5V9AQxkcDtTQmiAx7udqAA1aZgMqGfYQ+Wqz5XgUZWk Fz9CnbgEztN5ecjTihYykuDXou7XN0wvrLh7vkX28RgznHs3piTZvECrAOnDN4ur 2LbzXoFOsBRrBz4f7ML2RCKVu7Pmb9b5cGW6CoNlqg4TL4MTI1OLQBb6zi/8TQT4 69isxTbCFVdIOOxVs7Qeuq3SQgYXDXPIV6a+lk2p8sD7eiEc9clwqYKQtfEM1HkQ voGm6VxhnHd5mqTDNyZXN8lSLPoI/9BfxmHA9Ha+/N5Oz6tRmXHH33701s8GVhkT UwttdFlIGZtTBS2dMlTT5SxTi2Q+1GR744AJFMz+FkZja3Fp+PnLJ/aIVLxFs84C yJTuQFv5QgLC/7DYLOsof17JJgGZpw== -----END CERTIFICATE----- Certificate Ingredients: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Thawte, OU=Thawte Universal CA Root, CN=Thawte Universal CA Root Validity Not Before: Dec 5 13:56:05 1999 GMT Not After : Apr 3 13:56:05 2037 GMT Subject: O=Thawte, OU=Thawte Universal CA Root, CN=Thawte Universal CA Root Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (16384 bit) Modulus (16384 bit): 00:e2:89:05:6d:c3:7f:ad:a6:89:3a:ff:bb:c7:cd: 9d:37:b1:e1:d2:21:1e:9b:61:2a:15:e7:7b:57:4f: 55:3c:d0:bb:f9:d9:3d:3e:a6:bc:ec:b4:ad:53:9a: 16:02:eb:0b:72:fd:8a:f2:8f:44:05:c5:eb:d3:e5: bd:b6:44:39:e6:fb:47:bf:6a:9e:0a:95:18:e2:68: e2:d6:96:d6:21:ad:88:fd:f5:17:f5:d3:da:42:a5: 90:ed:29:95:96:75:3a:da:87:a1:d4:f5:d3:87:de: 05:62:a6:e3:66:74:92:cf:a5:bc:bb:df:68:ff:71: 75:56:41:59:35:eb:33:5a:66:51:f2:d2:a3:0a:c1: 8c:ce:73:5c:11:6f:2d:8c:95:8c:91:b1:fd:cf:e5: ad:56:95:cc:85:92:83:90:55:41:c9:c2:77:ed:f9: a3:74:42:0a:68:08:f3:d0:d1:65:fd:67:2c:34:ff: 24:7f:e7:79:c8:07:3b:25:57:dd:a4:0c:98:3d:be: e0:cc:19:65:db:f2:54:a2:af:42:d4:9d:e2:ae:84: 23:25:09:33:12:b5:6a:1e:76:c4:8b:d9:49:00:6c: 5e:ba:1f:f2:1b:da:67:ca:27:aa:a3:44:23:1b:83: 82:ce:f2:ab:33:ed:54:a4:dc:c9:ab:59:65:d1:38: 0e:c1:3e:1b:67:8f:d6:75:01:e0:55:22:dd:76:77: ec:8e:dd:f4:cf:79:22:6d:b9:57:03:f5:99:08:a7: 3c:3e:34:fb:c4:17:ae:23:58:cd:24:f3:23:ca:6a: 02:28:94:01:81:34:b4:6c:6b:ae:8b:1a:c3:a3:d2: 09:3c:16:54:f5:36:5f:24:e3:9f:4a:a1:e2:64:c6: 16:c3:a6:81:7a:24:36:47:8e:c1:5e:0e:fb:f9:15: 78:04:d6:0e:59:d9:9d:58:66:62:d2:94:29:32:32: c8:78:b9:66:f6:b5:56:e1:6c:c6:14:4b:96:52:59: 91:02:24:6a:55:47:d7:3f:b6:23:1a:60:77:97:2e: e2:40:af:9e:04:57:9e:ad:11:c5:c9:43:70:ef:48: b4:5e:ac:1c:69:2e:2e:82:d5:5b:8b:be:82:be:19: 14:5e:e7:0d:22:c7:51:1b:ff:1e:9b:f1:30:8f:71: 31:06:b3:34:27:8f:5f:7a:66:82:4f:8a:2d:13:ab: 42:cf:21:56:9e:97:8e:66:36:0f:96:9b:e5:2b:f4: 02:a9:2a:6a:8c:2c:c4:c3:b8:70:2c:2d:29:1e:3f: 50:77:1e:6d:2a:54:e4:55:0a:91:38:a1:c5:b5:66: a2:76:5a:ee:0f:bf:b4:67:e1:28:6e:0f:e1:36:a1: 82:d1:bf:d4:77:e1:c4:67:32:93:78:c8:e7:54:53: fe:23:79:e6:68:cc:26:90:f6:10:63:5d:2a:6f:91: 2d:a4:73:32:51:21:f2:bb:15:df:aa:24:08:48:06: de:a1:9e:26:bf:ba:83:bf:7c:a4:c8:a0:8c:bd:d2: ff:bc:84:69:27:13:24:18:c4:45:18:23:26:5e:18: 14:ca:2e:88:87:62:a3:53:e6:21:b7:b8:85:7b:9a: 85:bb:15:26:72:f8:b9:f7:6a:74:0f:49:3f:92:be: a9:05:b7:99:27:bf:bf:09:17:4b:99:4c:ad:11:10: 7c:df:74:31:f6:8f:26:5f:aa:88:ae:38:57:c8:55: 2d:d3:fb:d8:1b:51:99:be:25:1b:3a:ba:c0:7d:1b: ed:ce:d2:49:b9:cf:f3:c5:7d:89:90:81:d8:69:48: 20:10:a3:f8:ef:92:51:18:32:8b:11:18:c0:3f:1b: 85:56:ce:57:c9:f2:82:64:c6:df:02:09:2e:4a:11: 2f:b1:27:6d:37:52:f0:f0:16:61:f1:67:8d:df:87: 72:af:87:da:cf:fb:50:94:6e:d4:94:85:eb:8a:2c: ea:21:f5:96:4a:44:d5:e0:ce:6a:74:44:4d:d0:05: d3:87:15:ed:36:d0:a4:8b:66:55:70:93:ee:47:06: c1:7e:2e:a5:18:79:67:f3:28:85:f1:70:f7:0e:83: a4:7e:54:9e:5a:76:32:cb:65:1b:b8:cd:fb:c8:28: 03:d2:54:91:d1:a7:c5:85:43:08:17:76:a5:e6:2f: 67:08:d8:a1:a2:82:2d:0c:f8:c1:af:63:d4:50:77: 6d:6b:46:4a:41:85:d5:90:5f:79:2d:c4:ec:d7:11: 87:40:8a:e1:68:e2:64:f8:55:32:fb:6f:93:2c:da: 77:d9:21:c1:17:e5:36:2c:4e:7e:90:7f:ac:94:2b: 32:67:be:38:50:76:b8:ae:41:b9:d7:21:c5:09:4c: 60:c8:a3:51:c4:34:9b:57:37:df:cb:c9:33:57:8b: eb:fb:76:9f:19:4d:c5:6a:1f:2a:45:ae:2b:ed:2f: 8d:a7:a5:00:cb:04:fa:25:62:2e:74:48:1b:ca:2a: 8c:ba:db:b6:7e:f6:bb:02:7c:a9:c3:db:58:78:a1: bf:f0:fe:1a:10:55:11:ce:e8:69:4e:96:65:c6:17: 03:d6:07:68:8c:54:82:ae:1c:22:55:3f:f1:f4:09: 97:28:c0:46:f7:4e:0b:25:1d:f7:07:d7:09:1d:3a: 18:57:38:3b:e8:33:06:e7:8f:78:46:1e:5b:f5:06: b6:ec:b8:a6:0d:f1:ba:13:4b:d6:18:20:dd:69:33: 4a:33:15:ae:b8:c8:98:8a:27:2c:93:bc:2d:fb:ee: 33:bf:66:e6:4d:ba:b6:9b:06:55:60:97:4b:bc:44: cd:7e:f4:a1:d8:aa:2f:c0:02:28:21:16:62:78:db: 08:54:f2:fc:f4:34:e3:c6:8f:1c:43:57:ce:90:1a: 4b:dc:2e:3b:28:91:89:3f:7a:da:35:1d:8e:2c:ee: 49:ec:f4:33:ad:c9:53:a8:8c:9f:04:53:3e:24:1c: 52:c9:12:f9:62:57:a3:bc:ee:2c:eb:40:7c:20:23: 70:2b:95:f9:73:17:8a:d1:c1:1c:69:a6:b7:38:9a: 67:f7:70:1d:7a:5a:0c:40:cf:62:0f:85:3c:c2:02: 4e:7e:b5:f6:c5:2a:29:84:b3:1f:37:2a:e1:aa:72: 42:c4:ed:6b:1a:8f:92:1c:5d:be:d1:f2:5b:f2:ab: aa:a9:d2:f5:b8:a4:41:2b:2b:91:6e:12:48:ca:98: d8:37:8d:c8:ed:00:30:b5:b6:04:4e:7e:9c:da:84: ec:c0:fa:7b:e5:1d:88:a4:53:46:b0:94:e4:5c:1b: a1:25:2c:0f:48:52:77:97:09:6c:ec:5b:18:33:83: 02:e5:82:7e:cd:85:21:30:11:fd:27:4f:cf:e4:1e: ec:3f:a5:57:6c:e9:2a:30:19:2a:88:e5:c3:69:38: ab:6f:39:71:7f:84:e1:41:c3:e1:cc:2a:89:20:52: 2e:83:0f:6c:39:3f:4b:2d:16:ac:2d:f0:24:ac:00: 73:f4:9b:b3:06:3f:05:b8:14:85:1f:ab:9e:5c:3c: 9e:62:9d:0e:6d:3b:80:09:fc:02:ea:a2:97:74:ca: c7:f9:e3:56:e1:c3:ca:a5:a6:9a:c0:90:e0:24:12: 53:d2:c2:8b:da:be:ed:02:43:5e:67:e1:89:98:79: ee:cb:aa:ca:c3:1b:dc:e7:a5:46:a5:7c:6b:16:87: b6:5a:28:d7:db:27:3c:5e:a5:bd:b6:51:dd:1f:43: cf:3b:26:c8:3a:8d:25:61:c1:49:f4:3c:1b:c9:44: ea:af:1c:c2:2b:94:01:2a:0e:30:d1:5b:8b:2b:47: e5:c3:d1:04:03:9b:0e:39:2c:d6:27:d4:e6:70:5a: d9:75:cf:2a:d8:c9:00:05:e4:13:88:ec:c3:39:fb: 87:61:30:36:43:03:c8:9e:9c:a2:06:c2:2f:c5:fc: f0:80:63:b1:54:04:a0:4c:a9:2e:c6:f5:76:7a:d8: d0:e4:d4:94:11:e5:15:b5:78:06:dc:b8:80:8f:99: a9:20:33:3d:10:85:4c:65:09:ca:3e:58:5e:60:93: 9a:aa:62:5d:c0:51:06:1c:5d:60:a0:0d:9c:4b:43: f6:a7:16:21:a4:87:aa:f2:c1:2e:ee:92:30:b8:9e: df:df:10:01:8b:86:09:70:d8:6c:a8:b7:50:1e:16: 96:b4:f7:67:fd:35:3a:21:90:2a:32:c7:00:7b:4d: 07:10:09:b9:2f:73:d8:18:7e:67:99:04:4f:06:fc: 50:c7:85:9b:9d:40:9d:b3:96:37:fa:a5:dc:b2:72: 4e:ef:4e:09:2c:fd:91:fd:4d:f7:bb:a6:a1:3e:ab: 7b:a2:03:40:a6:a9:55:27:e2:fa:f9:19:ce:87:75: aa:f1:75:36:f3:f3:b8:91:f8:91:c3:8b:75:13:8e: 4c:65:9a:16:39:6a:e5:34:e8:7a:96:59:7f:35:b0: 00:fd:5b:69:fc:43:26:fa:f5:28:6e:fe:87:d9:7e: 24:fb:b4:a0:82:6e:54:a2:ff:ae:bf:62:b4:f4:72: 01:c2:cb:98:47:98:e1:4c:b5:17:80:80:ce:8f:a6: 28:ee:1e:45:6a:fb:df:f1:1d:fc:5a:3b:d6:ea:f4: 6c:1d:62:49:57:3b:8a:8f:86:ea:f0:53:04:ce:9c: 16:68:ff:ba:b9:fc:88:0f:47:f7:02:44:72:40:b8: ca:3b:2d:53:9d:dc:3c:56:8c:59:7b:68:1a:2c:8d: 71:bb:6c:00:c7:1a:ce:6f:40:92:b1:a3:2f:0f:d9: 44:f2:a3:70:2e:9e:ee:0e:ae:32:d0:3b:3e:8b:07: ea:e6:79:b3:5c:29:e2:7d:6b:a8:5e:f9:5a:31:e8: 08:96:a2:8c:03:98:46:f1:b8:7d:90:54:26:ed:76: 62:fe:9e:e9:9a:6e:5e:c9:49:c7:5c:34:53:29:54: d9:ec:e4:46:e1:80:3b:75:d9:df:fb:79:d5:87:f1: ba:9e:eb:19:ce:4c:52:73:e6:5b:87:ae:25:4f:39: 79:cc:c6:b8:f9:10:7b:ec:f0:9b:71:a4:05:a0:d3: 29:d3:4e:7f:1f:f4:2d:28:78:cc:55:95:7b:1e:91: 2f:cc:56:18:73:8b:b2:db:bc:69:07:e6:d0:d8:4f: ed:a2:ff:58:85:a3:6d:e0:4a:53:b7:67:7d:8d:0c: 5c:5b:7b:77:28:02:35:44:7a:04:d3:28:43:c8:6b: 30:17:5d:32:b8:29:35:ba:76:da:3b:14:4a:76:18: 58:a4:f8:92:3c:9e:4d:33:6f:46:6b:08:d9:31:48: 68:dd:f4:fb:24:56:34:b2:cf:69:66:be:48:d2:8a: 66:22:cd:f2:69:cd:c2:53:13:45:29:41:22:d6:5d: 98:1f:b6:a4:b2:a3:c2:ee:02:2f:51:1b:dc:83:a4: ec:70:25:a8:d4:08:61:32:6f:e4:a1:81:2e:7c:63: 72:fa:29:65:bc:70:44:cf:5d Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 55:9a:34:6a:22:06:69:09:45:33:c7:ae:a9:5c:c7:09:4e:9b: 86:bc:41:90:d4:94:52:f6:cd:23:29:94:4b:22:cd:e8:bd:fe: 9d:cd:52:f2:bd:ed:ab:87:c9:ab:ab:46:04:b4:bd:a2:3f:22: 30:47:50:c0:4b:8c:76:0f:03:f5:92:d2:b1:2d:c4:7a:35:9c: c9:73:87:eb:a6:9f:de:0f:73:8d:d3:7f:99:d8:ba:8f:6f:c4: f3:be:1a:ae:8b:a2:94:36:90:e2:e5:eb:8d:05:f4:fc:65:df: 95:f1:c4:94:4d:17:56:d7:9f:3c:8f:50:3c:e7:77:bf:95:86: 26:64:fb:6a:ff:c6:da:e9:8c:ae:42:bb:69:e5:33:c6:d8:e9: 0d:c6:55:21:49:c1:0c:b4:a3:f9:9b:4b:5c:de:83:4f:41:03: ce:2a:79:68:38:7d:f0:54:49:20:f5:b6:10:ff:08:dc:33:66: 96:9b:ff:06:de:00:9e:d7:ce:56:43:9a:51:fc:70:cd:f6:f0: 51:a3:b7:cd:b4:5c:85:62:cd:71:b7:c6:2b:23:2b:dd:c3:6e: 40:42:fa:37:ff:37:1c:f6:7a:57:94:87:85:23:d7:d4:c9:c7: 5f:c1:4d:2f:c9:0d:d7:5c:ec:9c:25:ee:9e:30:82:91:96:72: b8:75:1d:f8:09:68:57:97:b2:2d:4b:ee:25:ec:7a:24:29:ee: 72:d4:9c:13:db:ab:dc:03:0a:d8:4a:14:c9:08:57:44:5d:a1: b5:53:80:34:f2:14:97:cf:52:de:a2:0e:8a:10:e9:14:ef:d0: 60:be:61:a1:f1:25:5d:d5:18:73:3f:93:10:ca:96:ee:b3:40: d2:db:a3:55:cf:57:5a:a5:0e:4f:75:47:df:ea:f7:90:9a:6d: f5:70:2e:1d:14:1c:37:64:04:59:50:b0:dc:72:86:6f:9c:37: 3d:5d:28:af:73:55:ef:d2:ee:24:74:74:13:ef:dc:db:31:49: fb:3f:63:f5:d3:08:3e:33:a5:e7:9d:0a:de:53:2c:51:8e:67: db:9b:41:65:41:50:bd:d4:a4:96:6c:87:bc:12:e0:94:c7:d3: c0:e4:cb:73:58:00:83:e1:ac:27:85:d6:9d:53:9d:5c:bd:0a: 3e:03:43:9c:0c:91:f5:6d:7b:f8:40:72:75:ab:11:76:91:2b: e1:c6:aa:1f:70:69:76:70:15:09:fe:93:d0:d6:2d:b7:15:6a: 9b:67:5c:b4:69:9f:25:a6:7d:8a:fb:7d:22:a9:71:f2:ce:4e: 8c:b8:21:2d:de:fe:41:71:0d:ff:9d:ec:73:a6:bb:07:4f:88: 0e:58:47:2e:7e:a9:c2:c7:78:dd:ba:7a:9e:4e:e0:30:4e:63: 6f:85:d4:20:41:e9:fa:fe:43:45:e7:fb:af:7a:b2:ce:a4:05: 1d:22:9a:58:86:df:e4:ce:4c:a9:fe:d8:16:a5:6f:fb:d8:ce: 56:7b:f5:d6:20:ef:e4:47:cd:63:24:ff:b9:be:f1:48:a3:c1: 01:72:e6:bd:c0:ad:ed:26:0d:ca:34:9f:fc:02:2d:20:4f:05: 20:ae:21:3d:0c:c2:20:3c:3f:f0:04:84:dc:cf:89:fd:b9:25: 91:8e:d0:43:e6:b3:20:ab:5c:2d:d5:40:9e:a0:4b:d8:f4:b2: cc:7d:f1:58:0a:8e:87:ed:88:ac:36:96:e4:56:a0:11:8a:f2: 9a:d0:b3:57:a3:34:bb:19:ab:38:e1:74:6b:22:c4:31:ce:01: d5:1b:36:e3:1e:38:4c:33:93:df:40:e3:59:57:4e:ac:6e:7b: 1e:5a:3d:c5:1d:5b:ac:c8:10:82:35:02:22:b2:fc:75:e8:10: 91:8d:c4:7d:78:93:47:9e:1c:9d:ac:6b:62:02:58:8c:d6:1c: 23:d6:af:78:c2:80:9c:a4:aa:24:54:14:b5:14:98:c6:f8:2b: 1a:24:cb:71:32:0a:e2:9b:0e:69:6b:dd:7e:8c:64:d1:2e:63: ef:0e:7f:b1:3e:88:4c:9d:55:e5:c9:6e:17:04:b7:41:ff:bd: 8a:41:cb:25:31:6f:44:77:3f:47:b1:fc:81:88:07:8e:05:49: 20:b7:11:d9:69:03:2a:03:9d:b9:33:84:9a:df:df:7a:e3:46: 73:a3:d8:a2:8c:53:19:88:55:4c:74:b8:f6:44:84:2b:d1:14: 2d:4e:39:2e:92:68:ff:69:fc:85:62:1b:eb:55:4f:ef:25:84: 62:45:99:d6:d8:4e:6f:3f:53:08:7d:1d:06:95:81:80:7f:4f: 4e:74:36:98:b5:e2:87:70:98:dc:d7:f5:dc:52:15:e6:c6:d6: 79:96:39:7f:8f:95:cf:ab:80:53:ad:1b:0b:45:40:0e:d4:18: bd:2c:de:8a:77:76:fd:f2:44:47:c6:21:d0:e4:74:f0:d8:18: 05:c8:7c:30:72:c7:df:f1:bb:fc:02:30:a9:f4:42:26:59:0d: 93:05:82:a1:73:ed:34:e5:38:5d:cd:50:90:fe:94:fc:13:bc: bd:fc:a8:a2:88:a7:73:c4:b2:a8:d1:5d:88:c4:02:a2:7a:f1: 04:c9:fe:8c:74:c9:ef:1d:64:41:9f:ac:1e:96:67:64:ac:ab: 28:41:c7:9d:f7:c0:98:1b:6e:07:c2:64:7d:5a:83:66:56:28: 36:9c:e7:fb:1c:77:0e:28:a0:c4:f7:6b:79:39:04:20:84:c7: 57:93:bc:1b:a0:ea:bc:eb:42:e5:a8:11:fe:fc:ac:65:cc:fd: f8:28:88:f4:a5:9a:e5:73:51:e0:a8:9b:0d:03:77:4e:e5:e0: 98:b3:88:da:7d:e6:c6:9e:7c:14:66:c1:2e:53:4a:92:07:37: a0:7e:e9:3d:09:e4:15:7c:cf:fd:b8:41:a5:ef:9e:66:9d:c4: 5e:07:1d:87:f8:41:ad:ea:e7:2f:d2:41:63:18:37:f9:14:e3: 4d:d0:e5:f7:43:fd:15:e3:f9:36:73:06:26:df:01:4f:a9:c3: 4e:de:20:46:77:98:b4:7a:24:2b:3b:75:2b:4e:58:8d:9b:5d: a4:c7:16:a0:bc:32:88:3f:a1:83:f3:00:c8:f8:d8:58:e9:63: 5d:4c:2b:b5:f0:72:41:d8:ab:77:37:d6:72:74:ae:b6:36:9c: c8:a6:83:49:4b:e0:c9:56:0b:29:be:00:30:cb:dd:d6:c8:42: 8a:00:d9:ec:15:d1:34:71:f2:5b:64:87:f6:27:d2:b7:eb:86: b0:90:bf:29:db:21:9e:36:8c:e3:20:2f:95:23:51:6c:1b:c2: a4:d5:e6:d8:02:43:67:a0:fe:9b:50:03:44:7f:bb:e4:72:d5: d1:e4:da:8f:92:14:64:fb:5d:14:10:12:4a:95:06:c9:65:08: 29:ca:21:a3:26:38:11:c9:27:df:70:67:04:fd:ca:48:32:7f: 63:b2:45:74:31:50:4f:87:d9:20:70:d2:21:70:b1:d6:10:9d: 33:5d:78:83:91:6d:55:82:ec:da:e4:62:63:c7:81:46:d7:19: 65:72:2a:43:19:90:b8:d7:23:4d:4c:1c:e0:44:a9:66:67:ac: ee:71:79:27:26:78:6d:72:0e:f5:5d:4b:23:b5:7c:7c:65:e9: 17:c6:3a:0b:0d:dd:5e:1e:51:c3:86:b8:ec:7f:c7:27:4a:a5: 46:e8:6a:2d:19:c1:87:a3:cb:99:93:87:64:a2:55:14:4c:b7: 43:a5:93:d7:e7:d2:4e:79:40:ca:65:99:46:3d:3f:7a:80:7a: 88:6a:cc:1e:e5:6b:33:46:f4:50:c0:d5:1f:09:b8:cd:8a:2e: a1:27:eb:5d:73:a7:e8:6b:0a:e5:57:82:2a:b0:fc:e2:54:52: 56:f0:ab:a9:12:c6:23:96:07:24:9c:e0:bc:46:a5:b4:20:04: da:09:93:63:e5:d4:2e:c2:7e:c5:31:ed:b5:15:74:86:17:b9: b3:f3:26:8a:1d:02:6a:da:1a:3f:e8:ba:f1:04:6d:94:51:54: e2:5a:b4:59:83:1d:60:d0:2d:73:cc:07:b5:26:8c:f9:d7:c6: 88:91:ef:80:cf:5d:0f:a1:60:cb:45:d4:42:22:d1:b1:70:1d: fd:d0:b7:30:90:3a:c6:48:6d:67:e5:32:da:8f:db:e3:a8:e3: 1d:20:25:a2:1c:e1:4c:b9:a4:f6:c6:3f:5c:58:0d:bb:c6:b2: 77:01:16:91:9f:17:06:0d:b7:40:3e:cc:8f:8e:9c:4b:e0:9d: 7e:9b:1e:05:ab:88:22:fa:d3:28:1b:57:14:64:4a:3e:24:2c: 38:4d:21:69:00:73:2e:d0:55:2d:74:f2:15:e8:94:43:3e:40: 2a:c6:c6:b9:6a:5b:de:a2:cc:18:50:54:5d:4e:2a:85:6c:f6: 92:8b:29:19:7e:e7:ea:4a:e0:22:2b:25:bc:f7:66:cf:77:9a: 41:74:f2:3c:14:0d:74:69:f5:50:83:cd:cd:2f:21:db:22:46: 8a:d0:f7:51:1a:95:57:f2:05:8b:1a:19:ed:3b:45:e8:36:c2: 6e:7e:fb:57:22:00:1f:06:53:a9:ae:93:c6:8f:71:2a:31:45: 92:e7:8e:6d:e6:99:22:c0:83:fc:ef:dc:57:66:77:4f:a2:36: 31:fb:a1:13:8d:e5:ca:a3:95:7d:01:0c:64:70:3b:53:42:68: 80:c7:bb:9d:a8:00:35:69:98:0c:a8:67:d8:43:e5:aa:cf:95: e0:51:95:a4:17:3f:42:9d:b8:04:ce:d3:79:79:c8:d3:8a:16: 32:92:e0:d7:a2:ee:d7:37:4c:2f:ac:b8:7b:be:45:f6:f1:18: 33:9c:7b:37:a6:24:d9:bc:40:ab:00:e9:c3:37:8b:ab:d8:b6: f3:5e:81:4e:b0:14:6b:07:3e:1f:ec:c2:f6:44:22:95:bb:b3: e6:6f:d6:f9:70:65:ba:0a:83:65:aa:0e:13:2f:83:13:23:53: 8b:40:16:fa:ce:2f:fc:4d:04:f8:eb:d8:ac:c5:36:c2:15:57: 48:38:ec:55:b3:b4:1e:ba:ad:d2:42:06:17:0d:73:c8:57:a6: be:96:4d:a9:f2:c0:fb:7a:21:1c:f5:c9:70:a9:82:90:b5:f1: 0c:d4:79:10:be:81:a6:e9:5c:61:9c:77:79:9a:a4:c3:37:26: 57:37:c9:52:2c:fa:08:ff:d0:5f:c6:61:c0:f4:76:be:fc:de: 4e:cf:ab:51:99:71:c7:df:7e:f4:d6:cf:06:56:19:13:53:0b: 6d:74:59:48:19:9b:53:05:2d:9d:32:54:d3:e5:2c:53:8b:64: 3e:d4:64:7b:e3:80:09:14:cc:fe:16:46:63:6b:71:69:f8:f9: cb:27:f6:88:54:bc:45:b3:ce:02:c8:94:ee:40:5b:f9:42:02: c2:ff:b0:d8:2c:eb:28:7f:5e:c9:26:01:99:a7 From itp at ximian.com Wed Mar 12 03:48:02 2003 From: itp at ximian.com (Ian Peters) Date: Wed Mar 12 03:48:02 2003 Subject: [gnutls-dev] [PATCH] error handling large CA files In-Reply-To: <1047418898.19053.64.camel@filbert> References: <1047418898.19053.64.camel@filbert> Message-ID: <1047437138.19054.74.camel@filbert> On Tue, 2003-03-11 at 16:41, Ian Peters wrote: > The attached patch fixes these three functions to read passed file into > a heap-allocated buffer, parse the memory, and then free the buffer. > You'll probably want to tweak things to fit into gnutls better > stylistically. Of course, -this- attached patch does the same, but doesn't leak file descriptors. :-) Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-0.8.4-large-ca-file.patch Type: text/x-patch Size: 2860 bytes Desc: not available URL: From itp at ximian.com Wed Mar 12 03:52:01 2003 From: itp at ximian.com (Ian Peters) Date: Wed Mar 12 03:52:01 2003 Subject: [gnutls-dev] [PATCH] incredibly large RSA modulus not handled In-Reply-To: <1047419166.7042.70.camel@filbert> References: <1047419166.7042.70.camel@filbert> Message-ID: <1047437344.7053.76.camel@filbert> On Tue, 2003-03-11 at 16:46, Ian Peters wrote: > This patch bumps that define up to 2400, which allows the successful > parsing of the Thawte cert. And, this patch actually applies (tip: never edit your patches by hand). Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-0.8.4-thawte-cert.patch Type: text/x-patch Size: 544 bytes Desc: not available URL: From nmav at gnutls.org Wed Mar 12 11:58:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Mar 12 11:58:02 2003 Subject: [gnutls-dev] [PATCH] error handling large CA files In-Reply-To: <1047418898.19053.64.camel@filbert> References: <1047418898.19053.64.camel@filbert> Message-ID: <20030312104643.GA21743@gnutls.org> On Tue, Mar 11, 2003 at 04:41:39PM -0500, Ian Peters wrote: > In lib/gnutls_x509.c, the functions read_cert_file, read_ca_file, and > read_key_file all read into a stack-allocated buffer of MAX_FILE_SIZE, > which is defined as 1024*100. The default CA file that comes with most > web browsers exceeds this (it is closer to 245k). This means that the > file is truncated, and parse_pem_cert_mem only sees part of the file, > resulting in only some of the trusted certificates being loaded. > Because of the pem file format, this is not a fatal error, and program > execution continues, but some certificates that should be trusted are > not. > The attached patch fixes these three functions to read passed file into > a heap-allocated buffer, parse the memory, and then free the buffer. > You'll probably want to tweak things to fit into gnutls better > stylistically. It is already solved in the 0.9.0 release, but this has the problem of loading the whole file into memory. I'm now working on something that will allow reading mmaped file regions. That will need and strnstr implementation which is not available in gnu libc (thus I'll have to implement it or get it from somewhere). > Ian -- Nikos Mavroyanopoulos From r.kittinger at efkon.com Wed Mar 12 13:08:01 2003 From: r.kittinger at efkon.com (Rupert Kittinger) Date: Wed Mar 12 13:08:01 2003 Subject: [gnutls-dev] gnutls-0.8.4 valgrind diagnosis Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I just decided to take a look at gnutls. I ran gnutls-serv and and gnutls-cli-debug on the loopback interface, using valgrind for diagnosis. The session log follows. It was created with the following command: $ valgrind --num-callers=8 --leak-check=yes --show-reachable=yes gnutls-cli-debug -p 5556 localhost &> /tmp/message System: linux compiler: ggc-2.95.3 libgcrypt: libgcrypt-1.1.12 ==31365== valgrind-1.0.4, a memory error detector for x86 GNU/Linux. ==31365== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==31365== Estimated CPU clock rate is 952 MHz ==31365== For more details, rerun with: -v ==31365== Connecting to '127.0.0.1:5556'... ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE756: gcry_mpi_print (mpicoder.c:482) ==31365== by 0x40297AD7: sexp_sscan (sexp.c:1033) ==31365== by 0x40297FA2: gcry_sexp_build (sexp.c:1180) ==31365== by 0x4025C76B: ??? (gnutls_pk.c:516) ==31365== by 0x4025C084: ??? (gnutls_pk.c:124) ==31365== by 0x4025B3A9: ??? (auth_rsa.c:309) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) ==31365== ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE756: gcry_mpi_print (mpicoder.c:482) ==31365== by 0x40297AD7: sexp_sscan (sexp.c:1033) ==31365== by 0x40297FA2: gcry_sexp_build (sexp.c:1180) ==31365== by 0x4025C796: ??? (gnutls_pk.c:532) ==31365== by 0x4025C084: ??? (gnutls_pk.c:124) ==31365== by 0x4025B3A9: ??? (auth_rsa.c:309) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) ==31365== ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE756: gcry_mpi_print (mpicoder.c:482) ==31365== by 0x40297AD7: sexp_sscan (sexp.c:1033) ==31365== by 0x40297FA2: gcry_sexp_build (sexp.c:1180) ==31365== by 0x4029DF9D: gcry_pk_encrypt (pubkey.c:1304) ==31365== by 0x4025C7C7: ??? (gnutls_pk.c:539) ==31365== by 0x4025C084: ??? (gnutls_pk.c:124) ==31365== by 0x4025B3A9: ??? (auth_rsa.c:309) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE7B1: gcry_mpi_print (mpicoder.c:503) ==31365== by 0x4025BDB9: ??? (gnutls_mpi.c:74) ==31365== by 0x4026F3B2: ??? (auth_dh_common.c:110) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) ==31365== by 0x40253BA9: gnutls_handshake (gnutls_handshake.c:1857) ==31365== by 0x804B2E9: do_handshake (tests.c:50) ==31365== by 0x804C0D2: test_anonymous (tests.c:509) ==31365== ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE7B1: gcry_mpi_print (mpicoder.c:503) ==31365== by 0x4025BDB9: ??? (gnutls_mpi.c:74) ==31365== by 0x40289969: ??? (gnutls_srp.c:147) ==31365== by 0x4028AC5F: ??? (auth_srp.c:217) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) ==31365== by 0x40253BA9: gnutls_handshake (gnutls_handshake.c:1857) ==31365== by 0x804B2E9: do_handshake (tests.c:50) ==31365== ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE7B1: gcry_mpi_print (mpicoder.c:503) ==31365== by 0x4025BDB9: ??? (gnutls_mpi.c:74) ==31365== by 0x4028997B: ??? (gnutls_srp.c:149) ==31365== by 0x4028AC5F: ??? (auth_srp.c:217) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) ==31365== by 0x40253BA9: gnutls_handshake (gnutls_handshake.c:1857) ==31365== by 0x804B2E9: do_handshake (tests.c:50) ==31365== ==31365== Conditional jump or move depends on uninitialised value(s) ==31365== at 0x402BE7B1: gcry_mpi_print (mpicoder.c:503) ==31365== by 0x4025BDB9: ??? (gnutls_mpi.c:74) ==31365== by 0x4028AD4F: ??? (auth_srp.c:249) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) ==31365== by 0x40253BA9: gnutls_handshake (gnutls_handshake.c:1857) ==31365== by 0x804B2E9: do_handshake (tests.c:50) ==31365== by 0x804B718: test_srp (tests.c:180) Resolving 'localhost'... Checking for TLS 1.0 support... yes Checking for SSL 3.0 support... yes Checking for certificate information... - - Certificate type: X.509 - Certificate info: # Certificate is valid since: Tue Nov 12 10:49:00 CET 2002 # Certificate expires: Wed Nov 12 10:49:00 CET 2003 # Certificate fingerprint: 87 68 6b 07 dc ad 05 0d 46 6e 82 3d ef 55 30 1e # Certificate serial number: 01 # Certificate version: #3 # Certificate public key algorithm: RSA # Modulus: 712 bits # CN=cch_agent test,OU=Software Department,O=Efkon AG,ST=ST,C=AT # Certificate Issuer's info: # CN=internal testing ca,OU=Software Department,O=Efkon AG,L=Graz,ST=ST,C=AT Checking for version rollback bug in RSA PMS... no Checking for version rollback bug in Client Hello... no Checking whether we need to disable TLS 1.0... no Checking whether the server can accept Hello Extensions... yes Checking whether the server can accept cipher suites not in SSL 3.0 spec... yes Checking whether the server understands TLS closure alerts... yes Checking whether the server supports session resumption... yes Checking for export-grade ciphersuite support... no Checking for anonymous authentication support... yes Checking for ephemeral Diffie Hellman support... yes Checking for AES cipher support... yes Checking for 3DES cipher support... yes Checking for ARCFOUR cipher support... yes Checking for MD5 MAC support... yes Checking for SHA1 MAC support... yes Checking for max record size TLS extension... yes Checking for SRP authentication support (gnutls extension)... yes Checking for OpenPGP authentication support (gnutls extension)... no ==31365== ==31365== ERROR SUMMARY: 56 errors from 7 contexts (suppressed: 3 from 1) ==31365== malloc/free: in use at exit: 4958 bytes in 23 blocks. ==31365== malloc/free: 29498 allocs, 29475 frees, 3140240 bytes allocated. ==31365== For counts of detected errors, rerun with: -v ==31365== searching for pointers to 23 not-freed blocks. ==31365== checked 4479860 bytes. ==31365== ==31365== definitely lost: 60 bytes in 3 blocks. ==31365== possibly lost: 0 bytes in 0 blocks. ==31365== still reachable: 4898 bytes in 20 blocks. ==31365== ==31365== 23 bytes in 1 blocks are still reachable in loss record 1 of 9 ==31365== at 0x40048DEB: malloc (vg_clientfuncs.c:100) ==31365== by 0x4000AC39: _dl_new_object (dl-object.c:106) ==31365== by 0x400062AE: _dl_map_object_from_fd (dl-load.c:833) ==31365== by 0x400079D9: _dl_map_object (dl-load.c:1747) ==31365== by 0x4041786C: dl_open_worker (dl-open.c:217) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40417D4E: _dl_open (dl-open.c:407) ==31365== by 0x40418BB1: do_dlopen (dl-libc.c:78) ==31365== ==31365== 23 bytes in 1 blocks are still reachable in loss record 2 of 9 ==31365== at 0x40048DEB: malloc (vg_clientfuncs.c:100) ==31365== by 0x40007CF8: _dl_map_object (dl-load.c:164) ==31365== by 0x4041786C: dl_open_worker (dl-open.c:217) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40417D4E: _dl_open (dl-open.c:407) ==31365== by 0x40418BB1: do_dlopen (dl-libc.c:78) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40418A5C: __libc_dlopen (dl-libc.c:44) ==31365== ==31365== 28 bytes in 1 blocks are still reachable in loss record 3 of 9 ==31365== at 0x40048DEB: malloc (vg_clientfuncs.c:100) ==31365== by 0x4000C74E: _dl_map_object_deps (dl-deps.c:528) ==31365== by 0x40417901: dl_open_worker (dl-open.c:255) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40417D4E: _dl_open (dl-open.c:407) ==31365== by 0x40418BB1: do_dlopen (dl-libc.c:78) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40418A5C: __libc_dlopen (dl-libc.c:44) ==31365== ==31365== 60 bytes in 3 blocks are definitely lost in loss record 4 of 9 ==31365== at 0x40048DEB: malloc (vg_clientfuncs.c:100) ==31365== by 0x40295FB6: gcry_malloc (global.c:386) ==31365== by 0x402962A9: gcry_xmalloc (global.c:502) ==31365== by 0x402BFED5: _gcry_mpi_alloc (mpiutil.c:43) ==31365== by 0x402C064C: gcry_mpi_new (mpiutil.c:320) ==31365== by 0x40289A86: ??? (gnutls_srp.c:299) ==31365== by 0x4028AC9D: ??? (auth_srp.c:228) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== ==31365== 128 bytes in 1 blocks are still reachable in loss record 5 of 9 ==31365== at 0x400492E3: calloc (vg_clientfuncs.c:239) ==31365== by 0x4000ED0A: _dl_check_map_versions (dl-version.c:289) ==31365== by 0x40417C20: dl_open_worker (dl-open.c:257) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40417D4E: _dl_open (dl-open.c:407) ==31365== by 0x40418BB1: do_dlopen (dl-libc.c:78) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40418A5C: __libc_dlopen (dl-libc.c:44) ==31365== ==31365== 550 bytes in 1 blocks are still reachable in loss record 6 of 9 ==31365== at 0x400492E3: calloc (vg_clientfuncs.c:239) ==31365== by 0x4000A9C0: _dl_new_object (dl-object.c:43) ==31365== by 0x400062AE: _dl_map_object_from_fd (dl-load.c:833) ==31365== by 0x400079D9: _dl_map_object (dl-load.c:1747) ==31365== by 0x4041786C: dl_open_worker (dl-open.c:217) ==31365== by 0x4000D7C3: _dl_catch_error (dl-error.c:153) ==31365== by 0x40417D4E: _dl_open (dl-open.c:407) ==31365== by 0x40418BB1: do_dlopen (dl-libc.c:78) ==31365== ==31365== 836 bytes in 4 blocks are still reachable in loss record 7 of 9 ==31365== at 0x400493FE: realloc (vg_clientfuncs.c:270) ==31365== by 0x402960A7: gcry_realloc (global.c:428) ==31365== by 0x4029631A: gcry_xrealloc (global.c:516) ==31365== by 0x402C00A6: _gcry_mpi_resize (mpiutil.c:120) ==31365== by 0x402BCB25: gcry_mpi_mul_ui (mpi-mul.c:52) ==31365== by 0x40289AF7: ??? (gnutls_srp.c:308) ==31365== by 0x4028AC9D: ??? (auth_srp.c:228) ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) ==31365== ==31365== 1595 bytes in 1 blocks are still reachable in loss record 8 of 9 ==31365== at 0x40048DEB: malloc (vg_clientfuncs.c:100) ==31365== by 0x804B3F5: do_handshake (tests.c:84) ==31365== by 0x804C216: test_openpgp1 (tests.c:293) ==31365== by 0x804B11D: main (tls_test.c:191) ==31365== by 0x403186F7: __libc_start_main (../sysdeps/generic/libc-start.c:129) ==31365== by 0x8049E91: alarm@@GLIBC_2.0 (in /usr/local/bin/gnutls-cli-debug) ==31365== ==31365== 1715 bytes in 10 blocks are still reachable in loss record 9 of 9 ==31365== at 0x40048DEB: malloc (vg_clientfuncs.c:100) ==31365== by 0x40295FB6: gcry_malloc (global.c:386) ==31365== by 0x402962A9: gcry_xmalloc (global.c:502) ==31365== by 0x402963C4: gcry_xcalloc (global.c:538) ==31365== by 0x402B20C5: initialize (random.c:148) ==31365== by 0x402B2140: _gcry_random_initialize (random.c:164) ==31365== by 0x402958C3: gcry_control (global.c:245) ==31365== by 0x4025DC16: gnutls_global_init (gnutls_global.c:172) ==31365== ==31365== LEAK SUMMARY: ==31365== definitely lost: 60 bytes in 3 blocks. ==31365== possibly lost: 0 bytes in 0 blocks. ==31365== still reachable: 4898 bytes in 20 blocks. ==31365== Notes: - - the unitialized memory errors in libgcrypt gcry_mpi_print() seem to be caused by passing an uninitialized size_t in *nbytes. - - the 60 byte memory leak is probably worth looking at. - - suppressed errors are probably from glibc. No supressions have been added beside those provided by the valgrind team. These errors do not look very platform-specific at first sight, but if you want more details (libc, binutils, whatever), please mail me. Hope this helps improving the software :-) cheers, Rupert - -- Rupert Kittinger EFKON AG, Software Development Department Andritzer Reichsstrasse 66 Austria, 8045 Graz Tel: +43 316 695675-714 Fax: +43 316 695675-9 pgp-keyID: A500DBAD -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQE+bePq3Cm/56UA260RAr52AJ0WqBgw3Sz8PpX87TIQxL4nv/ObpwCgjjVQ HdpQUjdHE7Cpm0yvgsXPiis= =rlcw -----END PGP SIGNATURE----- From nmav at gnutls.org Wed Mar 12 13:44:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Mar 12 13:44:01 2003 Subject: [gnutls-dev] [PATCH] incredibly large RSA modulus not handled In-Reply-To: <1047437344.7053.76.camel@filbert> References: <1047419166.7042.70.camel@filbert> <1047437344.7053.76.camel@filbert> Message-ID: <20030312123031.GA11048@gnutls.org> On Tue, Mar 11, 2003 at 09:49:04PM -0500, Ian Peters wrote: > > This patch bumps that define up to 2400, which allows the successful > > parsing of the Thawte cert. > And, this patch actually applies (tip: never edit your patches by hand). Thanks. I've commited it. I think that this will go to a new 0.8.x release, it will be for sure included in the development 0.9.1. > Ian -- Nikos Mavroyanopoulos From nmav at gnutls.org Wed Mar 12 13:49:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Mar 12 13:49:01 2003 Subject: [gnutls-dev] [PATCH] incredibly large RSA modulus not handled In-Reply-To: <20030312123031.GA11048@gnutls.org> References: <1047419166.7042.70.camel@filbert> <1047437344.7053.76.camel@filbert> <20030312123031.GA11048@gnutls.org> Message-ID: <20030312125128.GA382@gnutls.org> On Wed, Mar 12, 2003 at 02:30:31PM +0200, Nikos Mavroyanopoulos wrote: > > > This patch bumps that define up to 2400, which allows the successful > > > parsing of the Thawte cert. > > And, this patch actually applies (tip: never edit your patches by hand). > Thanks. I've commited it. I think that this will go to a new 0.8.x release, The correct phrase should be that this will NOT go to a new 0.8.x release. I'm too tired :) -- Nikos Mavroyanopoulos From itp at ximian.com Wed Mar 12 15:11:02 2003 From: itp at ximian.com (Ian Peters) Date: Wed Mar 12 15:11:02 2003 Subject: [gnutls-dev] gnutls-0.8.4 valgrind diagnosis In-Reply-To: References: Message-ID: <1047477143.12353.2.camel@filbert> On Tue, 2003-03-11 at 08:25, Rupert Kittinger wrote: > ==31365== Conditional jump or move depends on uninitialised value(s) > ==31365== at 0x402BE756: gcry_mpi_print (mpicoder.c:482) > ==31365== by 0x40297AD7: sexp_sscan (sexp.c:1033) > ==31365== by 0x40297FA2: gcry_sexp_build (sexp.c:1180) > ==31365== by 0x4025C76B: ??? (gnutls_pk.c:516) > ==31365== by 0x4025C084: ??? (gnutls_pk.c:124) > ==31365== by 0x4025B3A9: ??? (auth_rsa.c:309) > ==31365== by 0x402569A2: ??? (gnutls_kx.c:183) > ==31365== by 0x40253E1E: ??? (gnutls_handshake.c:1978) > > - - the unitialized memory errors in libgcrypt gcry_mpi_print() seem to be > caused by passing an uninitialized size_t in *nbytes. I actually just sent a patch for this to the libgcrypt mailing list last night. Ian From itp at ximian.com Wed Mar 12 16:08:01 2003 From: itp at ximian.com (Ian Peters) Date: Wed Mar 12 16:08:01 2003 Subject: [gnutls-dev] [PATCH] error handling large CA files In-Reply-To: <20030312104643.GA21743@gnutls.org> References: <1047418898.19053.64.camel@filbert> <20030312104643.GA21743@gnutls.org> Message-ID: <1047481631.12358.10.camel@filbert> On Wed, 2003-03-12 at 05:46, Nikos Mavroyanopoulos wrote: > On Tue, Mar 11, 2003 at 04:41:39PM -0500, Ian Peters wrote: > It is already solved in the 0.9.0 release, but this has the problem of loading > the whole file into memory. > > I'm now working on something that will allow reading mmaped file regions. That > will need and strnstr implementation which is not available in gnu libc (thus > I'll have to implement it or get it from somewhere). Right; I looked at doing it with mmap, but parse_pem_cert_mem and similar functions seemed to assume NULL-terminated strings, regardless of the passed in length -- hence the need for strnstr and some tweaks in the parsing code. Anyway, if you're already working on it, I'm not going to worry about it anymore (and stick with the inefficient solution of reading the entire file into memory for now). BTW here's a strnstr I used for another project a while back, pretty straightforward. #include char * strnstr (const char *haystack, const char *needle, size_t hlen) { size_t nlen; if (!needle || !*needle) return (char *)haystack; else nlen = strlen (needle); while (hlen >= nlen) { if (*needle == *haystack && !strncmp (haystack + 1, needle + 1, nlen - 1)) return (char *) haystack; haystack++; hlen--; } return NULL; } Also, do you have any plans at this point for what your upcoming releases should be? When do you / will you consider the 0.9.x releases to be a better choice than the 0.8.x releases? Ian From nmav at gnutls.org Wed Mar 12 22:47:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Mar 12 22:47:02 2003 Subject: [gnutls-dev] [PATCH] error handling large CA files In-Reply-To: <1047481631.12358.10.camel@filbert> References: <1047418898.19053.64.camel@filbert> <20030312104643.GA21743@gnutls.org> <1047481631.12358.10.camel@filbert> Message-ID: <20030312213433.GB871@gnutls.org> On Wed, Mar 12, 2003 at 10:07:11AM -0500, Ian Peters wrote: > > I'm now working on something that will allow reading mmaped file regions. That > > will need and strnstr implementation which is not available in gnu libc (thus > > I'll have to implement it or get it from somewhere). > Right; I looked at doing it with mmap, but parse_pem_cert_mem and > similar functions seemed to assume NULL-terminated strings, regardless > of the passed in length -- hence the need for strnstr and some tweaks in > the parsing code. The code commited this morning should have this capability. I'll have a 0.9.1 release soon. > file into memory for now). BTW here's a strnstr I used for another > project a while back, pretty straightforward. Thank you. > Also, do you have any plans at this point for what your upcoming > releases should be? When do you / will you consider the 0.9.x releases > to be a better choice than the 0.8.x releases? The 0.9.x releases have a different API (for the certificate parsing) and should be used by new programs. Today I commited most of the planned changes for the x.509 certificates. What remains to be done, is the new openpgp key handling API, and probably a certificate request generation api (I've not started working on it, and I don't know if it will make it to the 1.0.0 release). When these two features are added I'll move to 0.9.9x which will be testing releases for the stable 1.0.0. > Ian -- Nikos Mavroyanopoulos From nmav at gnutls.org Wed Mar 12 23:12:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed Mar 12 23:12:01 2003 Subject: [gnutls-dev] gnutls 0.9.1 Message-ID: <20030312221415.GA2956@gnutls.org> I'll not be able to do any work on gnutls this week, so I'm releasing the 0.9.1 which has several poorly tested new features and some bug fixes over the 0.9.0. - Corrected a bug in 64 bit architectures, which affected the serial number calculation in the record layer. - Added gnutls_certificate_free_keys() which deletes all the private keys and certificates from the credentials structure. - Corrected a broken buffer check in _gnutls_io_read_buffered(), which caused some unexpected packet length errors. Report and patch by Ian Peters . - Added ability to generate RSA keys. - Increased the maximum parameter size in order to read some large keys by some CAs. Patch by Ian Peters . - Added an strnstr() function and the requirement in some functions to use null terminated PEM structures is no more. - Use mmap() if available to read files. - Fixed a memory leak in SRP code reported by Rupert Kittinger . -- Nikos Mavroyanopoulos From nmav at gnutls.org Sat Mar 15 12:01:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat Mar 15 12:01:01 2003 Subject: [gnutls-dev] gnutls 0.9.2 Message-ID: <20030315110327.GA31786@gnutls.org> I said there wouldn't be a release soon, but I lied :) Gnutls 0.9.2 is out. - Some corrections in the memory mapping code (file is unmapped after it is read). - Added support for PKCS#10 certificate requests generation. -- Nikos Mavroyanopoulos From nmav at gnutls.org Sat Mar 22 16:27:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat Mar 22 16:27:01 2003 Subject: [gnutls-dev] gnutls 0.8.5 Message-ID: <20030322152936.GA13133@gnutls.org> I've just released gnutls 0.8.5. The changes since the last release are: - Allow larger MPI parameters in certificates. - Implemented the counter measure discussed in the paper "Attacking RSA-based Sessions in SSL/TLS", against the attack discribed in the same paper. - The RSA premaster secret version check can no longer be disabled. -- Nikos Mavroyanopoulos From nmav at gnutls.org Mon Mar 24 07:35:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon Mar 24 07:35:02 2003 Subject: [gnutls-dev] gnutls 0.9.3 Message-ID: <20030324063739.GA6159@gnutls.org> I've just released gnutls 0.9.3. The changes since the latest development version are listed below. Note that this version only works with the included libtasn1. - Support for MD2 was dropped. - Improved the error logging functions, by adding a level, and by allowing debugging messages just by increasing the level. - The diffie Hellman ciphersuites are now of higher priority than the plain RSA. - The RSA premaster secret version check can no longer be disabled. - Implemented the counter measure discussed in the paper "Attacking RSA-based Sessions in SSL/TLS", against the attack described in the same paper. - Added the functions: gnutls_handshake_get_last_in(), gnutls_handshake_get_last_out(). - The gnutls_certificate_set_rsa_params() was renamed to gnutls_certificate_set_rsa_export_params(). - Added the new functions: gnutls_certificate_set_x509_key() gnutls_certificate_set_x509_trust(), gnutls_certificate_set_x509_crl(), gnutls_x509_crt_export(), gnutls_x509_crl_export(). - Added support for encoding and decoding PKCS #8 2.0 encrypted RSA private keys. -- Nikos Mavroyanopoulos From nmav at gnutls.org Tue Mar 25 10:09:19 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue Mar 25 10:09:19 2003 Subject: [gnutls-dev] gnutls 0.8.6 Message-ID: <20030325091154.GA13333@gnutls.org> gnutls 0.8.6 was just released. The changes since 0.8.5 are listed below. - Corrected a parsing error in the Certificate request message. - Corrected behaviour when a certificate request message is received. Now a certificate packet is always sent, and in SSL 3.0 cipher suites a no_certificate alert is sent instead. -- Nikos Mavroyanopoulos From vcotirlea at hotmail.com Tue Mar 25 15:00:02 2003 From: vcotirlea at hotmail.com (vc) Date: Tue Mar 25 15:00:02 2003 Subject: [gnutls-dev] gnutls lib for VC7.1 Win200 Message-ID: Hi all, I am new to the gnutls world and I have to port a Linux application on Windows. I am using Win 2000 and the VC++7.1 (VS .NET beta 2003) compiler. As the Linux application is using the gnutls lib I need also a windows version of this lib, so I have a few questions: 1) Has the gnutls lib support for VC++7.1? Can it be built using this compiler? 2) Can I create a normal VC++ workspace for this lib ? If yes how can I find the settings that have to be done? Thanks a lot in advance, Viv From nmav at gnutls.org Tue Mar 25 17:44:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue Mar 25 17:44:01 2003 Subject: [gnutls-dev] gnutls lib for VC7.1 Win200 In-Reply-To: References: Message-ID: <20030325164638.GA843@gnutls.org> On Tue, Mar 25, 2003 at 02:58:07PM +0100, vc wrote: > Hi all, > I am new to the gnutls world and I have to port a Linux application on > Windows. > I am using Win 2000 and the VC++7.1 (VS .NET beta 2003) compiler. > As the Linux application is using the gnutls lib I need also a windows > version of this lib, > so I have a few questions: > 1) Has the gnutls lib support for VC++7.1? Can it be built using this > compiler? Gnutls can be built with any ANSI C99 compliant compiler, so you should be able to use cygwin's make/bash and the cl.exe compiler to build it (I've never tried that though). > 2) Can I create a normal VC++ workspace for this lib ? If yes how can I find > the settings > that have to be done? I don't know about that, since I'm not familiar on the VC++ build procedure. > Thanks a lot in advance, > Viv -- Nikos Mavroyanopoulos From vcotirlea at hotmail.com Wed Mar 26 17:29:02 2003 From: vcotirlea at hotmail.com (vc) Date: Wed Mar 26 17:29:02 2003 Subject: [gnutls-dev] gnutls lib for VC7.1 Win200 References: <20030325164638.GA843@gnutls.org> Message-ID: I would like to build the lib without using cygwin or mingw as these emulate a unix environment, and I don't want that. I would like to build the lib independent just by using the MS VC++ compiler. Can I do that? Without cygwin how can I run the ./configure? I have to port the app on native Windows, so I am not allowed to use cygwin or mingw. Does anybody have any idea that could help me? Thanks, Viv ----- Original Message ----- From: "Nikos Mavroyanopoulos" To: Sent: Tuesday, March 25, 2003 5:46 PM Subject: Re: [gnutls-dev] gnutls lib for VC7.1 Win200 > On Tue, Mar 25, 2003 at 02:58:07PM +0100, vc wrote: > > > Hi all, > > I am new to the gnutls world and I have to port a Linux application on > > Windows. > > I am using Win 2000 and the VC++7.1 (VS .NET beta 2003) compiler. > > As the Linux application is using the gnutls lib I need also a windows > > version of this lib, > > so I have a few questions: > > 1) Has the gnutls lib support for VC++7.1? Can it be built using this > > compiler? > Gnutls can be built with any ANSI C99 compliant compiler, so you should > be able to use cygwin's make/bash and the cl.exe compiler to build it (I've > never tried that though). > > > 2) Can I create a normal VC++ workspace for this lib ? If yes how can I find > > the settings > > that have to be done? > I don't know about that, since I'm not familiar on the VC++ build procedure. > > > > Thanks a lot in advance, > > Viv > > -- > Nikos Mavroyanopoulos > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev > From wk at gnupg.org Thu Mar 27 09:48:01 2003 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 27 09:48:01 2003 Subject: [gnutls-dev] gnutls lib for VC7.1 Win200 In-Reply-To: ("vc"'s message of "Wed, 26 Mar 2003 17:27:54 +0100") References: <20030325164638.GA843@gnutls.org> Message-ID: <87n0jhb3dn.fsf@alberti.g10code.de> On Wed, 26 Mar 2003 17:27:54 +0100, vc said: > Without cygwin how can I run the ./configure? I have to port the app on > native Windows, You can't - configure relies on a basic Unix system. What you have to do is to create a config.h manually for your system. > so I am not allowed to use cygwin or mingw. mingw32 creates native windows binaries and you are allowed tocreate proprietary code using it. Cygwin is a different story, though. Shalom-Salam, Werner -- Nonviolence is the greatest force at the disposal of mankind. It is mightier than the mightiest weapon of destruction devised by the ingenuity of man. -Gandhi From vcotirlea at hotmail.com Thu Mar 27 12:29:01 2003 From: vcotirlea at hotmail.com (vc) Date: Thu Mar 27 12:29:01 2003 Subject: [gnutls-dev] gnutls lib for VC7.1 Win200 References: <20030325164638.GA843@gnutls.org> <87n0jhb3dn.fsf@alberti.g10code.de> Message-ID: Thanks a lot for your answer. I haven't used mingw32, but as you are saying, could I just run the configure using mingw32 and then to use with a VC++ project the sources and the obtained config.h? Or do I have to do everything on mingw32, like obtaining the binaries? I'm asking this because I saw something in the configure file: "# cygwin and mingw dlls have different entry points and sets of symbols # to exclude. # FIXME: what about values for MSVC?" Also, creating manually the config.h is not a trivial task. Can you give me some hints on how to do it? Thanks a lot, Viv ----- Original Message ----- From: "Werner Koch" To: Sent: Thursday, March 27, 2003 9:49 AM Subject: Re: [gnutls-dev] gnutls lib for VC7.1 Win200 > On Wed, 26 Mar 2003 17:27:54 +0100, vc said: > > > Without cygwin how can I run the ./configure? I have to port the app on > > native Windows, > > You can't - configure relies on a basic Unix system. What you have > to do is to create a config.h manually for your system. > > > so I am not allowed to use cygwin or mingw. > > mingw32 creates native windows binaries and you are allowed tocreate > proprietary code using it. Cygwin is a different story, though. > > > Shalom-Salam, > > Werner > > -- > Nonviolence is the greatest force at the disposal of > mankind. It is mightier than the mightiest weapon of > destruction devised by the ingenuity of man. -Gandhi > > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev > From jvb at prairienet.org Fri Mar 28 11:39:01 2003 From: jvb at prairienet.org (John Belmonte) Date: Fri Mar 28 11:39:01 2003 Subject: [gnutls-dev] TLS/PGP standard? Message-ID: <3E81FAE8.2020708@prairienet.org> Hello, How do things look for PGP support being officially added to the TLS specification? I noticed that the most recent Draft expired last month. I am designing a new network application and would like to make use of this feature, but am concerned that it will fail to become a standard. Regards, -John Belmonte -- http:// if l . / From nmav at gnutls.org Fri Mar 28 12:11:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Mar 28 12:11:02 2003 Subject: [gnutls-dev] TLS/PGP standard? In-Reply-To: <3E81FAE8.2020708@prairienet.org> References: <3E81FAE8.2020708@prairienet.org> Message-ID: <20030328111322.GA14315@gnutls.org> On Wed, Mar 26, 2003 at 02:09:28PM -0500, John Belmonte wrote: > Hello, > How do things look for PGP support being officially added to the TLS > specification? I noticed that the most recent Draft expired last month. > I am designing a new network application and would like to make use of this > feature, but am concerned that it will fail to become a standard. Well I will continue submiting the draft, and the openpgp support from gnutls isn't going anywhere. Whether it will be advanced to RFC status, is up to the ietf-tls Working Group[0]. Usually drafts move to RFC status if there is interest about them (in the WG mailing list). So you might want to forward your question to the Working Group's mailing list. [0]. http://www.ietf.org/html.charters/tls-charter.html > Regards, > -John Belmonte -- Nikos Mavroyanopoulos From nmav at gnutls.org Fri Mar 28 13:32:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri Mar 28 13:32:02 2003 Subject: [gnutls-dev] gnutls 0.9.4 Message-ID: <20030328123448.GA5812@gnutls.org> I've released the gnutls 0.9.4. The changes are: - Corrected a parsing error in the Certificate request message. - Corrected behaviour when a certificate request message is received. Now a certificate packet is always sent, and in SSL 3.0 cipher suites a no_certificate alert is sent instead. - Added functionality to generate PKCS #7 structures (with certificates). -- Nikos Mavroyanopoulos