I was doing some testing and noticed that when I search for entries using TLS, significantly more memory is used when using client certificates than without them. In fact, memory will eventually be exhausted if the searches are performed indefinitely. Without using them, memory use stays (around) the same value.
I stripped down the config, removed all ACLs except one (to disallow access), and started with an empty database, and get the same results.
I've noticed this in 2.4.11, 2.4.12, and 2.4.13 with OpenSSL 0.9.8i. I do not notice it with an old 2.3.39 instance.
Has anyone noticed anything similar, or can anyone reproduce this?
Dave
--On Tuesday, November 25, 2008 7:24 PM -0500 David Hawes dhawes@vt.edu wrote:
I was doing some testing and noticed that when I search for entries using TLS, significantly more memory is used when using client certificates than without them. In fact, memory will eventually be exhausted if the searches are performed indefinitely. Without using them, memory use stays (around) the same value.
I stripped down the config, removed all ACLs except one (to disallow access), and started with an empty database, and get the same results.
I've noticed this in 2.4.11, 2.4.12, and 2.4.13 with OpenSSL 0.9.8i. I do not notice it with an old 2.3.39 instance.
Has anyone noticed anything similar, or can anyone reproduce this?
Have you run OpenLDAP in this situation under valgrind to see where the leak is occurring?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, November 25, 2008 7:24 PM -0500 David Hawes dhawes@vt.edu wrote:
I was doing some testing and noticed that when I search for entries using TLS, significantly more memory is used when using client certificates than without them. In fact, memory will eventually be exhausted if the searches are performed indefinitely. Without using them, memory use stays (around) the same value.
I stripped down the config, removed all ACLs except one (to disallow access), and started with an empty database, and get the same results.
I've noticed this in 2.4.11, 2.4.12, and 2.4.13 with OpenSSL 0.9.8i. I do not notice it with an old 2.3.39 instance.
Has anyone noticed anything similar, or can anyone reproduce this?
Have you run OpenLDAP in this situation under valgrind to see where the leak is occurring?
I have not, but I intend to do that next. I'll be sure to post the results.
David Hawes wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, November 25, 2008 7:24 PM -0500 David Hawes dhawes@vt.edu wrote:
I was doing some testing and noticed that when I search for entries using TLS, significantly more memory is used when using client certificates than without them. In fact, memory will eventually be exhausted if the searches are performed indefinitely. Without using them, memory use stays (around) the same value.
I stripped down the config, removed all ACLs except one (to disallow access), and started with an empty database, and get the same results.
I've noticed this in 2.4.11, 2.4.12, and 2.4.13 with OpenSSL 0.9.8i. I do not notice it with an old 2.3.39 instance.
Has anyone noticed anything similar, or can anyone reproduce this?
Have you run OpenLDAP in this situation under valgrind to see where the leak is occurring?
I have not, but I intend to do that next. I'll be sure to post the results.
valgrind seems to indicate that the leak occurs in OpenSSL (6,214 bytes are lost each connection with TLS and client certificates).
That said, I find it odd that 2.3.43, linked against the same OpenSSL, does not show this leak. 2.4.6 and up (though I did not test .7-.10) do show the leak. I'm still trying to explain that.
David Hawes wrote:
David Hawes wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, November 25, 2008 7:24 PM -0500 David Hawes dhawes@vt.edu wrote:
I was doing some testing and noticed that when I search for entries using TLS, significantly more memory is used when using client certificates than without them. In fact, memory will eventually be exhausted if the searches are performed indefinitely. Without using them, memory use stays (around) the same value.
I stripped down the config, removed all ACLs except one (to disallow access), and started with an empty database, and get the same results.
I've noticed this in 2.4.11, 2.4.12, and 2.4.13 with OpenSSL 0.9.8i. I do not notice it with an old 2.3.39 instance.
Has anyone noticed anything similar, or can anyone reproduce this?
Have you run OpenLDAP in this situation under valgrind to see where the leak is occurring?
I have not, but I intend to do that next. I'll be sure to post the results.
valgrind seems to indicate that the leak occurs in OpenSSL (6,214 bytes are lost each connection with TLS and client certificates).
That said, I find it odd that 2.3.43, linked against the same OpenSSL, does not show this leak. 2.4.6 and up (though I did not test .7-.10) do show the leak. I'm still trying to explain that.
Here is an excerpt of the valgrind output when using client certificates:
==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 23 ==13311== at 0x401D898: malloc (vg_replace_malloc.c:207) ==13311== by 0x41FCCC4: default_malloc_ex (mem.c:79) ==13311== by 0x41FD33F: CRYPTO_malloc (mem.c:304) ==13311== by 0x428CA65: asn1_item_ex_combine_new (tasn_new.c:191) ==13311== by 0x428C79C: ASN1_item_ex_new (tasn_new.c:85) ==13311== by 0x428ECAA: ASN1_item_ex_d2i (tasn_dec.c:399) ==13311== by 0x428E5F9: ASN1_item_d2i (tasn_dec.c:134) ==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521) ==13311== by 0x4191897: ssl3_accept (s3_srvr.c:462) ==13311== by 0x41AD930: SSL_accept (ssl_lib.c:867) ==13311== by 0x815D00E: ldap_pvt_tls_accept (tls.c:1594) ==13311== by 0x8076926: connection_read_thread (connection.c:1286) ==13311== by 0x813CEE5: ldap_int_thread_pool_wrapper (tpool.c:663) ==13311== by 0x415823F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13311== by 0x43ED49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
It seems like something doesn't get freed properly when client certificates are used, but I have been unable to track it down so far.
On Thu, 4 Dec 2008, David Hawes wrote: ...
Here is an excerpt of the valgrind output when using client certificates:
==13311== 4,906 (92 direct, 4,814 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 23
...
==13311== by 0x4286A57: d2i_X509 (x_x509.c:136) ==13311== by 0x4194F26: ssl3_get_client_certificate (s3_srvr.c:2521)
...
It seems like something doesn't get freed properly when client certificates are used, but I have been unable to track it down so far.
In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: the call to SSL_get_peer_certificate() in tls_get_cert() increments the reference count on the cert and it never gets decremented by a call to X509_free(). Simply adding the call there might not be safe, depending on whether the berval that tls_get_cert_dn() sets up relies on the underlying X509 to stay valid for longer than this chain of calls, as the X509 may be invalidated by a rehandshake.
Philip Guenther
--On Thursday, December 04, 2008 5:47 PM -0800 Philip Guenther guenther+ldapsoft@sendmail.com wrote:
In 2.4.x, tls_get_cert_dn() leaks a reference to the client's X509 cert: the call to SSL_get_peer_certificate() in tls_get_cert() increments the reference count on the cert and it never gets decremented by a call to X509_free(). Simply adding the call there might not be safe, depending on whether the berval that tls_get_cert_dn() sets up relies on the underlying X509 to stay valid for longer than this chain of calls, as the X509 may be invalidated by a rehandshake.
File an ITS please. :)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
David Hawes -
Philip Guenther -
Quanah Gibson-Mount