Conversations: No (obvious?) way to accept SASL downgrade

[MarcelWaldvogel]

General information

• Version: eg 1.18.4
• Device: OnePlus 2
• Android Version: Android 6.0.1 OxygenOS 3.5.8
• Server name: self hosted
• Server software: ejabberd 17.04
• Installed server modules: several
• Conversations source: eg PlayStore, PlayStore Beta Channel, F-Droid, self build (latest HEAD)

Steps to reproduce

1. Run ejabberd with an SQL database. ejabberd offers PLAIN, DIGEST-MD5, X-OAUTH2, and SCRAM-SHA1 as SASL authentication mechanisms.
2. Conversations connects happily (and, according to the source, records the SASL priority)
3. Switch ejabberd to use external authentication (in this case, https://github.com/jsxc/xmpp-cloud-auth, to use ownCloud/Nextcloud database for authentication). ejabberd limits mechanisms to PLAIN and X-OAUTH2.
4. Conversations does not connect, but complains about "downgrade attack"
5. There is no way to say, "yes, I know, the server was reconfigured". At least, I did not find any.

Expected result

1. Having an option to say, "this is not a downgrade attack, the server was reconfigured" and then continue.

[SamWhited]

If you give people an option, they'll just hit the button and do it (even if it is an attack). If you really need to change it, you can remove the account and recreate it which isn't nice, but that's the point.

Prior art:

If you have a pinned cert or key via HPKP in Firefox, for instance, it does not give you any option to ignore the error if you change the cert.

[MarcelWaldvogel]

I was fully aware of this. But reconfiguration is probably more common than an actual after-breaking-TLS-we-have-nothing-better-to-do-than-downgrade-SASL attack.

A message like "By clicking here, you agree to send your password in a less safe mode, which can allow an attacker to obtain it." would be my call for a compromise.

[SamWhited]

But reconfiguration is probably more common than an actual after-breaking-TLS-we-have-nothing-better-to-do-than-downgrade-SASL attack.

I think the more likely attack vector is that someone breaks into the server and wants everyone to start writing their passwords to the database in plaintext or that an already weak TLS method was being used. The message doesn't matter; people will just click through if you give them an option and in the rare occasion where you actually do need to reconfigure, you have a workaround readily available (recreating the account).

[MarcelWaldvogel]

Unfortunately, for me, that is several accounts. And for me, the experience 100% disagrees with your scenario (yes, I know, single sample theory). But just assume a University with several thousand users has to instruct them to do the delete/add again procedure. The IT department will be toast.

[SamWhited]

But just assume a University with several thousand users has to instruct them to do the delete/add again procedure. The IT department will be toast.

It doesn't matter how many users there are, this is still a rare situation. It's also part of the threat model we're dealing with; doing it this way protects the users from themselves as well as from a malicious server administrator who now wants to start harvesting passwords (or someone who broke into the server). As unfortunate as that sounds since there is a valid reason to change the auth method, we can't distinguish between well meaning IT folks and malicious administrators, and also have to protect the user form themselves since most of them won't know the difference either.

[MarcelWaldvogel]

Prior art:

If you have a pinned cert or key via HPKP in Firefox, for instance, it does not give you any option to ignore the error if you change the cert.

Pinning is, however, admin-controlled. So the server admin has to first enable this, while hopefully being aware, that any later change requires 6 months of prior announcement. But at least the admin can announce a key or protocol change.

This is not possible here, as the pinning is done unilaterally at the client side, with no way for the server to control this or announce upcoming changes. If such a mechanism had been available and promoted, I would have kept quiet.

[iNPUTmice]

Independent of the discussion of whether we should offer a way to 'accept' the downgrade attack I find it implausible that an institution would migrate from using the ejabberd internal database to using a third party database (NextCloud in your example). How would you even transfer the user data from ejabberd to NextCloud? (Given the fact that in any proper setup the passwords are hashed in the ejabberd database.)
Either they both NextCloud and ejabberd would authenticate against a third party or NextCloud would authenticate against the ejabberd that existed prior to that. Or it is a fresh setup in that case you don't have the problem of preexisting clients.

I'm sorry you are having problems in your test setup but it don't think this will translate to any real life scenarios.

[MarcelWaldvogel]

Yes, as you put it, it sounds weird or even stupid. But even in the "traditional" world which you describe, switching to a different XMPP server may change the set of supported mechanisms, even if both use the same authentication backend, e.g. LDAP.

In our case, xmpp-cloud-auth was written to solve two distinct problems SAML/Shibboleth and web-based XMPP/JSXC posed:

1. No access to passwords at all (Shibboleth), and
2. prefer not to store passwords openly in the Browser, despite the need for long-term sessions with the need to reconnect.

xmpp-cloud-auth solves both at one stroke by establishing a transitive trust relationship XMPP server→web application→user, instead of the traditional two independent trust relationships XMPP server→user and web application→user. (I'll skip the details here, but feel free to ask.)

No, we currently don't have 10k XMPP users, but many of our users do like Conversations, one of our recommended clients. A SCRAM implementation over the path described in jsxc/xmpp-cloud-auth#14 seems unnecessarily complex, so probably we'll have to accept that our users will have to delete and re-add the university account.

[kmmndr]

If you give people an option, they'll just hit the button and do it (even if it is an attack). If you really need to change it, you can remove the account and recreate it which isn't nice, but that's the point.

That's a simple option, but unless I'm mistaken you'd lose all your conversation history as OMEMO identity would be different

[cweiske]

I had the same problem when moving to a new server. The old server used ejabberd with native user storage and offered SCRAM-SHA-1 authentication.
Now on the new server, I chose to align xmpp and email user database and also to switch to prosody, using dovecot's SASL implementation. Because dovecot requires the user names to be "user@host" and not only "user" (multi-domain setup), SCRAM cannot work because prosody needs to rewrite the username.
So today I have 6 people in my family that I have to re-setup conversations for. I had much fun entering 16 character passwords like s%pi%;5-VJ]6WT*a on the android keyboard.

[SamWhited]

I suppose it's already done now, but personally I'd argue that this should be rare enough that not allowing people to click through is a good thing (since people will blindly click through any security dialog). The point of the feature was that on the rare occasion where you need to downgrade, such as this situation, you have to manually recreate the account. It should be a rare enough occurrence that the hassle is worth the potential security benefits.

EDIT: oops, I apparently already made this argument earlier and forgot. Sorry for the noise, I guess this was already considered and you didn't agree.

[cweiske]

Thank you, @iNPUTmice.

[pitchum]

@iNPUTmice today I wanted to migrate my ejabberd accounts to LDAP accounts and I encountered the problem described here with people using Conversations 2.6 (because SASL is not supported with LDAP in ejabberd). I thought your fix from 30d5c08 was included but I could'nt find how to use it. I don't use Conversations myself so I had hard time on the phone trying to debug this remotely and we could not find a proper solution. So I temporarily disabled LDAP.
What is the right way to use your fix?
I have 8 persons to guide through this change... remotely :(

[iNPUTmice]

@pitchum the 'Save' button in the account details will turn into an 'Accept' button.

[pitchum]

o/ thanks !