From simon at josefsson.org Wed Oct 7 16:50:59 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 07 Oct 2009 16:50:59 +0200 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <4A5F1961.7060507@unifr.ch> (Carolin Latze's message of "Thu, 16 Jul 2009 14:13:21 +0200") References: <4A5F1961.7060507@unifr.ch> Message-ID: <878wfn6ywc.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi all, > > according to RFC 5246, TLS 1.2 should use a standard signature, but if > I enable TLS 1.2 in GnuTLS and print out the hash size it says > 36... that does not sound like a standard signature.. I would expect > something like 20 for SHA1. Am I wrong? Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take a look? It should have more solid TLS 1.2 support. Thanks, Simon From carolin.latze at unifr.ch Thu Oct 8 11:16:11 2009 From: carolin.latze at unifr.ch (Carolin Latze) Date: Thu, 08 Oct 2009 11:16:11 +0200 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <878wfn6ywc.fsf@mocca.josefsson.org> References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> Message-ID: <4ACDADDB.3030703@unifr.ch> Hi Simon, I tried to use TLS 1.2 with and without sign callback, and I still see a signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't it be max 35 then? Maybe we should check, whether I check the right variables: In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure called dconcat. dconcat.size holds the hash size, right? and dconcat.data should hold the hash itself? dconcat.size has a value of 36 for me... If I use the sign callback, I print the value of hash->size (=36) and hash->data (cannot see the OID included in that value, so for me it looks like it is really not SHA-1 only). Maybe I check the wrong values? BTW: I used the latest Snapshot, 2.9.8 to test it. Sorry... :-/ Carolin Simon Josefsson wrote: > Carolin Latze writes: > > >> Hi all, >> >> according to RFC 5246, TLS 1.2 should use a standard signature, but if >> I enable TLS 1.2 in GnuTLS and print out the hash size it says >> 36... that does not sound like a standard signature.. I would expect >> something like 20 for SHA1. Am I wrong? >> > > Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take > a look? It should have more solid TLS 1.2 support. > > Thanks, > Simon > -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de P?rolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec From hoyt6 at llnl.gov Thu Oct 8 17:41:52 2009 From: hoyt6 at llnl.gov (Hoyt, David) Date: Thu, 8 Oct 2009 08:41:52 -0700 Subject: FIPS Certification Message-ID: Is or will there be an effort to become FIPS certified? If so, is there a schedule laid out for the process? Is there a webpage I can look at to keep myself up-to-date on the certification process? Thanks, - David Hoyt -------------- next part -------------- An HTML attachment was scrubbed... URL: From axos88 at gmail.com Thu Oct 8 19:35:07 2009 From: axos88 at gmail.com (=?ISO-8859-1?Q?Vandra_=C1kos?=) Date: Thu, 08 Oct 2009 19:35:07 +0200 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <4ACDADDB.3030703@unifr.ch> References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> Message-ID: <4ACE22CB.6090309@gmail.com> Last time I checked, the signature algorithm is broken, still uses the TLSv1.1 implementation meaning SHA1 ++ MD5 concat. Regards, Vandra ?kos On 2009. 10. 08. 11:16, Carolin Latze wrote: > Hi Simon, > > I tried to use TLS 1.2 with and without sign callback, and I still see a > signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't > it be max 35 then? Maybe we should check, whether I check the right > variables: > > In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure > called dconcat. dconcat.size holds the hash size, right? and > dconcat.data should hold the hash itself? dconcat.size has a value of 36 > for me... > > If I use the sign callback, I print the value of hash->size (=36) and > hash->data (cannot see the OID included in that value, so for me it > looks like it is really not SHA-1 only). > > Maybe I check the wrong values? > > BTW: I used the latest Snapshot, 2.9.8 to test it. > > Sorry... :-/ > Carolin > > Simon Josefsson wrote: > >> Carolin Latze writes: >> >> >> >>> Hi all, >>> >>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>> 36... that does not sound like a standard signature.. I would expect >>> something like 20 for SHA1. Am I wrong? >>> >>> >> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >> a look? It should have more solid TLS 1.2 support. >> >> Thanks, >> Simon >> >> > From simon at josefsson.org Thu Oct 8 20:09:47 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 Oct 2009 20:09:47 +0200 Subject: FIPS Certification In-Reply-To: (David Hoyt's message of "Thu, 8 Oct 2009 08:41:52 -0700") References: Message-ID: <87zl81ycyc.fsf@mocca.josefsson.org> "Hoyt, David" writes: > Is or will there be an effort to become FIPS certified? If so, is > there a schedule laid out for the process? Is there a webpage I can > look at to keep myself up-to-date on the certification process? All the crypto in GnuTLS normally happens in libgcrypt, and I recall seeing libgcrypt mentioned on the list of projects underway of becoming FIPS-certified some time ago. Also, it is possible to replace the crypto calls to your own library on the fly, see: http://www.gnu.org/software/gnutls/reference/gnutls-crypto.html There may be more involved, but this is as much as I am aware of. I am certainly interested in seeing GnuTLS FIPS-certified, but if anything more than FIPS-certifying libgcrypt is required, that will require funding from someone. Thanks, /Simon From simon at josefsson.org Thu Oct 8 20:12:56 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 Oct 2009 20:12:56 +0200 Subject: TLS 1.2 with standard signature? Why hash->size == 36?? In-Reply-To: <4ACDADDB.3030703@unifr.ch> (Carolin Latze's message of "Thu, 08 Oct 2009 11:16:11 +0200") References: <4A5F1961.7060507@unifr.ch> <878wfn6ywc.fsf@mocca.josefsson.org> <4ACDADDB.3030703@unifr.ch> Message-ID: <87vdipyct3.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi Simon, > > I tried to use TLS 1.2 with and without sign callback, and I still see a > signature of 36 bytes... Even if there is a leading SHA-1 OID, shouldn't > it be max 35 then? Hi, and thanks for testing. Nope, then it doesn't work. :-( I recall the SHA-1 OID plus the SHA-1 hash is 32 bytes. I suspect this indicate that signing using _client_ certificates haven't been made working with TLS 1.2 yet. I'll try to get an environment up where I can start debug this better. It should be possible to get something working now that both Opera 10 and mikestoolbox.* are available for testing. > Maybe we should check, whether I check the right variables: > > In gnutls_sig.c, method _gnutls_tls_sign_hdata, there is a structure > called dconcat. dconcat.size holds the hash size, right? and > dconcat.data should hold the hash itself? dconcat.size has a value of 36 > for me... > > If I use the sign callback, I print the value of hash->size (=36) and > hash->data (cannot see the OID included in that value, so for me it > looks like it is really not SHA-1 only). > > Maybe I check the wrong values? No you did right -- if it works, the first few bytes of the data to sign should be an OID which should be easy to identify. /Simon > BTW: I used the latest Snapshot, 2.9.8 to test it. > > Sorry... :-/ > Carolin > > Simon Josefsson wrote: >> Carolin Latze writes: >> >> >>> Hi all, >>> >>> according to RFC 5246, TLS 1.2 should use a standard signature, but if >>> I enable TLS 1.2 in GnuTLS and print out the hash size it says >>> 36... that does not sound like a standard signature.. I would expect >>> something like 20 for SHA1. Am I wrong? >>> >> >> Hi! With GnuTLS 2.9.7 I hope this should work better -- could you take >> a look? It should have more solid TLS 1.2 support. >> >> Thanks, >> Simon >> From mwd at cert.org Fri Oct 9 16:54:40 2009 From: mwd at cert.org (Michael Welsh Duggan) Date: Fri, 09 Oct 2009 10:54:40 -0400 Subject: Handling network disconnects during read Message-ID: I've been encountering a problem using gnutls_record_recv() using old versions of gnutls, and I want to find out if a) current versions are not subject to this problem, or b) there is a decent workaround to this problem that I have not considered. The version of gnutls that I am currently constrained to work with is v1.4.1. I am reading data using gnutls_record_recv(). I am using select() to determine whether there is data available on that socket before calling gnutls_record_recv(). Internally, gnutls_record_recv() appears to be doing multiple recv calls until "enough" data is read. If a network disconnect happens in between recv calls in such a way that the os cannot determine that the connection is disconnected, then the recv call blocks. This currently hangs my software. I have a potential workaround I am looking at involving writing my own pull function, but I am not particularly happy with it. Any suggestions? -- Michael Welsh Duggan (mwd at cert.org) From nmav at gnutls.org Sat Oct 10 10:01:24 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 10 Oct 2009 11:01:24 +0300 Subject: Handling network disconnects during read In-Reply-To: References: Message-ID: <4AD03F54.8000109@gnutls.org> Michael Welsh Duggan wrote: > I've been encountering a problem using gnutls_record_recv() using old > versions of gnutls, and I want to find out if a) current versions are > not subject to this problem, or b) there is a decent workaround to this > problem that I have not considered. The version of gnutls that I am > currently constrained to work with is v1.4.1. > I am reading data using gnutls_record_recv(). I am using select() to > determine whether there is data available on that socket before calling > gnutls_record_recv(). Internally, gnutls_record_recv() appears to be > doing multiple recv calls until "enough" data is read. If a network > disconnect happens in between recv calls in such a way that the os > cannot determine that the connection is disconnected, then the recv > call blocks. This currently hangs my software. Hello, Unfortunately this problem cannot be solved unless you use non blocking sockets. The usage of select() with gnutls functions has this side-effect since select only tells if there are data in the socket, not if they are enough for a gnutls read. > I have a potential workaround I am looking at involving writing my own > pull function, but I am not particularly happy with it. Any > suggestions? If you want to stick on blocking sockets this is the "correct" solution. regards, Nikos From tang__tong at hotmail.com Sat Oct 10 10:21:05 2009 From: tang__tong at hotmail.com (tangtong) Date: Sat, 10 Oct 2009 08:21:05 +0000 Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode Message-ID: Hi, My program is a multi-thread server(pthread) working in Solaris enviorment, For thread-safe consideration, according to the guide, I have defined the following macro and call the specific function during iniatlization: GCRY_THREAD_OPTION_PTHREAD_IMPL; gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); Scenario1: Launch Tls session one after another to guarantee there is no concurrency existing between tls session, there is no memory leak reported by MDB; Scenario2: Launch TLS session concurrently, e.g., 50 TPS, memory leaks are reported by MDB > ::findleaks CACHE LEAKED BUFCTL CALLER 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 0020dc08 100 013aa000 libgcrypt.so.11`do_malloc+0x54 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 529 buffers, 325752 bytes I have disabled the session reusage and deinit tls sessions structure with gnutls_deinit(). Anybody can give me some tips on this issue? Regards Tony _________________________________________________________________ Messenger??????????????????Messenger??? http://im.live.cn/safe/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tang__tong at hotmail.com Mon Oct 12 07:56:34 2009 From: tang__tong at hotmail.com (tangtong) Date: Mon, 12 Oct 2009 05:56:34 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: I have redone my test and go through the memory leak points, I get the following info: > ::findleaks CACHE LEAKED BUFCTL CALLER 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 33122 buffers, 21130336 bytes > 007f53b0$ ::findleaks CACHE LEAKED BUFCTL CALLER 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 0020dc08 100 013aa000 libgcrypt.so.11`do_malloc+0x54 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 529 buffers, 325752 bytes I have disabled the session reusage and deinit tls sessions structure with gnutls_deinit(). Anybody can give me some tips on this issue? Regards Tony ????? Windows Live Messenger ???????? ????? _________________________________________________________________ Messenger??????????????????Messenger??? http://im.live.cn/safe/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tang__tong at hotmail.com Mon Oct 12 08:29:09 2009 From: tang__tong at hotmail.com (tangtong) Date: Mon, 12 Oct 2009 06:29:09 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Some more info for issue investigation: 1)I define my own push/pull function for transport; gnutls_transport_set_pull_function(session,pullFunc); gnutls_transport_set_push_function(session,pushFunc); 2)To support server name extension, I define the certificate call back func for credential: gnutls_certificate_server_set_retrieve_function(_x509Cred,certRequestCallBack); In certRequestCallBack(): st->deinit_all = 0;//I think all cert/key information are shared by all session, so should not be released According to my understanding, all memory allocated in handshake for a session will be released in gnutls_deinit(session). right? Regards Tony From: tang__tong at hotmail.com To: help-gnutls at gnu.org Date: Mon, 12 Oct 2009 05:56:34 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode I have redone my test and go through the memory leak points, I get the following info: > ::findleaks CACHE LEAKED BUFCTL CALLER 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 33122 buffers, 21130336 bytes > 007f53b0$ ::findleaks CACHE LEAKED BUFCTL CALLER 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 0020dc08 100 013aa000 libgcrypt.so.11`do_malloc+0x54 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 529 buffers, 325752 bytes I have disabled the session reusage and deinit tls sessions structure with gnutls_deinit(). Anybody can give me some tips on this issue? Regards Tony ????? Windows Live Messenger ???????? ????? ????? Windows Live Messenger ???????? ????? _________________________________________________________________ Messenger??????????????????Messenger??? http://im.live.cn/safe/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwd at cert.org Mon Oct 12 20:32:20 2009 From: mwd at cert.org (Michael Welsh Duggan) Date: Mon, 12 Oct 2009 14:32:20 -0400 Subject: How do I create a PKCS#12 file in certtool 2.8.[34]? Message-ID: After an update of GnuTLS, we are no longer able to use certtool to create PKCS#12 files. In both 2.8.3 on a Mac, and 2.8.4 under Linux, I get the following error: md5i at maru:~/projects/git/netsa/silk/src/sendrcv/tests$ certtool --load-certificate /tmp/cert.pem --load-privkey key1.pem --to-p12 --outder --outfile /tmp/foo.p12 Generating a PKCS #12 structure... Loading certificate list... Loaded 1 certificates. Enter a name for the key: Foo Enter password: |<1>| Cannot find OID: 1.2.840.113549.1.9.21 certtool: bag_encrypt: The OID is not supported. Any ideas how we can work around this problem? -- Michael Welsh Duggan (mwd at cert.org) From tang__tong at hotmail.com Tue Oct 13 11:48:29 2009 From: tang__tong at hotmail.com (tangtong) Date: Tue, 13 Oct 2009 09:48:29 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi, I have checked the source codes of gnutls, in _gnutls_handshake_hash_init(), which will be called by gnutls_hand_shake, both "session->internals.handshake_mac_handle_md5" and "session->internals.handshake_mac_handle_sha" will be initalized by _gnutls_hash_init(), What confuse me is why only _gnutls_hash_init() for MD5 will trigger memory leak, seems under some situation, only sha related resource of a session allocated by _gnutls_hash_init() is released. Would anybody give me some advice on this dilema? Regards Tony From: tang__tong at hotmail.com To: help-gnutls at gnu.org Date: Mon, 12 Oct 2009 06:29:09 +0000 Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode Some more info for issue investigation: 1)I define my own push/pull function for transport; gnutls_transport_set_pull_function(session,pullFunc); gnutls_transport_set_push_function(session,pushFunc); 2)To support server name extension, I define the certificate call back func for credential: gnutls_certificate_server_set_retrieve_function(_x509Cred,certRequestCallBack); In certRequestCallBack(): st->deinit_all = 0;//I think all cert/key information are shared by all session, so should not be released According to my understanding, all memory allocated in handshake for a session will be released in gnutls_deinit(session). right? Regards Tony From: tang__tong at hotmail.com To: help-gnutls at gnu.org Date: Mon, 12 Oct 2009 05:56:34 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode I have redone my test and go through the memory leak points, I get the following info: > ::findleaks CACHE LEAKED BUFCTL CALLER 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 33122 buffers, 21130336 bytes > 007f53b0$ ::findleaks CACHE LEAKED BUFCTL CALLER 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 0020dc08 100 013aa000 libgcrypt.so.11`do_malloc+0x54 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 ---------------------------------------------------------------------- Total 529 buffers, 325752 bytes I have disabled the session reusage and deinit tls sessions structure with gnutls_deinit(). Anybody can give me some tips on this issue? Regards Tony ????? Windows Live Messenger ???????? ????? ????? Windows Live Messenger ???????? ????? ????? Windows Live Messenger ???????? ????? _________________________________________________________________ MSN????????MSN??????????? http://10.msn.com.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Oct 13 15:56:42 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Oct 2009 16:56:42 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi, thanks for the investigation. >From the following trace: libgcrypt.so.11`md_enable+0xfc libgcrypt.so.11`md_open+0xfc I suppose that this leak occurs in libgcrypt md_enable() in md.c. I cannot figure out where exactly though. I CC the gcrypt-devel list for more insight. best regards, Nikos 2009/10/12 tangtong : > I have redone my test and go through the memory leak points, I get the > following info: >> ::findleaks > CACHE LEAKED BUFCTL CALLER > 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 > 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 > 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 > ---------------------------------------------------------------------- > To! tal 33122 buffers, 21130336 bytes > >> 007f53b0$ 0x7f53b0: next addr slab > 0 7f3700 21aa50 > 0x7f53bc: cache timestamp thread > 20b188 738886035200566511 &nb! sp; > 0x7f53cc: lastlog contents stackdepth > 1d8000 0 15 > libumem.so.1`umem_cache_alloc+0x208 > libumem.so.1`umem_alloc+0x44 > libumem.so.1`malloc+0x2c > libgcrypt.so.11`do_malloc+0x54 > &nbs! p; libgcrypt.so.11`_gcry_malloc+0x10 > libgcrypt.so.11`md_enable+0xfc > libgcrypt.so.11`md_open+0xfc > libgcrypt.so.11`_gcry_md_open+0x4c > libgnutls.so.26`wrap_gcry_hash_init+0x60 > libgnutls.so.26`_gnutls_hash_init+0x78 > libgnutls.so.26`gnutls_handshake+0xe8 > libUE.so`_ZN12SSLSETDriver9onRec! eiveEv+0x268 > libUE.so`_ZN12InTaskRunner3runEv+0x118 > libclassutil.so`_ZN7MThread7routineEv+0x28 > libclassutil.so`_ZN7MThread10thrRoutineEPv+0x1c > > All other leaks points also show the same clues: memory leaks happen during > the gnutls_handshake. > > For the report of MDB, total 21130336 bytes memory leaks are observed. I > have launched 167201 session in 3344 seconds. > > Anybody can give me some helps? If I am not using gnutls in the proper > way??? > > Regards > Tony > > ________________________________ > From: tang__tong at hotmail.com > To: help-gnutls at gnu.org > Date: Sat, 10 Oct 2009 08:21:05 +0000 > Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode > > Hi, > My program is a multi-thread server(pthread) working in Solaris enviorment, > For thread-safe consideration, according to the guide, I have defined the > following macro and call the specific function during iniatlization: > GCRY_THREAD_OPTION_PTHREAD_IMPL; > gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); > > Scenario1: > Launch Tls session one after another to guarantee there is no concurrency > existing between tls session, there is no memory leak reported by MDB; > > > Scenario2: > Launch TLS session concurrently, e.g., 50 TPS, memory leaks are reported by > MDB > >> ::findleaks > CACHE LEAKED BUFCTL CALLER > 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 > 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 > 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 > 0020dc08&n! bsp; 100 013aa000 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 > 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 > 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 > 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 > ---------------------------------------------------------------------- > Total 529 buffers, 325752 bytes > > I have disabled the session reusage and deinit tls sessions structure with > gnutls_deinit(). > > Anybody can give me some tips on this issue? > > Regards > Tony > > > > > > > > > > > > ________________________________ > ????? Windows Live Messenger ???????? ????? > ________________________________ > ????? Windows Live Messenger ???????? ????? > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > From simon at josefsson.org Wed Oct 14 11:49:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 14 Oct 2009 11:49:03 +0200 Subject: Instructions "8.4.1 Setting Up a Test HTTPS Server In-Reply-To: <86B4390CC1325D4AA265F8EB64477E5A6BC18E03F0@EPASTS.bank.lv> (Ivars Suba's message of "Wed, 14 Oct 2009 12:29:40 +0300") References: <86B4390CC1325D4AA265F8EB64477E5A6BC18E03F0@EPASTS.bank.lv> Message-ID: <87d44qqp9s.fsf@mocca.josefsson.org> Ivars Suba writes: > Hello Simon! > > You have incorrect instructions to create pkcs#12 files *.p12. > In such way created *.p12 files wouldn't be accepted by browser (FireFox, IE etc.). You need complement certtool with --load-ca-certificate key: > > > certtool --to-p12 --load-ca-certificate x509-ca.pem --load-privkey x509-client-key.pem --load-certificate x509-client.pem --outder --outfile x509-client.p12 > In such way created *.p12 files will be accepted by any browser. I have updated the documentation like this: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=d1b5f97940fe09e3e2baf7da3b4968f7e53be034 Thanks, /Simon > Cheers, > Ivars > > > > > > ________________________________ > > ?? e-pasta v?stule paredz?ta nor?d?tajam adres?tam. T? var satur?t konfidenci?lu inform?ciju, un t?s satura piln?ga vai da??ja nesankcion?ta izpau?ana, izmanto?ana vai t?l?ka izplat??ana jebk?d? veid? ir aizliegta. Ja ?? v?stule sa?emta k??das d??, l?dzam sazin?ties ar s?t?t?ju, nos?tot atbildes e-pasta v?stuli, un izdz?st ?o v?stuli. > > E-pasta v?stules netiek pak?autas t?d?m p?rbaudes proced?r?m k? sarakste pap?ra dokumenta veid?. T?p?c ?? e-pasta v?stule nerada nek?das saist?bas Latvijas Bankai. > > This e-mail is intended for the addressee(s) named above. It may contain confidential information, and any unauthorised disclosure, use or dissemination, either in whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete this e-mail from your system. > > Communications by e-mail are not subject to the same verification procedures as paper-based communications, therefore this e-mail is in no way whatsoever binding on the Bank of Latvia. From simon at josefsson.org Wed Oct 14 16:19:10 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 14 Oct 2009 16:19:10 +0200 Subject: How do I create a PKCS#12 file in certtool 2.8.[34]? In-Reply-To: (Michael Welsh Duggan's message of "Mon, 12 Oct 2009 14:32:20 -0400") References: Message-ID: <874oq2hxcx.fsf@mocca.josefsson.org> Michael Welsh Duggan writes: > After an update of GnuTLS, we are no longer able to use certtool to > create PKCS#12 files. In both 2.8.3 on a Mac, and 2.8.4 under Linux, I > get the following error: > > md5i at maru:~/projects/git/netsa/silk/src/sendrcv/tests$ certtool --load-certificate /tmp/cert.pem --load-privkey key1.pem --to-p12 --outder --outfile /tmp/foo.p12 > Generating a PKCS #12 structure... > Loading certificate list... > Loaded 1 certificates. > Enter a name for the key: Foo > Enter password: > |<1>| Cannot find OID: 1.2.840.113549.1.9.21 > certtool: bag_encrypt: The OID is not supported. I can reproduce it. > Any ideas how we can work around this problem? http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=9eba9e651a08dc69cafffad162d21a0ccb5c4dc3 This was introduced in http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=781d1aefa1df6c18f75e582ec9e278d55b6cccd1 So possibly other similar problems are lurking. /Simon From simon at josefsson.org Wed Oct 14 17:17:50 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 14 Oct 2009 17:17:50 +0200 Subject: How do I create a PKCS#12 file in certtool 2.8.[34]? In-Reply-To: <874oq2hxcx.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 14 Oct 2009 16:19:10 +0200") References: <874oq2hxcx.fsf@mocca.josefsson.org> Message-ID: <87ocoagg2p.fsf@mocca.josefsson.org> FYI, I added a self-test to make sure that PKCS#12 encoding is tested in future releases: http://git.savannah.gnu.org/cgit/gnutls.git/tree/tests/pkcs12_encode.c /Simon From tang__tong at hotmail.com Fri Oct 16 08:35:13 2009 From: tang__tong at hotmail.com (tangtong) Date: Fri, 16 Oct 2009 06:35:13 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi,Nikos and Simon To verify the issue, I have configured my server to run as signle thread mode. Under high TPS, the memory leak still happen in gnutls_handshake, which means the root-cause is not caused by multi-thread. By more logs and analysis, I have the following findings: Under high TPS, my server can't serve every session timely, which leads to the closure of the sockets by the clients for timeout reason. The write operation on the server side of the corresponding socket leads to broken pipe error. gnutls_handshake() reports GNUTLS_E_PUSH_ERROR, -53. As a result, the hand-shake stage of tls session is not finished successfully. After repeated testing, It is evident when aborted tls session caused by error -53 are observed, the memory leak happen. I have double check my codes, for these aborted session, I have called the gnutls_bye()/gnutls_deinit() function. My assumption now is for those session which has unfinished hand-shake stage, the resourses are not released properly in gnutls_handshake() for some reason. What's your opinion? Regards Tony > Date: Tue, 13 Oct 2009 16:56:42 +0300 > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: help-gnutls at gnu.org; gcrypt-devel at gnupg.org > > Hi, > thanks for the investigation. > From the following trace: > libgcrypt.so.11`md_enable+0xfc > libgcrypt.so.11`md_open+0xfc > > I suppose that this leak occurs in libgcrypt md_enable() in md.c. I > cannot figure out where exactly though. I CC the gcrypt-devel list for > more insight. > > best regards, > Nikos > > 2009/10/12 tangtong : > > I have redone my test and go through the memory leak points, I get the > > following info: > >> ::findleaks > > CACHE LEAKED BUFCTL CALLER > > 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 > > 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 > > 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 > > ---------------------------------------------------------------------- > > To! tal 33122 buffers, 21130336 bytes > > > >> 007f53b0$ > 0x7f53b0: next addr slab > > 0 7f3700 21aa50 > > 0x7f53bc: cache timestamp thread > > 20b188 738886035200566511 &nb! sp; > > 0x7f53cc: lastlog contents stackdepth > > 1d8000 0 15 > > libumem.so.1`umem_cache_alloc+0x208 > > libumem.so.1`umem_alloc+0x44 > > libumem.so.1`malloc+0x2c > > libgcrypt.so.11`do_malloc+0x54 > > &nbs! p; libgcrypt.so.11`_gcry_malloc+0x10 > > libgcrypt.so.11`md_enable+0xfc > > libgcrypt.so.11`md_open+0xfc > > libgcrypt.so.11`_gcry_md_open+0x4c > > libgnutls.so.26`wrap_gcry_hash_init+0x60 > > libgnutls.so.26`_gnutls_hash_init+0x78 > > libgnutls.so.26`gnutls_handshake+0xe8 > > libUE.so`_ZN12SSLSETDriver9onRec! eiveEv+0x268 > > libUE.so`_ZN12InTaskRunner3runEv+0x118 > > libclassutil.so`_ZN7MThread7routineEv+0x28 > > libclassutil.so`_ZN7MThread10thrRoutineEPv+0x1c > > > > All other leaks points also show the same clues: memory leaks happen during > > the gnutls_handshake. > > > > For the report of MDB, total 21130336 bytes memory leaks are observed. I > > have launched 167201 session in 3344 seconds. > > > > Anybody can give me some helps? If I am not using gnutls in the proper > > way??? > > > > Regards > > Tony > > > > ________________________________ > > From: tang__tong at hotmail.com > > To: help-gnutls at gnu.org > > Date: Sat, 10 Oct 2009 08:21:05 +0000 > > Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode > > > > Hi, > > My program is a multi-thread server(pthread) working in Solaris enviorment, > > For thread-safe consideration, according to the guide, I have defined the > > following macro and call the specific function during iniatlization: > > GCRY_THREAD_OPTION_PTHREAD_IMPL; > > gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); > > > > Scenario1: > > Launch Tls session one after another to guarantee there is no concurrency > > existing between tls session, there is no memory leak reported by MDB; > > > > > > Scenario2: > > Launch TLS session concurrently, e.g., 50 TPS, memory leaks are reported by > > MDB > > > >> ::findleaks > > CACHE LEAKED BUFCTL CALLER > > 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 > > 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 > > 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08&n! bsp; 100 013aa000 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 > > 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 > > 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 > > 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 > > ---------------------------------------------------------------------- > > Total 529 buffers, 325752 bytes > > > > I have disabled the session reusage and deinit tls sessions structure with > > gnutls_deinit(). > > > > Anybody can give me some tips on this issue? > > > > Regards > > Tony > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > ????? Windows Live Messenger ???????? ????? > > ________________________________ > > ????? Windows Live Messenger ???????? ????? > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > _________________________________________________________________ ?Windows Live ??????????Messenger? http://www.windowslive.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Oct 16 09:00:08 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 16 Oct 2009 09:00:08 +0200 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: (tangtong's message of "Fri, 16 Oct 2009 06:35:13 +0000") References: Message-ID: <87d44nygav.fsf@mocca.josefsson.org> (dropping libgcrypt-devel because this appears non-libgcrypt related after all) tangtong writes: > Hi,Nikos and Simon > > To verify the issue, I have configured my server to run as signle thread mode. Under high TPS, the memory leak still happen in gnutls_handshake, which means the root-cause is not caused by multi-thread. > > By more logs and analysis, I have the following findings: > Under high TPS, my server can't serve every session timely, which leads to the closure of the sockets by the clients for timeout reason. The write operation on the server side of the corresponding socket leads to broken pipe error. gnutls_handshake() reports GNUTLS_E_PUSH_ERROR, -53. As a result, the hand-shake stage of tls session is not finished successfully. Maybe that suggests a separate problem -- do you specify your own push/pull functions? Do they fail? > After repeated testing, It is evident when aborted tls session caused by error -53 are observed, the memory leak happen. > > I have double check my codes, for these aborted session, I have called the gnutls_bye()/gnutls_deinit() function. > > My assumption now is for those session which has unfinished hand-shake stage, the resourses are not released properly in gnutls_handshake() for some reason. > > What's your opinion? That seems plausible, we have only tried to fix memory leaks which we have noticed. Please provide a small standalone test code that reproduce your problem, and it should be possible to fix it. Look at tests/mini.c, it may be useful as a starting point. /Simon > Regards > Tony > > >> Date: Tue, 13 Oct 2009 16:56:42 +0300 >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode >> From: nmav at gnutls.org >> To: tang__tong at hotmail.com >> CC: help-gnutls at gnu.org; gcrypt-devel at gnupg.org >> >> Hi, >> thanks for the investigation. >> From the following trace: >> libgcrypt.so.11`md_enable+0xfc >> libgcrypt.so.11`md_open+0xfc >> >> I suppose that this leak occurs in libgcrypt md_enable() in md.c. I >> cannot figure out where exactly though. I CC the gcrypt-devel list for >> more insight. >> >> best regards, >> Nikos >> >> 2009/10/12 tangtong : >> > I have redone my test and go through the memory leak points, I get the >> > following info: >> >> ::findleaks >> > CACHE LEAKED BUFCTL CALLER >> > 00204e08 1 004ab7e8 libclntsh.so.10.1`sigpnm+0x80 >> > 0020b188 7816 007f53b0 libgcrypt.so.11`do_malloc+0x54 >> > 0020ae08 106 0130e960 libgcrypt.so.11`do_malloc+0x54 >> > 0020dc08 1 00c0cd98 libgcrypt.so.11`do_malloc+0x54 >> > 0020dc08 63 008a5e78 libgcrypt.so.11`do_malloc+0x54 >> > 0020ae08 8153 0043f518 libgcrypt.so.11`do_malloc+0x54 >> > 0020b188 422 01046168 libgcrypt.so.11`do_malloc+0x54 >> > 0020dc08 8330 00b3d860 libgcrypt.so.11`do_malloc+0x54 >> > 0020dc08 8230 01206438 libgcrypt.so.11`do_malloc+0x54 >> > ---------------------------------------------------------------------- >> > To! tal 33122 buffers, 21130336 bytes >> > >> >> 007f53b0$> > 0x7f53b0: next addr slab >> > 0 7f3700 21aa50 >> > 0x7f53bc: cache timestamp thread >> > 20b188 738886035200566511 &nb! sp; >> > 0x7f53cc: lastlog contents stackdepth >> > 1d8000 0 15 >> > libumem.so.1`umem_cache_alloc+0x208 >> > libumem.so.1`umem_alloc+0x44 >> > libumem.so.1`malloc+0x2c >> > libgcrypt.so.11`do_malloc+0x54 >> > &nbs! p; libgcrypt.so.11`_gcry_malloc+0x10 >> > libgcrypt.so.11`md_enable+0xfc >> > libgcrypt.so.11`md_open+0xfc >> > libgcrypt.so.11`_gcry_md_open+0x4c >> > libgnutls.so.26`wrap_gcry_hash_init+0x60 >> > libgnutls.so.26`_gnutls_hash_init+0x78 >> > libgnutls.so.26`gnutls_handshake+0xe8 >> > libUE.so`_ZN12SSLSETDriver9onRec! eiveEv+0x268 >> > libUE.so`_ZN12InTaskRunner3runEv+0x118 >> > libclassutil.so`_ZN7MThread7routineEv+0x28 >> > libclassutil.so`_ZN7MThread10thrRoutineEPv+0x1c >> > >> > All other leaks points also show the same clues: memory leaks happen during >> > the gnutls_handshake. >> > >> > For the report of MDB, total 21130336 bytes memory leaks are observed. I >> > have launched 167201 session in 3344 seconds. >> > >> > Anybody can give me some helps? If I am not using gnutls in the proper >> > way??? >> > >> > Regards >> > Tony >> > >> > ________________________________ >> > From: tang__tong at hotmail.com >> > To: help-gnutls at gnu.org >> > Date: Sat, 10 Oct 2009 08:21:05 +0000 >> > Subject: Memory leaks are observed for libgcrypt.so.11 in multi-thread mode >> > >> > Hi, >> > My program is a multi-thread server(pthread) working in Solaris enviorment, >> > For thread-safe consideration, according to the guide, I have defined the >> > following macro and call the specific function during iniatlization: >> > GCRY_THREAD_OPTION_PTHREAD_IMPL; >> > gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); >> > >> > Scenario1: >> > Launch Tls session one after another to guarantee there is no concurrency >> > existing between tls session, there is no memory leak reported by MDB; >> > >> > >> > Scenario2: >> > Launch TLS session concurrently, e.g., 50 TPS, memory leaks are reported by >> > MDB >> > >> >> ::findleaks >> > CACHE LEAKED BUFCTL CALLER >> > 00204a88 17 0053b860 libUE.so`_ZN12PacketHelper12createPacketEi+0x34 >> > 0020dc08 27 00aea708 libgcrypt.so.11`do_malloc+0x54 >> > 0020b188 88 012f0b40 libgcrypt.so.11`do_malloc+0x54 >> > 0020dc08&n! bsp; 100 013aa000 libgcrypt.so.11`do_malloc+0x54 >> > 0020ae08 64 00461e00 libgcrypt.so.11`do_malloc+0x54 >> > 0020b188 39 0073a780 libgcrypt.so.11`do_malloc+0x54 >> > 0020ae08 65 016cf248 libgcrypt.so.11`do_malloc+0x54 >> > 0020dc08 129 00aea7f8 libgcrypt.so.11`do_malloc+0x54 >> > ---------------------------------------------------------------------- >> > Total 529 buffers, 325752 bytes >> > >> > I have disabled the session reusage and deinit tls sessions structure with >> > gnutls_deinit(). >> > >> > Anybody can give me some tips on this issue? >> > >> > Regards >> > Tony >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > ________________________________ >> > ????? Windows Live Messenger ???????? ????? >> > ________________________________ >> > ????? Windows Live Messenger ???????? ????? >> > _______________________________________________ >> > Help-gnutls mailing list >> > Help-gnutls at gnu.org >> > http://lists.gnu.org/mailman/listinfo/help-gnutls >> > >> > > > _________________________________________________________________ > ?Windows Live ??????????Messenger? > http://www.windowslive.cn_______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls From nmav at gnutls.org Sun Oct 18 09:32:45 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 18 Oct 2009 10:32:45 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: <4ADAC49D.6050102@gnutls.org> tangtong wrote: > Hi,Nikos and Simon > > To verify the issue, I have configured my server to run as signle thread mode. Under high TPS, the memory leak still happen in gnutls_handshake, which means the root-cause is not caused by multi-thread. > > By more logs and analysis, I have the following findings: > Under high TPS, my server can't serve every session timely, which leads to the closure of the sockets by the clients for timeout reason. The write operation on the server side of the corresponding socket leads to broken pipe error. gnutls_handshake() reports GNUTLS_E_PUSH_ERROR, -53. As a result, the hand-shake stage of tls session is not finished successfully. > > After repeated testing, It is evident when aborted tls session caused by error -53 are observed, the memory leak happen. > > I have double check my codes, for these aborted session, I have called the gnutls_bye()/gnutls_deinit() function. > > My assumption now is for those session which has unfinished hand-shake stage, the resourses are not released properly in gnutls_handshake() for some reason. Could you for this (memory leak) scenario to send us debugging output of gnutls? To do that just add a logging function such as: static void tls_log_func (int level, const char *str) { fprintf (stderr, "|<%d>| %s", level, str); } and call those after initialization of gnutls. gnutls_global_set_log_function (tls_log_func); gnutls_global_set_log_level (2); regards, Nikos From tang__tong at hotmail.com Mon Oct 19 05:11:07 2009 From: tang__tong at hotmail.com (tangtong) Date: Mon, 19 Oct 2009 03:11:07 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: <4ADAC49D.6050102@gnutls.org> References: <4ADAC49D.6050102@gnutls.org> Message-ID: Hi,Nikos The attach is the log for 8tps/20tps, both have memory-leaks. Regards Tony > Date: Sun, 18 Oct 2009 10:32:45 +0300 > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > > tangtong wrote: > > Hi,Nikos and Simon > > > > To verify the issue, I have configured my server to run as signle thread mode. Under high TPS, the memory leak still happen in gnutls_handshake, which means the root-cause is not caused by multi-thread. > > > > By more logs and analysis, I have the following findings: > > Under high TPS, my server can't serve every session timely, which leads to the closure of the sockets by the clients for timeout reason. The write operation on the server side of the corresponding socket leads to broken pipe error. gnutls_handshake() reports GNUTLS_E_PUSH_ERROR, -53. As a result, the hand-shake stage of tls session is not finished successfully. > > > > After repeated testing, It is evident when aborted tls session caused by error -53 are observed, the memory leak happen. > > > > I have double check my codes, for these aborted session, I have called the gnutls_bye()/gnutls_deinit() function. > > > > My assumption now is for those session which has unfinished hand-shake stage, the resourses are not released properly in gnutls_handshake() for some reason. > > Could you for this (memory leak) scenario to send us debugging output of > gnutls? To do that just add a logging function such as: > > static void > tls_log_func (int level, const char *str) > { > fprintf (stderr, "|<%d>| %s", level, str); > } > > and call those after initialization of gnutls. > gnutls_global_set_log_function (tls_log_func); > gnutls_global_set_log_level (2); > > > regards, > Nikos _________________________________________________________________ ?????????????????msn????? http://ditu.live.com/?form=TL&swm=1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_8tps.log.gz Type: application/x-gzip Size: 1307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_20tps.log.gz Type: application/x-gzip Size: 1958 bytes Desc: not available URL: From tang__tong at hotmail.com Mon Oct 19 05:37:18 2009 From: tang__tong at hotmail.com (tangtong) Date: Mon, 19 Oct 2009 03:37:18 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi,Nikos and Simon I find out another condition for memory leaks beside -53 error is tls sessions's handshake process are interweaven together. If the hanshake of tls sessions are finished before another session is launched,no memory leaks happen; But if the handshake of tls sessions are interlaced and at the same time -53 error is observed, the memory leaks will happen. BTW, In my program, all tls session share the same credentials. Regards Tony From: tang__tong at hotmail.com To: nmav at gnutls.org Date: Mon, 19 Oct 2009 03:11:07 +0000 CC: simon at josefsson.org; help-gnutls at gnu.org Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode Hi,Nikos The attach is the log for 8tps/20tps, both have memory-leaks. Regards Tony > Date: Sun, 18 Oct 2009 10:32:45 +0300 > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > > tangtong wrote: > > Hi,Nikos and Simon > > > > To verify the issue, I have configured my server to run as signle thread mode. Under high TPS, the memory leak still happen in gnutls_handshake, which means the root-cause is not caused by multi-thread. > > > > By more logs and analysis, I have the following findings: > > Under high TPS, my server can't serve every session timely, which leads to the closure of the sockets by the clients for timeout reason. The write operation on the server side of the corresponding socket leads to broken pipe error. gnutls_handshake() reports GNUTLS_E_PUSH_ERROR, -53. As a result, the hand-shake stage of tls session is not finished successfully. > > > > After repeated testing, It is evident when aborted tls session caused by error -53 are observed, the memory leak happen. > > > > I have double check my codes, for these aborted session, I have called the gnutls_bye()/gnutls_deinit() function. > > > > My assumption now is for those session which has unfinished hand-shake stage, the resourses are not released properly in gnutls_handshake() for some reason. > > Could you for this (memory leak) scenario to send us debugging output of > gnutls? To do that just add a logging function such as: > > static void > tls_log_func (int level, const char *str) > { > fprintf (stderr, "|<%d>| %s", level, str); > } > > and call those after initialization of gnutls. > gnutls_global_set_log_function (tls_log_func); > gnutls_global_set_log_level (2); > > > regards, > Nikos ??????????MSN??? ????? _________________________________________________________________ Messenger??????????????????Messenger??? http://im.live.cn/safe/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Oct 19 22:41:36 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Oct 2009 23:41:36 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: <4ADAC49D.6050102@gnutls.org> Message-ID: <4ADCCF00.1080304@gnutls.org> tangtong wrote: > Hi,Nikos > > The attach is the log for 8tps/20tps, both have memory-leaks. Hi Tony, Thank you for the report. I managed to reproduce the error by modifying mini-egain to fail on handshake. Could you please try the attached patch? It makes the hash functions used during handshake a bit more conservative in use and are now always released on deinit. best regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: safe_mac.patch Type: text/x-patch Size: 6564 bytes Desc: not available URL: From orbisvicis at gmail.com Tue Oct 20 00:05:06 2009 From: orbisvicis at gmail.com (Yclept Nemo) Date: Mon, 19 Oct 2009 18:05:06 -0400 Subject: chainverify fails Message-ID: just a heads-up that in 2.9.8 the chainverify test fails due to an expired certificate. Don't know which one but I set the system clock back two months (2.9.2 release date) and the test passes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Tue Oct 20 14:59:21 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 20 Oct 2009 14:59:21 +0200 Subject: chainverify fails In-Reply-To: (Yclept Nemo's message of "Mon, 19 Oct 2009 18:05:06 -0400") References: Message-ID: <87vdiagr12.fsf@mocca.josefsson.org> Yclept Nemo writes: > just a heads-up that in 2.9.8 the chainverify test fails due to an expired > certificate. Don't know which one but I set the system clock back two months > (2.9.2 release date) and the test passes. Yup, fixed already. /Simon From tang__tong at hotmail.com Wed Oct 21 08:20:43 2009 From: tang__tong at hotmail.com (tangtong) Date: Wed, 21 Oct 2009 06:20:43 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: <4ADCCF00.1080304@gnutls.org> References: <4ADAC49D.6050102@gnutls.org> <4ADCCF00.1080304@gnutls.org> Message-ID: Hi,Nikos After applying the patch, I get the following error during handshake: error number:-18 dec:An error was encountered at the TLS Finished packet calculation. My lib is based on git 2.9.4. Regards Tony > Date: Mon, 19 Oct 2009 23:41:36 +0300 > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > > tangtong wrote: > > Hi,Nikos > > > > The attach is the log for 8tps/20tps, both have memory-leaks. > > Hi Tony, > Thank you for the report. I managed to reproduce the error by modifying > mini-egain to fail on handshake. Could you please try the attached > patch? It makes the hash functions used during handshake a bit more > conservative in use and are now always released on deinit. > > > best regards, > Nikos _________________________________________________________________ ?Windows Live ??????????Messenger? http://www.windowslive.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Oct 21 23:38:14 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Oct 2009 00:38:14 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: <4ADAC49D.6050102@gnutls.org> <4ADCCF00.1080304@gnutls.org> Message-ID: <4ADF7F46.3010404@gnutls.org> tangtong wrote: > Hi,Nikos > After applying the patch, I get the following error during handshake: > error number:-18 dec:An error was encountered at the TLS Finished packet calculation. > > My lib is based on git 2.9.4. There is some issue with TLS1.2 hashes and handshake. Anyway the attached patch should fix the issue you encounter. The issue with TLS1.2 is that when a client that supports TLS1.2 tries to connect to a server that doesn't support tls1.2 he will have SHA256 initiated instead of SHA1. I made a quick and dirty fix for it. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: hash.patch Type: text/x-patch Size: 12614 bytes Desc: not available URL: From tang__tong at hotmail.com Thu Oct 22 06:46:02 2009 From: tang__tong at hotmail.com (tangtong) Date: Thu, 22 Oct 2009 04:46:02 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: <4ADF7F46.3010404@gnutls.org> References: <4ADAC49D.6050102@gnutls.org> <4ADCCF00.1080304@gnutls.org> <4ADF7F46.3010404@gnutls.org> Message-ID: Hi,Nikos I have rebuilt the lib with your patch, do the following tests: 1)Setting the client working with tls1.0, and run the testing with high TPS, the memory leaks are not observed anymore. 2)The patch doesn't support "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I think your patch disable the tls1.2 support, it will core with the following dump info: fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) + 30 feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c The memory leak issues have been resolved, Thanks very much?Would you please do me a favor to provide a patch wich support TLS1.2/SHA256? My pilot project needs it . BTW, Is there any plan for the stable release of gnutls which support TLS1.2/SHA256? Regards Tony > Date: Thu, 22 Oct 2009 00:38:14 +0300 > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > > tangtong wrote: > > Hi,Nikos > > After applying the patch, I get the following error during handshake: > > error number:-18 dec:An error was encountered at the TLS Finished packet calculation. > > > > My lib is based on git 2.9.4. > > There is some issue with TLS1.2 hashes and handshake. Anyway the > attached patch should fix the issue you encounter. > > The issue with TLS1.2 is that when a client that supports TLS1.2 tries > to connect to a server that doesn't support tls1.2 he will have SHA256 > initiated instead of SHA1. I made a quick and dirty fix for it. > > regards, > Nikos _________________________________________________________________ ????????????360??????? http://club.msn.cn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Oct 22 18:31:02 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Oct 2009 19:31:02 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: <4ADAC49D.6050102@gnutls.org> <4ADCCF00.1080304@gnutls.org> <4ADF7F46.3010404@gnutls.org> Message-ID: <4AE088C6.9080506@gnutls.org> tangtong wrote: > Hi,Nikos > 2)The patch doesn't support > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I think your > patch disable the tls1.2 support, it will core with the following dump > info: > fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) + 30 > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c Can you send me information on how I can reproduce this issue? I can use ./gnutls-cli tls.secg.org --priority "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to connect using TLS1.2 without any issues. regards, Nikos From jpettiss at yahoo.com Thu Oct 22 22:43:05 2009 From: jpettiss at yahoo.com (Jason Pettiss) Date: Thu, 22 Oct 2009 13:43:05 -0700 (PDT) Subject: Initializing gcrypt in gnutls4win? Message-ID: <492787.47695.qm@web110214.mail.gq1.yahoo.com> Thanks to GnuTLS for Windows I was able to convert an existing application to use TLS in about 30 minutes. Yay for that. Everything works fine until I make two connections at the same time (from different threads), where gcrypt asserts on me, complaining of mutex state. Does GnuTLS for Windows perform the gcry_control(GCRYCTL_SET_THREAD_CBS, ...) operation for me, or is that still my application's responsibility? If I need to do that, anyone have any pointers on how to accomplish that? Every time I think I've got the answer, I find I need to download and build yet another peripheral library, most of those of course not quite Windows-friendly. Thanks for any tips, Jason Pettiss jpettiss at yahoo.com From tang__tong at hotmail.com Fri Oct 23 09:20:49 2009 From: tang__tong at hotmail.com (tangtong) Date: Fri, 23 Oct 2009 07:20:49 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: <4AE088C6.9080506@gnutls.org> References: <4ADAC49D.6050102@gnutls.org> <4ADCCF00.1080304@gnutls.org> <4ADF7F46.3010404@gnutls.org> <4AE088C6.9080506@gnutls.org> Message-ID: Hi,Nikos The gnutls-cli built by me will core when I enable TLS1.2. I think the code base I use is a little diffent from what you are using. The following is my steps to setup the build enviorment: 1)Download a gnutls releaes package 2.8.3 and decompress it; 2)Download 2.9.4 snap shot and uncompress it to the directory created in the step 1); 3)Run patch you provide. Seems only snapshot of 2.9.4 is not the whole build env, that's why i decompress it to a build enviorment of 2.8.3. Regards Tony > Date: Thu, 22 Oct 2009 19:31:02 +0300 > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > > tangtong wrote: > > Hi,Nikos > > > 2)The patch doesn't support > > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I think your > > patch disable the tls1.2 support, it will core with the following dump > > info: > > fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 > > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 > > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 > > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 > > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) + 30 > > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 > > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 > > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c > > Can you send me information on how I can reproduce this issue? I can use > ./gnutls-cli tls.secg.org --priority > "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to > connect using TLS1.2 without any issues. > > regards, > Nikos _________________________________________________________________ ?? Windows 7???????? PC?????? http://www.microsoft.com/china/windows/buy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Oct 23 09:38:20 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 23 Oct 2009 10:38:20 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: <4ADAC49D.6050102@gnutls.org> <4ADCCF00.1080304@gnutls.org> <4ADF7F46.3010404@gnutls.org> <4AE088C6.9080506@gnutls.org> Message-ID: Thanks. However in order to reproduce it I need to know to which server you connect to and which options does this server use? 2009/10/23 tangtong : > Hi,Nikos > > The gnutls-cli built by me will core when I enable TLS1.2. I think the code > base I use is a little diffent from what you are using. The following is my > steps to setup the build enviorment: > 1)Download a gnutls releaes package 2.8.3 and decompress it; > 2)Download 2.9.4 snap shot and uncompress it to the directory created in the > step 1); > 3)Run patch you provide. > > Seems only snapshot of 2.9.4 is not the whole build env, that's why i > decompress it to a build enviorment of 2.8.3. > > Regards > Tony > > > > > > > > >> Date: Thu, 22 Oct 2009 19:31:02 +0300 >> From: nmav at gnutls.org >> To: tang__tong at hotmail.com >> CC: simon at josefsson.org; help-gnutls at gnu.org >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode >> >> tangtong wrote: >> > Hi,Nikos >> >> > 2)The patch doesn't support >> > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I t! hink your >> > patch disable the tls1.2 support, it will core with the following dump >> > info: >> > fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 >> > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 >> > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 >> > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 >> > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) >> > + 30 >> > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 >> > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 >> > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c >> >> Can you send me information on how I can reproduce this issue? I can use >> ./gnutls-cli tls.secg.org --priority >> "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to >> connect using TLS1.2 without any issues.> >> regards, >> Nikos > > ________________________________ > ?? Windows 7???????? PC? ????? From tang__tong at hotmail.com Fri Oct 23 16:28:50 2009 From: tang__tong at hotmail.com (tangtong) Date: Fri, 23 Oct 2009 14:28:50 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi,Nikos The server is implemented by myself with gnutls2.9.4 and your patch. To make investigation easy, I will build a simplified server based on gnutls demo server codes and let you know the results later. Regards Tony > Date: Fri, 23 Oct 2009 10:38:20 +0300 > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > > Thanks. However in order to reproduce it I need to know to which > server you connect to and which options does this server use? > > 2009/10/23 tangtong : > > Hi,Nikos > > > > The gnutls-cli built by me will core when I enable TLS1.2. I think the code > > base I use is a little diffent from what you are using. The following is my > > steps to setup the build enviorment: > > 1)Download a gnutls releaes package 2.8.3 and decompress it; > > 2)Download 2.9.4 snap shot and uncompress it to the directory created in the > > step 1); > > 3)Run patch you provide. > > > > Seems only snapshot of 2.9.4 is not the whole build env, that's why i > > decompress it to a build enviorment of 2.8.3. > > > > Regards > > Tony > > > > > > > > > > > > > > > > > >> Date: Thu, 22 Oct 2009 19:31:02 +0300 > >> From: nmav at gnutls.org > >> To: tang__tong at hotmail.com > >> CC: simon at josefsson.org; help-gnutls at gnu.org > >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > >> > >> tangtong wrote: > >> > Hi,Nikos > >> > >> > 2)The patch doesn't support > >> > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I t! hink your > >> > patch disable the tls1.2 support, it will core with the following dump > >> > info: > >> > fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 > >> > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 > >> > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 > >> > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 > >> > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) > >> > + 30 > >> > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 > >> > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 > >> > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c > >> > >> Can you send me information on how I can reproduce this issue? I can use > >> ./gnutls-cli tls.secg.org --priority > >> "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to > >> connect using TLS1.2 without any issues.> > >> regards, > >> Nikos > > > > ________________________________ > > ?? Windows 7???????? PC? ????? _________________________________________________________________ MSN????????MSN??????????? http://10.msn.com.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpettiss at yahoo.com Fri Oct 23 18:40:42 2009 From: jpettiss at yahoo.com (Jason Pettiss) Date: Fri, 23 Oct 2009 09:40:42 -0700 (PDT) Subject: Initializing gcrypt on GnuTLS4Win? Message-ID: <604756.97443.qm@web110217.mail.gq1.yahoo.com> Thanks to GnuTLS for Windows I was able to convert an existing application to use TLS in about 30 minutes. Yay for that. Everything works fine until I make two connections at the same time (from different threads), where gcrypt asserts on me, complaining of mutex state. Does GnuTLS for Windows perform the gcry_control(GCRYCTL_SET_THREAD_CBS, ...) operation for me, or is that still my application's responsibility? If I need to do that, anyone have any pointers on how to accomplish that? Every time I think I've got the answer, I find I need to download and build yet another peripheral library, most of those of course not quite Windows-friendly. Thanks for any tips, Jason Pettiss jpettiss at yahoo.com From nmav at gnutls.org Fri Oct 23 18:41:53 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 23 Oct 2009 19:41:53 +0300 Subject: Initializing gcrypt in gnutls4win? In-Reply-To: <492787.47695.qm@web110214.mail.gq1.yahoo.com> References: <492787.47695.qm@web110214.mail.gq1.yahoo.com> Message-ID: <4AE1DCD1.5050904@gnutls.org> Jason Pettiss wrote: > Thanks to GnuTLS for Windows I was able to convert an existing application to use TLS in about 30 minutes. Yay for that. Everything works fine until I make two connections at the same time (from different threads), where gcrypt asserts on me, complaining of mutex state. > > Does GnuTLS for Windows perform the gcry_control(GCRYCTL_SET_THREAD_CBS, ...) operation for me, or is that still my application's responsibility? If I need to do that, anyone have any pointers on how to accomplish that? I believe you have to set your own lock functions and call the gcry_control. regards, Nikos From simon at josefsson.org Fri Oct 23 18:43:56 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 23 Oct 2009 18:43:56 +0200 Subject: Initializing gcrypt in gnutls4win? In-Reply-To: <492787.47695.qm@web110214.mail.gq1.yahoo.com> (Jason Pettiss's message of "Thu, 22 Oct 2009 13:43:05 -0700 (PDT)") References: <492787.47695.qm@web110214.mail.gq1.yahoo.com> Message-ID: <87aazi2h83.fsf@mocca.josefsson.org> Jason Pettiss writes: > Thanks to GnuTLS for Windows I was able to convert an existing application to use TLS in about 30 minutes. Yay for that. Everything works fine until I make two connections at the same time (from different threads), where gcrypt asserts on me, complaining of mutex state. > > Does GnuTLS for Windows perform the gcry_control(GCRYCTL_SET_THREAD_CBS, ...) operation for me, No. It doesn't under Unix either. > or is that still my application's responsibility? Yes. > If I need to do that, anyone have any pointers on how to accomplish > that? Try asking on libgcrypt's mailing list, it seems to be a general question for all applications using libgcrypt on Windows. I don't know the answer... > Every time I think I've got the answer, I find I need to download and > build yet another peripheral library, most of those of course not > quite Windows-friendly. I know the feeling. :-( /Simon From michael at weiser.dinsnail.net Fri Oct 23 20:07:12 2009 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Fri, 23 Oct 2009 20:07:12 +0200 Subject: {Spam?} Re: loading psk credentials from encrypted file In-Reply-To: <20081222225504.GA1100@weiser.dinsnail.net> References: <20081222225504.GA1100@weiser.dinsnail.net> Message-ID: <20091023180712.GA89714@weiser.dinsnail.net> Hello, almost a year ago I asked the question below about putting PSK keys into an encrypted file. I had a look at how to do it using a block cipher directly. After seeing, what this entailed, and considering my crypto knowledge, I was sure, I couldn't do this correctly. So I put the project aside. A few days ago I had an idea though: Why not abuse the PKCS12 functions to save the datum_t holding the PSK key out in an encrypted PKCS12 structure? The code looks as shown below (without the error checking for readability). It works fine, but my questions are: - Is this at all sensible or (will it break|is it braindead|other reason for never ever doing it)? - Is my PSK key secure this way or do I have an inherent security hole somewhere? - Can I use something stronger than RC4-128 for encryption? - Can I have my own bag type GNUTLS_BAG_PSK_KEY so I don't need to abuse GNUTLS_BAG_CERTIFICATE? ;) Or should/can I use GNUTLS_BAG_ENCRYPTED for generic encrypted data? - Or is there some similar interface I might abuse which supports stronger encryption or generic data content? (And yes: I save a randomly generated key that way, not one derived from a password.) Thanks! Micha Saving the key in key_datum: gnutls_pkcs12_bag_init(&bag); gnutls_pkcs12_bag_set_data(bag, GNUTLS_BAG_CERTIFICATE, &key_datum); pkcs12_password = getpass("Verify Passphrase: "); gnutls_pkcs12_bag_encrypt(bag, pkcs12_password, GNUTLS_PKCS_USE_PKCS12_ARCFOUR); gnutls_pkcs12_init(&pkcs12); gnutls_pkcs12_set_bag(pkcs12, bag); gnutls_pkcs12_generate_mac(pkcs12, pkcs12_password); memset(pkcs12_password, 0x0, strlen(pkcs12_password)); pkcs12_struct_size = sizeof(pkcs12_struct); gnutls_pkcs12_export(pkcs12, GNUTLS_X509_FMT_PEM, pkcs12_struct, &pkcs12_struct_size); fd = open(psk_outfile, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR); write(fd, pkcs12_struct, pkcs12_struct_size); close(fd); Loading the key into key_datum: pkcs12_datum.size = 1024 * 10; pkcs12_datum.data = malloc(pkcs12_datum.size); fd = open(keyfile, O_RDONLY); pkcs12_datum.size = read(fd, pkcs12_datum.data, pkcs12_datum.size); close(fd); gnutls_pkcs12_init(&pkcs12); gnutls_pkcs12_import(pkcs12, &pkcs12_datum, GNUTLS_X509_FMT_PEM, 0); free(pkcs12_datum.data); do { passphrase = getpass("Passphrase: "); } while (gnutls_pkcs12_verify_mac(pkcs12, passphrase) < 0); gnutls_pkcs12_bag_init(&bag); gnutls_pkcs12_get_bag(pkcs12, 0, bag); gnutls_pkcs12_bag_decrypt(bag, passphrase); memset(passphrase, 0x0, strlen(passphrase)); gnutls_pkcs12_bag_get_data(bag, 0, &key_datum); On Mon, Dec 22, 2008 at 11:55:04PM +0100, Michael Weiser wrote: > I've written a small program that uses gnutls for authentication. I've > chosen to use PSK authentication because it is simple to implement (no > certificate checking and the like) and fits my use case well (single > user). Now I've got a small usability problem: > On the client side I have to enter a password to derive the PSK key > from. Whether I've entered it correctly or not can only be determined by > trying a handshake. With my application this can be some time after I've > entered the password and can be confused with connectivity and other > problems on the network or server side. > So I'd like to enter the password just once, derive the PSK key from it > and store it in an AES-encrypted file. When starting my client > application, it would then ask for the passphrase of that file and could > immediately determine if the file can be decrypted using that key. This > way it can produce a proper error message or just ask for the passphrase > again. > (This would be analogous to using an encrypted RSA private key for X509 > authentication and being asked for its passphrase.) > Is this directly supported by gnutls? > How would I best go about implementing it? > Is this a case for enhancing gnutls or should I rather implement the > neccessary logic in my application? -- bye, Michael I hate forms! From nmav at gnutls.org Sat Oct 24 03:34:55 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 24 Oct 2009 04:34:55 +0300 Subject: {Spam?} Re: loading psk credentials from encrypted file In-Reply-To: <20091023180712.GA89714@weiser.dinsnail.net> References: <20081222225504.GA1100@weiser.dinsnail.net> <20091023180712.GA89714@weiser.dinsnail.net> Message-ID: <4AE259BF.4070808@gnutls.org> Michael Weiser wrote: > A few days ago I had an idea though: Why not abuse the PKCS12 functions > to save the datum_t holding the PSK key out in an encrypted PKCS12 > structure? What are the reasons for doing that? Is it for distributing the actual key to clients? For protecting the whole password file maybe pkcs-12 is too much, and saving the password file into an encrypted partition might be simpler. > The code looks as shown below (without the error checking for > readability). It works fine, but my questions are: > > - Is this at all sensible or (will it break|is it braindead|other > reason for never ever doing it)? I don't like pkcs-12 due to it's complexity, but nevertheless there is nothing (else) wrong with it and pretty much seems to fit here. > - Is my PSK key secure this way or do I have an inherent security hole > somewhere? Depends on how is it going to be used. > - Can I use something stronger than RC4-128 for encryption? I believe PKCS-12 supports 3DES as well. > - Can I have my own bag type GNUTLS_BAG_PSK_KEY so I don't need to abuse > GNUTLS_BAG_CERTIFICATE? ;) Or should/can I use GNUTLS_BAG_ENCRYPTED > for generic encrypted data? In ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12.asn I can see a secretbag that is underdefined though. If you want to use that you might need to do some checking on whether someone already uses this bag type to put octet data (the asn.1 wording for bytes) there. If yes I think the modifications to gnutls to support it should be minor. If noone uses it might be possible to use some object identifier (OID) to define just a blob. best regards, Nikos From nmav at gnutls.org Sat Oct 24 04:40:34 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 24 Oct 2009 05:40:34 +0300 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: <4AE26922.9070905@gnutls.org> tangtong wrote: > Hi,Nikos > > > > The server is implemented by myself with gnutls2.9.4 and your patch. To make investigation easy, I will build a simplified server based on gnutls demo server codes and let you know the results later. Please also try gnutls from the git repository directly: git://git.sv.gnu.org/gnutls.git regards, Nikos From michael at weiser.dinsnail.net Sat Oct 24 09:46:47 2009 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Sat, 24 Oct 2009 09:46:47 +0200 Subject: {Spam?} Re: loading psk credentials from encrypted file In-Reply-To: <4AE259BF.4070808@gnutls.org> References: <20081222225504.GA1100@weiser.dinsnail.net> <20091023180712.GA89714@weiser.dinsnail.net> <4AE259BF.4070808@gnutls.org> Message-ID: <20091024074647.GB27138@weiser.dinsnail.net> Hi Nikos, On Sat, Oct 24, 2009 at 04:34:55AM +0300, Nikos Mavrogiannopoulos wrote: > > A few days ago I had an idea though: Why not abuse the PKCS12 functions > > to save the datum_t holding the PSK key out in an encrypted PKCS12 > > structure? > What are the reasons for doing that? Is it for distributing the actual > key to clients? For protecting the whole password file maybe pkcs-12 is > too much, and saving the password file into an encrypted partition might > be simpler. Yes, it's meant for storage of keys on the client. I thought about an encrypted filesystem container as well, but then the key is vulnerable as long as that container is mounted. It also adds at least two more steps to startup of my client. Of course, they can be automated by a script. But that together with a whole encrypted container for 64 bytes of data seems even more overkill to mee. If the key is in an encrypted file all by itself, someone wanting to extract it would need much more access than just mixed up filesystem permissions. > > The code looks as shown below (without the error checking for > > readability). It works fine, but my questions are: > > > > - Is this at all sensible or (will it break|is it braindead|other > > reason for never ever doing it)? > I don't like pkcs-12 due to it's complexity, but nevertheless there is > nothing (else) wrong with it and pretty much seems to fit here. What SSH does with it's identities is much what I'd like. After looking at their code, I despaired of being able to get it implemented without major breakage. PKCS12 might be complex on the inside but GNUTLS's PKCS12 API to me as developer is nicely simple. If there were something similarly simple API-wise with support for stronger ciphers and perhaps even a simpler internal structure, I'd jump on it. :) > > - Can I use something stronger than RC4-128 for encryption? > I believe PKCS-12 supports 3DES as well. Is there a way of adding something like AES-256? -- Thanks, Micha From nmav at gnutls.org Sat Oct 24 16:42:43 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 24 Oct 2009 17:42:43 +0300 Subject: {Spam?} Re: loading psk credentials from encrypted file In-Reply-To: <20091024074647.GB27138@weiser.dinsnail.net> References: <20081222225504.GA1100@weiser.dinsnail.net> <20091023180712.GA89714@weiser.dinsnail.net> <4AE259BF.4070808@gnutls.org> <20091024074647.GB27138@weiser.dinsnail.net> Message-ID: <4AE31263.4050100@gnutls.org> Michael Weiser wrote: >>> - Is this at all sensible or (will it break|is it braindead|other >>> reason for never ever doing it)? >> I don't like pkcs-12 due to it's complexity, but nevertheless there is >> nothing (else) wrong with it and pretty much seems to fit here. > > What SSH does with it's identities is much what I'd like. After looking > at their code, I despaired of being able to get it implemented without > major breakage. > > PKCS12 might be complex on the inside but GNUTLS's PKCS12 API to me as > developer is nicely simple. If there were something similarly simple > API-wise with support for stronger ciphers and perhaps even a simpler > internal structure, I'd jump on it. :) > >>> - Can I use something stronger than RC4-128 for encryption? >> I believe PKCS-12 supports 3DES as well. > > Is there a way of adding something like AES-256? I've checked a bit and it seems there is a definition of the AES family in PKCS #5 2.1 (PBES). I have added support for them in the git repository. About using the secret bag, from a quick glimpse it seems it can only be used with a custom extension. regards, Nikos From tang__tong at hotmail.com Mon Oct 26 02:35:35 2009 From: tang__tong at hotmail.com (tangtong) Date: Mon, 26 Oct 2009 01:35:35 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi,Nikos I have reproduced the core dump with the server/client in the attach. If not using the memory-leak patch, the core will not happen. Regards Tony From: tang__tong at hotmail.com To: nmav at gnutls.org Date: Fri, 23 Oct 2009 14:28:50 +0000 CC: simon at josefsson.org; help-gnutls at gnu.org Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode Hi,Nikos The server is implemented by myself with gnutls2.9.4 and your patch. To make investigation easy, I will build a simplified server based on gnutls demo server codes and let you know the results later. Regards Tony > Date: Fri, 23 Oct 2009 10:38:20 +0300 > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > > Thanks. However in order to reproduce it I need to know to which > server you connect to and which options does this server use? > > 2009/10/23 tangtong : > > Hi,Nikos > > > > The gnutls-cli built by me will core when I enable TLS1.2. I think the code > > base I use is a little diffent from what you are using. The following is my > > steps to setup the build enviorment: > > 1)Download a gnutls releaes package 2.8.3 and decompress it; > > 2)Download 2.9.4 snap shot and uncompress it to the directory created in the > > step 1); > > 3)Run patch you provide. > > > > Seems only snapshot of 2.9.4 is not the whole build env, that's why i > > decompress it to a build enviorment of 2.8.3. > > > > Regards > > Tony > > > > > > > > > > > > > > > > > >> Date: Thu, 22 Oct 2009 19:31:02 +0300 > >> From: nmav at gnutls.org > >> To: tang__tong at hotmail.com > >> CC: simon at josefsson.org; help-gnutls at gnu.org > >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > >> > >> tangtong wrote: > >> > Hi,Nikos > >> > >> > 2)The patch doesn't support > >> > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I t! hink your > >> > patch disable the tls1.2 support, it will core with the following dump > >> > info: > >> > fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 > >> > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 > >> > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 > >> > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 > >> > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) > >> > + 30 > >> > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 > >> > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 > >> > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c > >> > >> Can you send me information on how I can reproduce this issue? I can use > >> ./gnutls-cli tls.secg.org --priority > >> "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to > >> connect using TLS1.2 without any issues.> > >> regards, > >> Nikos > > > > ________________________________ > > ?? Windows 7???????? PC? ????? Messenger???2.0???????Messenger??? ?????? _________________________________________________________________ MSN????????MSN??????????? http://10.msn.com.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: client.cpp URL: From simon at josefsson.org Mon Oct 26 13:41:33 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 26 Oct 2009 13:41:33 +0100 Subject: gnutls 2.8.5 release candidate: please test! Message-ID: <87tyxm9vk2.fsf@mocca.josefsson.org> I'm planning to release 2.8.5 shortly. It will be the same as http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20091026.tar.bz2 unless you holler. In other words: please test the above as if it were the next stable release! /Simon From techdisser at gmail.com Tue Oct 27 09:09:27 2009 From: techdisser at gmail.com (Vladimir Estis) Date: Tue, 27 Oct 2009 11:09:27 +0300 Subject: Strange bug in the TLS application protocol with PSK Message-ID: <86959b190910270109m4d440aa5m21628e1a026fbbef@mail.gmail.com> Hello, I've used GNUTLS for testing of the TLS with the PSK cipher suite (TLS_PSK_WITH_3DES_EDE_CBC_SHA). But I've faced a problem with PSK kind of authentication in the gnutls-cli. I see that handshake was successfully done. But then I tried to send part of application data, and I found that first cipher block (8 bytes) was corrupted. I think, GNUTLS calculates checksum for application data, injures first block and then do ciphering across all data. I think this is bug in GNUTLS, but I couldn't find any discussion at the forums about this fact. Has anyone else encountered this behaviour of the GNUTLS? Thanks very much in advance for any help! With best regards, Vlad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Oct 27 09:33:48 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Oct 2009 10:33:48 +0200 Subject: Strange bug in the TLS application protocol with PSK In-Reply-To: <86959b190910270109m4d440aa5m21628e1a026fbbef@mail.gmail.com> References: <86959b190910270109m4d440aa5m21628e1a026fbbef@mail.gmail.com> Message-ID: If you think this is a gnutls bug please send an example program that reproduces this bug. regards, Nikos On Tue, Oct 27, 2009 at 10:09 AM, Vladimir Estis wrote: > Hello, > > I've used GNUTLS for testing of the TLS with the PSK cipher suite > (TLS_PSK_WITH_3DES_EDE_CBC_SHA). But I've faced a problem with PSK kind of > authentication in the gnutls-cli. I see that handshake was successfully > done. But then I tried to send part of application data, and I found that > first cipher block (8 bytes) was corrupted. I think, GNUTLS calculates > checksum for application data, injures first block and then do ciphering > across all data. I think this is bug in GNUTLS, but I couldn't find any > discussion at the forums about this fact. > > Has anyone else encountered this behaviour of the GNUTLS? > Thanks very much in advance for any help! > > With best regards, Vlad. > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > From hortons at sc.rr.com Tue Oct 27 13:19:50 2009 From: hortons at sc.rr.com (hortons at sc.rr.com) Date: Tue, 27 Oct 2009 8:19:50 -0400 Subject: gnuTLS with Lighttpd Message-ID: <20091027121950.EP4HF.5081.root@cdptpa-web22-z02> I'm trying to get gnuTLS working with lighttpd 1.5.x within a singletheaded env. I managed to get gnuTLS to compile but I don't think it worked. Has anyone else figured this out yet? I see most of the posts appear to cover Apache only. I would like to ultimately use it to extend lighttpd "SSL-ness" to TLS 1.2 to make use of Elliptical Curve Cryptography (ECC) to secure a Ruby on rails app. Any help would be greatly appreciated. I hear ECC is much more resource friendly. Thanks! -SH From techdisser at gmail.com Tue Oct 27 14:09:01 2009 From: techdisser at gmail.com (Vladimir Estis) Date: Tue, 27 Oct 2009 16:09:01 +0300 Subject: Fwd: Strange bug in the TLS application protocol with PSK In-Reply-To: <86959b190910270606o50b1819cu66d0eb6b4557b57c@mail.gmail.com> References: <86959b190910270109m4d440aa5m21628e1a026fbbef@mail.gmail.com> <86959b190910270606o50b1819cu66d0eb6b4557b57c@mail.gmail.com> Message-ID: <86959b190910270609n150bd262y3ee03ca6548a29fd@mail.gmail.com> Hi Nikos, Thanks for your answer. I've solved this problem. It was my error. I've reset IV for cipher after every message. But TLS uses the last cipher block of record as the CBC IV for next block. Thus, IV for first block of every new message was lost, and I wasn't able to decrypt the first cipher block of message. Now I call update() function instead of doFinal() and GNUTLS works fine. Thank you again, regards, Vlad. 2009/10/27 Nikos Mavrogiannopoulos If you think this is a gnutls bug please send an example program that > reproduces this bug. > > regards, > Nikos > > On Tue, Oct 27, 2009 at 10:09 AM, Vladimir Estis > wrote: > > Hello, > > > > I've used GNUTLS for testing of the TLS with the PSK cipher suite > > (TLS_PSK_WITH_3DES_EDE_CBC_SHA). But I've faced a problem with PSK kind > of > > authentication in the gnutls-cli. I see that handshake was successfully > > done. But then I tried to send part of application data, and I found that > > first cipher block (8 bytes) was corrupted. I think, GNUTLS calculates > > checksum for application data, injures first block and then do ciphering > > across all data. I think this is bug in GNUTLS, but I couldn't find any > > discussion at the forums about this fact. > > > > Has anyone else encountered this behaviour of the GNUTLS? > > Thanks very much in advance for any help! > > > > With best regards, Vlad. > > > > _______________________________________________ > > Help-gnutls mailing list > > Help-gnutls at gnu.org > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Oct 27 15:11:36 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Oct 2009 16:11:36 +0200 Subject: Strange bug in the TLS application protocol with PSK In-Reply-To: <86959b190910270606o50b1819cu66d0eb6b4557b57c@mail.gmail.com> References: <86959b190910270109m4d440aa5m21628e1a026fbbef@mail.gmail.com> <86959b190910270606o50b1819cu66d0eb6b4557b57c@mail.gmail.com> Message-ID: I'm quite intrigued... How did you manage to do that? Do you use custom push and pull functions? regards, Nikos On Tue, Oct 27, 2009 at 3:06 PM, Vladimir Estis wrote: > Hi Nikos, > > Thanks for your answer. I've solved this problem. It was my error. I've > reset IV for cipher after every message. But TLS uses the last cipher block > of record as the CBC IV for next block. Thus, IV for first block of every > new message was lost, and I wasn't able to decrypt the first cipher block of > message. Now I call update() function instead of doFinal() and GNUTLS works > fine. > > Thank you again, > regards, Vlad. > > 2009/10/27 Nikos Mavrogiannopoulos >> >> If you think this is a gnutls bug please send an example program that >> reproduces this bug. >> >> regards, >> Nikos >> >> On Tue, Oct 27, 2009 at 10:09 AM, Vladimir Estis >> wrote: >> > Hello, >> > >> > I've used GNUTLS for testing of the TLS with the PSK cipher suite >> > (TLS_PSK_WITH_3DES_EDE_CBC_SHA). But I've faced a problem with PSK kind >> > of >> > authentication in the gnutls-cli. I see that handshake was successfully >> > done. But then I tried to send part of application data, and I found >> > that >> > first cipher block (8 bytes) was corrupted. I think, GNUTLS calculates >> > checksum for application data, injures first block and then do ciphering >> > across all data. I think this is bug in GNUTLS, but I couldn't find any >> > discussion at the forums about this fact. >> > >> > Has anyone else encountered this behaviour of the GNUTLS? >> > Thanks very much in advance for any help! >> > >> > With best regards, Vlad. >> > >> > _______________________________________________ >> > Help-gnutls mailing list >> > Help-gnutls at gnu.org >> > http://lists.gnu.org/mailman/listinfo/help-gnutls >> > >> > > > From nmav at gnutls.org Tue Oct 27 20:35:26 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Oct 2009 21:35:26 +0200 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: <4AE74B7E.7080509@gnutls.org> tangtong wrote: > Hi,Nikos > I have reproduced the core dump with the server/client in the attach. If not using the memory-leak patch, the core will not happen. Can you reproduce it with the latest code in the git repository? At least the negotiation works there. Check http://git.savannah.gnu.org/gitweb/?p=gnutls.git best regards, Nikos From sdecugis at nict.go.jp Wed Oct 28 06:01:51 2009 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Wed, 28 Oct 2009 14:01:51 +0900 Subject: Bootstrap parallel connections using session resume ? Message-ID: <4AE7D03F.1050803@nict.go.jp> Hello, I am trying to establish several parallel TLS-protected channels between two nodes, like this : - establish the first connection (called "master") - TLS handshake, verify credentials, - If successful, establish the other connections (same endpoints) - TLS handshake each of these connections (in parallel in several threads), using the same credentials as the master session. I got this working, but I would like to optimize the establishment of the multi-connections. I can see several ways to do this, but I would like to know if they are not mis-use of the GnuTLS library. What I am trying to do is: - create several threads after the master handshake and verification, and handle each children handshake independently. - use session resuming from the master session to accelerate the handshake in all children connections. Each connection has an independant gnutls_session_t object, but share the same credentials structures. On the server side, I have set the same session store for all sessions. I need to set the transport pointer in the sessions using the gnutls_transport_set_ptr function. Should I do it before or after the gnutls_session_set_data on the client side? Is there anything more to do ? I don't know if it is relevant, my different channels are actually the same socket object, but different SCTP streams, and I use customs push/pull functions to mux/demux the messages. I can send my code showing the actual implementation if you are interested. So far, I was not able to use multithreading and resuming efficiently. Most of the sessions fail to resume and fallback to a full handshake. I have seen also some strange behavior (store operation with the same key but different data) so I am wondering if this whole mechanism is really possible with GnuTLS. I don't really understand what is behind session resuming, so please tell me if what I am trying to do is really wrong... Thank you in advance, Best regards, Sebastien. From nmav at gnutls.org Wed Oct 28 07:41:45 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 28 Oct 2009 08:41:45 +0200 Subject: Bootstrap parallel connections using session resume ? In-Reply-To: <4AE7D03F.1050803@nict.go.jp> References: <4AE7D03F.1050803@nict.go.jp> Message-ID: <4AE7E7A9.8090405@gnutls.org> Sebastien Decugis wrote: > Hello, > > I am trying to establish several parallel TLS-protected channels between > two nodes, like this : > - establish the first connection (called "master") > - TLS handshake, verify credentials, > - If successful, establish the other connections (same endpoints) > - TLS handshake each of these connections (in parallel in several > threads), using the same credentials as the master session. > > I got this working, but I would like to optimize the establishment of > the multi-connections. I can see several ways to do this, but I would > like to know if they are not mis-use of the GnuTLS library. What I am > trying to do is: > - create several threads after the master handshake and verification, > and handle each children handshake independently. > - use session resuming from the master session to accelerate the > handshake in all children connections. > > Each connection has an independant gnutls_session_t object, but share > the same credentials structures. On the server side, I have set the same > session store for all sessions. I need to set the transport pointer in > the sessions using the gnutls_transport_set_ptr function. Should I do it > before or after the gnutls_session_set_data on the client side? There is no real difference. > Is there > anything more to do ? I don't think so. It looks correct. > I don't know if it is relevant, my different channels are actually the > same socket object, but different SCTP streams, and I use customs > push/pull functions to mux/demux the messages. I can send my code > showing the actual implementation if you are interested. Actually I'm interested in the implementation. Would you be interested to write few words and example push/pull functions on how to use gnutls over SCTP, to add in the manual? It can be something like the examples there: http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples > So far, I was not able to use multithreading and resuming efficiently. > Most of the sessions fail to resume and fallback to a full handshake. I > have seen also some strange behavior (store operation with the same key > but different data) so I am wondering if this whole mechanism is really > possible with GnuTLS. Was this on the server side or client side? If it is on client side, you should note that you need not and better shouldn't keep the session data of a resumed session. Just use the session data of the original one or the last on that didn't success in resuming. If this is not the case please let me know of the details as well. I don't really understand what is behind session > resuming, so please tell me if what I am trying to do is really wrong... What you do is what session resuming was made for. regards, Nikos From sdecugis at nict.go.jp Wed Oct 28 08:25:37 2009 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Wed, 28 Oct 2009 16:25:37 +0900 Subject: Bootstrap parallel connections using session resume ? In-Reply-To: <4AE7E7A9.8090405@gnutls.org> References: <4AE7D03F.1050803@nict.go.jp> <4AE7E7A9.8090405@gnutls.org> Message-ID: <4AE7F1F1.4040303@nict.go.jp> Hi Nikos, thank you for your fast answer. >> Each connection has an independant gnutls_session_t object, but share >> the same credentials structures. On the server side, I have set the same >> session store for all sessions. I need to set the transport pointer in >> the sessions using the gnutls_transport_set_ptr function. Should I do it >> before or after the gnutls_session_set_data on the client side? >> > > There is no real difference. > [talking about the client side here] Ok, so if I understand correctly the transport parameters are not stored inside the data returned by gnutls_session_get_data2, right ? What about the credentials (priority, CA, key, ...) ? Do I have to set them before I set the session data, or does this operation set them for me (so I don't have to do it at all ?) >> I don't know if it is relevant, my different channels are actually the >> same socket object, but different SCTP streams, and I use customs >> push/pull functions to mux/demux the messages. I can send my code >> showing the actual implementation if you are interested. >> > > Actually I'm interested in the implementation. Would you be interested > to write few words and example push/pull functions on how to use gnutls > over SCTP, to add in the manual? It can be something like the examples > there: > http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples > Well, I can at least send you pointers to my code with some explanation so that you get an idea of how I am doing it, and then if you're still interested I'll try to extract the parts interesting for the manual or build a demonstration sample. BTW my code is BSD licensed (but I think it is no problem to extract a small part for the gnutls manual and release this part under a different license -- at least on my side) >> So far, I was not able to use multithreading and resuming efficiently. >> Most of the sessions fail to resume and fallback to a full handshake. I >> have seen also some strange behavior (store operation with the same key >> but different data) so I am wondering if this whole mechanism is really >> possible with GnuTLS. >> > > Was this on the server side or client side? If it is on client side, you > should note that you need not and better shouldn't keep the session data > of a resumed session. Just use the session data of the original one or > the last on that didn't success in resuming. If this is not the case > please let me know of the details as well. > Well, currently I am using the db_* functions only on the server side, my understanding was that they are not used on the client side, right ? On the client side, I only get the data of my primary (handshaken) session and then set this data in all other sessions before handshake. Anyway for some reason that I don't understand, it seems that now it started to work properly, and I see successfully resumed sessions -- I really don't know what I changed in my code for this result -- but I am not complaining ^^ > What you do is what session resuming was made for. > Ok, great then :) Thank you again! Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From nmav at gnutls.org Wed Oct 28 09:55:13 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 28 Oct 2009 10:55:13 +0200 Subject: Bootstrap parallel connections using session resume ? In-Reply-To: <4AE7F1F1.4040303@nict.go.jp> References: <4AE7D03F.1050803@nict.go.jp> <4AE7E7A9.8090405@gnutls.org> <4AE7F1F1.4040303@nict.go.jp> Message-ID: <4AE806F1.1020400@gnutls.org> Sebastien Decugis wrote: > [talking about the client side here] > Ok, so if I understand correctly the transport parameters are not stored > inside the data returned by gnutls_session_get_data2, right ? Indeed. > What about the credentials (priority, CA, key, ...) ? Do I have to set > them before I set the session data, or does this operation set them for > me (so I don't have to do it at all ?) Those are needed to be set since the server might decide not to resume. If he doesn't typically they are ignored. >>> I don't know if it is relevant, my different channels are actually the >>> same socket object, but different SCTP streams, and I use customs >>> push/pull functions to mux/demux the messages. I can send my code >>> showing the actual implementation if you are interested. >>> >> Actually I'm interested in the implementation. Would you be interested >> to write few words and example push/pull functions on how to use gnutls >> over SCTP, to add in the manual? It can be something like the examples >> there: >> http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples >> > Well, I can at least send you pointers to my code with some explanation > so that you get an idea of how I am doing it, and then if you're still > interested I'll try to extract the parts interesting for the manual or > build a demonstration sample. That would be perfect. Please send me. >>> So far, I was not able to use multithreading and resuming efficiently. >>> Most of the sessions fail to resume and fallback to a full handshake. I >>> have seen also some strange behavior (store operation with the same key >>> but different data) so I am wondering if this whole mechanism is really >>> possible with GnuTLS. >>> >> Was this on the server side or client side? If it is on client side, you >> should note that you need not and better shouldn't keep the session data >> of a resumed session. Just use the session data of the original one or >> the last on that didn't success in resuming. If this is not the case >> please let me know of the details as well. >> > Well, currently I am using the db_* functions only on the server side, > my understanding was that they are not used on the client side, right ? > On the client side, I only get the data of my primary (handshaken) > session and then set this data in all other sessions before handshake. Correct. > Anyway for some reason that I don't understand, it seems that now it > started to work properly, and I see successfully resumed sessions -- I > really don't know what I changed in my code for this result -- but I am > not complaining ^^ I'm quite curious on the previous behavior, where you noticed the same session ID being save twice in server side. It seems the server was wrongly trying to overwrite the initial session parameters with the resumed one. The attached patch should fix what you have noticed. (what you see now might be a timing issue if all the clients connect before the server has overwritten the initial parameters). regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: resuming.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: From techdisser at gmail.com Wed Oct 28 10:29:35 2009 From: techdisser at gmail.com (Vladimir Estis) Date: Wed, 28 Oct 2009 12:29:35 +0300 Subject: Strange bug in the TLS application protocol with PSK In-Reply-To: References: <86959b190910270109m4d440aa5m21628e1a026fbbef@mail.gmail.com> <86959b190910270606o50b1819cu66d0eb6b4557b57c@mail.gmail.com> Message-ID: <86959b190910280229l3b202d1fha9457c6ab6eb464f@mail.gmail.com> Hi Nikos, No, I use GNUTLS only as reference test client and I don't use functions from GNUTLS in my code. But problem described above was in my code, that based on standart API for ciphering. Thanks for your answers, GNUTLS works fine. regards, Vlad. 2009/10/27 Nikos Mavrogiannopoulos > > I'm quite intrigued... How did you manage to do that? Do you use > custom push and pull functions? > > regards, > Nikos > > On Tue, Oct 27, 2009 at 3:06 PM, Vladimir Estis wrote: > > Hi Nikos, > > > > Thanks for your answer. I've solved this problem. It was my error. I've > > reset IV for cipher after every message. But TLS uses the last cipher block > > of record as the CBC IV for next block. Thus, IV for first block of every > > new message was lost, and I wasn't able to decrypt the first cipher block of > > message. Now I call update() function instead of doFinal() and GNUTLS works > > fine. > > > > Thank you again, > > regards, Vlad. > > > > 2009/10/27 Nikos Mavrogiannopoulos > >> > >> If you think this is a gnutls bug please send an example program that > >> reproduces this bug. > >> > >> regards, > >> Nikos > >> > >> On Tue, Oct 27, 2009 at 10:09 AM, Vladimir Estis > >> wrote: > >> > Hello, > >> > > >> > I've used GNUTLS for testing of the TLS with the PSK cipher suite > >> > (TLS_PSK_WITH_3DES_EDE_CBC_SHA). But I've faced a problem with PSK kind > >> > of > >> > authentication in the gnutls-cli. I see that handshake was successfully > >> > done. But then I tried to send part of application data, and I found > >> > that > >> > first cipher block (8 bytes) was corrupted. I think, GNUTLS calculates > >> > checksum for application data, injures first block and then do ciphering > >> > across all data. I think this is bug in GNUTLS, but I couldn't find any > >> > discussion at the forums about this fact. > >> > > >> > Has anyone else encountered this behaviour of the GNUTLS? > >> > Thanks very much in advance for any help! > >> > > >> > With best regards, Vlad. > >> > > >> > _______________________________________________ > >> > Help-gnutls mailing list > >> > Help-gnutls at gnu.org > >> > http://lists.gnu.org/mailman/listinfo/help-gnutls > >> > > >> > > > > > From sdecugis at nict.go.jp Wed Oct 28 10:46:01 2009 From: sdecugis at nict.go.jp (Sebastien Decugis) Date: Wed, 28 Oct 2009 18:46:01 +0900 Subject: Bootstrap parallel connections using session resume ? In-Reply-To: <4AE806F1.1020400@gnutls.org> References: <4AE7D03F.1050803@nict.go.jp> <4AE7E7A9.8090405@gnutls.org> <4AE7F1F1.4040303@nict.go.jp> <4AE806F1.1020400@gnutls.org> Message-ID: <4AE812D9.3020401@nict.go.jp> Hi again Nikos, >> Well, I can at least send you pointers to my code with some explanation >> so that you get an idea of how I am doing it, and then if you're still >> interested I'll try to extract the parts interesting for the manual or >> build a demonstration sample. >> > > That would be perfect. Please send me. > Ok, I am sending this in private mail, to avoid spamming the list :) >> Anyway for some reason that I don't understand, it seems that now it >> started to work properly, and I see successfully resumed sessions -- I >> really don't know what I changed in my code for this result -- but I am >> not complaining ^^ >> > > I'm quite curious on the previous behavior, where you noticed the same > session ID being save twice in server side. It seems the server was > wrongly trying to overwrite the initial session parameters with the > resumed one. The attached patch should fix what you have noticed. > (what you see now might be a timing issue if all the clients connect > before the server has overwritten the initial parameters). > Well, I might have used some un-initialized pointers at some point when I saw those traces, so maybe it's better to ignore them... I'll investigate more seriously if I run into them again. Thank you for the patch, but I am using a pre-compiled GnuTLS library currently, and I would prefer to stick with it if I can... Best regards, Sebastien. From couickie at gmail.com Wed Oct 28 16:36:37 2009 From: couickie at gmail.com (john doe) Date: Wed, 28 Oct 2009 16:36:37 +0100 Subject: High loads and failure due to mod_gnutls Message-ID: <999168750910280836sf380b45rd6aa1e078fd340ab@mail.gmail.com> Hello, I am using Apache 2.2.9 and mod_gnutls.so (GNUTLS version 1_4) and I have experienced high load values on my server (HTTP/HTTPS Reverse proxy running on Lenny). Regularly a new apache2 process spawns on the `top` command and takes X% of the CPU, if there is a single bugged process X=100, if there are 2 X=50 etc... `w' command reported a load value of 27 this morning, after a restart of apache it went down to 0 again. After 2 hours the load is now at 2. I am not used to troubleshooting but I managed to get a backtrace with gdb, here is the output: #0 0xb7f78a0e in apr_bucket_free () from /usr/lib/libaprutil-1.so.0 #1 0x08078dac in ap_core_output_filter () #2 0xb75133d3 in mgs_transport_write () from /usr/lib/apache2/modules/mod_gnutls.so #3 0xb78b93f2 in _gnutls_io_write_buffered () from /usr/lib/libgnutls.so.26 #4 0xb78b9950 in _gnutls_io_write_flush () from /usr/lib/libgnutls.so.26 #5 0xb78b5dc0 in _gnutls_send_int () from /usr/lib/libgnutls.so.26 #6 0xb78b627b in gnutls_record_send () from /usr/lib/libgnutls.so.26 #7 0xb7513b09 in mgs_filter_output () from /usr/lib/apache2/modules/mod_gnutls.so #8 0x0806f10e in ap_content_length_filter () #9 0xb74e07fc in ?? () from /usr/lib/apache2/modules/mod_proxy_http.so #10 0x08407b98 in ?? () #11 0x084223a0 in ?? () #12 0x084223a0 in ?? () #13 0x00000001 in ?? () #14 0x00002000 in ?? () #15 0x00000000 in ?? () I sent a interrupt signal to the process and then ended up in a sort of fatal error function from gnu_tls (I cannot recall the name). Maybe some function in gnu_tls is looping forever, waiting for a right return value (that never come unfortunately). Here are some other debugging clues: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5269 www-data 20 0 15136 5516 2424 R 49.8 0.4 15:53.62 apache2 5314 www-data 20 0 15012 5296 2308 R 47.8 0.4 10:55.86 apache2 load average: 1.50, 1.80, 1.68 This output is redundant in apache error log: [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1819): proxy: worker proxy:reverse already initialized [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1913): proxy: initialized single connection worker 17 in child 5461 for (*) ===================================================================================== [Wed Oct 28 15:48:33 2009] [info] [client 62.36.240.2] (104)Connection reset by peer: core_output_filter: writing data to the network [Wed Oct 28 15:49:40 2009] [info] [client 193.203.96.2] (32)Broken pipe: core_output_filter: writing data to the network [Wed Oct 28 15:53:59 2009] [info] [client 193.203.96.2] (32)Broken pipe: core_output_filter: writing data to the network I may not be able to give you more information about this server, the load was high but there were no latency. Do you have an idea about this issue ? Thank you for your attention. Regards. From tang__tong at hotmail.com Thu Oct 29 06:27:52 2009 From: tang__tong at hotmail.com (tangtong) Date: Thu, 29 Oct 2009 05:27:52 +0000 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Hi,Nikos I have rebuilt the lib with the latest daily snap shot and the GIT snapshot commited by you, the memory leak and core issue have been resolved. One more question: in your commit comments: "3. In TLS 1.2 when a certificate request is sent, support is not complete. In that case abort the handshake. By checking TLS 1.2 it seems that the algorithms to be used for the signature in the certificate verify message are negotiated not at the client/server hello messages but rather selected by the server at the certificate request. This might not look as bad, but since in this message we have to sign all previous handshake messages, it forces us to keep all the handshake messages into a buffer until this point... I don't know who proposed this change to the TLS WG, but it seems it wasn't really thought of." If client certificate is not needed, the current implemenation can support TLS1.2, right? Regards Tony From: tang__tong at hotmail.com To: nmav at gnutls.org Date: Mon, 26 Oct 2009 01:35:35 +0000 CC: simon at josefsson.org; help-gnutls at gnu.org Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode Hi,Nikos I have reproduced the core dump with the server/client in the attach. If not using the memory-leak patch, the core will not happen. Regards Tony From: tang__tong at hotmail.com To: nmav at gnutls.org Date: Fri, 23 Oct 2009 14:28:50 +0000 CC: simon at josefsson.org; help-gnutls at gnu.org Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode Hi,Nikos The server is implemented by myself with gnutls2.9.4 and your patch. To make investigation easy, I will build a simplified server based on gnutls demo server codes and let you know the results later. Regards Tony > Date: Fri, 23 Oct 2009 10:38:20 +0300 > Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > From: nmav at gnutls.org > To: tang__tong at hotmail.com > CC: simon at josefsson.org; help-gnutls at gnu.org > > Thanks. However in order to reproduce it I need to know to which > server you connect to and which options does this server use? > > 2009/10/23 tangtong : > > Hi,Nikos > > > > The gnutls-cli built by me will core when I enable TLS1.2. I think the code > > base I use is a little diffent from what you are using. The following is my > > steps to setup the build enviorment: > > 1)Download a gnutls releaes package 2.8.3 and decompress it; > > 2)Download 2.9.4 snap shot and uncompress it to the directory created in the > > step 1); > > 3)Run patch you provide. > > > > Seems only snapshot of 2.9.4 is not the whole build env, that's why i > > decompress it to a build enviorment of 2.8.3. > > > > Regards > > Tony > > > > > > > > > > > > > > > > > >> Date: Thu, 22 Oct 2009 19:31:02 +0300 > >> From: nmav at gnutls.org > >> To: tang__tong at hotmail.com > >> CC: simon at josefsson.org; help-gnutls at gnu.org > >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode > >> > >> tangtong wrote: > >> > Hi,Nikos > >> > >> > 2)The patch doesn't support > >> > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I t! hink your > >> > patch disable the tls1.2 support, it will core with the following dump > >> > info: > >> > fe9a2bb8 _gcry_md_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + 4 > >> > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 > >> > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 > >> > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 > >> > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, ffbff551) > >> > + 30 > >> > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 > >> > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 > >> > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c > >> > >> Can you send me information on how I can reproduce this issue? I can use > >> ./gnutls-cli tls.secg.org --priority > >> "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to > >> connect using TLS1.2 without any issues.> > >> regards, > >> Nikos > > > > ________________________________ > > ?? Windows 7???????? PC? ????? Messenger???2.0???????Messenger??? ?????? Messenger???2.0???????Messenger??? ?????? _________________________________________________________________ ?? Windows 7???????? PC?????? http://www.microsoft.com/china/windows/buy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Oct 29 09:15:51 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 29 Oct 2009 10:15:51 +0200 Subject: Memory leaks are observed for libgnutls in multi-thread mode In-Reply-To: References: Message-ID: Indeed. However I plan to fix the case for client certificate as well, in the next few days. regards, Nikos 2009/10/29 tangtong : > Hi,Nikos > I have rebuilt the lib with the latest daily snap shot and the GIT snapshot > commited by you, the memory leak and core issue have been resolved. > > One more question: in your commit comments: > "3. In TLS 1.2 when a certificate request is sent, support is not complete. > In that case abort the handshake. By checking > TLS 1.2 it seems that the algorithms to be used for the signature in the > certificate verify message are negotiated not at > the client/server hello messages but rather selected by the server at the > certificate request. This might not look as bad, but since in this message > we have to sign all previous handshake messages, it forces us to keep all > the handshake messages into a buffer until this point... I don't know who > proposed this change to the TLS WG, but it seems it wasn't really thought > of." > > If client certificate is not needed, the current implemenation can support > TLS1.2, right? > > Regards > Tony > > > ________________________________ > ! From: tang__tong at hotmail.com > To: nmav at gnutls.org > Date: Mon, 26 Oct 2009 01:35:35 +0000 > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode > > Hi,Nikos > I have reproduced the core dump with the server/client in the attach. If not > using the memory-leak patch, the core will not happen. > > Regards > Tony > > ________________________________ > From: tang__tong at hotmail.com > To: nmav at gnutls.org > Date: Fri, 23 Oct 2009 14:28:50 +0000 > CC: simon at josefsson.org; help-gnutls at gnu.org > Subject: RE: Memory leaks are observed for libgnutls in multi-thread mode > > Hi,Nikos > > The server is implemented by myself with gnutls2.9.4 and your patch. To make > investigation easy, I will build a simplified server based on gnutls demo > server codes and let you know the results later. > > > Regards > Tony > > >> Date: Fri, 23 Oct 2009 10:38:20 +0300 >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread mode >> From: nmav at gnutls.org >> To: tang__tong at hotmail.com >> CC: simon at josefsson.org; help-gnutls at gnu.org >> >> Thanks. However in order to reproduce it I need to know to which >> server you connect to and which options does this server use? >> >> 2009/10/23 tangtong : >> > Hi,Nikos >> > >> > The gnutls-cli built by me will core when I enable TLS1.2. I think the >> > code >> > base I use is a little diffent from what you are using. The following is >> > my >> > steps to setup the build enviorment: >> > 1)Download a gnutls releaes package 2.8.3 and decompress it; >> > 2)Download 2.9.4 snap shot and uncompress it to the directory created in >> > the >> > step 1); >> > 3)Run patch you provide. >> > > ! > > Seems only snapshot of 2.9.4 is not the whole build env, that's why i >> > decompress it to a build enviorment of 2.8.3. >> > >> > Regards >> > Tony >> > >> > >> > >> > >> > >> > >> > >> > >> >> Date: Thu, 22 Oct 2009 19:31:02 +0300 >> >> From: nmav at gnutls.org >> >> To: tang__tong at hotmail.com >> >> CC: simon at josefsson.org; help-gnutls at gnu.org >> >> Subject: Re: Memory leaks are observed for libgnutls in multi-thread >> >> mode >> >> >> >> tangtong wrote: >> >> > Hi,Nikos >> >> >> >> > 2)The patch doesn't support >> >> > "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", I t! hink >> >> > your >> >> > patch disable the tls1.2 support, it will core with the following >> >> > dump >> >> > info: >> >> > fe9a2bb8 _gcry_m! d_copy (ffbff33c, 0, 0, febc6ed0, 14f8, fed3805c) + >> >> > 4 >> >> > feca8dfc _gnutls_hash_copy (ffbff338, 365c4, 0, 0, 0, 0) + 80 >> >> > fec9e0fc _gnutls_finished (36180, 2, ffbff440, 1, 6, 0) + 84 >> >> > fec9edc0 _gnutls_send_handshake_final (0, 0, 0, e, e, 4) + 128 >> >> > feca2548 _gnutls_handshake_common (36180, 0, 10, 4, ffffffe0, >> >> > ffbff551) >> >> > + 30 >> >> > feca382c gnutls_handshake (0, 4, 32fc8, 8e8, 17ac, ffbff5c4) + 60 >> >> > 000119bc main (1, ffbffa54, ffbffa5c, 22508, 0, 0) + 118 >> >> > 000112c8 _start (0, 0, 0, 0, 0, 0) + 5c >> >> >> >> Can you send me information on how I can reproduce this issue? I can >> >> use >> >> ./gnutls-cli tls.secg.org --priority >> >> "NONE:+VERS-TLS1.2:+AES-128-CBC:+RSA:+DHE-DSS:+SHA256:+COMP-NULL" to >> >> connect using TLS1.2 without any issues.> >> >> regards, >> >> Nikos >> > >> > ___________________! _____________ >> > ?? Windows 7???????? PC? ????? > > ________________________________ > Messenger???2.0???????Messenger??? ?????? > ________________________________ > Messenger???2.0???????Messenger??? ?????? > ________________________________ > ?? Windows 7???????? PC? ????? From simon at josefsson.org Thu Oct 29 09:16:59 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 29 Oct 2009 09:16:59 +0100 Subject: High loads and failure due to mod_gnutls In-Reply-To: <999168750910280836sf380b45rd6aa1e078fd340ab@mail.gmail.com> (john doe's message of "Wed, 28 Oct 2009 16:36:37 +0100") References: <999168750910280836sf380b45rd6aa1e078fd340ab@mail.gmail.com> Message-ID: <87d446k41w.fsf@mocca.josefsson.org> john doe writes: > Hello, > > I am using Apache 2.2.9 and mod_gnutls.so (GNUTLS version 1_4) and I > have experienced high load values on my server (HTTP/HTTPS Reverse > proxy running on Lenny). > > Regularly a new apache2 process spawns on the `top` command and takes > X% of the CPU, if there is a single bugged process X=100, if there are > 2 X=50 etc... > `w' command reported a load value of 27 this morning, after a restart > of apache it went down to 0 again. After 2 hours the load is now at 2. I've seen this too, especially in high-load scenarios, but for me it always appeared to be related to the 'GnuTLSCache dbm' setting. Maybe you could try changing /etc/apache2/mods-enabled/gnutls.conf to use 'GnuTLSCache none none' to see if the problem goes away? Maybe someone on the mod_gnutls list knows more. /Simon > I am not used to troubleshooting but I managed to get a backtrace with > gdb, here is the output: > > #0 0xb7f78a0e in apr_bucket_free () from /usr/lib/libaprutil-1.so.0 > #1 0x08078dac in ap_core_output_filter () > #2 0xb75133d3 in mgs_transport_write () from > /usr/lib/apache2/modules/mod_gnutls.so > #3 0xb78b93f2 in _gnutls_io_write_buffered () from /usr/lib/libgnutls.so.26 > #4 0xb78b9950 in _gnutls_io_write_flush () from /usr/lib/libgnutls.so.26 > #5 0xb78b5dc0 in _gnutls_send_int () from /usr/lib/libgnutls.so.26 > #6 0xb78b627b in gnutls_record_send () from /usr/lib/libgnutls.so.26 > #7 0xb7513b09 in mgs_filter_output () from > /usr/lib/apache2/modules/mod_gnutls.so > #8 0x0806f10e in ap_content_length_filter () > #9 0xb74e07fc in ?? () from /usr/lib/apache2/modules/mod_proxy_http.so > #10 0x08407b98 in ?? () > #11 0x084223a0 in ?? () > #12 0x084223a0 in ?? () > #13 0x00000001 in ?? () > #14 0x00002000 in ?? () > #15 0x00000000 in ?? () > > I sent a interrupt signal to the process and then ended up in a sort > of fatal error function from gnu_tls (I cannot recall the name). > Maybe some function in gnu_tls is looping forever, waiting for a right > return value (that never come unfortunately). > > Here are some other debugging clues: > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 5269 www-data 20 0 15136 5516 2424 R 49.8 0.4 15:53.62 apache2 > 5314 www-data 20 0 15012 5296 2308 R 47.8 0.4 10:55.86 apache2 > > load average: 1.50, 1.80, 1.68 > > This output is redundant in apache error log: > > [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1819): proxy: worker > proxy:reverse already initialized > [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1913): proxy: > initialized single connection worker 17 in child 5461 for (*) > ===================================================================================== > [Wed Oct 28 15:48:33 2009] [info] [client 62.36.240.2] (104)Connection > reset by peer: core_output_filter: writing data to the network > [Wed Oct 28 15:49:40 2009] [info] [client 193.203.96.2] (32)Broken > pipe: core_output_filter: writing data to the network > [Wed Oct 28 15:53:59 2009] [info] [client 193.203.96.2] (32)Broken > pipe: core_output_filter: writing data to the network > > > I may not be able to give you more information about this server, the > load was high but there were no latency. > Do you have an idea about this issue ? > > Thank you for your attention. > Regards. From simon at josefsson.org Thu Oct 29 09:18:20 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 29 Oct 2009 09:18:20 +0100 Subject: gnuTLS with Lighttpd In-Reply-To: <20091027121950.EP4HF.5081.root@cdptpa-web22-z02> (hortons@sc.rr.com's message of "Tue, 27 Oct 2009 8:19:50 -0400") References: <20091027121950.EP4HF.5081.root@cdptpa-web22-z02> Message-ID: <878weuk3zn.fsf@mocca.josefsson.org> writes: > I'm trying to get gnuTLS working with lighttpd 1.5.x within a > singletheaded env. I managed to get gnuTLS to compile but I don't > think it worked. Has anyone else figured this out yet? I see most of > the posts appear to cover Apache only. Does lighttpd support GnuTLS? I dunno. > I would like to ultimately use it to extend lighttpd "SSL-ness" to TLS > 1.2 to make use of Elliptical Curve Cryptography (ECC) to secure a > Ruby on rails app. Any help would be greatly appreciated. I hear ECC > is much more resource friendly. GnuTLS does not implement ECC. /Simon From couickie at gmail.com Thu Oct 29 11:26:51 2009 From: couickie at gmail.com (john doe) Date: Thu, 29 Oct 2009 11:26:51 +0100 Subject: High loads and failure due to mod_gnutls In-Reply-To: <87d446k41w.fsf@mocca.josefsson.org> References: <999168750910280836sf380b45rd6aa1e078fd340ab@mail.gmail.com> <87d446k41w.fsf@mocca.josefsson.org> Message-ID: <999168750910290326o6614a4cy4e32782fa39c4ca9@mail.gmail.com> Thank you for your answer, but unfortunately it didn't solve the problem. 2009/10/29 Simon Josefsson : > john doe writes: > >> Hello, >> >> I am using Apache 2.2.9 and mod_gnutls.so (GNUTLS version 1_4) and I >> have experienced high load values on my server (HTTP/HTTPS Reverse >> proxy running on Lenny). >> >> Regularly a new apache2 process spawns on the `top` command and takes >> X% of the CPU, if there is a single bugged process X=100, if there are >> 2 X=50 etc... >> `w' command reported a load value of 27 this morning, after a restart >> of apache it went down to 0 again. After 2 hours the load is now at 2. > > I've seen this too, especially in high-load scenarios, but for me it > always appeared to be related to the 'GnuTLSCache dbm' setting. ?Maybe > you could try changing /etc/apache2/mods-enabled/gnutls.conf to use > 'GnuTLSCache none none' to see if the problem goes away? > > Maybe someone on the mod_gnutls list knows more. > > /Simon > >> I am not used to troubleshooting but I managed to get a backtrace with >> gdb, here is the output: >> >> #0 ?0xb7f78a0e in apr_bucket_free () from /usr/lib/libaprutil-1.so.0 >> #1 ?0x08078dac in ap_core_output_filter () >> #2 ?0xb75133d3 in mgs_transport_write () from >> /usr/lib/apache2/modules/mod_gnutls.so >> #3 ?0xb78b93f2 in _gnutls_io_write_buffered () from /usr/lib/libgnutls.so.26 >> #4 ?0xb78b9950 in _gnutls_io_write_flush () from /usr/lib/libgnutls.so.26 >> #5 ?0xb78b5dc0 in _gnutls_send_int () from /usr/lib/libgnutls.so.26 >> #6 ?0xb78b627b in gnutls_record_send () from /usr/lib/libgnutls.so.26 >> #7 ?0xb7513b09 in mgs_filter_output () from >> /usr/lib/apache2/modules/mod_gnutls.so >> #8 ?0x0806f10e in ap_content_length_filter () >> #9 ?0xb74e07fc in ?? () from /usr/lib/apache2/modules/mod_proxy_http.so >> #10 0x08407b98 in ?? () >> #11 0x084223a0 in ?? () >> #12 0x084223a0 in ?? () >> #13 0x00000001 in ?? () >> #14 0x00002000 in ?? () >> #15 0x00000000 in ?? () >> >> I sent a interrupt signal to the process and then ended up in a sort >> of fatal error function from gnu_tls (I cannot recall the name). >> Maybe some function in gnu_tls is looping forever, waiting for a right >> return value (that never come unfortunately). >> >> Here are some other debugging clues: >> >> >> PID USER ? ? ?PR ?NI ?VIRT ?RES ?SHR S %CPU %MEM ? ?TIME+ ?COMMAND >> 5269 www-data ?20 ? 0 15136 5516 2424 R 49.8 ?0.4 ?15:53.62 apache2 >> 5314 www-data ?20 ? 0 15012 5296 2308 R 47.8 ?0.4 ?10:55.86 apache2 >> >> load average: 1.50, 1.80, 1.68 >> >> This output is redundant in apache error log: >> >> [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1819): proxy: worker >> proxy:reverse already initialized >> [Wed Oct 28 15:54:44 2009] [debug] proxy_util.c(1913): proxy: >> initialized single connection worker 17 in child 5461 for (*) >> ===================================================================================== >> [Wed Oct 28 15:48:33 2009] [info] [client 62.36.240.2] (104)Connection >> reset by peer: core_output_filter: writing data to the network >> [Wed Oct 28 15:49:40 2009] [info] [client 193.203.96.2] (32)Broken >> pipe: core_output_filter: writing data to the network >> [Wed Oct 28 15:53:59 2009] [info] [client 193.203.96.2] (32)Broken >> pipe: core_output_filter: writing data to the network >> >> >> I may not be able to give you more information about this server, the >> load was high but there were no latency. >> Do you have an idea about this issue ? >> >> Thank you for your attention. >> Regards. > -- Regards, shiro.