Re: TLS_REQCERT and no server certificate

[Jan Synacek <jsynacek@redhat.com>]

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

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,
-- 
Jan Synacek
Software Engineer, Red Hat