Bug#823232: [Pkg-openldap-devel] Bug#823232: libldap-2.4-2: Cannot connect to LDAP server with invalid (self-signed or non-standard CA signed) certificate

2016-05-15 Thread aki . tuomi 

> On May 15, 2016 at 6:13 AM Ryan Tandy  wrote:
> 
> 
> On Mon, May 02, 2016 at 05:44:58PM +0300, Aki Tuomi wrote:
> >2. Try connect with openldap -Z -H ldap://server ...
> >
> >Expected behaviour
> >Invalid cert ignored, and TLS continues
> 
> I failed to read this closely enough the first time.
> 
> This is actually not the intended behaviour, though: the meaning of the 
> -Z option is to attempt TLS, but continue without it (cleartext) if the 
> startTLS operation fails. Therefore using TLS_REQCERT allow and -ZZ is a 
> better solution.
> 
> >Actual behaviour
> >Failure with non-descriptive error, debug shows
> >ldap_start_tls: Connect error (-11)
> 
> ... but this is not the expected behaviour, either way!
> 
> There's something odd going on after the certificate is rejected - may 
> be a bug in the GnuTLS support, or in the core TLS implementation - it 
> looks like the client sends a plain Bind request while the the server is 
> still expecting a TLS handshake, possibly. But I'd rather discourage the 
> use of this fallback to cleartext anyway, so I'm not going to look 
> further into that right now. And an OpenSSL-linked slapd closes the 
> connection outright after the TLS negotiation fails, which seems like 
> the more prudent thing to do.

Thank you for your help, the OpenLDAP library documentation could probably be 
better =)

Aki

Bug#823232: [Pkg-openldap-devel] Bug#823232: libldap-2.4-2: Cannot connect to LDAP server with invalid (self-signed or non-standard CA signed) certificate

2016-05-14 Thread Ryan Tandy 

On Mon, May 02, 2016 at 05:44:58PM +0300, Aki Tuomi wrote:

2. Try connect with openldap -Z -H ldap://server ...

Expected behaviour
Invalid cert ignored, and TLS continues


I failed to read this closely enough the first time.

This is actually not the intended behaviour, though: the meaning of the 
-Z option is to attempt TLS, but continue without it (cleartext) if the 
startTLS operation fails. Therefore using TLS_REQCERT allow and -ZZ is a 
better solution.



Actual behaviour
Failure with non-descriptive error, debug shows
ldap_start_tls: Connect error (-11)


... but this is not the expected behaviour, either way!

There's something odd going on after the certificate is rejected - may 
be a bug in the GnuTLS support, or in the core TLS implementation - it 
looks like the client sends a plain Bind request while the the server is 
still expecting a TLS handshake, possibly. But I'd rather discourage the 
use of this fallback to cleartext anyway, so I'm not going to look 
further into that right now. And an OpenSSL-linked slapd closes the 
connection outright after the TLS negotiation fails, which seems like 
the more prudent thing to do.

Bug#823232: [Pkg-openldap-devel] Bug#823232: libldap-2.4-2: Cannot connect to LDAP server with invalid (self-signed or non-standard CA signed) certificate

2016-05-14 Thread Ryan Tandy 

Control: tag -1 confirmed upstream
Control: retitle -1 libldap-2.4-2: default TLS context setup ignores options 
set on connection

Hello,

Sorry for the delayed response.

On Mon, May 02, 2016 at 05:44:58PM +0300, Aki Tuomi wrote:

Most simple usecase:
1. Install slapd with non-default CA signed certificate
2. Try connect with openldap -Z -H ldap://server ...

Expected behaviour
Invalid cert ignored, and TLS continues

Actual behaviour
Failure with non-descriptive error, debug shows
ldap_start_tls: Connect error (-11)


This appears to work for me, tested as follows:

- in a clean jessie system, apt-get install ssl-cert slapd ldap-utils
- add the openldap user to the ssl-cert group
- configure slapd to use the snakeoil (self-signed) certs

$ LDAPTLS_REQCERT=allow ldapwhoami -ZZ -x
anonymous

Another option, which I personally would prefer, is to set the CA cert 
just for LDAP:


