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" <andreas.trottmann at werft22.com> -----

Subject: Bug#183176: libgnutls5: Crypts wrong on alpha
Reply-To: "Andreas U. Trottmann" <andreas.trottmann at werft22.com>,
	183176 at bugs.debian.org
From: "Andreas U. Trottmann" <andreas.trottmann at werft22.com>
To: Debian Bug Tracking System <submit at bugs.debian.org>
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" <andreas.trottmann at werft22.com> -----
> 
> Subject: Bug#183176: libgnutls5: Crypts wrong on alpha
> Reply-To: "Andreas U. Trottmann" <andreas.trottmann at werft22.com>,
> 	183176 at bugs.debian.org
> From: "Andreas U. Trottmann" <andreas.trottmann at werft22.com>
> To: Debian Bug Tracking System <submit at bugs.debian.org>
> 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 <gnutls_num.h>
 #include <gnutls_errors.h>
 
-
-#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 <gnutls_int.h>
@@ -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: </pipermail/attachments/20030303/40fa3b12/attachment.obj>

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 <nmav at gnutls.org>
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: </pipermail/attachments/20030305/bc59aa74/attachment.eml>

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: </pipermail/attachments/20030305/7c23fdfb/attachment.bin>

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: </pipermail/attachments/20030306/e93c0f46/attachment.bin>

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: </pipermail/attachments/20030311/8dfb42b6/attachment.bin>

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: </pipermail/attachments/20030311/406f6cce/attachment.bin>
-------------- 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: </pipermail/attachments/20030312/2112aade/attachment.bin>

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: </pipermail/attachments/20030312/886f6284/attachment.bin>

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: <Pine.LNX.4.44.0303111350170.31373-100000@homer.efkon>

-----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 <r.kittinger at efkon.com>
  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: <Pine.LNX.4.44.0303111350170.31373-100000@homer.efkon>
References: <Pine.LNX.4.44.0303111350170.31373-100000@homer.efkon>
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 <string.h>
                                                                                
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 <itp at ximian.com>.
- 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 <itp at ximian.com>.
- 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 <r.kittinger at efkon.com>.

-- 
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: <OE47OIGE6rzsjrVvCyx0001523d@hotmail.com>

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: <OE47OIGE6rzsjrVvCyx0001523d@hotmail.com>
References: <OE47OIGE6rzsjrVvCyx0001523d@hotmail.com>
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: <OE47OIGE6rzsjrVvCyx0001523d@hotmail.com> <20030325164638.GA843@gnutls.org>
Message-ID: <OE295TK3XiWGiyF63i400017958@hotmail.com>

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" <nmav at gnutls.org>
To: <gnutls-dev at gnupg.org>
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: <OE295TK3XiWGiyF63i400017958@hotmail.com> ("vc"'s message of
 "Wed, 26 Mar 2003 17:27:54 +0100")
References: <OE47OIGE6rzsjrVvCyx0001523d@hotmail.com>
	<20030325164638.GA843@gnutls.org>
	<OE295TK3XiWGiyF63i400017958@hotmail.com>
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: <OE47OIGE6rzsjrVvCyx0001523d@hotmail.com><20030325164638.GA843@gnutls.org><OE295TK3XiWGiyF63i400017958@hotmail.com> <87n0jhb3dn.fsf@alberti.g10code.de>
Message-ID: <OE60EAngArL0RQW8SCE00016f36@hotmail.com>

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" <wk at gnupg.org>
To: <gnutls-dev at gnupg.org>
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