Bug 2009534

+++ This bug was initially created as a clone of Bug #1999036 +++

Description of problem:
OpenLDAP 2.4's libldap client library does not send a server name indication (SNI) TLS extension during the TLS handshake. The SNI extension is useful for virtual hosting and application-level routing. For example OpenShift's ingress router can route any traffic that uses TLS with SNI.

OpenLDAP added TLS SNI feature in 2.5 in upstream ticket ITS#9176.

Version-Release number of selected component (if applicable):
All OpenLDAP 2.4 releases

How reproducible:
always

Steps to Reproduce:
1. Use any tool like ldapsearch with ldaps:// URI
2. sniff traffic on port 636/TCP

Actual results:
ClientHello does not have a SNI extension

Expected results:
ClientHello contains a SNI extension for hostname of LDAP server.

Additional info:
https://www.openldap.org/lists/openldap-bugs/202002/msg00421.html

Related upstream commits:
5c0efb9ce83db383631ce79e8f246d73c33b9ab3
b8f34888c3c72e67e822843a9a83b83562f68e79
4265849b0f1e5e2f65da6fea603b7b66a2c9fbc1
e96f90e21229f9d83129db0da017e0fe5a0a27c8

Patch: https://github.com/openldap/openldap/compare/OPENLDAP_REL_ENG_2_4...tiran:sni_2_4.patch

--- Additional comment from Christian Heimes on 2021-09-14 08:13:43 UTC ---

I have tested your scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=75616846 . Wireshark's command line tool shows that the client library is sending a TLS SNI extension with correct hostname. The unpatched version openldap-2.4.59-3.fc35.x86_64 does not send the TLS SNI extension.

# rpm -qa openldap
openldap-2.4.59-3.fc35.x86_64
# LDAPTLS_REQCERT=never ldapsearch -H ldaps://ipa.demo1.freeipa.org -b "" -s base -x > /dev/null

# tshark -Y tls.handshake.type==1 -T fields -e tls.handshake.extensions_server_name -f "port 636"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
ipa.demo1.freeipa.org