RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 693470 - openldap-clients do not work correctly with -Z option
Summary: openldap-clients do not work correctly with -Z option
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-04 18:53 UTC by Ondrej Moriš
Modified: 2013-06-20 11:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 693471 (view as bug list)
Environment:
Last Closed: 2013-06-20 11:37:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ondrej Moriš 2011-04-04 18:53:50 UTC 
Description of problem:

When using openldap-clients (e.g. ldapsearch) with -Z option and start_tls fails (due to, for instance, invalid TLS_CACERT), the communication does not proceed and they fail with non-zero exit status.

According to documentation, -Z option means that TLS will be preferred for communication, but not required. In other words, if for some reason TLS cannot be negotiated, then client will try continue with unsecured communication.

Version-Release number of selected component (if applicable):

openldap-2.4.23-14.el6

How reproducible:

Always.

Steps to Reproduce:

1. Setup server to use TLS.
2. LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -Z 
  
Actual results:

ldap_start_tls: Connect error (-11)
 additional info: TLS error -8172:Unknown code ___f 20
ldap_result: Can't contact LDAP server (-1)

Expected results:

Success.

Additional info:

* see RHTS test for more details (configuration, etc.)
* this seems to be introduced with version 2.4
Comment 2 Jan Vcelak 2011-05-23 09:15:15 UTC 
This issue was not introduced by switching to NSS. Old OpenLDAP with OpenSSL behaves the same.

[root@f12 ~]# rpm -qa openldap\*
openldap-2.4.19-6.fc12.x86_64
openldap-clients-2.4.19-6.fc12.x86_64
openldap-servers-2.4.19-6.fc12.x86_64
[root@f12 ~]# LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -x
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
[root@f12 ~]# LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -x -Z
ldap_start_tls: Connect error (-11)
ldap_result: Can't contact LDAP server (-1)
[root@f12 ~]# LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -x -ZZ
ldap_start_tls: Connect error (-11)
[root@f12 ~]#
Comment 3 Jan Vcelak 2011-05-23 15:30:54 UTC 
(In reply to comment #0)
> According to documentation, -Z option means that TLS will be preferred for
> communication, but not required. In other words, if for some reason TLS cannot
> be negotiated, then client will try continue with unsecured communication.

When TLS session is requested (by specifying '-Z' option) LDAP extended request (StartTLS) is sent by client to the server. If the certificate verification fails, the communication will continue over established TLS channel. Unsecure channel is used only if server refuses StartTLS request (in case when TLS is not supported by server).

We use deferred TLS initialization. If the server supports TLS and accepts StartTLS request, it is supposed that all following messages will be encrypted. The TLS on the client side is initialized after server acceptance of StartTLS. If something goes wrong (e.g. the certificates can not be read), unencrypted communication will fail as the server expects encrypted message. In this case, we will get the described error.

Anyway, there are probably two ways of fixing this:

1.) Initialize client certificates before sending StartTLS request.
2.) Close the TLS connection and establish a new unencrypted one when this situation happens.

I don't know yet, how difficult the change will be. In the second case, I'm not sure if we can detect the situation safely.

Rich, please, you wrote the TLS code. Do you agree with me? Or are there other reasonable possibilities? 

Jan
Comment 4 Rich Megginson 2011-05-23 16:09:52 UTC 
(In reply to comment #3)
> (In reply to comment #0)
> > According to documentation, -Z option means that TLS will be preferred for
> > communication, but not required. In other words, if for some reason TLS cannot
> > be negotiated, then client will try continue with unsecured communication.
> 
> When TLS session is requested (by specifying '-Z' option) LDAP extended request
> (StartTLS) is sent by client to the server. If the certificate verification
> fails, the communication will continue over established TLS channel. Unsecure
> channel is used only if server refuses StartTLS request (in case when TLS is
> not supported by server).
> 
> We use deferred TLS initialization. If the server supports TLS and accepts
> StartTLS request, it is supposed that all following messages will be encrypted.
> The TLS on the client side is initialized after server acceptance of StartTLS.
> If something goes wrong (e.g. the certificates can not be read), unencrypted
> communication will fail as the server expects encrypted message. In this case,
> we will get the described error.
> 
> Anyway, there are probably two ways of fixing this:
> 
> 1.) Initialize client certificates before sending StartTLS request.

I think we would have to change the StartTLS protocol to handle this case.

> 2.) Close the TLS connection and establish a new unencrypted one when this
> situation happens.

This is the safest way to go, but I don't know what impact this would have on existing clients.
 
> I don't know yet, how difficult the change will be. In the second case, I'm not
> sure if we can detect the situation safely.
> 
> Rich, please, you wrote the TLS code. Do you agree with me? Or are there other
> reasonable possibilities? 


> 
> Jan
Comment 5 Jan Vcelak 2011-05-23 17:22:30 UTC 
Just came to my mind: maybe this is an expected behavior. The client is obviously configured wrong. In that case, manual pages are not very clear.
Comment 6 Rich Megginson 2011-05-23 17:26:17 UTC 
(In reply to comment #5)
> Just came to my mind: maybe this is an expected behavior. The client is
> obviously configured wrong. In that case, manual pages are not very clear.

This does not appear to be a regression from the openldap + openssl behavior, so it should be better clarified in the manual pages.
Comment 7 Jan Vcelak 2011-05-23 21:14:32 UTC 
I will write to OpenLDAP upstream developers to know their attitude. This issue is closely related to RFE bug 644119.
Comment 8 Ondrej Moriš 2011-05-24 13:26:38 UTC 
Well, from the QA point of view - it would be okay just to fix documentation, since the following:

"When TLS session is requested (by specifying '-Z' option) LDAP extended request
(StartTLS) is sent by client to the server. If the certificate verification
fails, the communication will continue over established TLS channel. Unsecure
channel is used only if server refuses StartTLS request (in case when TLS is
not supported by server)."

seems to be reasonable and explains the situation very well (especially the sentence in brackets). Currently man page contains:

       -Z[Z]  Issue StartTLS (Transport Layer Security) extended operation. If
              you use -ZZ, the command will require the operation to  be  suc-
              cessful.

which is pretty confusing and I have to admit, that I have almost no clue what should happen when using -Z. But, of course, we should keep up with the upstream, i.e. the meaning of -Z option should be understood in the same way by RH and by the upstream.
Comment 11 RHEL Program Management 2012-07-10 08:29:59 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 12 RHEL Program Management 2012-07-11 01:44:42 UTC 
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 13 RHEL Program Management 2012-12-14 08:27:57 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 15 Jan Synacek 2013-06-20 11:37:08 UTC 
Works as expected in RHEL-6.4 (openldap-servers-2.4.23-31.el6):

[root@rhel-6 ~]# LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -x 
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

[root@rhel-6 ~]# LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -x -Z
ldap_start_tls: Protocol error (2)
	additional info: unsupported extended operation
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 3
result: 32 No such object

# numResponses: 1
[root@rhel-6 ~]# LDAPTLS_CACERT=/ca/cert/does/not/exist ldapsearch -x -ZZ
ldap_start_tls: Protocol error (2)
	additional info: unsupported extended operation
Note You need to log in before you can comment on or make changes to this bug.