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
