Re: TLS_REQCERT and no server certificate

[Philip Guenther <guenther+ldaptech@sendmail.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
> 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