(ITS#5655) add option for setting minimum TLS/SSL protocol

[guenther+ldapdev@sendmail.com]

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.)