XMPP Service Operators - 2022-05-22

my server has a self-signed certificate. but in my logs i can see the s2s_in connection fails, but then the other server retries and it gets established. why does another server accept bad certificates on the second try?

They may be configured to fallback to dialback

what's dialback?

smooth_operator: https://xmpp.org/extensions/xep-0220.html

oh so i do have a mod_dialback. if i disable mod_dialback, will that prevent other servers that try to use it from succeeding?

i don't want another server to do anything if the tls fails

smooth_operator: if you want to block other servers you should block them

Using an untrusted cert or disabling dialback doesn't actually do that

the aim is preventing an already trusted cert falling victim to impersonation

*already trusted server

because dialback looks like it's just dns

never mind, lemme read through the whole thing first :)

before asking more questions

smooth_operator, "mod_dialback" Absolutely obsolete and unnecessary module. Cargo cult. The only reason this module is needed is to satisfy the needs of server administrators who do not know how to set up encryption

404 as usual :)

I'm also not using dialback. I think it's not too hard to obtain a valid cert nowadays.

404 makes it sound like enabling Dialback is an alternative to obtaining a valid cert. Probably stating the obvious but it's about whether to break communication with users of servers without valid cert, rather.

The only server I know of which needs dialback enabled for s2s is jabber.org. 🙊

I've seen various others forget to update certs in time. Including push app servers for iOS apps.

Each time that happens that obviously adds to the general perception of XMPP being broken. So in my book there's a trade-off vs. the (quite specific) attack vectors you protect against by disabling Dialback. Hence I wouldn't agree with 404.city's summary.

_Expired certs, XMPP's greatest enemy_

404.city: dialback doesn't disable encryption though? Hopefully no server allows plaintext nowadays, dialback is just a different form of certificate authentication

> _Expired certs, XMPP's greatest enemy_ Is it so hard to write a simple script to update the certificate?

No

It's hard to stop it from failing for stupid reasons though

Monitoring helps a lot, but not everyone sets up any monitoring

(i.e. monitoring that tells you *before* it expires)

It's kind of hard to keep something that's only supposed to run every 2 months running honestly, and hard to test properly in the first place

moparisthebest, (C2S) Users of a server with a self-signed certificate are extremely insecure and will push and accept any certificate

> Is it so hard to write a simple script to update the certificate? Really hard to code 😉 ``` servername=chat.foo.bar connthost=raspi.foo.bar:5269 TTL=20 echo | openssl s_client -starttls xmpp -servername $servername -connect $connethost 2>/dev/null | openssl x509 -noout -dates -subject -checkend $(($TTL*24*60*60)) && echo $servername okay || echo $servername less than $TTL days left ``` echo could be anything else, maybe curl to send xmpp-msg to the admin Normally the getssl/certbot/... is running everyday and if less than 30days left the update will be done. Above 3 lines could run every day and if getssl/certbot miss 10 tries, the admin should have a look. Without getssl/certbot you could use the 3 lines as a reminder to wake up and prepare your steps for a new cert.

ernst.on.tour: theory is good, practice? We see it here every month

404.city: I mean I agree with you, but it's made more secure in that you can't just silently replace it with trust on first use and such

Still far better than not encrypted

"My" 5 servers were never named 😛 But for sure, you must have a look about it in your InBox

ernst.on.tour: I have similar alerts set up, do you notice if they stop coming though? :)

Establishing a secure connection from jabber.gg to lebihan.pl failed. Certificate hash: 151045a9417eb1efacf0a7f6dfb7aa68a6b5f68c13a1e6d8c3b29752e447ec60. Error with certificate 0: certificate has expired.

Got it 2h ago

> do you notice if they stop coming? Exactly. You'll need a kind of watchdog xmpp client on your client devices (like, your phone) that'd alert you if it didn't receive a keepalive message. Or better: maintain session on the sending side, and alert when presence changes to offline. Then again, who'd be watching the watchers?

mjk: that's the problem

> ernst.on.tour: I have similar alerts set up, do you notice if they stop coming though? :) Yes, because i've pimp up my 3liner and every day 1 msg will be send that $servername=notexist.foo.bar couldn't be reached. Every day there will be *1* msg No msg = no function More than 1 = problems with certrenewal

Right, except I have 20 of those alerts coming in for various things and I've become numb to them, I'll never know if only 1 quit working

My theoretical solution so far is: make your daily driver the watcher. Like, open a chat with your server-side watchdog right in your $mobile_xmpp_client, pin it at the top and patch Conversations so that it displays contacts presence as color-coded something, right in the chat list. This way your eyes get used to seeing a green thingy, so when it goes grey, consider yourself notified

Just because it's connected doesn't mean it's running anything

Right, there's no absolute here, but seems like a huge improvement over expecting to be spammed daily ✏

Sorry, maybe lost in translation, but each monitorjob got its own serviceaccount, means 5jobs (monitor cert, monitor filespace, monitor ....) will have Svc01/Svc02/Svc.... Each day there should be 5 msg from 5 accounts to my monitoring-account. Thanks god xmpp is a multi-identity-chat-app, without neet of 5 different mobile-numbers 😉

> Right, there's no absolute here, but seems like a huge improvement over expecting to be spammed daily You could blowup the 3liner to a 300liner, don't check for cert only, monitor all you need and only 1 msg will send.

ernst.on.tour: I'll elaborate what I mean: instead of sending regular messages that say everything is right, only send a message when something's wrong. That's basically polling vs. pushing. The problem, though, is absence of "it broke" messages could mean the thing that sends them broke. If we assume it goes offline when it breaks, the presence-based solution works.

> ... If we assume it goes offline when it breaks, the presence-based solution works. Sadly presence isn't shown live. Maybe a problem with mod_csi/csi_simple Also a broken script will shown as online 😕

Wasn't there someone having an external xmpp service checker fro free?

monitor for free

Also.. Just listen to your let's encrypt mails

Also, somebody ©®™, should update https://modules.prosody.im/mod_checkcerts.html 😄

> Sadly presence isn't shown live. Sure, but the timeouts are reasonable enough for presence to become offline by the next day at worst :))

Sorry, I have a question about uploading images clips, the Connect client, are there any specific options or settings!

abdullah, what's a "Connect client" ?

One of the xmpps cleants

Didn't hear about them before. First test with known working ones like Dino/Gajim/Conversations/Siskin...

> Didn't hear about them before. First test with known working ones like Dino/Gajim/Conversations/Siskin... One compatible with Android

Its apparently an conversation fork (duh) 😄

Another?

No source to be seen easily..

abdullah: c0nnect pro? Pls don't use that... two points, source promised years ago yet none...so violation of license. And two...they broke http uploads? There's your answer about its worth.

ok so what i understand is dialback is only used for (temporary) convenience in case certificates expire? if that's so i will disable dialback. i would rather be secure and suffer the inconvenience

so for the most s2s security, i have: s2s_require_encryption = true s2s_secure_auth = true ssl { protocol = tlsv1_2+ } ssl { capath = /etc/mytrustedservers } tls_profile = modern mod_dialback disabled