A new security issue hit the streets this week: the Poodle SSL bug. Immediately we’ve received a question on the OpenDJ mailing list on how to remediate from the vulnerability.
While the vulnerability is mostly triggered by the client, it’s also possible to prevent attack by disabling the use of SSLv3 all together on the server side. Beware that disabling SSLv3 might break old legacy client applications.
OpenDJ uses the SSL implementation provided by Java, and by default will allow use of all the TLS protocols supported by the JVM. You can restrict the set of protocols for the Java VM installed on the system using deployment.properties (on the Mac, using the Java Preferences Panel, in the Advanced Mode), or using environment properties at startup (-Ddeployment.security.SSLv3=false). I will let you search through the official Java documentations for the details.
But you can also control the protocols used by OpenDJ itself. If you want to do so, you will need to change settings in several places :
- the LDAPS Connection Handler, since this is the one dealing with LDAP over SSL/TLS.
- the LDAP Connection Handler, if the startTLS extended operation is to be used to negotiate SSL/TLS establishment on the LDAP connection.
- the HTTP Connection Handler, if you have enabled it to activate the RESTful APIs
- The Crypto Manager, whose settings are used by Replication and possibly the Pass Through Authentication Plugin.
- The Administration Connector, which is also using LDAPS.
For example, to change the settings in the LDAPS Connection Handler, you would run the following command :
# dsconfig set-connection-handler-prop --handler-name "LDAPS Connection Handler" \
--add ssl-protocol:TLSv1 --add ssl-protocol:TLSv1.1 --add ssl-protocol:TLSv1.2 \
-h localhost -p 4444 -X -D "cn=Directory Manager" -w secret12 -n
Repeat for the LDAP Connection Handler and the HTTP Connection Handler.
For the crypto manager, use the following command:
# dsconfig set-crypto-manager-prop \
--add ssl-protocol:TLSv1 --add ssl-protocol:TLSv1.1 --add ssl-protocol:TLSv1.2 \
-h localhost -p 4444 -X -D "cn=Directory Manager" -w secret12 -n
And for the Administration Connector :
# dsconfig set-administration-connector-prop \
--add ssl-protocol:TLSv1 --add ssl-protocol:TLSv1.1 --add ssl-protocol:TLSv1.2 \
-h localhost -p 4444 -X -D "cn=Directory Manager" -w secret12 -n
All of these changes will take effect immediately, but they will only impact new connections established after the change.
Ludo Sketches 
Hey Ludo! Long time no speak. Just saw your post and wanted to point something out wrt this SSLv3 protocol vulnerability and LDAP. This attack is not feasible with LDAP because not only it requires man in the middle presence it does also require some control over client ie the client has to be made to send exact same requests to the server multiple times (practically 1000s of times) and while it is something that is practical with HTTP where some JavaScript or such can be injected to do so from the client side the same is not feasible with LDAP.
Agree Anton, it will be very difficult to inject and attack LDAP connections. Yet, SSLv3 is obsolete and it’s worth disabling it anyway.
Customers that have enabled the HTTP Handler definitely need to disable SSLv3.
I might be missing something, but when I am trying to force TLS, I get this error:
* [LDAP: error code 53 – Entry cn=LDAPS Connection Handler,cn=Connection
Handlers,cn=config cannot be modified because one of the configuration
change listeners registered for that entry rejected the change: An
error occurred while attempting to initialize the SSL context for use in
the LDAP Connection Handler: IllegalArgumentException(TLSv1.1)]
Looks like I am unable to enable TLS1.1 and TLS1.2
Any idea why this is happening?
which version of Java re you using ? It’s possible that very old versions of Java don’t support TLSv.1.1
That must be the problem and I will give that a shot. Thanks for replying.
Just wanted to update anyone else who might run into this problem.
It was due to an outdated version of Java 1.6. I updated to Java 1.8, updated java.properties, ran ./bin/dsjavaproperties and restarted opendj to fix the issue.
Thanks again