php5-ldap TLS (start_tls) quirks

Bug #240387 reported by Martin Adler
4
Affects Status Importance Assigned to Milestone
php5 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: php5-ldap

After switching from gentoo i386 to ubuntu hardy 8.04 x64, using the same configuration (of course adapted to the new host system), any PHP script that wants to issue a startTLS behaves unpredicatebly. Best example is phpLDAPadmin which at times lets you login and edit a record without a problem and on updating the tree fails with the usual PHP error message about not being able to start TLS. At other times, it does not even let me login.

All other services, be it authnz-ldap, libnss-ldap, libpam-ldap work without a flaw. I come to suspect the the php5-ldap module itself has a bug (maybe only x64 related).

I am unable to get good debug output out of the module so if you have some advice on how to receive this, I would be happy to post it along with this report.

Revision history for this message
Chuck Short (zulcss) wrote :

This might be due to openldap quirks can you enable hardy-proposed and test out the new openldap version there?

Thanks
chuck

Chuck Short (zulcss)
Changed in php5:
status: New → Incomplete
Revision history for this message
Martin Adler (martin-adler) wrote :

This is _not_ solely related to php5-ldap start_tls. After having a script on a htaccess protected webserver reload every five minutes, authnz-ldap also brings the error...

Will check with hardy-proposed on the weekend.

Revision history for this message
Martin Adler (martin-adler) wrote :

Just tried hardy-proposed version of slapd and it does _not_ help with the startTLS problem.

A failed connection looks like this:

Jun 24 11:23:57 srv-bs1 slapd[9577]: conn=0 fd=15 ACCEPT from IP=127.0.0.1:58521 (IP=0.0.0.0:389)
Jun 24 11:23:57 srv-bs1 slapd[9577]: conn=0 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jun 24 11:23:57 srv-bs1 slapd[9577]: conn=0 op=0 STARTTLS
Jun 24 11:23:57 srv-bs1 slapd[9577]: conn=0 op=0 RESULT oid= err=0 text=
Jun 24 11:23:58 srv-bs1 slapd[9577]: conn=0 fd=15 TLS established tls_ssf=32 ssf=32
Jun 24 11:23:58 srv-bs1 slapd[9577]: conn=0 op=1 UNBIND
Jun 24 11:23:58 srv-bs1 slapd[9577]: conn=0 fd=15 closed

So there is an immediate unbind after a successful STARTTLS.

Revision history for this message
Martin Adler (martin-adler) wrote :

I have turned off authnz-ldap apache authentication for the specific site and that seems to do the trick ... of course now all my pages are out in the open but at least the scripts run with startTLS ... so it seems to be a combination of starttls with apache authnz-ldap config and the php script itself using starttls ...

Revision history for this message
Adam Sommer (asommer) wrote :

I think I was able to reproduce this, but the start_tls errors were intermittent. I'm testing on an P3 448MHz, and initially had the error quite frequently. I then updated all the packages on the system and the error became less frequent. I also updated the slapd indexes to match our production system. After updating the indexs using slapindex, it was much harder to recreate the error.

For me it only seemed to happen when slapd was under heavy load, and only with php5-ldap I also tested with python-ldap and didn't see the error. Additionally I kept Apache configured with authnz-ldap during my tests. I ran slapd from console using:

  sudo slapd -u openldap -g openldap -f /etc/ldap/slapd -d -1

and didn't see any errors between when an start_tls error occurred and when one didn't.

Can you post your indexes from /etc/ldap/slapd.conf?

Thanks,
Adam

Revision history for this message
Martin Adler (martin-adler) wrote :

I missed to state that these errors are indeed sporadic.

Here are my indexes:

index objectClass,entryCSN,entryUUID eq
index cn,sn,uid,displayname pres,sub,eq
index mail eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index sambaGroupType eq
index sambaSIDList eq
index default sub

Revision history for this message
Martin Adler (martin-adler) wrote :

This bug seems solved when using the latest versions of apache2, php5-ldap, and slapd (etc).

Revision history for this message
Chuck Short (zulcss) wrote :

From hardy?

Revision history for this message
Martin Adler (martin-adler) wrote :

I spoke too soon. After using the combination for a while, the problems returned.

I am still on hardy-proposed for the webservices and hardy for ldap-server. Can anyone confirm this? I know that Adam was able to reproduce the sporadic behavior. I am guessing at gnutls, but have not run strace against slapd, so I really can't tell.

Revision history for this message
Martin Adler (martin-adler) wrote :

I was finally able to capture an strace of slapd with the error happening (apache auth_ldap failing the starttls):

Captured with the following command:

strace /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -d 255

See attached text file (large part of certificate dump removed).

Revision history for this message
Elliot (web-marlboro) wrote :

I can confirm this issue for both Apache2 with the authnz_ldap module and php5-ldap running on Ubuntu Hardy x64.

I've tested against both a dapper server running slapd and a hardy server running slapd. The problem seems worse when the ldap server is also running under Hardy.

The failed logins are inconsistent, and when Apache fails it gives a 500 error, php5-ldap seems to just connect and immediately disconnect from ldap and fail to authenticate.

The only solution we've found is to install stunnel4 as a client and send requests to ldap on the localhost and have stunnel convert them to ldaps on the remote host.

I have noticed that in Hardy slapd is now using gnutls instead of openssl, could this be related?
Does anyone know if php5-ldap is calling the local ldap client to make the connection?
Does it error because it is using an openldap client to talk to a gnutls server?
Has anyone figured out a more appropriate fix?

Chuck Short (zulcss)
Changed in php5 (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.