>> Philip Guenther <guenther+ldaptech(a)sendmail.com>
schrieb am 12.11.2013 um 16:37
in Nachricht
<alpine.BSO.2.11.1311120655310.19673(a)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:
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