jdev - 2025-02-15

Fellow server devs, in server-to-server certificate validation, do you (or your TLS library) check for the client auth extendedKeyUsage on incomming connections? Do you have the same trick as Prosody, where client certs are validated as server certs?

Sounds like the clientAuth purpose is going away, and it would be nice if that doesn't cause problems we had in the past to reappear: https://infosec.exchange/@mattm/114004472428368645 https://www.chromium.org/Home/chromium-security/root-ca-policy/#32-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies

> Do you have the same trick as Prosody, where client certs are validated as server certs? Yes, well, the opposite way, server certs are used for client auth but validated as server certs

You're saying the same thing as I did.

client cert as in the cert sent by the initiating party

then yes :)

Though at least for me the need for that hack wasn't obvious until it didn't work without it...

It seems like it's common for iOS XMPP users to have unreliable notifications for group chats

Apparently, when the app is in the background and goes offline for a day, the server maybe assume the user left the group chat

Monal recommends increasing the server's session timeout https://github.com/monal-im/Monal/wiki/Considerations-for-XMPP-server-admins/#session-timeout

Prosody: smacks_hibernation_time = 72 * 60 * 60 --72 hours

ejabberd: resume_timeout https://docs.ejabberd.im/admin/configuration/modules/#mod_stream_mgmt

I wonder how many iOS XMPP users have been lost due to frustration with notifications

I think when you enable push on a prosody session it extends smacks timeout to that

certainly mod_push2 does and for similar reasons

Is this a recent change?

I don't think so

https://modules.prosody.im/mod_cloud_notify.html

Good. Is this the same as what's discussed here about snikket? https://github.com/snikket-im/snikket-server/issues/240#issuecomment-2614430241

it is touched on there, but that ticket is about something unrelated

singpolyma, marcl: yes, both, prosody and ejabberd extend the smacks timeout if no push was sent. the timeout only starts after the first push was sent...but if the device in question isn't connected to the internet (turned off, flight mode, no mobile coverage etc.), then that push will get lost on apple systems...that means the timeout started, but Monal won't know...

if apple delivered pushes after the device came online again, that problem wouldn't exist at all...

only starting the timeout after the first push isn't a recent change but at least ~4 years old (both, for ejabberd and prosody)