We have an Openfire instance with a couple of Connection Manager instances pointing to the outside world in our DMZ. We hit a snag today when a routine PCI security scan noted that the connection manager allows ‘weak’ SSLv3 protocols to connect to it. Something like DES-CBC-SHA, which is only 56bit, seems to work on port 5223 and I verified with openssl s_client.
Is there a patch or modification out there which reduces the number of ciphers connection manager supports? It explicitly excludes SSLv1/2 in the code, however there are still a number of low/medium grade ciphers in both of these standards.
If there is not a patch, can anyone point me in the right direction for changing the code in a useful way?
There are two things to this SSL/TLS-based configuration of Openfire.
First, Openfire (as does any application that’s written in Java) depends on the options provided by its runtime environment. There’s a huge difference in what different versions of Java support, in terms of security settings. The Java runtime can be configured extensively to provide (or reject) various protocols and cipher suites, among others.
The second part of the equation is based on the Openfire configuration. Openfire takes what is made available through the Java runtime environment, which is complemented with options provided by the third party Bouncy Castle security provider. Up to and including version 3.10, this was the configuration that was used for SSL/TLS negotiation in Openfire. Since version 4.0.0, there are extensive configuration options provided in the Openfire Admin Console, that allows an admin to configure a wide array of options to be used per connection type.
