SSL 3.0 fallback vulnerability encounters to openfire/bouncycastle?

What’s the fuss all about? Read here.

So port 5222 is plain / TLS. Port 5223 is SSL - but openfire doesn’t use OpenSSL. It uses bouncycastle :slight_smile:

According to server test my server uses/allows the following protocols:



Is bouncycastle/openfire affected by this vulnerability? I rode some xmpp server blogs saying they turned off compression for connections because this could enforce this bug.


I’m still reading the details but it is rumored that the exploit is a weakness in the protocol spec of SSLv3 itself, so any service using the SSLv3 protocol according to the spec should be vulnerable :frowning:

So the question is now how to disable SSLv3 protocol for openfire?



Yes, my initial reaction was to patch openssl up to openssl-1.0.1i but it sounds like something else needs to be done. Can SSLv3 be disabled altogether?

Yes, since OpenFire doesn’t use OpenSSL (Is Openfire affected by Heartbleed? | Ignite Realtime ), something else needs to be done.
Would also like to know how to disable SSLv3 in OpenFire.

1 Like

Right! Maybe some Dev could light is up? :slight_smile:

Not a rumor. The flaw is in the SSLv3 protocol itself, not any particular implementation of it. So it is not only an OpenSSL problem. For example, Red Hat advises that both Tomcat and JBoss are vulnerable. See POODLE: SSLv3 vulnerability (CVE-2014-3566)

It seems the only way to deal with this at the moment is to only allow TLS v1, v1.1 and v1.2 protocol access.

Some Java applications inherit their SSL protocol config from the JVM, so specifying those safer protocols (and maybe disallowing SSLv3 and SSLv2) may work, although I have not yet found an app that does. With OpenDJ we had to explicitly configure each listener to only use those safer protocols (see POODLE SSL Bug and OpenDJ). It appears that the same method is required for Tomcat and JBoss.

Does anyone have any updates on this? This would seem like an important issue to address.

this is critical, should have the highest prio.

1 Like

“Bouncy Castle Java APIs version 1.46, or later, offer the ability to access SSL v3 by overriding methods in order to allow support for it. By default SSL v3 support is turned off.” - Legion of the Bouncy Castle Information for VU#577193

Since obviously SSL v3 have been enabled in Openfire, and is not a default option in Bouncy Castle… Does anyone know where to turn that switch off, if possible?

I have been looking through the source code, but unable to locate where this function is. Is it enabled by Openfire, or by a module which Openfire use?

I hope this does not sound naive or simplistic, but why not turn off SSL on port 5223 from openfire admin web page


Or there is a setting to require TLS specifically here http://server:9090/sss-settings.jsp Which does the same and Spark shows the padlock icon, meaning that connection is encrypted, but i’m not sure about the ciphers. Someone should investigate a traffic somehow and make sure only TLS is in use.

Dele, your domain is still in your link, if you hover over it. Have edited your link.


Your settings work fine for port 5223 but what about disabling SSLv3 on port 9091?

Original question was for client ports. Don’t know how to do this for Admin Console. Admin Console is handled by Jetty web server, i think, maybe this can be done in there.

Does anyone know where the settings are for Jetty?

Dont know yet, but we are using bouncycastle 1.51, the latest and greatest on 3.10 alpha

I believe it can be simply turned off for XMPP socket via admin console, but for Jetty you might need release the patch for

** **

final SslContextFactory sslContextFactory = new SslContextFactory();


thanks @sm, is this what you are suggesting?

PS, I filed OF-861 on this issue as well

[OF-861] Disable SSLv3 by default as per POODLE vulnerability - Jive Software Open Source

Yes, test it please


While browsing the source code of Openfire I found only two occurences of “SslContextFactory”

  • src/java/org/jivesoftware/openfire/container/
  • src/java/org/jivesoftware/openfire/http/

The default ports for these services are 7433 (HTTP Bind) and 9091 (Admin Console).

But what about client connections on port 5222 using STARTTLS, do they support SSLv3 as well?

A connection test using a patched version of OpenSSL (see tells me that SSLv3 is enabled for Client connections on my server. (the used command is: ./openssl s_client -connect myopenfireserver:5222 -ssl3 -starttls xmpp)

akrherz’s patch adresses only the first two problems. ( d3a)

Can you verify this behaviour and is it relevant?

Thank you very much,