Memory leaks are observed for libgcrypt.so.11 in multi-thread mode
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Memory leaks are observed for libgcrypt.so.11 in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
> ::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$<bufctl_audit 0x7f53b0: next addr slab 0 7f3700 21aa50 0x7f53bc: cache timestamp thread 20b188 738886035200566511 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 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`_ZN12SSLSETDriver9onReceiveEv+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@... To: help-gnutls@... 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 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@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... To: help-gnutls@... 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$<bufctl_audit 0x7f53b0: next addr slab 0 7f3700 21aa50 0x7f53bc: cache timestamp thread 20b188 738886035200566511 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 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`_ZN12SSLSETDriver9onReceiveEv+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@... To: help-gnutls@... 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 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 轻松交流和共享！ 立刻下载！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... To: help-gnutls@... 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@... To: help-gnutls@... 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$<bufctl_audit 0x7f53b0: next addr slab 0 7f3700 21aa50 0x7f53bc: cache timestamp thread 20b188 738886035200566511 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 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`_ZN12SSLSETDriver9onReceiveEv+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@... To: help-gnutls@... 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 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 轻松交流和共享！ 立刻下载！ Messenger保护盾2.0，更安全可靠的Messenger聊天！ 现在就下载！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... > To: tang__tong@... > CC: help-gnutls@...; gcrypt-devel@... > > 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 <tang__tong@...>: > > 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$<bufctl_audit > > 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@... > > To: help-gnutls@... > > 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@... > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > 搜索本应是快乐的，不是么? 快乐搜索，有问必应！微软隆重推出! 立即试用！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Simon Josefsson-2
::
Rate this Message:
|
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > 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首页！ 立刻访问！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... To: nmav@... Date: Mon, 19 Oct 2009 03:11:07 +0000 CC: simon@...; help-gnutls@... 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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > 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首页！ 立刻访问！ 使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > 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 搜索本应是快乐的，不是么? 快乐搜索，有问必应！微软隆重推出! 立即试用！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > 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 聊天+搜索+邮箱 想要轻松出游,手机MSN帮你搞定! 立刻下载！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > 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。 了解详情。 _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > > 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 <tang__tong@...>: > > 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@... > >> To: tang__tong@... > >> CC: simon@...; help-gnutls@... > >> 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聊天！ 现在就下载！ _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
|
|
Re: Memory leaks are observed for libgnutls in multi-thread mode
by Nikos Mavrogiannopoulos
::
Rate this Message:
|
|
|
RE: Memory leaks are observed for libgnutls in multi-thread mode
by tangtong
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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@... To: nmav@... Date: Fri, 23 Oct 2009 14:28:50 +0000 CC: simon@...; help-gnutls@... 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@... > To: tang__tong@... > CC: simon@...; help-gnutls@... > > 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 <tang__tong@...>: > > 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@... > >> To: tang__tong@... > >> CC: simon@...; help-gnutls@... > >> 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聊天！ 现在就下载！ // demo0.cpp : Defines the entry point for the console application. // #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <unistd.h> #include <sys/socket.h> #include <sys/types.h> #include <stdexcept> #include <netinet/in.h> #include <arpa/inet.h> #include <inttypes.h> #include <fcntl.h> #include <errno.h> #include <poll.h> #include <string.h> #include <unistd.h> #include <gnutls/gnutls.h> #include <gnutls/x509.h> #include <gcrypt.h> #define SA struct sockaddr #define SOCKET_ERR(err,s) if(err==-1) {perror(s);return(1);} #define MAX_BUF 1024 #define PORT 5556 void DisplayError(); #define CERT_FILE "ttcert.pem" #define KEY_FILE "ttkey.pem" #define CAFILE "ca.pem" gnutls_certificate_credentials_t x509_cred; gnutls_x509_crt_t crt; gnutls_x509_privkey_t key; static gnutls_datum_t load_file (const char *file) { FILE *f; gnutls_datum_t loaded_file = { NULL, 0 }; long filelen; void *ptr; if (!(f = fopen (file, "r")) || fseek (f, 0, SEEK_END) != 0 || (filelen = ftell (f)) < 0 || fseek (f, 0, SEEK_SET) != 0 || !(ptr = malloc ((size_t) filelen)) || fread (ptr, 1, (size_t) filelen, f) < (size_t) filelen) { return loaded_file; } loaded_file.data = (unsigned char*)ptr; loaded_file.size = (unsigned int) filelen; return loaded_file; } static void unload_file (gnutls_datum_t data) { free (data.data); } static void load_keys() { int ret; gnutls_datum_t data; data = load_file (CERT_FILE); if (data.data == NULL) { fprintf (stderr, "*** Error loading cert file.\n"); return; } gnutls_x509_crt_init (&crt); ret = gnutls_x509_crt_import (crt, &data, GNUTLS_X509_FMT_PEM); if (ret < 0) { fprintf (stderr, "*** Error loading key file: %s\n", gnutls_strerror (ret)); return; } unload_file (data); data = load_file (KEY_FILE); if (data.data == NULL) { fprintf (stderr, "*** Error loading key file.\n"); return; } gnutls_x509_privkey_init (&key); /*ret = gnutls_x509_privkey_import (key, &data, GNUTLS_X509_FMT_PEM); if (ret < 0) { fprintf (stderr, "*** Error loading key file: %s\n", gnutls_strerror (ret)); }*/ ret =gnutls_x509_privkey_import_pkcs8(key,&data,GNUTLS_X509_FMT_PEM,"moto",0); if (ret < 0) { fprintf (stderr, "*** Error loading key file: %s\n", gnutls_strerror (ret)); } unload_file (data); } gnutls_datum_t cacheItem; int db_store_func(void *, gnutls_datum_t key, gnutls_datum_t data) { cacheItem.size = data.size; cacheItem.data = (unsigned char*)malloc ((size_t) data.size); memcpy(cacheItem.data,data.data,data.size); return 0; } gnutls_datum_t db_retr_func(void *, gnutls_datum_t key) { gnutls_datum_t result = { NULL, 0 }; result = cacheItem; return cacheItem; } int db_remove_func(void *, gnutls_datum_t key) { return 0; } ssize_t pullFunc(gnutls_transport_ptr_t sock, void* buffer ,size_t size) { int ret = read((int)sock, (char*)buffer, size); return ret; } ssize_t pushFunc(gnutls_transport_ptr_t sock,const void* buffer, size_t size) { int ret = write((int)sock, (char*)buffer, size); return ret; } gnutls_priority_t priority_cache; static gnutls_session_t initialize_tls_session (void) { gnutls_session_t session; gnutls_init (&session, GNUTLS_SERVER); gnutls_priority_set (session, priority_cache); gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, x509_cred); // gnutls_db_set_store_function(session,db_store_func); // gnutls_db_set_retrieve_function(session,db_retr_func); // gnutls_db_set_remove_function(session,db_remove_func); /* request client certificate if any. */ //gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST); /* Set maximum compatibility mode. This is only suggested on public webservers * that need to trade security for compatibility */ //gnutls_session_enable_compatibility_mode (session); gnutls_transport_set_pull_function(session,pullFunc); gnutls_transport_set_push_function(session,pushFunc); return session; } void print_info (gnutls_session_t session) { const char *tmp; gnutls_credentials_type_t cred; gnutls_kx_algorithm_t kx; /* print the key exchange¡¯s algorithm name */ kx = gnutls_kx_get (session); tmp = gnutls_kx_get_name (kx); printf ("- Key Exchange: %s\n", tmp); /* Check the authentication type used and switch * to the appropriate. */ cred = gnutls_auth_get_type (session); switch (cred) { case GNUTLS_CRD_IA: printf ("- TLS/IA session\n"); break; #ifdef ENABLE_SRP case GNUTLS_CRD_SRP: printf ("- SRP session with username %s\n", gnutls_srp_server_get_username (session)); break; #endif case GNUTLS_CRD_PSK: /* This returns NULL in server side. */ if (gnutls_psk_client_get_hint (session) != NULL) printf ("- PSK authentication. PSK hint ¡¯%s¡¯\n", gnutls_psk_client_get_hint (session)); /* This returns NULL in client side. */ if (gnutls_psk_server_get_username (session) != NULL) printf ("- PSK authentication. Connected as ¡¯%s¡¯\n", gnutls_psk_server_get_username (session)); break; case GNUTLS_CRD_ANON: /* anonymous authentication */ printf ("- Anonymous DH using prime of %d bits\n", gnutls_dh_get_prime_bits (session)); break; case GNUTLS_CRD_CERTIFICATE: /* certificate authentication */ /* Check if we have been using ephemeral Diffie-Hellman. */ if (kx == GNUTLS_KX_DHE_RSA || kx == GNUTLS_KX_DHE_DSS) { printf ("\n- Ephemeral DH using prime of %d bits\n", gnutls_dh_get_prime_bits (session)); } /* if the certificate list is available, then * print some information about it. */ //print_x509_certificate_info (session); } /* switch */ /* print the protocol¡¯s name (ie TLS 1.0) */ tmp = gnutls_protocol_get_name (gnutls_protocol_get_version (session)); printf ("- Protocol: %s\n", tmp); /* print the certificate type of the peer. * ie X.509 */ tmp = gnutls_certificate_type_get_name (gnutls_certificate_type_get (session)); printf ("- Certificate Type: %s\n", tmp); /* print the compression algorithm (if any) */ tmp = gnutls_compression_get_name (gnutls_compression_get (session)); printf ("- Compression: %s\n", tmp); /* print the name of the cipher used. * ie 3DES. */ tmp = gnutls_cipher_get_name (gnutls_cipher_get (session)); printf ("- Cipher: %s\n", tmp); /* Print the MAC algorithms name. * ie SHA1 */ tmp = gnutls_mac_get_name (gnutls_mac_get (session)); printf ("- MAC: %s\n", tmp); return; } int main(int argc, char* argv[]) { int err, listen_sd; int sd, ret; struct sockaddr_in sa_serv; struct sockaddr_in sa_cli; int client_len; char topbuf[512]; char buffer[MAX_BUF + 1]; int optval = 1; gnutls_session_t session; struct pollfd client; bool handshake; gnutls_global_init (); gnutls_certificate_allocate_credentials (&x509_cred); load_keys(); ret = gnutls_certificate_set_x509_key(x509_cred,&crt,1,key); gnutls_priority_init (&priority_cache, "NORMAL:+VERS-TLS1.2", NULL); if(ret <0) { fprintf (stderr, "*** Error loading key file: %s\n", gnutls_strerror (ret)); } /* Socket operations */ listen_sd = socket (AF_INET, SOCK_STREAM, 0); SOCKET_ERR (listen_sd, "socket"); memset (&sa_serv,0 , sizeof (sa_serv)); sa_serv.sin_family = AF_INET; sa_serv.sin_addr.s_addr = INADDR_ANY; sa_serv.sin_port = htons (PORT); /* Server Port number */ setsockopt (listen_sd, SOL_SOCKET, SO_REUSEADDR, (void *) &optval, sizeof (int)); err = bind (listen_sd, (SA *) & sa_serv, sizeof (sa_serv)); SOCKET_ERR (err, "bind"); err = listen (listen_sd, 1024); SOCKET_ERR (err, "listen"); printf ("Server ready. Listening to port %d.\n\n", PORT); client_len = sizeof (sa_cli); while(1) { char* t = new char[100]; session = initialize_tls_session (); handshake = true; //gnutls_transport_set_pull_function(session,pullFunc); sd = accept (listen_sd, (SA *)& sa_cli, (socklen_t*)&client_len); printf ("- connection from %s, port %d\n", inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf,sizeof (topbuf)), ntohs (sa_cli.sin_port)); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); //int flags = fcntl(sd, F_GETFL, 0); //fcntl(sd, F_SETFL, flags | O_NONBLOCK); client.fd = sd; client.events = POLLRDNORM; while(1) { ret = poll(&client,1,-1); if(ret > 0) { if(handshake) { ret = gnutls_handshake (session); if (ret < 0 && gnutls_error_is_fatal (ret)) { fprintf (stderr, "*** Handshake has failed (%s)\n\n",gnutls_strerror (ret)); break; } else if(ret <0) { printf("non-fatal error(%s), go on...\n",gnutls_strerror (ret)); } else { printf ("- Handshake was completed\n"); print_info(session); handshake = false; } } else { memset (buffer, 0, MAX_BUF + 1); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) { printf ("\n- Peer has closed the GNUTLS connection\n"); break; } else if (ret < 0) { fprintf (stderr, "\n*** Received corrupted data(%d). Closing the connection.\n", ret); break; } else if (ret > 0) { printf("data received, %d %s\n",ret,buffer); gnutls_record_send (session, buffer, strlen (buffer)); } } } else { printf("Socket abnormal situation...\n"); } } printf("close session and socket\n"); gnutls_bye (session, GNUTLS_SHUT_RDWR); close(sd); gnutls_deinit (session); } close(listen_sd); gnutls_certificate_free_credentials(x509_cred); gnutls_priority_deinit(priority_cache); gnutls_global_deinit(); printf("end of test!\n"); while(1) { sleep(10); } return 0; } // demo0.cpp : Defines the entry point for the console application. // #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <unistd.h> #include <sys/socket.h> #include <sys/types.h> #include <stdexcept> #include <netinet/in.h> #include <arpa/inet.h> #include <inttypes.h> #include <fcntl.h> #include <errno.h> #include <poll.h> #include <string.h> #include <unistd.h> #include <gnutls/gnutls.h> #include <gnutls/x509.h> #include <gcrypt.h> #define SA struct sockaddr #define SOCKET_ERR(err,s) if(err==-1) {perror(s);return(1);} #define MAX_BUF 1024 #define SERVER "200.61.250.16" #define PORT 5556 #define MSG "GET / HTTP/1.0\r\n\r\n" void DisplayError(); #define CAFILE "ttcert.pem" gnutls_certificate_credentials_t x509_cred; gnutls_x509_crt_t crt; gnutls_x509_privkey_t key; int buildClientSocket(const char* szIpAddress_,int nPort_) { struct sockaddr_in sin; int addr; memset(&sin, 0, sizeof(sin)); sin.sin_family = AF_INET; addr = inet_addr(szIpAddress_); if (addr == -1 ) { return -1;//invalid ip address } else { sin.sin_addr.s_addr = addr; } sin.sin_port = htons((u_short)nPort_); int fd = socket(AF_INET, SOCK_STREAM, 0); if (fd < 0) { return -1; } /* Connect the socket to other module*/ if (connect(fd, (struct sockaddr *)&sin, sizeof(sin)) < 0) { close(fd); return -1; } return fd; } gnutls_priority_t priority_cache; static gnutls_session_t initialize_tls_session (void) { gnutls_session_t session; gnutls_init (&session, GNUTLS_SERVER); gnutls_priority_set (session, priority_cache); gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, x509_cred); /* request client certificate if any. */ gnutls_certificate_server_set_request (session, GNUTLS_CERT_REQUEST); /* Set maximum compatibility mode. This is only suggested on public webservers * that need to trade security for compatibility */ gnutls_session_enable_compatibility_mode (session); return session; } void print_info (gnutls_session_t session) { const char *tmp; gnutls_credentials_type_t cred; gnutls_kx_algorithm_t kx; /* print the key exchange¡¯s algorithm name */ kx = gnutls_kx_get (session); tmp = gnutls_kx_get_name (kx); printf ("- Key Exchange: %s\n", tmp); /* Check the authentication type used and switch * to the appropriate. */ cred = gnutls_auth_get_type (session); switch (cred) { case GNUTLS_CRD_IA: printf ("- TLS/IA session\n"); break; #ifdef ENABLE_SRP case GNUTLS_CRD_SRP: printf ("- SRP session with username %s\n", gnutls_srp_server_get_username (session)); break; #endif case GNUTLS_CRD_PSK: /* This returns NULL in server side. */ if (gnutls_psk_client_get_hint (session) != NULL) printf ("- PSK authentication. PSK hint ¡¯%s¡¯\n", gnutls_psk_client_get_hint (session)); /* This returns NULL in client side. */ if (gnutls_psk_server_get_username (session) != NULL) printf ("- PSK authentication. Connected as ¡¯%s¡¯\n", gnutls_psk_server_get_username (session)); break; case GNUTLS_CRD_ANON: /* anonymous authentication */ printf ("- Anonymous DH using prime of %d bits\n", gnutls_dh_get_prime_bits (session)); break; case GNUTLS_CRD_CERTIFICATE: /* certificate authentication */ /* Check if we have been using ephemeral Diffie-Hellman. */ if (kx == GNUTLS_KX_DHE_RSA || kx == GNUTLS_KX_DHE_DSS) { printf ("\n- Ephemeral DH using prime of %d bits\n", gnutls_dh_get_prime_bits (session)); } /* if the certificate list is available, then * print some information about it. */ //print_x509_certificate_info (session); } /* switch */ /* print the protocol¡¯s name (ie TLS 1.0) */ tmp = gnutls_protocol_get_name (gnutls_protocol_get_version (session)); printf ("- Protocol: %s\n", tmp); /* print the certificate type of the peer. * ie X.509 */ tmp = gnutls_certificate_type_get_name (gnutls_certificate_type_get (session)); printf ("- Certificate Type: %s\n", tmp); /* print the compression algorithm (if any) */ tmp = gnutls_compression_get_name (gnutls_compression_get (session)); printf ("- Compression: %s\n", tmp); /* print the name of the cipher used. * ie 3DES. */ tmp = gnutls_cipher_get_name (gnutls_cipher_get (session)); printf ("- Cipher: %s\n", tmp); /* Print the MAC algorithms name. * ie SHA1 */ tmp = gnutls_mac_get_name (gnutls_mac_get (session)); printf ("- MAC: %s\n", tmp); return; } int main(int argc, char* argv[]) { int ret, sd, ii; gnutls_session_t session; char buffer[MAX_BUF + 1]; const char *err; gnutls_certificate_credentials_t xcred; gnutls_global_init (); gnutls_certificate_allocate_credentials (&xcred); gnutls_certificate_set_x509_trust_file (xcred, CAFILE, GNUTLS_X509_FMT_PEM); for(int i=0;i<1;i++) { gnutls_init (&session, GNUTLS_CLIENT); ret = gnutls_priority_set_direct (session, "NONE:+VERS-TLS1.2:+AES-256-CBC:+RSA:+SHA256:+COMP-NULL", &err); //ret = gnutls_priority_set_direct (session, "NORMAL", &err); if (ret < 0) { if (ret == GNUTLS_E_INVALID_REQUEST) { fprintf (stderr, "Syntax error at: %s\n", err); } exit (1); } gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, xcred); sd = buildClientSocket(SERVER,PORT); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); ret = gnutls_handshake (session); if (ret < 0) { fprintf (stderr, "*** Handshake failed\n"); gnutls_perror (ret); goto end; } else { printf ("- Handshake was completed\n"); print_info(session); } gnutls_record_send (session, MSG, strlen (MSG)); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) { printf ("- Peer has closed the TLS connection\n"); goto end; } else if (ret < 0) { fprintf (stderr, "*** Error: %s\n", gnutls_strerror (ret)); goto end; } printf ("- Received %d bytes: ",ret); for (ii = 0; ii < ret; ii++) { fputc (buffer[ii], stdout); } gnutls_bye (session, GNUTLS_SHUT_RDWR); end: close(sd); gnutls_deinit (session); } printf("end of test!\n"); gnutls_certificate_free_credentials (xcred); gnutls_global_deinit (); return 0; } _______________________________________________ Help-gnutls mailing list Help-gnutls@... http://lists.gnu.org/mailman/listinfo/help-gnutls |
gnutls_8tps.log.gz (1K) | < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
