Offering Other SASL Modes to Clients

Openfire Openfire Support
1

I’ve been trying to resolve a Nagios plugin 87736 “XMPP Cleartext Authentication” finding for a while. I have STARTTLS set to required so I couldn’t figure out while I was getting this. Instructions I’d previously found for this plugin didn’t seem to help, and setting sasl.mechs to EXTERNAL seemed to break things completely and my XMPP client couldn’t connect. Most of my users are using Pidgin or Adium. This morning I noticed the “SASL Mechanisms” configuration GUI in the Registration & Login section and saw that only PLAIN and EXTERNAL were being offered to clients but all have the implementation available. What I can’t figure out is how to make other modes offered to clients; I’m hoping if I can do that I can disable PLAIN and resolve the Nagios finding.

My server is running on CentOS 6.9 64-bit:

Openfire Version: 4.1.4 (installed from 64-bit RPM from Ignite Realtime website)

Java Version: 1.8.0_131 Oracle Corporation – Java HotSpot™ 64-Bit Server VM

Appserver: jetty/9.2.z-SNAPSHOT

Any suggestions would be appreciated. Thanks.

2

Did a bit more digging and found this 2006 thread:

Understanding SASL, and SASL with LDAP?

My server is setup with local accounts and LDAP authentication. So it sounds like PLAIN is the only thing that works with LDAP authentication, unless something has changed in the past 11 years? If that’s the case, then I can’t resolve the finding unless I stop using LDAP, which means users have another password to manage.

3

That finding is a false positive, if you have this set in your console “Required - Connections cannot be established unless they are encrypted.” then your SASL conversation is happening over an SSL encrypted tunnel

What is happening is the Nessus plugin runs a scan on the port, sees “PLAIN” offered in the SASL response and marks it as vulnerable without considering that it is looking at that response inside of an SSL context.

1 Like