[Date Prev][Date Next]
Antw: Re: TLS_REQCERT and no server certificate
>>> Philip Guenther <firstname.lastname@example.org> schrieb am 12.11.2013 um 16:37
in Nachricht <alpine.BSO.email@example.com>:
> 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
>> 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