Antw: Re: TLS_REQCERT and no server certificate

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> 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:
> 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