OpenSRF: XMPP Non-SASL auth is being phased out

[James Fournie]

OpenSRF uses XMPP's "non-SASL authentication" as described in XEP-0078:
https://xmpp.org/extensions/xep-0078.html

This is obsolete, it uses plain-text and while it seems to be used in the wild by XMPP clients, XMPP server developers are gradually phasing it out.

with around ejabberd v17.02, ejabberd disabled non-SASL authentication by default. It must be enabled in the config file by adding a plugin to the plugins section:

mod_legacy_auth: {}

However there is a bug in some early versions of v17 which prevents legacy_auth from working at all:

https://github.com/processone/ejabberd/issues/1678

I suspect the fix in that issue should resolve the problem in ejabberd v17.06 or 17.07 but I haven't been able to test yet.

Major linux distros aren't using v17 yet as far as I can tell anyway, and hopefully they will skip over this bug.

Once people start using distros with v17, they'll need to add "mod_legacy_auth: {}" to the ejabberd.yml, presuming the distro maintainers don't add it.

However, I think this is also a longer-term technical debt issue as well.

Another major XMPP server Openfire (not used by the OpenSRF community) also removed this in 2016 and relegated it to a plugin:
https://issues.igniterealtime.org/browse/OF-1097
https://www.igniterealtime.org/projects/openfire/plugins/nonsaslauthentication/readme.html

It seems like this authentication is being phased out (it has already been considered an "obsolete" standard for nearly 10 years)

[Ben Shum (bshum)]

Well, Ubuntu 18.04 is going to use a newer ejabberd that has the legacy auth disabled by default. Adding the directive here does not get us all the way around the problem though. There's a lot of areas in the design where the authentication just really does not like us using plain text. Still testing with OpenSRF master and Ubuntu 18.04 at the moment and gathering information.

But marking this bug confirmed.

[Chris Sharp (chrissharp123)]

I can confirm that uncommenting "mod_legacy_auth: {}" in /etc/ejabberd/ejabberd.yml allows OpenSRF to work, but the other problem here is that ejabberd is more strict about enforcing STARTTLS. Setting "loglevel" to "5" (debug) allowed me to see this (after enabling legacy auth):

<<"<stream:error><policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Use of STARTTLS required</text></stream:error>">>

Setting "starttls_required" to "false" allowed OpenSRF to start successfully. But that's probably a separate bug.

[Chris Sharp (chrissharp123)]

Well, actually, I spoke too soon. ejabberd is still rejecting connections. This time, the error message from OpenSRF is:

Aug 10 07:37:59 csharp-master-bionic router[19272]: [ERR :19272:osrf_parse_json.c:844:] *JSON Parser Error
                                                     - char = r
                                                     - index = 1
                                                     - near => registering
                                                     - Unexpected character
Aug 10 07:37:59 csharp-master-bionic router[19272]: [WARN:19272:osrf_message.c:548:] osrfMessageDeserialize() unable to parse data:
                                                    registering

[Jason Stephenson (jstephenson)]

I experimented with ejabberd and OpenSRF on Ubuntu 18.04 this morning. I could not get any better results than Chris Sharp reports in comment #3.

I did turn all of the loglevels up to 5 and do a test run of starting ejabberd, OpenSRF services, srfsh, and trying to introspect opensrf.settings and opensrf.math. I am attaching a zip archive of the logs and configurations from that endeavor. Don't worry about passwords in the configs, I used stupid passwords as this was a test VM.

At the moment, this is the best that I can do.?field.comment=I experimented with ejabberd and OpenSRF on Ubuntu 18.04 this morning. I could not get any better results than Chris Sharp reports in comment #3.

I did turn all of the loglevels up to 5 and do a test run of starting ejabberd, OpenSRF services, srfsh, and trying to introspect opensrf.settings and opensrf.math. I am attaching a zip archive of the logs and configurations from that endeavor. Don't worry about passwords in the configs, I used stupid passwords as this was a test VM.

[Bill Erickson (berick)]

I think this is the smoking gun (from router.log):

router 2018-08-28 12:02:20 [INT :11785:socket_bundle.c:891:] Socket 3 Read 178 bytes and data: <message xml:lang='en' <email address hidden>/router' <email address hidden>/opensrf.settings_listener_localhost_11792'><body>registering</body><thread/></message>
router 2018-08-28 12:02:20 [DEBG:11785:osrf_router.c:284:] osrfRouterHandleIncoming(): investigating message from <email address hidden>/opensrf.settings_listener_localhost_11792
router 2018-08-28 12:02:20 [ERR :11785:osrf_parse_json.c:844:] *JSON Parser Error
 - char = r
 - index = 1
 - near => registering
 - Unexpected character
router 2018-08-28 12:02:20 [WARN:11785:osrf_message.c:548:] osrfMessageDeserialize() unable to parse data: registering

It looks like the local/custom router XML attributes (router_command, router_class, osrf_xid, etc.) are getting stripped from the message, so the router doesn't know how to handle the message.

[Bill Erickson (berick)]

Related to previous comment: https://github.com/processone/ejabberd/issues/1692

[Jason Stephenson (jstephenson)]

So, my reading of the ejabberd bug is that we have to reimplement the OpenSRF message extensions for ejabberd 17+.

[Mike Rylander (mrylander)]

If the comment in that link is correct, and enough, and we don't need to implement an entire extension, then I offer this WIP branch:

http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/miker/lp-1703411-xmpp-opensrf-message-subelement

[Jason Stephenson (jstephenson)]

Well, that branch gets a little bit farther. When I run osrf_control -l --diagnostic after starting services, I get the folowing:

srf_control -l --diagnostic
Useless use of unshift with no values at /usr/local/share/perl/5.26.1/OpenSRF/AppSession.pm line 596.
Useless use of unshift with no values at /usr/local/share/perl/5.26.1/OpenSRF/AppSession.pm line 596.
* opensrf.dbmath is not running
* opensrf.math is not running
* opensrf.persist [18336] uptime=00:26 cputime=00:00:00 #drones=0/25 0%
* ERR opensrf.persist has no running drones.
* opensrf.settings [18328] uptime=00:26 cputime=00:00:00 #drones=0/15 0%
* ERR opensrf.settings has no running drones.
* opensrf.validator [18349] uptime=00:25 cputime=00:00:00 #drones=0/15 0%
* ERR opensrf.validator has no running drones.
* router [18320] uptime=00:28 cputime=00:00:00
* router [18321] uptime=00:28 cputime=00:00:00

That's better than before in that it reports no drones running for the started services. Prior to that patch, there were apparently no drones, but it wasn't being reported.

[Jason Stephenson (jstephenson)]

Here's another set of logs from after Mike's branch is applied.

[Mike Rylander (mrylander)]

I've got a typo there... Force-pushed a branch fixing that, but I'm going to push an update that attempts to shift completely to a subelement rather than duplicating attributes for backward compatibility with older clients. That will cause a complete break in compatibility with older clients, but may well be necessary.

Please feel free to test with and without the very top commit!

[Bill Erickson (berick)]

Opened a separate LP for addressing the XML attributes issue: bug #1793356.