[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "error in SSLv3 flush data" when connecting from network



--On Wednesday, February 28, 2007 1:29 PM +0200 Antonis Christofides <anthony@itia.ntua.gr> wrote:

I wrote: 
A tls connection between a client and a 2.3.30 slapd hangs while the
server is giving the certificate; but this does not happen if the
server is run with -d 2 or higher, or if the client is the server
itself.

My slapd is the Debian-etch-packaged 2.3.30.

Quanah Gibson-Mount <quanah@stanford.edu> replied: 
Problems with SSL on Debian are well known, and it is due to the fact
that they long ago patched OpenLDAP 2.1 to compile against GnuTLS


Thanks for the information. I downloaded and compiled 2.3.32 and I
have exactly the same symptom.  I used
  ./configure --with-tls
and had to install package libssl-dev for it to work.

Could it be a dependency on a Debian shared library?  While
investigating whether this is the case with gnutls, I found out that
the slapd package does depend on the libgnutls package, but I can't
find the library dependence using ldd, and when I try "lsof|grep
gnutls", slapd (the Debian slapd) isn't listed there (I can see slapd
if I run "lsof|grep libssl).  So either the Debian slapd does not
actually use gnutls, or I don't know what's going on here (which is
very likely).


The libraries compiled against GnuTLS are:

:/usr/lib> ldd libldap.so.2.0.130
       liblber.so.2 => /usr/lib/liblber.so.2 (0xa7f16000)
       libresolv.so.2 => /lib/tls/libresolv.so.2 (0xa7f03000)
       libdl.so.2 => /lib/tls/libdl.so.2 (0xa7f00000)
       libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0xa7ed3000)
       libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xa7ebe000)
       libgnutls.so.11 => /usr/lib/libgnutls.so.11 (0xa7e57000)
       libpthread.so.0 => /lib/tls/libpthread.so.0 (0xa7e48000)
       libc.so.6 => /lib/tls/libc.so.6 (0xa7d12000)
       /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x75555000)
       libtasn1.so.2 => /usr/lib/libtasn1.so.2 (0xa7d01000)
       libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xa7cb4000)
       libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xa7cb0000)
       libz.so.1 => /usr/lib/libz.so.1 (0xa7c9e000)
       libnsl.so.1 => /lib/tls/libnsl.so.1 (0xa7c8a000)


The problem comes when the user ID running slapd, and the user ID handling other things that load /usr/lib/libldap.so.* are the same, whether that is root or the ldap user. As soon as both sets of libraries get loaded into the same user space, problems ensue.

Now, I just ran my build of OpenLDAP 2.3.28+patches (pretty much 2.3.32) at -d 0, and did a TLS bind to it, and there was no problem. (ldapsearch -ZZZ).
I also ran my build of OpenLDAP 2.3.33 at -d 0, and did a TLS bind to it, and there was no problem.

So I can't reproduce the problem you are reporting, and this is on a debian server where I'm sure that slapd is only linked against the software pieces I've built myself.

ldd slapd
/usr/local/lib/libhoard.so => /usr/local/lib/libhoard.so (0x00002ba7e0e35000)
/usr/lib/libdl.so => /usr/lib/libdl.so (0x00002ba7e102a000)
libldap_r-2.3.so.0 => /usr/local/lib/libldap_r-2.3.so.0 (0x00002ba7e112d000)
liblber-2.3.so.0 => /usr/local/lib/liblber-2.3.so.0 (0x00002ba7e1276000)
libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x00002ba7e1385000)
libssl.so.0.9.8 => /usr/local/lib/libssl.so.0.9.8 (0x00002ba7e149d000)
libcrypto.so.0.9.8 => /usr/local/lib/libcrypto.so.0.9.8 (0x00002ba7e15e4000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00002ba7e185e000)
libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0x00002ba7e1972000)
libwrap.so.0 => /lib/libwrap.so.0 (0x00002ba7e1a79000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002ba7e1b83000)
libc.so.6 => /lib/libc.so.6 (0x00002ba7e1c97000)
libstdc++.so.6 => /usr/local/lib/libstdc++.so.6 (0x00002ba7e1ed6000)
libm.so.6 => /lib/libm.so.6 (0x00002ba7e20d6000)
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x00002ba7e225c000)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002ba7e0d1f000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002ba7e236a000)

Which is most everything, as you can see. ;)


--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html