https://bugs.openldap.org/show_bug.cgi?id=8047

--- Comment #11 from maxime.besson@worteks.com maxime.besson@worteks.com --- Hi,

I understand that fixing timeouts during SSL handshake is not possible in the current state of SSL libraries, but I would like to report what seems to me like a regression in OpenLDAP 2.5/2.6

On my RHEL7 and RHEL8 systems ( OpenLDAP 2.4 built with OpenSSL), I was somehow not able to reproduce the issue mentioned here: NETWORK_TIMEOUT works for ldaps:// URLs and TIMEOUT works for ldap:// URLS + StartTLS

In OpenLDAP 2.4.49 + GnuTLS (Ubuntu Focal), NETWORK_TIMEOUT does not work for ldaps:// URLs but TIMEOUT works for StartTLS

However starting with 2.5 (Debian Bookworm, RHEL9, and also reproduced with a source build of OPENLDAP_REL_ENG_2_6 as well), I observe a different behavior, affecting both GnuTLS and OpenSSL:

The following command enters the CPU loop reported in ITS#10141, and never times out

ldapsearch -H ldaps://stuck-slapd -o network_timeout=5

The following command still times out as expected

ldapsearch -H ldap://stuck-slapd -Z -o timeout=5

To clarify, users of OpenLDAP + OpenSSL will start noticing a large CPU spike that does not timeout, instead of a clean timeout, when a LDAP server becomes unreachable for non-TCP reasons. For instance: I discovered this issue while investigating an outage following a storage issue.