Workaround broken SASL implementation(s)

[brmiller@…]

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="​http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="​http://jabber.org/features/iq-auth"/></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.

[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.

[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!

[dx]

See also #1186

[dx]

Well, here's a workaround:

​https://github.com/bitlbee/bitlbee/commit/91dd19caf16790c3b77818f8efd6cabaca209ecf

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)))