Last Monday there is again found a big hole in the SSL Version 3 (SSLv3) technology. We call this bug POODLE which stands for Padding Oracle On Downgraded Legacy Encryption. So with this bug found and you as admin for your IBM Connections your first reaction would be lets disable SSLV3 on my front end web server (which is generally in an IBM Connections environment the IBM HTTP Server). Well when you do this you will be surprised by the outcome. You will discover that your environment doesn’t work anymore. I will try to explain here in short what happens.
IBM Connections has an HTTP Client embedded in the applications. This client is based on the open source Apache Commons HTTP Client. This client is only used for creating HTTP traffic and basically has nothing to do with SSL/TLS itself. The IBMJSSE2 library (which is part of websphere itself) is the library used for creating the SSL/TLS encryption layer for the HTTP data. So what basically happens is that the Apache Commons HTTP Client is used to create an http message and that that message is given to the IBMJSSE2 libary to encrypt it and send it (it is a bit more complicated than this but to make it understandable you can use this as a reference).
Within IBM Connections it seems that currently the Apache Commons HTTP Client is configured so that it tells the IBMJSSE2 library to only use SSLv3 where the IBMJSSE2 library is perfectly suited to use higher levels of encryption like TLSv1 and higher, this depends on the version of this library used which is delivered with websphere, so it basically means it depends on which version of websphere you run what types of TLS versions are supported. As you can understand that if you have just disabled SSLv3 on your front end server you will run into an problem now. When one of the IBM Connections applications needs to access one of the other apps via the web front end it will try to do that with SSLv3 which you have disabled on your front end server. So it can’t make a connection and voila your environment is dead 🙂
One of the solution which can be used to downscale the bug in your environment is as follows. We just have seen that disabling SSLv3 isn’t an option where IBM communicates otherwise. We can add some lines to the HTTP config file to check who is trying to build an SSLv3 connection to the webserver and if we identify that the source is our IBM Connections environment we allow it and otherwise we redirect it to a SSLv3 isn’t allowed sorry page on your environment.
What you can do is add these lines to your config
RewriteEngine on
RewriteCond %{ENV:SSL_PROTOCOL_VERSION} SSLV(.*)
RewriteCond %{REMOTE_HOST} !<your_ip_address_of _websphere_server>
RewriteCond %{REQUEST_URI} !errorpages/(.*)
RewriteRule ^/(.*)$ https://<FQHN>/errorpages/ssl_errorpage.html [R,L,NE]
What this basically does it test the incoming connection on if it is a SSLV1/SSLV2/SSLV3 connection and if it is then it test if the incoming connection is coming from websphere, if so then it will allow the traffic, if not comming from websphere you will be redirected to an self created error page where you can describe that you don’t allow SSL anymore but only TLS.
It is really a workaround and I don’t say it is the best solution but it is at least more than nothing. I really hope IBM comes with a fix fast ! With this implemented you can at least be sure that sensitive information isn’t being sent over SSL.
Update 18-Nov-2014
As Luis commented on this article. IBM has delivered an fix today for the POODLE bug for IBM Connections from version 3.0.1 trough version 5. Here is the link to the TechNote document