Full_Name: Philip Guenther Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/guenther-080813.patch Submission from: (NULL) (64.58.1.252)
It's time for SSL version 2.0 to die: it has numerous weaknesses and has been superseded by SSL version 3.0 and TLS version 1.0 for *years*. Indeed, the LDAP Start_Tls extended operation is defined by reference to the TLS standard.
(It could be argued that a client that sends an SSLv2-compatible handshake after doing Start_Tls is non-compliant, or at least non-interoperable, as servers are only required to support true TLS handshakes.)
As a first step, here's a patch against the CVS trunk that adds the ability to set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: C API ldap_[sg]et_option() ldap.conf/slapd config ----------------------------------------------------------- LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0
(1.0, because TLSv1.1 is already published, even though OpenSSL doesn't support it yet)
This option is set up to specify a minimum version instead of permitting arbitrary control of which versions are supported because the SSL/TLS version negotiation assumes that both ends support a contiguous range. If one end has a gap in what it supports (e.g., SSLv2 and TLSv1, but not SSLv3), then it'll fail to handshake with another one that has the missing version as its highest supported version, even though they both support a lower version. Simply setting just the lower-bound prevents the specification of such a 'silly-state'.
(for example: "openssl s_client -no_ssl3" will fail to handshake with "openssl s_server -no_tls1", even though they both support SSLv2. Ditto if you flip the ends.)