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.
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.
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.
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
ADMIN Console with ssl enabled is using Jetty
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.