XMPP Service Operators - 2026-01-10

> ive heard theories that its rewtkid, no evidence to corroborate though its not rewtkid ↺

if it was rewtkid then the spam would be worse and there would be some child porn and gore to go along with it

tom, moparisthebest, on my servers, prose.org, jabber.org or xmppbl.org still rely on dialback, as well as a bunch of less popular servers.

It’s a valid way of authenticating a server which doesn’t serve a valid certificate still.

Link Mauve, you implement TLS?

so this only to fix federation if a server has a expired certificate? ✏

That and self signed

> It’s a valid way of authenticating a server which doesn’t serve a valid certificate still. servers who don't have a valid cert aren't valid, letsencrypt has been around for over 11 years, 2014, zero excuse here in 2026 ↺

I've had dialback disabled forever, 2 or 3 years ago when I disabled TLS 1.2 I lost federation with 1 person running mlink on Ubuntu 14.04 🤷

what tools do you use yo view your peers? just grep the logs?

moparisthebest, Let’s Encrypt still doesn’t support domains which only use SRV records to delegate their XMPP service.

I’ve heard this is changing, but having an invalid certificate is still not that uncommon due to that, sadly.

hueso, prosodyctl shell s2s show

You have many interesting commands in prosodyctl shell, try help() for a list.

I use ejabberd ¯\_(ツ)_/¯

Maybe ask in their room? I haven’t used it since 2016.

> moparisthebest, Let’s Encrypt still doesn’t support domains which only use SRV records to delegate their XMPP service. Link Mauve, you can use acme.sh or dehydrated to issue certs via DNS ↺

so non-issue

A user got some spam from an elaon.de user today. Dunno if the admin is here and wants to review recent signups

icebound.dev, I’m not the manager of the domain, my users delegate the SRV to me, and unless they send me a valid certificate every three months they will get an invalid one.

> moparisthebest, Let’s Encrypt still doesn’t support domains which only use SRV records to delegate their XMPP service. Sure it does, DNS challenge ↺

There's also a ton of other ways to do it with the https challenge and no communication between servers, letsencrypt DNS delegation etc etc

moparisthebest, our users will not delegate their whole acme zone to us.

If you haven't bothered to do any of this in 14 years that indicates you care nothing about your XMPP server

Oh yeah sure we don’t care about it.

See you.

Not you, the people without valid certs

Insane how people are justifying invalid certificates in 2026

> moparisthebest, Let’s Encrypt still doesn’t support domains which only use SRV records to delegate their XMPP service. No, but a reverse proxy can just forward the request for the well-known file to the other server, this reverse proxied connection can even uses self-signed certs, so still not a good excuse to not do it right. ↺

I also don't have mod_dialback enabled.

> If you haven't bothered to do any of this in 14 years that indicates you care nothing about your XMPP server Mopar your not listening to what link is saying ↺

Link Mauve: thanks for your justification. Guess I'll keep dialback since there is no harm in it.

> I've had dialback disabled forever, 2 or 3 years ago when I disabled TLS 1.2 I lost federation with 1 person running mlink on Ubuntu 14.04 🤷 Jabber.Ru still uses tls1.2. ↺

Tls1.2 is not insecure, just requires proper configuration ✏

no that's wrong, it's insecure in many ways configuration can't even fix tom

Source?

and there is harm in dialback since anyone on the single path between you and the other server can MITM your connection, vs letsencrypt or dnssec+Dane which prevents that

the easiest problem to point to with TLS 1.2 with XMPP specifically is it makes channel binding useless, rather it's vulnerable to MITM, there are a lot of other things like truncated hashes and such that affect all protocols using it downsides for disabling it are you'll lose federation with the one guy running mlink on Ubuntu 14

didnt openfire only recently get tls1.3 because some jvm thing?

https://web.archive.org/web/20250406160338/https://www.mitls.org/pages/attacks/SLOTH there's a ton of attacks linked here that are mostly the cause of TLS 1.3 existing

all I can say is I'm in 100+ MUCs and turned off 1.2 when it was only used for 1 of 1000 or so connections, years ago, same with dialback... by all means check first but neither should be a problem in real life now

> and there is harm in dialback since anyone on the single path between you and the other server can MITM your connection, vs letsencrypt or dnssec+Dane which prevents that Would dialback and dnssec prevent that? ↺

