[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: client StartTLS issue and return codes enhancement

Jan Vcelak wrote:

Hello everyone,

I'm trying to fix one of the OpenLDAP bugs which was reported to Red Hat
bugzilla [1]. But I'm not very sure about the correct behavior of client tools
'-Z' option. In addition, this is closely related to one enhancement, we would
like to propose.

Manual page says:

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


According to my findings, -Z option causes that StartTLS request is sent as
a first operation. And then:

1.) If everything goes well, the client and server will communicate securely.

2.) If the TLS connection is established but the certificate verification is
unsuccessful (e.g. hostname doesn't match), the error message is emitted and
the communication continues over the TLS channel.

3.) If the server doesn't support TLS (or is configured not to use TLS),
StartTLS request is rejected and communication is held insecurely.

4.) If client's TLS configuration is wrong (e.g. TLS_CACERT does not exist),
the client connection will fail with 'Can't contact LDAP server (-1)'.

The situation we are dealing with is the 4th option. Is this an expected
behavior? The problem is, that StartTLS request is sent before processing the
certificates. If the server accepts the request, it expects that all following
communication is encrypted. But the client cannot process the certificates,
ignores the TLS failure and sends the following next unencrypted. The server
doesn't understand it, which leads to mentioned error code.
In general, behavior with invalid configurations is "undefined" - I see no reason to put any particular effort into these areas. After the first time you see a client fail due to a config error, you should simply fix the config. It's unreasonable to expect the client to progress anywhere useful with an invalid config. If the data is actually sensitive enough that you don't want the client to send its next request unencrypted, you should be using -ZZ anyway, so there's no security aspect to this.
Looking at the code, I guess we could insert a call to ldap_pvt_tls_init_def_ctx() in the ldap_start_tls[_s] functions before doing anything else. Again, I don't consider it crucial but if you want to write the patch, go ahead. 


The behavior is the same for OpenSSL and Mozilla NSS. And if it is incorrect,
there at least two possibilities of fixing it, citing from the bug report:

On 2011-05-23 18:09 Rich Megginson wrote:

On 2011-05-23 17:30 Jan Vcelak wrote:


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.


What do you think about that? Is that expected? Are there a better ways of
solving this?

If this is an expected behavior, the manual pages should probably mention it.

Anyway it would be great, if we could resolve the situation, where the
connection to the server fails due to connection error and due to invalid TLS
configuration. At the API level and maybe as a return code of the client
tools. What do you think about this enhancement?

Thank you.

Jan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=693470





--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/