Jan Vcelak wrote:
I'm trying to fix one of the OpenLDAP bugs which was reported to Red Hat
bugzilla . 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
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
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?
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/