#866 closed enhancement (fixed)

Workaround broken SASL implementation(s)

Reported by: brmiller@… Owned by: wilmer
Priority: normal Milestone:
Component: Jabber Version: 3.0.3
Keywords: SASL patch Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:


I am using Bitlbee against a broken OpenFire server which fails in the SASL Digest-MD5 negotiation. I debugged this a month ago or so, and came up with the attached patch.

The server offers DIGEST-MD5, PLAIN, ANONYMOUS, and CRAM-MD5 authentication mechanisms:

08:44 RX: <stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns=""><method>zlib</method></compression><auth xmlns=""/></stream:features>

The [Bitlbee] client chooses DIGEST-MD5

08:44 TX: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST-MD5"/>

The server sends the auth challenge:

08:44 RX: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">--bunch of base64 removed--</challenge>

The client sends the resposne.

08:44 TX: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">--some more base64 data--</response>

The server says this is not authorized.

08:44 RX: <failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><not-authorized/></failure>

And then my negotiation is dead in the water. I noted that other clients (the purlpley one, for example) do the same thing but then retry PLAIN after DIGEST-MD5 fails.

To get around this (on a production server I cannot upgrade), I created the following "ignore_broken_sasl_digest_md5" patch/hack. I don't know if this is useful for anyway, bad style, never-gonna-be-incorporated, etc. or not, but I wanted to "give back" as it were. I also note that this feels a little like overlap with #863, but that patch did not solve my particular problem.

Attachments (1)

broken_jabber_sasl_digest_md5.patch (1.2 KB) - added by brmiller@… at 2011-11-28T22:15:06Z.

Download all attachments as: .zip

Change History (6)

Changed at 2011-11-28T22:15:06Z by brmiller@…

comment:1 Changed at 2011-12-07T21:55:32Z by wilmer

Wow, that's utterly annoying. I was hoping that the non-SASL patch would fix this, but it seems you've tried that already.

Maybe a better fix here would be to have a setting that enforces the SASL authentication method to be used? Also, I wonder if implementing CRAM-MD5 would solve your problem.

Possibly the authentication with DIGEST-MD5 is failing for you because the server has no unencrypted copy of the password available. It seems dumb to offer the option then though.

comment:2 Changed at 2014-02-04T06:00:24Z by dx

Keywords: patch added

comment:3 Changed at 2015-02-03T03:50:09Z by dx

This is still an issue three years later with openfire 3.9.3 (just found someone in #pidgin complaining about it, and I reproduced the issue locally)

Can be workarounded server side by setting the server property "sasl.mechs" to "PLAIN" (and requiring TLS to avoid sending plaintext passwords)

Pidgin marked the issue as wontfix, but i'd like to do something.

Maybe a better fix here would be to have a setting that enforces the SASL authentication method to be used?

And this is a good idea!

comment:4 Changed at 2015-03-16T00:20:18Z by dx

See also #1186

comment:5 Changed at 2015-07-30T03:28:00Z by dx

Resolution: fixed
Status: newclosed

Well, here's a workaround:

It solves this problem for TLS connections which should be 99.9% of them.

I'm closing this as fixed, unless someone complains (please don't complain (not that a lot of people did in the last few years (even though it seems to be really easy to reproduce)))

Modify Ticket

as closed The owner will remain wilmer.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.