“security ssf=128”, we said. The RHEL ES 3 box’s passwd spoke PAM and pam_ldap handled the referral back to the master, and the master churned and clunked “You may pass.”
The RHEL ES 2.1 box tried also, but got back “Permission denied,” with no further clues. The OpenLDAP master server mumbled in its raspy monotone “stronger confidentiality required.” What?
So we checked with openssl s_client, to see what ciphers were being negotiated. The ES3 box was choosing AES256, which happily met the requirements. However, the ES2.1 box was negotiating DES-CBC3-SHA.
Well, no problem. 3DES has 112 bits of secrecy, so let’s drop the SSF requirement. “Stronger confidentiality required!” blurted the master.
What? Surely OpenLDAP doesn’t think that we’re using single DES here? Drop the SSF to 56… BEHOLD! The password update is allowed.
OpenLDAP is calculating the SSF of a cipher by using SSL_CIPHER_get_bits(), which seems fine except that for 3DES it’s not considering the triple application – 168 bits all up but only 112 once you consider meet in the middle attacks. So one could argue that using the get_bits function is wrong… except that it works for all other ciphers, because they don’t do multiple cycles.
You could ask SSL_CIPHER_description() for the SSF, parsing the string for the Enc attribute, but for 3DES you’d get 168, which isn’t correct either. The real solution then is to special case 3DES with an SSF of 112 – but now that openssl 0.9.7 is in common use, who really cares? It’s only the few old instances of 0.9.6b lying around on legacy RHEL 2.1 boxes that are even affected, and in this bleeding edge world of Open Sores with its -funroll-loops, there’s no glory in working around it.
Ideally, the OpenSSL library itself would return the SSF of a cipher, so we wouldn’t have to rely on application writers assuming get_bits is correct all the time.
So if you want an older SSL client to connect to an OpenLDAP server, you’re going to have to sacrifice the SSF level to get basic cooperation between the client and server; but really, there are enough bugs in OpenLDAP that any attacker isn’t going to start by attempting to crack SSL.
One does pause to wonder how the replication from the master to the local slave on the ES 2.1 box worked at all though, given that they also use SSL; the SSF of the client as we know wasn’t high enough. Could it be: another OpenLDAP bug?
DOM DOM DOM!