$ LDAPTLS_CACERT=/etc/ssl/certs/ssl-cert-snakeoil.pem ldapwhoami -ZZ -x
anonymous


Workaround, of course, is to install the non-standard CA as trusted CA
certificate. But the man page *does* say that it really should work.


Right, installing the non-standard CA system wide should not be 
necessary, for either of the options above.



The same behaviour occurs with direct LDAP library usage with

 int opt = LDAP_OPT_X_TLS_ALLOW;
 ldap_set_option(conn->conn, LDAP_OPT_X_TLS, );
 ldap_set_option(conn->conn, LDAP_OPT_X_TLS_REQUIRE_CERT, );

Again, this should allow non-trusted certificate on peer, which is appears
not to do.


As a side note, the LDAP_OPT_X_TLS option is deprecated in favour of 
ldap_start_tls(3):


http://www.openldap.org/lists/openldap-software/200706/msg00159.html

The documentation apparently doesn't talk about this, but it looks like 
what happens is that you get a default TLS context, initialized using 
the global options, unless you specifically ask for a new one using 
LDAP_OPT_X_TLS_NEWCTX.


So this works:

int require_cert = LDAP_OPT_X_TLS_ALLOW;
rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, _cert);
assert(rc == LDAP_SUCCESS);

int new_ctx = 0;
rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, _ctx);
assert (rc == LDAP_SUCCESS);

rc = ldap_start_tls_s(ld, NULL, NULL);
assert(rc == LDAP_SUCCESS);

and this works:

int require_cert = LDAP_OPT_X_TLS_ALLOW;
rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, _cert);
assert(rc == LDAP_SUCCESS);

LDAP *ld;
rc = ldap_initialize(, "ldap://;);
assert(rc == LDAP_SUCCESS);

rc = ldap_start_tls_s(ld, NULL, NULL);
assert(rc == LDAP_SUCCESS);

but this doesn't work:

int require_cert = LDAP_OPT_X_TLS_ALLOW;
rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, _cert);
assert(rc == LDAP_SUCCESS);

rc = ldap_start_tls_s(ld, NULL, NULL);
assert(rc == LDAP_SUCCESS);

Other people have noticed this, too:

http://stackoverflow.com/a/27713355
http://www.openldap.org/its/?findid=7843

I'm guessing this is intended behaviour, and the documentation should be 
clarified. I'll follow up with upstream. Thanks for the report!

Bug#823232: libldap-2.4-2: Cannot connect to LDAP server with invalid (self-signed or non-standard CA signed) certificate

2016-05-02 Thread Aki Tuomi 
Package: libldap-2.4-2
Version: 2.4.40+dfsg-1+deb8u2
Severity: important

Dear Maintainer,

The behaviour of OpenLDAP CLI and library appears to be broken. There seems to
be no way to allow invalid certificates (despite OpenLDAP library claiming that
it should be possible).

Most simple usecase:
1. Install slapd with non-default CA signed certificate
2. Try connect with openldap -Z -H ldap://server ...

Expected behaviour
Invalid cert ignored, and TLS continues

Actual behaviour
Failure with non-descriptive error, debug shows
ldap_start_tls: Connect error (-11)

Workaround, of course, is to install the non-standard CA as trusted CA
certificate. But the man page *does* say that it really should work.

The same behaviour occurs with direct LDAP library usage with 

  int opt = LDAP_OPT_X_TLS_ALLOW;
  ldap_set_option(conn->conn, LDAP_OPT_X_TLS, );
  ldap_set_option(conn->conn, LDAP_OPT_X_TLS_REQUIRE_CERT, );

Again, this should allow non-trusted certificate on peer, which is appears
not to do.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libldap-2.4-2 depends on:
ii  libc6  2.19-18+deb8u3
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  multiarch-support  2.19-18+deb8u3

libldap-2.4-2 recommends no packages.

libldap-2.4-2 suggests no packages.

-- Configuration Files:
/etc/ldap/ldap.conf changed:
TLS_CACERT /etc/ldap/certs.pem
TLS_REQCERT allow
TLS_CRLCHECK none


-- no debconf information