> the easiest problem to point to with TLS 1.2 with XMPP specifically is it makes channel binding useless, rather it's vulnerable to MITM, there are a lot of other things like truncated hashes and such that affect all protocols using it > > downsides for disabling it are you'll lose federation with the one guy running mlink on Ubuntu 14 I don't want to lose federation with jabber.ru ↺

They are under a constant barrage of cyber attacks so I wonder if they truly do not support tls1.3 yet or if this is a downgrade attack. My resolver is constantly spitting warnings about attempted tampering with their zone that dnssec prevents

>> and there is harm in dialback since anyone on the single path between you and the other server can MITM your connection, vs letsencrypt or dnssec+Dane which prevents that > Would dialback and dnssec prevent that? nope, but if you have dnssec then you can have Dane which prevents it ↺

>> the easiest problem to point to with TLS 1.2 with XMPP specifically is it makes channel binding useless, rather it's vulnerable to MITM, there are a lot of other things like truncated hashes and such that affect all protocols using it >> >> downsides for disabling it are you'll lose federation with the one guy running mlink on Ubuntu 14 > I don't want to lose federation with jabber.ru again, 14+ years to fix it, famously been attacked before, imho it'd be much better to cut it off and force those users to pick an actually maintained server than for them to use a known insecure already compromised one ↺

iirc even debian oldoldoldstable supports TLS 1.3, it's wildly insecure in all the other ways of course not having received updates for 8 years but anything not updated for even longer I'm not interested in federating with, I think it's a disservice to their users to let them keep using it not knowing how bad it is

> iirc even debian oldoldoldstable supports TLS 1.3, it's wildly insecure in all the other ways of course not having received updates for 8 years but anything not updated for even longer I'm not interested in federating with, I think it's a disservice to their users to let them keep using it not knowing how bad it is This.

moparisthebest: Is there a hardening guide for XMPP servers somewhere and if not... Would you be willing to write down some notes? :D

Guess that might be helpful to many

Hardening is basically: using defaults with tls13 only. Having DANE records. And if prosody use DANE outgoing and sasl2

That and disabling dialback

Oh right that is still on in the defuault config file.

erebion: here's some other things to think about https://github.com/divestedcg/safeguarding-xmpp-2025

https://codeberg.org/divested/safeguarding-xmpp-2025

> didnt openfire only recently get tls1.3 because some jvm thing? jjj333_p [pain.agency], Openfire had tls1.3 a for a while. There was a bug which prevented TLS1.3 for c2s a year or two ago. ↺

> erebion: here's some other things to think about https://github.com/divestedcg/safeguarding-xmpp-2025 no, stop endorsing this, it literally contains Linuxisms, not to mention some of it is questionable. ↺

> jjj333_p [pain.agency], Openfire had tls1.3 a for a while. There was a bug which prevented TLS1.3 for c2s a year or two ago. ah ↺

>> erebion: here's some other things to think about https://github.com/divestedcg/safeguarding-xmpp-2025 > no, stop endorsing this, it literally contains Linuxisms, not to mention some of it is questionable. It has good general advice that's all, cut it out ↺

> It has good general advice that's all, cut it out most of it is standard anyways, but it strays outside the realm of XMPP ↺

> Program allowlisting and integrity checks SHOULD be enforced via eg. fapolicyd Even tavi stopped using fapolicyd because it kept breaking

these are sensible defaults, especially: >Distinct public facing services SHOULD be isolated to their own (virtual) machine this can be costly

also no mention of containerisation, which can be a lighter way of isolating services

lighter but not as secure

Please notice I said things to think about, not do 100% of these things lol

> lighter but not as secure so we should have providers splash the cash shall we? ↺

how about we mandate that all server hardware is the latest too

where do you draw the line!?

who's mandating anything

Security is not some checklist, it needs to be evaluated and is specific to each setup

hence "things to think about" right

> System updates MUST be performed at least once a month Base BSD systems can go months without security patches being required. > Updates SHOULD be performed more frequently such as weekly or daily ditto > Full system reboots MUST be performed at least once a month ditto

> hence "things to think about" right yeah but an RFC style "standard" is just bullshit ↺

if you changed it to "security considerations" instead of demanding what people do or do not do, I probably would oppose it so rigidly

but making security like its some sort of standard you must follow to be considered "secure" is stupid ✏

Can you comment on each line elsewhere ✏

can you stop shilling it like its the arbiter of truth?

never did it once so far

I told you before, I would rigidly oppose it every time someone tried to push it for XSF approval.

what are you talking about

nvm, im half asleep