[OPENDS-4607] Problem preventing OpenDS admin port from negotiating less
than 128-bit SSL ciphers? Created: 05/Jul/11 Updated: 15/Sep/11
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Open
opends
Administration/Other
2.0.0
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
rjustice
Unresolved
None
Not Specified
None
Priority:
Assignee:
Votes:
Major
Unassigned
0
Not Specified
Not Specified
OpenDS 2.0 on RHEL 5
Description
Our product utilizes OpenDS and it is getting flagged by a Qualys security scanner for the
following weakness. Am I
I've mailed the OpenDS mailing list twice to see if the following is a bug and/or limitation of
OpenDS.
Am I missing some configuration option that would allow me to turn off < 128-bit ciphers?
THREAT:
The Secure Socket Layer (SSL) protocol allows for secure communication between a client and
a server.
SSL encryption ciphers are classified based on encryption key length as follows:
HIGH - key length larger than 128 bits
MEDIUM - key length equal to 128 bits
LOW - key length smaller than 128 bits
Messages encrypted with LOW encryption ciphers are easy to decrypt. Commercial SSL
servers should only support MEDIUM or HIGH strength
ciphers to guarantee transaction security.
The following link provides more information about this vulnerability:
Analysis of the SSL 3.0 protocol (http://www.schneier.com/paper-ssl-revised.pdf)
Please note that this detection only checks for weak cipher support at the SSL layer. Some
servers may implement additional protection at the data
layer. For example, some SSL servers and SSL proxies (such as SSL accelerators) allow cipher
negotiation to complete but send back an error
message and abort further communication on the secure channel. This vulnerability may not be
exploitable for such configurations.
Configuration of the admin connector in config.ldif:
dn: cn=Administration Connector,cn=config
objectClass: ds-cfg-administration-connector
objectClass: top
ds-cfg-listen-address: 0.0.0.0
ds-cfg-listen-port: 16003
ds-cfg-ssl-cert-nickname: ldap-server-ssl-cert
cn: Administration Connector
ds-cfg-key-manager-provider: cn=JKS,cn=Key Manager Providers,cn=config
ds-cfg-trust-manager-provider: cn=Blind Trust,cn=Trust Manager Providers,cn=config
ACTION TAKEN: Continued to test a variety of configuration
modifications. The primary method to refuse a connection based on SSL
cipher strength is documented here:
https://www.opends.org/wiki/page/SSFBindRule
I have placed this bind rule in our config.ldif (line 47) and verified
this worked and the server started up
ds-cfg-global-aci:
(targetattr="audio||authPassword||description||displayName||givenName||h
omePhone||homePostalAddress||initials||jpegPhoto||labeledURI||mobile||pa
ger||postalAddress||postalCode||preferredLanguage||telephoneNumber||user
Password")(version 3.0; acl "Self entry modification"; allow (write)
userdn="ldap:///self" and ssf>="128"
However, the following OpenSSL test script used to test if the admin
port is accepting the SSL connections at a lower cipher rate is showing
we still can initially establish the connection. My guess is Qualys is
using a similar method and may still flag the port as accepting a
connection at a lower cipher.
I suspect at this point that we are dealing with a bug in OpenDS. I
have also tried various options in keytool with different keystores to
try to prevent us from negotiating a lesser key size without success.
------------------------------------------------------------------------
#!/bin/sh
1.
1. sslthing.sh 20040621 by blh [at] blh.se
1.
1. Location of openssl
ossl=/usr/bin/openssl
1.
1. Make a request (may be altered)
echo "GET / HTTP/1.0" > sslthing.tmp
1.
1.
1.
1.
1.
1. END OF CONFIGURATION #####
if ! [ $1 ]; then
echo syntax: $0 host:sslport [-v]
exit
fi
if ! [ -e $ossl ]; then
echo The path to openssl is wrong, please edit $0
exit
fi
1.
1. Request available ciphers from openssl and test them
for ssl in -ssl3 -ssl2 -tls1
do
echo Testing `echo $ssl | cut | tr "a-z" "A-Z"`...
$ossl ciphers $ssl -v | while read line
do
cipher=`echo $line | awk ' {print $1}
'`
bits=`echo $line | awk '
{print $5}
' | cut -f2 -d( | cut -f1 -d)`
if [ $2 ]; then
echo -n $cipher - $bits bits...
fi
if ($ossl s_client $ssl -cipher $cipher -connect $1 < sslthing.tmp 2>&1
grep ^New > /dev/null); then
if [ $2 ]; then
echo OK
else
echo $cipher - $bits bits
fi
grep -v error
else
done
if [ $2 ]; then
echo Failed
fi
fi
done
1.
1. Remove temporary file
rm -f sslthing.tmp
-----------------------------------------------------------------------$ /cygdrive/c/sslthing.sh rjustice:4444
Testing SSL3...
EDH-RSA-DES-CBC3-SHA - 168 bits
DES-CBC3-SHA - 168 bits
RC4-SHA - 128 bits
RC4-MD5 - 128 bits
EDH-RSA-DES-CBC-SHA - 56 bits
DES-CBC-SHA - 56 bits
EXP-EDH-RSA-DES-CBC-SHA - 40 bits
EXP-DES-CBC-SHA - 40 bits
EXP-RC4-MD5 - 40 bits
Testing SSL2...
Testing TLS1...
DHE-RSA-AES256-SHA - 256 bits
AES256-SHA - 256 bits
EDH-RSA-DES-CBC3-SHA - 168 bits
DES-CBC3-SHA - 168 bits
DHE-RSA-AES128-SHA - 128 bits
AES128-SHA - 128 bits
RC4-SHA - 128 bits
RC4-MD5 - 128 bits
EDH-RSA-DES-CBC-SHA - 56 bits
DES-CBC-SHA - 56 bits
EXP-EDH-RSA-DES-CBC-SHA - 40 bits
EXP-DES-CBC-SHA - 40 bits
EXP-RC4-MD5 - 40 bits
ACTION PLAN: Message OpenDS mailing list to determine if this is infact
an OpenDS bug.
Comments
Comment by rjustice [ 12/Sep/11 ]
Any updates?
Comment by mmarie [ 15/Sep/11 ]
The Administration connector was on purpose designed to be non-configurable. It seems that
you pinpointed an security issue in the way we establish the SSL connection.
The workaround for you if you don't want to expose the admin connector (which is only useful
for administration purposes and thus should not be exposed to the outside) is to configure its
listen address using dsconfig. Use a private IP accessible only on your internal network.
That way even if its security is non-optimal, it should be accessible only to people that have
already access to your internal network.
Regarding the SSFBindRule, it is validated long after the connection is established (that's a
security check that is enforced by the server code, not the SSL layer).
Generated at Wed Feb 10 06:56:28 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.