[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
client StartTLS issue and return codes enhancement
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.
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