# Conversations (F-Droid build) / TLS 1.3 channel binding deadlock with LDAP backends **URL:** \ **Category:** Support\ **Tags:** xmpp, french, english\ **Created:** [October 30, 2026, 4:26pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280 "2026-10-30T16:26:22Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![peripheria](https://forum.yunohost.org/user_avatar/forum.yunohost.org/peripheria/32/13938_2.png) [@peripheria](https://forum.yunohost.org/u/peripheria)\ **Post date:** [October 30, 2026, 4:26pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/1 "2026-10-30T16:26:22Z")
### 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\> ---
**Author:** ![anubis](https://forum.yunohost.org/user_avatar/forum.yunohost.org/anubis/32/9218_2.png) [@anubis](https://forum.yunohost.org/u/anubis)\ **Post date:** [October 31, 2026, 10:18am UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/2 "2026-10-31T10:18:13Z")
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](https://github.com/YunoHost/issues/issues/2829) ---
**Author:** ![tmb](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/t/7c8e57/32.png) [@tmb](https://forum.yunohost.org/u/tmb)\ **Post date:** [October 31, 2026, 10:57am UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/3 "2026-10-31T10:57:49Z")
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](https://forum.yunohost.org/t/galene-videoconferencing-server/14730/44) ? ---
**Author:** ![niconicoDT](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/e36b37/32.png) [@niconicoDT](https://forum.yunohost.org/u/niconicoDT)\ **Post date:** [November 2, 2026, 9:16pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/4 "2026-11-02T21:16:25Z")
Same here. I’ve downgraded Conversations to version 2.20.4 while waiting to find something better. ---
**Author:** ![axac](https://forum.yunohost.org/user_avatar/forum.yunohost.org/axac/32/7624_2.png) [@axac](https://forum.yunohost.org/u/axac)\ **Post date:** [November 2, 2026, 9:53pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/5 "2026-11-02T21:53:42Z")
![Screenshot_20261102-225100](https://forum.yunohost.org/uploads/default/original/2X/7/76ca1a7a895d56ca765ce7608f3a4b652da2d96b.png) ---
**Author:** ![axac](https://forum.yunohost.org/user_avatar/forum.yunohost.org/axac/32/7624_2.png) [@axac](https://forum.yunohost.org/u/axac)\ **Post date:** [November 2, 2026, 9:55pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/6 "2026-11-02T21:55:03Z")
Ça fonctionne en décochant : oblige la liaison de salon ---
**Author:** ![tmb](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/t/7c8e57/32.png) [@tmb](https://forum.yunohost.org/u/tmb)\ **Post date:** [November 3, 2026, 7:45am UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/7 "2026-11-03T07:45:51Z")
Does the problem also apply to [YunoHost 13.0 / Trixie spooky beta](https://forum.yunohost.org/t/yunohost-13-0-trixie-spooky-beta/40656) installs? > [@jack\_o\_lantern YunoHost 13.0 / Trixie spooky beta](https://forum.yunohost.org/t/yunohost-13-0-trixie-spooky-beta/40656/1): > > - **Users / LDAP stack** : Switch to [`sssd`](https://packages.debian.org/trixie/sssd) / [`sssd-ldap`](https://packages.debian.org/trixie/sssd-ldap) and other SSS-related stuff as a replacement for unscd, nslcd, sudo-ldap and everything else related to LDAP integration to the system ---
**Author:** ![niconicoDT](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/e36b37/32.png) [@niconicoDT](https://forum.yunohost.org/u/niconicoDT)\ **Post date:** [November 3, 2026, 3:41pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/8 "2026-11-03T15:41:55Z")
Thanks for the advice ! ---
**Author:** ![cdnca6688](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/c/7ea924/32.png) [@cdnca6688](https://forum.yunohost.org/u/cdnca6688)\ **Post date:** [November 4, 2026, 10:55pm UTC](https://forum.yunohost.org/t/conversations-f-droid-build-tls-1-3-channel-binding-deadlock-with-ldap-backends/43280/9 "2026-11-04T22:55:35Z")
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.