Mastodawn

@xmpp_providers
My XMPP server, chat.between-us.online, fell off the Category A list about a week ago, and the reasons I see each day are inconsistent. I also can no longer connect with chat.xmpp-providers.org. I get "Could not authenticate remote servers". Other than this, my server seems to have no problems connecting to any other server, as far as I can tell.

It seems to have happened coincident with getting updated Let's Encrypt certificates.

Let's Encrypt no longer creates dual-use certificates; they dropped ClientAuth from their certificates. I tried switching to ZeroSSL certificates, but they too have dropped ClientAuth.

Is the certificate change coincidental, or do you know if there's another explanation?

If it is the certificates, what do I do? Prosody does not yet have an ability to serve different certificates for inbound and outbound server connections, and so I cannot present a certificate with ClientAuth any longer.

#XMPP

Show thread

Zash 1d ago

@Jerry Looks like @xmpp_providers is running an older version of ejabberd affected by the Let's Encrypt change.

What you can do is to enable mod_dialback to have a fallback from certificate authentication.

Show thread

Jerry on Mastodon 1d ago

@zash @xmpp_providers

Good suggestion, but one doubt.

I do have mod_dialback turned off because I thought the xmpp-providers auditor strictly requires certificate-based authentication to be a Category A provider.

So while enabling mode_dialback may allow connections to chat.xmpp-providers.org again, I believe it would prevent the server from ever becoming category A again, if my understanding is correct.

Show thread

Zash 1d ago

@Jerry As usual, the choice is between purity and "it has to work" 😅

The correct fix is of course for @xmpp_providers to update

Show thread

Jerry on Mastodon

@zash @xmpp_providers
Yeah it does. But maybe more than purity.

Enabling an old authentication capability like Dialback opens a new attack vector on the server, for not a whole lot of good reasons.

Also, when people signed up, they chose a Category A server. Perhaps there's someone using it who would be endangered if I suddenly lowered the security shield just to talk to an outdated server. That person is expecting the server to maintain a Category A security capability.

I decided to stay Category D if it means leaving the server as secure as possible.

I'll wait for the providers and other servers to update.

Show thread

Debacle 1d ago

@Jerry @zash

If @xmpp_providers are using #Debian stable, they have to upgrade #ejabberd to 24.12-3+deb13u2. It has the relevant patch by @holger to ignore the certificate purpose. It's currently in "proposed-updates" (yeah, Debian lingo).

@Jerry @zash @xmpp_providers regarding the attack vector, Holger die a nice writeup on what this actually is over here: https://metalhead.club/@holger/116239792302016942

Holger Weiß (@[email protected])

@[email protected] Yes. I think the main scenario that certificate authentication protects against but Dialback does not looks like this: - Alice exchanges messages with a remote contact, Bob. - Those messages aren't E2E-encrypted/-verified. - The attacker cannot MitM Alice's c2s connection. - The attacker cannot MitM Bob's c2s connection. - The attacker has no access to the remote server's certificate/key. - DNSSEC is not deployed for the relevant domain(s). - The attacker cannot MitM the (multi-perspective) DNS traffic used for issuing a new certificate. - But the attacker can MitM the DNS traffic used for Dialback.

Metalhead.club

Show thread

Jerry on Mastodon 23h ago

@Monal @zash @xmpp_providers

Thanks for this.

This is why I won't use Dialback. It's crazy easy for a state actor or even a sophisticated local hacker to do a MitM attack by manipulating DNS if I allow dialback.

Some people on my server might need to hide, and they expect the security to prevent MitM attacks to be always enabled.

I decided that I'll wait for the storm to clear. I appreciate the information.

Show thread

Zash 9h ago

@Jerry As shown by the jabber.ru hack, it's about as easy to intercept the ACME challenges and issue a certificate for MITM use. No DNS manipulation required, just intercept port 80 traffic close to the server. Consider deploying CAA records https://letsencrypt.org/docs/caa/ or better yet DANE https://prosody.im/doc/dnssec#dane

Certificate Authority Authorization (CAA)

CAA is a type of DNS record that allows site owners to specify which Certificate Authorities (CAs) are allowed to issue certificates containing their domain names. It was first standardized in 2013, and the version we use today was standardized in 2019 by RFC 8659 and RFC 8657. By default, every public CA is allowed to issue certificates for any domain name in the public DNS, provided they validate control of that domain name. That means that if there’s a bug in any one of the many public CAs’ validation processes, every domain name is potentially affected. CAA provides a way for domain holders to reduce that risk.

Show thread

Jerry on Mastodon 8h ago

@zash

Fortunately, I already have DANE enabled on chat.between-us.online and I don't use port 80 to renew certificates. I use the DNS-01 challenge for renewal. So, for both reasons, I think I'm immune to the jabber.ru attack type.

Adding a CAA record is a good idea to narrow the attack surface. I'll do that.

So if I don't enable Dialback I should remain secure is my thinking.