XMPP Service Operators - 2022-03-15

well this seems absolutely fatal for every XMPP server on the internet that uses OpenSSL https://www.openssl.org/news/secadv/20220315.txt update soon?

'Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1.'

1.0.2zd, I'll miss their versioning scheme when 1.x is dead!

_Premium versioning schemes_

Soon: 1.0.2zzzzzzzzz

Eternal slumber

Guess I'll finally slap rustls in front of my server later instead of upgrading...

OpenSSL high volunablity https://www.openssl.org/news/secadv/20220315.txt

moparisthebest: 0.x versions for the win!

> There are no major breaking interface changes envisioned after the set included in the 0.20 release. Wouldn't SemVer suggest 1.0 then?

moparisthebest, I wouldn't call a remote unauthenticated DoS "absolutely fatal". A remote unauthenticated code execution, *that's* absolutely fatal.

you had me scared there for a second.

jonas’: I mean, you can cripple the entire public federated XMPP network I'd guess

sure, but then people will update and restart their servers.

that's ok

You are right RCE would be worse, I'd still call this fatal

absoutely fatal has some absolute fatalism to me and the bare possibility of a worse bug precludes the use of that term :)

Well there's always a worse bug... :D

FWIW I also went "huh did I misread their announcement, wasn't it just DoS?".

Debian has only 1.1.1.k?

...if not patched much earlier

moparisthebest: only xmpp?

Licaon_Kter: I mean, who does TLS with SMTP?

or HTTP for that matter

Menel, for debian, see https://security-tracker.debian.org/tracker/CVE-2022-0778

It's almost only XMPP

You can't force an arbitrary https or SMTP server to parse a certificate of your choosing

Where as you can force any XMPP server that does s2s to do it

moparisthebest, clients though.

> or HTTP for that matter Yeah, not that many http servers accept client certs, I think

And SMTP servers don't?

*Clients accessing evil.com

"My browser is using 100% CPU... that's never happened before, oh no"

xD

well, it would be interesting to have something other than ublock origin eat a CPU core for a change

SMTP doesn't authenticate certificates at all by default

jonas’: thanks. Got confused but of course.. Debian stable not updating the version "number"

moparisthebest: does it need to authenticate using them, or only parse them?

moparisthebest, for certain definitions of "by default"

MattJ: just parse, but they wouldn't accept client certs at all I suspect

> It's almost only XMPP Matrix!

Oh yeah, there's that other ~homeserver~ federated protocol

Holger: do they do client cert auth for s2s? It wouldn't surprise me I just don't know anything about it

moparisthebest: I had no idea and was hoping someone would tell us 😁 Seems the answer is no: > Requests are authenticated at the HTTP layer rather than at the TLS layer because HTTP services like Matrix are often deployed behind load balancers that handle the TLS and these load balancers make it difficult to check TLS client certificates. They then go on saying "if you like just do it nevertheless" (not sure how that's supposed to be useful): > A homeserver may provide a TLS client certificate and the receiving homeserver may check that the client certificate matches the certificate of the origin homeserver.

Holger, could someone running a matrix homeserver tell between a pinned CPU and normal use though?

Heh.