Disable Cleartext Auth - SSL Configuration

Openfire
1

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.

Any help is greatly appreciated! Thank you!

2

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:

image
image1040×601 64.2 KB

For additional security, you should disable SASL mechanisms that offer little to no encryption, such as PLAIN or ANONYMOUS.

image

image
image1535×432 59.8 KB

1 Like
3

@guus

Thank you for the info. Before I proceed, will disabling PLAIN or ANONYMOUS break our LDAP authentication?

4

I don’t think so, as it should affect client to server authentication only. I’m not certain though.

5

@guus
After disabling both Anonymous and Plaintext, my client is failing to authenticate. I receive the error “error binding resource”

6

It’s been a while since I last looked into this. You might need PLAINTEXT for Openfire to be able to authenticate the user with AD.

7

@guus
If that is the case, that doesn’t solve the initial issue. Is there another way to work around this potentially?

8

Using PLAIN is far from ideal from a security perspective, but combined mandatory TLS, no plain text credentials are exchanged between clients and server.

9

you’ll need to enable ldaps to protect the creds during transport. You can also look at enabling gssapi (kerberos/sso), but thats more complicated.

10

@speedy

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.

11

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.

12

The first picture is our “Client Connections” settings that result in successful authentication (using Swift.IM as the client)

working_client_connections
working_client_connections1030×1236 145 KB

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.

encryption_error_client_connections
encryption_error_client_connections1416×1211 122 KB

13

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.

1 Like