XMPP Service Operators - 2026-03-14

Seems I can't s2s to ejabberds anymore. Quicksy.im and jabber.fu-berlin.de fail with > Could not get software version: Server-to-server connection failed: Could not authenticate to remote server

Wild guess: you server doesn't support dialback?

Isn't that the ssl cert issue on outdated ejabbered servers people have been talking about since weeks?

*sigh* I didn't expect quicksy.im to be affected. I assumed this would only weed out unmaintained servers. :(

Most likely, for both server I get: Authentication failed: Peer responded with error: unsupported certificate purpose (not-authorized).

Hmm, DANE can't work around this?

I don't think that DANE can verify the client's identity.

iirc Daniel told me that quicksy was indeed running an older ejabberd version that was affected by the LetsEncrypt change thing. Conversations.im is fine.

*sigh*

😭

sezuan, DANE can work for authenticating the client side of incoming s2s connections: https://prosody.im/doc/modules/mod_s2s_auth_dane_in

> I don't think that DANE can verify the client's identity. It can, you have the domain, look up all TLSA records for XMPP and allow any ↺

but of course DNSSEC/DANE will never work for .im domains so...

> Martin enabled dialback in 2026… Are there any security disadvantages for dialback? I enabled it too because someone I know uses a very questionable setup that breaks everything ↺

It's... complicated

Both the full answer is complicated, and "dialback is complicated" is part of the answer 🙂

Usually I'd say it is so easy to gather widely accepted certs with let's encrypt that I won't bother with dialback.

It can be made very secure, especially if you sprinkle in DNSSEC and TLS (and the latter is mandatory on practically all servers)

But to issue a certificate, Let's Encrypt will typically check a server from multiple vantage points to minimize the risk of MITMs (through, say, BGP hijacks or whatever). Dialback just requires someone to MITM your server.

The logic to implement dialback correctly is surprisingly complicated, even though at a high level it's quite a simple mechanism. There are no known security issues, and all major servers have had their code in production for a long time by now, so it's probably fine.

TLS/PKI verification is also complicated, but there are significantly more people working on those things because they are used everywhere on the internet

My preference is to lean on the standard work of others, especially since we already rely on it for other things. It allows us to literally disable hundreds of lines of critical code and reduce the surface area for attacks. ✏

That said, dialback has one advantage over pure TLS/PKI auth: if a cert/key is leaked or maliciously obtained, it's rather trivial to use that to impersonate a service without needing to also perform any network MITM attacks.

That can be improved through DNSSEC+DANE, but deployment of that is far from universal currently

The sheer number of trusted root certificates in `/etc/ssl/certs` alarms me a little, but you've clearly thought about this more than I have.

Yeah. The situation is better now than it used to be, since the introduction of Certificate Transparency requirements, etc. But realistically 99.9% of XMPP servers are using <1% of the CAs in the default trust store, and if you have qualms about specific CAs, you can always distrust them on your system(s).

And of course, deploy DNSSEC/DANE if you haven't already, which bypasses the trust store issue completely

I have DNSSEC but not DANE yet

> Seems I can't s2s to ejabberds anymore. Quicksy.im and jabber.fu-berlin.de fail with >> Could not get software version: Server-to-server connection failed: Could not authenticate to remote server Same, just noticed it

What is the tl;dr for ways to work around that?

Convince the admins to upgrade their ejabberds, enable mod_dialback yourself or just live with broken s2s to those servers.

I enabled dialback, although I don't like it.

easiest is to change your LE profile and get a new cert that broken ejabberd's will accept for a few more months

and hound the admins to upgrade in the meantime

> Convince the admins to upgrade their ejabberds, enable mod_dialback yourself or just live with broken s2s to those servers. Does anyone know whether quicksy.im has planned maintenance to fix it?

> easiest is to change your LE profile and get a new cert that broken ejabberd's will accept for a few more months Or that. Where can I find details on what I need to do?

tlsclient acme profile https://letsencrypt.org/2025/05/14/ending-tls-client-authentication

erebion: quicksy.im is waiting for an update to be available in Debian

renew with that one more time may 12th for maximum time

I've heard rumour that people are working on that, but I actually don't know who/where, so I'm not confident a fix is imminent

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128568

> erebion: quicksy.im is waiting for an update to be available in Debian Oh, 26.02. is in unstable now, so could be taken from there 🤔

No. Must be in testing before you can backport the version to stable-backports.

> No. Must be in testing before you can backport the version to stable-backports. The package could just be taken

>I will try to prepare packages for >proposed-updates over the weekend, >which would move into stable with the >following point release of Trixie. Nice, but a really long time that users will be disconnected from their conversations. ✏

>I will try to prepare packages for >proposed-updates over the weekend, >which would move into stable with the >following point release of >Trixie. Nice, but a really long time that users will be disconnected from their conversations. ✏

>I will try to prepare packages for proposed-updates over the weekend, >which would move into stable with the >following point release of >Trixie. Nice, but a really long time that users will be disconnected from their conversations. ✏

what does that mean date-wise ?

> > No. Must be in testing before you can backport the version to stable-backports. > > The package could just be taken Not sure if this will work. If it is a "standalone" package it might work. But if it needs e.g. a newer libc or something it won't. As an operator of a large public server I wouldn't toy around with sid packages in stable…

they can add ejabberd's repos instead, it's an option anyway

moparisthebest: You could take it from proposed-updates in a few days if he succeeds, it will come to regular updates in the next point release then.

when's the next point release

Unfortunately the last point release was today, so not around the corner

But at least proposed-updates is an easy path for most setups

> they can add ejabberd's repos instead, it's an option anyway That's what I do, even though I definitely don't like not using Debian repos, but those still have a ~ two year old version in testing.

July 12th is the last possible time the tlsclient profile workaround certs will still work under default config if everyone renews may 12th

> Unfortunately the last point release was today, so not around the corner This shouldn't need to wait as this is a grave functionality issue.

But yes, using the Process One repos helps, moving to that just requires one or two symlinks and then the data folders work with both package sources.

Doesn't debian patch security problems quicker? This is a DoS

> Doesn't debian patch security problems quicker? This is a DoS Yeah and it also is likely to make people fall back to less secure methods. That's why it is critical to get the fix into the repos quickly.

After all, the diff is quite small.

I think it's a stretch whether this can be considered a security issue, though I'll admit it's not definitely not one (e.g. there is an argument that ever accepting client purpose is potentially a security issue)

it's at least a DoS

If google chrome released an update making it unable to connect to nginx/apache on debian stable I bet they'd find a way to patch it outside point releases, this is the same

Someone with a xmpp.earth account was blocked by mod_anti_spam from being able to message me. I only have it subscribed to xmppbl.org and don't have it set to block any strings. I don't think xmpp.earth has been a significant source of spam. Have people run into false positives with it before?