Hello,
quoting ldap.conf(5):
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. ...
I'd like to try the "If no certificate is provided" part, but can't manage to do so. I tried configuring the server to 1) not use any CA certificate or server certificate, 2) only use the CA certificate without any server certificate, 3) specify CA certificate dir with no certs in it, 4) specify CA certificate dir with a valid CA cert and no server certs.
In any case, the client (ldapsearch) doesn't even connect to the server, stating either "SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure" or simply failing to connect with "Can't contact LDAP server (-1)". The server is listening on ldap and ldaps. I tested this using both ldaps and StartTLS.
That leads me to a conclusion that what I'm trying to achieve is not achievable and that the manpage should be changed.
Is the manpage wrong or is there any other way I can test the client with no server certificate provided?
Cheers,
On Tue, Nov 12, 2013 at 2:34 AM, Jan Synacek jsynacek@redhat.com wrote:
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. Is the manpage wrong or is there any other way I can test the client with no server certificate provided?
While troubleshooting an LDAP issue, I stumbled across an IRC log or mailing list comment (can't remember exactly) which basically said that try == hard and the manpage was inaccurate to say anything else (paraphrased). I have not perused the openldap server or client code to verify the accuracy of that statement, but the comment (and your results) matches my experience when troubleshooting.
...Todd
On Tue, Nov 12, 2013 at 2:34 AM, Jan Synacek jsynacek@redhat.com wrote:
Is the manpage wrong or is there any other way I can test the client with no server certificate provided?
I forgot to answer the second part. I just use accept. With tcpdump, you can verify if it is or is not using encryption. It doesn't do cert chain checking so it will accept self-signed certs.
...Todd
Hi!
"It doesn't do cert chain checking so it will accept self-signed certs."
Even if it does cert chain checking, a self-signed certificate will be accepted! What are you saying?
Regards, Ulrich
Todd Lyons tlyons@ivenue.com schrieb am 12.11.2013 um 14:26 in Nachricht
CAFG21ogCpL1q4hBU-y1tqLxRML1xrMN3tVkB-qj23mzBUZJGLg@mail.gmail.com:
On Tue, Nov 12, 2013 at 2:34 AM, Jan Synacek jsynacek@redhat.com wrote:
Is the manpage wrong or is there any other way I can test the client with no server certificate provided?
I forgot to answer the second part. I just use accept. With tcpdump, you can verify if it is or is not using encryption. It doesn't do cert chain checking so it will accept self-signed certs.
...Todd
The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine
On Wed, 13 Nov 2013, Ulrich Windl wrote:
"It doesn't do cert chain checking so it will accept self-signed certs."
Even if it does cert chain checking, a self-signed certificate will be accepted! What are you saying?
His use of the phrase "cert chain checking" was misleading.
With 'allow', the ldap client library doesn't care whether the cert's signature can be validated back to a known-and-trusted root CA.
(If you copied the self-signed cert into the client's trusted CA file or directory, then you might be able to use 'TLS_REQCERT demand' and be secure from MitM attacks.)
Philip Guenther
On Tue, 12 Nov 2013, Jan Synacek wrote:
quoting ldap.conf(5):
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. ...
Yeah, that text is bogus. At least with OpenLDAP 2.4.37 and OpenSSL version 1.0.1c and earlier, 'TLS_REQCERT try' is exactly the same as 'TLS_REQCERT demand'. The only difference in the OpenLDAP source is that 'demand' sets the SSL_VERIFY_FAIL_IF_NO_PEER_CERT option...which is documented by OpenSSL as having NO EFFECT on the SSL client side, which can be confirmed in the OpenSSL source.
(c.f. ITS #4941 for when I tried to get this text fixed. Closed with no changes.)
I'd like to try the "If no certificate is provided" part, but can't manage to do so.
Almost all TLS cipher suites, including the most deployed ones, require the server to have a certificate, period. If you look at the output of "openssl ciphers -v", the ciphers which have an 'Au' field of RSA, DSS, ECDH, or ECDSA can only be used if the server has a certificate of the indicated type.
So if you rule those out, you end up with basically three choices: 1) "Au=None": the anonymous ciphers. Possible, but they are trivially subject to Man-in-the-Middle attacks, so TLS implementations disable them by default.
(In theory they can be used securely via a channel-binding in a SASL layer which supports integrity protections, but I haven't seen anyone on list saying they've actually got that working. I lost track of where the SASL bits stand on that after there was confusion on the IETF mailing lists about what the protocols actually required. <sigh>)
2) "Au=PSK": pre-shared keys. Looks like these require a callback to be configured on the server, but code to do that hasn't been added to OpenLDAP. Good luck finding a client that would be able to use it.
3) "Au=SOMETHING_ELSE": something unusual like a Kerberos cipher suite. Again, those require C code changes to enable their use, as well as whatever infrastructure is behind them, which you didn't mention so I'll assume you don't have.
So, right now, which one of those were you planning on using?
Philip Guenther
Philip Guenther guenther+ldaptech@sendmail.com schrieb am 12.11.2013 um 16:37
in Nachricht alpine.BSO.2.11.1311120655310.19673@morgaine.local:
On Tue, 12 Nov 2013, Jan Synacek wrote:
quoting ldap.conf(5):
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is
Maybe that should read "... If no VALID certificate is..."
provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. ...
Yeah, that text is bogus. At least with OpenLDAP 2.4.37 and OpenSSL version 1.0.1c and earlier, 'TLS_REQCERT try' is exactly the same as 'TLS_REQCERT demand'. The only difference in the OpenLDAP source is that 'demand' sets the SSL_VERIFY_FAIL_IF_NO_PEER_CERT option...which is documented by OpenSSL as having NO EFFECT on the SSL client side, which can be confirmed in the OpenSSL source.
(c.f. ITS #4941 for when I tried to get this text fixed. Closed with no changes.)
I'd like to try the "If no certificate is provided" part, but can't manage to do so.
Almost all TLS cipher suites, including the most deployed ones, require the server to have a certificate, period. If you look at the output of
Yes, but the certificate could be expired or mismatching the host, etc.
"openssl ciphers -v", the ciphers which have an 'Au' field of RSA, DSS, ECDH, or ECDSA can only be used if the server has a certificate of the indicated type.
So if you rule those out, you end up with basically three choices:
"Au=None": the anonymous ciphers. Possible, but they are trivially subject to Man-in-the-Middle attacks, so TLS implementations disable them by default.
(In theory they can be used securely via a channel-binding in a SASL layer which supports integrity protections, but I haven't seen anyone on list saying they've actually got that working. I lost track of where the SASL bits stand on that after there was confusion on the IETF mailing lists about what the protocols actually required. <sigh>)
"Au=PSK": pre-shared keys. Looks like these require a callback to be configured on the server, but code to do that hasn't been added to OpenLDAP. Good luck finding a client that would be able to use it.
"Au=SOMETHING_ELSE": something unusual like a Kerberos cipher suite. Again, those require C code changes to enable their use, as well as whatever infrastructure is behind them, which you didn't mention so I'll assume you don't have.
So, right now, which one of those were you planning on using?
Philip Guenther
On Wed, 13 Nov 2013, Ulrich Windl wrote:
Philip Guenther guenther+ldaptech@sendmail.com schrieb am 12.11.2013 um 16:37
in Nachricht alpine.BSO.2.11.1311120655310.19673@morgaine.local:
On Tue, 12 Nov 2013, Jan Synacek wrote:
quoting ldap.conf(5):
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is provided, the session proceeds normally.
Maybe that should read "... If no VALID certificate is..."
I can't tell whether you're claiming that's how the code * _does_ behave, and you've tested it * _does_ behave, but you haven't tested it, OR * _should_ behave, in your opinion.
Almost all TLS cipher suites, including the most deployed ones, require the server to have a certificate, period. If you look at the output of
Yes, but the certificate could be expired or mismatching the host, etc.
I see no guarantee from OpenLDAP docs or code or OpenSSL docs or code that such a setup would not fail immediately. I'm not going to bother checking because such a setup would be be insecure and a waste of resources.
"What problem are you trying to solve?"
Philip Guenther
On 11/13/2013 08:20 AM, Ulrich Windl wrote:
Philip Guenther guenther+ldaptech@sendmail.com schrieb am 12.11.2013 um 16:37
in Nachricht alpine.BSO.2.11.1311120655310.19673@morgaine.local:
On Tue, 12 Nov 2013, Jan Synacek wrote:
quoting ldap.conf(5):
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is
Maybe that should read "... If no VALID certificate is..."
I guess that's what "If a bad certificate is provided" means.
On 11/12/2013 04:37 PM, Philip Guenther wrote:
On Tue, 12 Nov 2013, Jan Synacek wrote:
quoting ldap.conf(5):
TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. ...
Yeah, that text is bogus. At least with OpenLDAP 2.4.37 and OpenSSL version 1.0.1c and earlier, 'TLS_REQCERT try' is exactly the same as 'TLS_REQCERT demand'. The only difference in the OpenLDAP source is that 'demand' sets the SSL_VERIFY_FAIL_IF_NO_PEER_CERT option...which is documented by OpenSSL as having NO EFFECT on the SSL client side, which can be confirmed in the OpenSSL source.
(c.f. ITS #4941 for when I tried to get this text fixed. Closed with no changes.)
I'd like to try the "If no certificate is provided" part, but can't manage to do so.
Almost all TLS cipher suites, including the most deployed ones, require the server to have a certificate, period. If you look at the output of "openssl ciphers -v", the ciphers which have an 'Au' field of RSA, DSS, ECDH, or ECDSA can only be used if the server has a certificate of the indicated type.
So if you rule those out, you end up with basically three choices:
"Au=None": the anonymous ciphers. Possible, but they are trivially subject to Man-in-the-Middle attacks, so TLS implementations disable them by default.
(In theory they can be used securely via a channel-binding in a SASL layer which supports integrity protections, but I haven't seen anyone on list saying they've actually got that working. I lost track of where the SASL bits stand on that after there was confusion on the IETF mailing lists about what the protocols actually required. <sigh>)
"Au=PSK": pre-shared keys. Looks like these require a callback to be configured on the server, but code to do that hasn't been added to OpenLDAP. Good luck finding a client that would be able to use it.
"Au=SOMETHING_ELSE": something unusual like a Kerberos cipher suite. Again, those require C code changes to enable their use, as well as whatever infrastructure is behind them, which you didn't mention so I'll assume you don't have.
So, right now, which one of those were you planning on using?
Neither of them. All I wanted to do was to "provide no server certificate" and verify that "TLS_REQCERT try" really did what it claimed.
Anyway, thank you for the complex explanation!
Philip Guenther
Cheers,
openldap-technical@openldap.org
-
Jan Synacek -
Philip Guenther -
Todd Lyons -
Ulrich Windl