431676 - LDAP authentication fails with "stronger confidentiality required" when using LDAPstarttls

Status: UNCONFIRMED

(Bugzilla :: User Accounts, defect)

Description

[Bryan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Bugzilla 3.0.3

LDAP authentication fails with "stronger confidentiality required" when using LDAPstarttls to connect to an LDAP server that requires confidentiality (no plain-text auth).  There is no where to configure the location of a CA certificate for verification of the server certificate.

It looks like this support may have existed once before it was removed by someone who doesn't understand LDAP.  https://bugzilla.mozilla.org/show_bug.cgi?id=282687

This part of Bugzilla/Auth/Verify/LDAP.pm is incomplete:

    # try to start TLS if needed
    if (Bugzilla->params->{"LDAPstarttls"}) {
        my $mesg = $self->{ldap}->start_tls();
        ThrowCodeError("ldap_start_tls_failed", { error => $mesg->error() })
            if $mesg->code();
    }

start_tls options: http://search.cpan.org/~gbarr/perl-ldap/lib/Net/LDAP.pod#start_tls

The ability to configure the location of a CA certificate path needs to be restored.

Reproducible: Always

Steps to Reproduce:
1. Configure Bugzilla to use LDAP authentication and starttls against an LDAP server that requires confidentiality.
2. Attempt to log in as an LDAP user.
Actual Results:  
An error occurred while trying to search LDAP for "...": stronger confidentiality required

Expected Results:  
Successful login.

Comment 1

[starbrk]

I also can't find a way to specify my CA certificate to establish secure connection to upstream LDAP server. Bugzilla 4.4 (Linux, Apache, MySQL). Using Active Directory's LDAP

Comment 2

[guillomovitch]

If the application layer doesn't allow to set up those parameters, you can always do it directly at the underlying library layer. See TLS_CACERT and TLS_CACERTDIR options in ldap.conf(5).

Comment 3

[starbrk]

Hi,

I want to protect users' passwords from DNS hijack, that's why I need my Bugzilla to connect over TLS and only to authorized server. I put this line to ldap.conf:

TLS_CACERT /etc/openldap/ca.pem

ca.pem is PEM bundle containing 2 certificates: self-signed root CA and intermediate one (signed by that ca). Now, when I try to connect to a fake Active Directory server - Bugzilla still successfully connects and passes user's password to the fake ldap server, I get no error about unsafe connection or certificate error.

Is there something more I need to configure? What steps can I perform to verify Bugzilla is using my CA bundle?

Thanks

Comment 4

[guillomovitch]

Check TLS_REQCERT value. According to the documentation, the default value should be 'hard', which doesn't match your result. BTW, it also requires to also ensure TLS is actually used, and I'm not sure AD supports start_tls option. You'd better use an ldaps:// URI here.

I suggest testing with ldapsearch from the same host to debug the issue.

Comment 5

[starbrk]

I have explicitly defined "TLS_REQCERT hard" and I can see in Wireshark that LDAP establishes SSL connection and the server certificate provided to Bugzilla is signed by a fake authority - no error from Bugzilla side

If I execute ldapsearch from the same machine and request SSL connection I get error as expected:

ldapsearch -Z -b "CN=User1,OU=Users,OU=Enterprise,DC=fakedomain,DC=lan" -h dc.fakedomain.lan -D "CN=User1,OU=Users,OU=Enterprise,DC=fakedomain,DC=lan" -w 12345678 "*"
ldap_start_tls: Connect error (-11)
        additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate)
ldap_result: Can't contact LDAP server (-1)

When I change "TLS_REQCERT never" - the above ldapsearch command completes successfully.

I have tried to use ldaps:// prefix in Bugzilla, but in this case regardless of ldap.conf settings I get error: "Could not start TLS with LDAP server: ldap_start_tls_failed"

Comment 6

[starbrk]

Looks like ldaps:// fails because AD is not listening on TCP 636 port. But still AD supports connecting over TCP 389 port and then initiates SSL connection. Still looking how to make Bugzilla perform as ldapsearch and force verify certificate