Conversations (F-Droid build) / TLS 1.3 channel binding deadlock with LDAP backends

I have searched the forum for similar issues

on

This category is for general issues(=something is broken) regarding YunoHost, NOT apps.

on

This form is written in English but feel free to write in French if you’re more comfortable!

on

What type of hardware are you using

VPS bought online

What YunoHost version are you running

12.1.41.2

How are you able to access your server

The webadmin

Are you in a special context or did you perform specific tweaking on your YunoHost instance ?

Using YunoHost LDAP backend for XMPP (PLAIN mechanism) with Prosody.

Describe your issue

Since recent updates (especially with strict F-Droid builds of Conversations), attempting to connect to XMPP on a YunoHost server using the LDAP backend triggers a TLS 1.3 / channel binding failure.

Prosody logs show:
“Channel binding ‘tls-unique’ undefined in context of TLS 1.3”

Conversations rejects the connection outright during SASL negotiation because it expects a channel binding under TLS 1.3 while using the PLAIN mechanism required for LDAP authentication. Since typical users cannot easily tweak advanced connection settings/ports on mobile clients, this creates a deadlock for self-hosted instances using LDAP authentication.

Share relevant logs or error messages

c2s5b82b40: Channel binding ‘tls-unique’ undefined in context of TLS 1.3
c2s5b82b40: SASL mechanisms supported by handler: PLAIN
c2s5b82b40: Offering usable mechanisms: PLAIN
c2s5b82b40: Destroying unbound session for <(unknown)@peripheria.org>

Hello peripheria, the issue has been reported here : XMPP/mail limited to SASL PLAIN — no SCRAM (nor usable channel binding) due to LDAP credential storage: any plans? · Issue #2829 · YunoHost/issues · GitHub

Hm, that’s really an unfortunate breakage/regression.

Also @TabTwo, is there a way this new SCRAM/LDAP challenge response auth could provide group/role membership information as well?

For example, to be directly usable for permissions in cases like galene videoconferencing rooms, as discussed in [Galène] Videoconferencing server - #44 by tmb ?

Same here. I’ve downgraded Conversations to version 2.20.4 while waiting to find something better.

Ça fonctionne en décochant : oblige la liaison de salon

Does the problem also apply to YunoHost 13.0 / Trixie spooky beta installs?

Thanks for the advice !

Hit the same Prosody log on a YH instance that still uses LDAP-backed PLAIN for XMPP: Channel binding 'tls-unique' undefined in context of TLS 1.3, then the session dies during SASL.

What helped as a short-term client-side workaround (not a server fix): in Conversations, turn off the option that forces channel binding / “require channel binding” (wording varies by build). After that, PLAIN over TLS 1.3 can complete again on the F-Droid builds that started rejecting the missing binding.

That matches what others reported here. It does not restore SCRAM or proper channel binding — LDAP credential storage still limits the usable SASL set to PLAIN — so it is only a way to keep mobile clients connecting until the LDAP/SCRAM work lands.

Also curious whether YH 13 / sssd changes the picture for Prosody auth, or if XMPP stays on the same PLAIN path for now.