Hi,
I have installed OpenFire (now running 4.5.3 as of this morning). I was able to get LDAP authentication working properly, however, our NESSUS scans are reporting “XMPP Cleartext Authentication” is enabled. I am assuming I will need to somehow get XMPP secured over port 5222, or convert my communication to legacy, 5223. I am fine using either one, however, I have been trying to go down the path of using 5223 over the past few days without any success. I feel like I am missing something when it comes to the client certificates, but I cannot find a good explanation or documentation relating to this.
Our OpenFire server is installed on Windows, and the client we are using is Swift or Pidgin.
Port 5222 isn’t inherently less secure than port 5223. What you probably should do is to force that every connection on port 5222 is using encryption. You can do that in the admin console:
Using PLAIN is far from ideal from a security perspective, but combined mandatory TLS, no plain text credentials are exchanged between clients and server.
Our LDAP configuration is using LDAPS (port 636) already. Would requiring “Mutual Authentication”
Server > Server Settings > Client Connections > Mutual Authentication > “Needed” assist with any of this?
If so, can someone provide some detailed instructions for what I need to do in order to get client certificates working on this? I’ve installed on a Windows VM, using a Microsoft Internal CA, and Active Directory for LDAP auth. I’ve got our root and intermediate CA certs in the “Keystore” but I am unclear on any remaining steps.
I don’t have any experience with mutual auth. on openfire, have you selected the “require” secure connection as @guus stated? I have a nessus scanner setup at work and tested this months ago. I think setting encryption required everywhere solves this.
This also is with the “PLAIN” SASL Mechanism enabled. With this setting, the NESSUS scan still comes back that we have a vulnerability.
The second picture, is when I change the Mutual Authentication settings to “needed” and the error that is received on my swift.im client. I would assume if I am requiring my client to present a certificate, that MIGHT make NESSUS happy, but maybe I’m just trying to make something more complex than it needs to be.
Hi all – This issue came up several months ago, and there is an open bug report to address it. This is not a server configuration issue, it is an implementation issue.