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
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
-
Howard Chu -
Jan Vcelak