powered by Jive Software

Disable TLS client renegotiation support

Hi,

I have an openfire server (3.10.2) configured with TLS required. When running a ssl analyzer (sslyze) i have the following ouput:

Client-initiated Renegotiation:
VULNERABLE - Server honors client-initiated renegotiations

As i understand there is a vulnerability that allows a DoS attack using the TLS renegotiation.

I searched the documentation but couldn’t find any relevant data.

Is there a way (or workaround) to disable this on openfire?

Openssl:

Version 1.0.1e

Release 60.60.el7

Openfire : 3.10.2 (same occurs in current release -> 4.0.4)

Same issue for me as well. We have one Windows 2012 server running Openfire that does not throw this NESSUS scan vulnerability. Our Windows 2008 Openfire servers are.

Are you saying that same version of Openfire on WS2012 doesn’t show such result in Nessus and on WS2008 it does? In that case i would say this is not related to Openfire and Nessus is detecting something else and giving a misleading output.

I apologize, I should have been more specific.

Windows 2008 running Openfire 3.7.1 (Server A and Server B)

Windows 2012 running Openfire 3.9.3 (Server C)

We fixed the following 2 NESSUS scan vulnerabilities on all 3 servers above last week:

XMPP Cleartext Authentication (Affected Port-5222), SSL Certificate Signed Using Weak Hashing Algorithm (Affected Port-5222).

Once we fixed those the MiTM vulnerability (SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection Affected Port-5222) showed up on Server B. It has been showing up since June on Server A.

The only remediation steps we took was add the sasl.mechs = EXTERNAL ain System Properties and updated the internal certificate in the keystore.

Could you use sslyze tool on server C?

I can. Is there a specific command I should try? If I just run the sslyze_cli.exe ServerC from a cmd line I get a Warning: Connection Rejected.

Can I run this to scan a specific port? i.e. 5222 As that is the port the vulnerability is being generated from.

Thanks for your help.

That i don’t know, i have never used it. I’m just curious what result will it show on your server. Maybe antonio will give you a hint.

Either that or if there is a System Property that can be added to disable the SSL/TLS renegotiation.

Looks like my issue may be the version of java being used on the 3.7.1 server (1.6.0_18 Sun Microsystems Inc. – Java HotSpot™ Client VM)

I assume we can upgrade the version by installing java and removing the jre folder in Openfire? I would not want to perform an Openfire upgrade at this time if possible.

Yes, usually you can just remove the jre folder and install system java (i do this myself on my server). But i don’t remember which version was supported for 3.7.1. It might not work with 1.8.0 Java. But i can’t tell for sure.

I was able to update with the latest version of Java and it worked. Thanks!

We are also getting the following output from sslyze Client-initiated Renegotiation: VULNERABLE…

Findings after debugging the Openfire (4.1.3)


There are two potential paths due to which we can get this VULNERABILITY

  1. ADMIN Console with ssl enabled is using Jetty
  2. Whenever we enable BOSH with ssl enabled also uses Jetty
    Openfire creates the SslContextFactory object (org.eclipse.jetty.util.ssl.SslContextFactory) in EncryptionArtifactFactory (org.jivesoftware.openfire.spi.EncryptionArtifactFactory) and Jetty provide the API to set whether the client renegotiation is allowed or not. Default value is set to true. I have tested by changing the code of Openfire by adding a single line of code right after the creation of SslContextFactory obejct

sslContextFactory = new SslContextFactory();

sslContextFactory.setRenegotiationAllowed(false);

and everything(Admin Console and BOSH) works fine. I don’t know why Openfire need client renegotiation. I think if this is not needed then it should consider as a bug and should be fixed in the next release.

I found the solution and it is not related to Openfire like some users already pointed to.

It is only needed to add a flag to the java command that starts Openfire.

The flag is -Djdk.tls.rejectClientInitiatedRenegotiation=true

and can be added for example in the init.d script to OPENFIRE_OPTS

OPENFIRE_OPTS=``"${OPENFIRE_OPTS} -DopenfireHome=${OPENFIRE_HOME} -Dopenfire.lib.dir=${OPENFIRE_LIB} -Djdk.tls.rejectClientInitiatedRenegotiation=true"

2 Likes