Bug 693470

Summary:	openldap-clients do not work correctly with -Z option
Product:	Red Hat Enterprise Linux 6	Reporter:	Ondrej Moriš <omoris>
Component:	openldap	Assignee:	Jan Synacek <jsynacek>
Status:	CLOSED CURRENTRELEASE	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.1	CC:	dspurek, jplans, ovasik, rmeggins, rvokal, tsmetana
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	693471 (view as bug list)		Environment:
Last Closed:	2013-06-20 11:37:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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