XMPP Service Operators - 2023-10-21

What DNS to set for pop3s?

I have it on 995

You mean port not fns?

995 TCP

I guess the whole cert generation tools, CAA and the rest got a bit more testing these days given the incident. I've seen some issues in my setup at leastp

well, I'd really love for XMPP Observatory to make a comeback, I'm still struggling to find an easy-to-use tool to check TLS configuration

have to use multiple

I mean, I remember that it was a resource hog, but man it was handy

It just needs someone to make it 🙂

And, crucially, maintain it

The old one was out of date and giving bad security advice

but it provided with a lot of raw data in a single place -- yes, it was up to maintainer to decide on it -- but nevertheless, it was all in one place

Yes, set the SRV record

Anyone have an idea about why Gajim gets no “Private messages are disabled” in this room?

☭Mike Yellow: rephrase "gets no" ? Does it get the messsage since they are disabled? Or does not get that message and then errors when you try?

https://suchat.org:5443/upload/72100d426ee0a341f79cb126f62c325d03f117fb/pNaJLfj0HBlixDWXG51PfspwgiP7ayFOVeaPX4AK/0a4911f2-acb3-4125-bf30-68fa73838fc5.png

I can get error and see “Private messages are disabled” on Conversations.

Mattj: are there any specifics with enabling channel binding on prosody? I couldn't find anything in the docs on the site

Licaon_Kter, did you receive that?

https://upload.core.radiosignal.net/upload/5zVL7VH25QCMzvvR0Or680Mq/8372ca08-ee51-4568-95bc-c0c04e889328.png

for crying out loud

i don't know if oxpa is still here, but they really need to get their act together

their TLS configuration is not just outdated, it is dangerous

https://upload.core.radiosignal.net/upload/25OSPKvlWgiPKEQciOnmgEpN/c6b8012c-d881-4847-8620-36c0f1cb3c56.png

Pet peeve, a d I'm not 100% sure if this is the case with oxpa, but it kind of irks me when people start requiring things from other people that are providing free services in their spare time.

I don't require anything from anyone, I'm using my own server

but my friends are using this, hence my interest and, frankly, discomfort

what are your friends using?

jabber.ru as their primary server, for various reasons

☭Mike Yellow: > Licaon_Kter, did you receive that? No

ru_maniac: > Mattj: are there any specifics with enabling channel binding on prosody? I couldn't find anything in the docs on the site Run "trunk"

>No So I wonder why there is no an exclamation symbol on Gajim.

Licaon_Kter: > Run "trunk" Not available at 0.12 branch, I take it?

> i don't know if oxpa is still here, but they really need to get their act together Think this was always known, for years ru_maniac: > jabber.ru as their primary server, for various reasons Ask them to make another account on an working server, sorry, but use the incident as leverage

☭Mike Yellow: go in the Gajim room and ask, search their Issues section in their repo etc

> MattJ a écrit : > AFAICT certspotter doesn't differentiate between certs issued to you, or to someone else. So it would just notify you every month or so about your own certificates. That would be annoying, and make it more likely that you would miss actual issues. This is not a problem, if you refine it to make it easier to pay attention to

Licaon_Kter: known or not, this is barely an excuse

ru_maniac: nope, didn't know either, thought that 50% of the network, those who host prosody, have this live since a year ago or more when the blogposts where posted and Monal and Conversations and who ever started to support it

as for moving to another server -- this solves this specific situation, sure, but not really a fix in the end

> ru_maniac a écrit : > for crying out loud > i don't know if oxpa is still here, but they really need to get their act together afaik their act is together, the interceptor is who is mucked up

ru_maniac: baby steps

true enough

Lightning Bjornsson: oh, c'mon... their ejabberd version was 3.2 or some $hit from 2014????

> Lightning Bjornsson: oh, c'mon... their ejabberd version was 3.2 or some $hit from 2014???? 3.2 something from 2016 ↺

afaik, 3.2 last release was around 2018

okay, you have a point, but that doesn't go against the fact that the cert on-device wasn't expired, and the cert others saw was.

had their act been together, their dns would have been set up properly

> okay, you have a point, but that doesn't go against the fact that the cert on-device wasn't expired, and the cert others saw was. they've caught this only when their service went belly up, and clients were unable to connect due to expired cert ↺

ru_maniac: the mitm-er service went belly up' I blame the mitm for not refreshing certs on time :)) _XMPP's greatest enemy are certs_

> afaik, 3.2 last release was around 2018 Was it? ejabberd switched to YEAR.MONTH before 2017 iirc, then again maybe they had Bussiness Edition? ¯\_(ツ)_/¯

ru_maniac, channel binding is automatically offered in Prosody whenever it can be, you don't need to "enable it". However the biggest reason it might not be offered right now is because the current stable branch doesn't support it with TLS 1.3

>> afaik, 3.2 last release was around 2018 > Was it? ejabberd switched to YEAR.MONTH before 2017 iirc, then again maybe they had Bussiness Edition? ¯\_(ツ)_/¯ last release in the branch, prob was a maintenance release

Channel binding was only defined properly for TLS 1.3 in RFC 9266, last year

> ru_maniac, channel binding is automatically offered in Prosody whenever it can be, you don't need to "enable it". However the biggest reason it might not be offered right now is because the current stable branch doesn't support it with TLS 1.3 got it, thanks that was a bit unclear from 0.12.4 changelog

It wouldn't be in the 0.12.4 changelog because there have been no changes related to channel binding in 0.12, as far as I recall

I think we've supported it in 0.10 or so, released back in 2017

there was something re: TLS 1.3 and how SCRAM-SHA-1-PLUS works improper, iirc

but I may be mistaken

So the important change in trunk (and the next major release) will be support for channel binding with TLS 1.3

I see, thank you for the detailed explanation, this answers my question fully

I am a simple Jabber user, not a system administrator can someone explain in detail yesterday’s incident with jabber.ru? Does what happened indicate Jabber as an unreliable method of communication? I use OMEMO encryption with all contacts (key fingerprints have been confirmed in real life)

basicdreams, no, the same attack could have worked against any protocol, it's not a problem of Jabber/XMPP

In fact Jabber/XMPP does already have protection against this, but it wasn't enabled on jabber.ru

> I am a simple Jabber user, not a system administrator > can someone explain in detail yesterday’s incident with jabber.ru? Does what happened indicate Jabber as an unreliable method of communication? I use OMEMO encryption with all contacts (key fingerprints have been confirmed in real life) 1) TLDR: their hosting provider implemented man-in-the-middle type of attack, de-crypting and re-encrypting all of their traffic 2) it does not, their service was just incorrectly configured ↺

basicdreams, and if you use verified OMEMO, your communications are secure (they could see that you sent a message to a person, but not the message contents)

thanks for the answer yes, I understand what MITM is, but I don't understand if I should take any action on the client side (someone above advised to enable DNSSEC in Conversations settings, for example) ✏

Just DNSSEC wouldn't have prevented this, the best defence is channel binding, but you need a server that supports it (the latest Conversations version does, if the server does)

and discussion about channel binding support in servers is precisely what is happening here this morning :)

How to check if channel binding is enabled?

In Conversations

I don't know if it tells you, unfortunately

mekosko: you need server running prosody trunk, maybe https://compliance.conversations.im tells you the version

Licaon_Kter, (or Holger) do you know if ejabberd supports tls-exporter?

¯\_(ツ)_/¯

Is there any XEP that describes channel binding?

basicdreams, no, it's part of SCRAM, the authentication method we mostly use these days

Both Prosody and ejabberd have supported it for years, on TLS 1.2. Support for channel binding with TLS 1.3 will be in the next Prosody release, and I'm unsure if ejabberd has it already or if it's planned.

Licaon_Kter, I think compliance site does not check for this XEP, because it shows 100% compliance for ejabberd 23.04 server I'm currently on

mekosko: "tells you the software version"

It's not a XEP

Well, there is XEP-0440, but servers can support channel binding without XEP-0440

The old xmpp.net would have reported this, but unfortunately it died

There is also an option to verify each cert manually in conversations, maybe this may help?

Not really, unless you know which certificate should be trusted and which should not

But you will know if cert is changed

mekosko: maybe the real admin changed it

Yes, it changes every 4 weeks probably

Although I'm not sure what difficulties there are when working in this mode ✏

Then sure, you can log in via ssh every 4 weeks and verify the fingerprint

What if you are an admin ✏

Although I'm not sure what difficulties there are when working in this mode

would s2s suffer from the same type of attack?

Yes, it could do. It didn't in this case (they only targeted port 5222). Channel binding isn't an option for s2s, so we're considering what other protections might help there.

Licaon_Kter:

Licaon_Kter: I have something to share

I have something to share

Licaon_Kter:

I have something to freely share

what

techmetx11: our frenly spammer, nvm

yes i expected

they sound like that oneplus vpn guy

Because they is

We have an unusual idea. We find that well-maintained servers never guarantee they are able to register in-band in long term, so many servers suggested in the manual are not reliable for newcomers. How about suggesting some half-abandoned servers for them?

After they get familiar with XMPP, then they can choose a suitable server for themselves by themselves. ✏

☭Mike Yellow: not sure what reliable has te do with spammers actions ✏

>has te do What is this?

☭Mike Yellow: not sure what reliable has to do with spammers actions ✏

Typos

I know spammers are annoying. And we see the future of XMPP servers is to refuse to register in-band, reasonable and acceptable. But for computer newbies, especially who can not read English, it may be better to tell them to register half-abandoned servers, which has a greater probability to succeed in one try.

It is awkward when they tried two servers and be refused to register in-band.

Better don't recommend abandoned servers. If you want to recommend a server with ibr your group should operate one if you have someone with the expertise as for other servers you can't guarantee the availability of ibr. Bit running an ibr enabled server takes a lot of effort if you don't want to get quickly blocked by other servers due to spam.

If you are operating the server and only people you know are using it, invites sound great for your use case

Yeah. Invitation-only institution is always the way to fully block spammers and enemies.

For Chinese, to establish an XMPP server, one should...: Learn to be an advanced XMPP user. Then learn to be an server host. Be able to read another language and have money to rent a foreign cloud server. Or have a full-time running computer and learn to establish an XMPP server over I2P or Tor?

Chinese users are not united for now. Can not even think about establishing such an invitation-only server. Even the amount of advanced XMPP users in China I know is not greater than 10.

☭Mike Yellow: that's what anyone has to do, wtf, U R not special, head down, read more, stfu :)

```Details for xmpps-client check Certificate expires at 2023-12-06T16:45:38Z. SASL mechanisms: PLAIN, SCRAM-SHA-1, SCRAM-SHA-1-PLUS, X-OAUTH2``` Should I disable all methods besides SCRAM-SHA-1-PLUS to force channel binding? ✏

raver, yes, though you may end up with clients not able to connect. And that will include all web clients, because browsers don't support channel binding.

Anyone uses opensmtpd?

sagaracharya: wrong channel

sagaracharya, ask here: hbsc@muc.lurk.org ✏

sagaracharya: I am truly curious - what is your motivation to keep asking offtopic questions here, when that typically ends up in a verbal clash with others? Do you disagree that this is offtopic? Do you disagree with the policy? Is this the most appropriate channel that you know of to ask these questions?

Ihave to learn the art of having 200 users at the very start

MattJ: thx, good to know. I only use movim very rarely. If I leave more mechanisms enabled can I force the client to use the best?

That is acrucial art

Well. I don't act in silos. I believe a discussion near the topic is allowed. I personally wouldn't mind discussion on food if this were my channel

okay, so you do not agree with the policy - I get that.

Guus: https://humaaraartha.in/sagar/essays.html

I can teach you English if you want

I believe the moderators are doing their job well

Guus: When you become the moderator, you can add your divine opinion on what's on topic and what is not

I'm not trying to aggravate you. I was truly interested.

Anyways, I have better work to do, i.e. completing my mailserver setup :)

Yes, I saw that interest

but, as you implied yourself: this is not 'your' room. We're all guests here, basically. It does not seem unreasonable to me to adhere to the stated policy - especially when you have already challenged that policy, and owners indicate that they keep the policy as-is.

should there be another "spam manifesto" style pledge/whatever to get most/all the server to deploy CAA+DNSSEC and channel binding where possible?

octagon, a general set of evolving "best practices" for server operators would probably be nice to have

and this would be something that can go on it. Well, soon (we still need to get channel binding for TLS 1.3 generally available - afaik neither Prosody nor ejabberd support it in current releases)

> octagon, a general set of evolving "best practices" for server operators.... So you are always behind "modern" setup

"Just do what Snikket does." EOF

(but I'm currently working on a PR to disable PLAIN in Snikket entirely)

> ```Details for xmpps-client check > Certificate expires at 2023-12-06T16:45:38Z. > SASL mechanisms: PLAIN, SCRAM-SHA-1, SCRAM-SHA-1-PLUS, X-OAUTH2``` > Should I disable all methods besides SCRAM-SHA-1-PLUS to force channel binding? raver, I’m curious how you check this

unfortunately i’m not sure how I’d set this up with the way my services are authenticated to (LDAP)

Yeah, some deployments make it hard/impossible to do channel binding

and sometimes even SCRAM isn't possible

yeah, all the passwords are hashed with argon2id on the LDAP side, so i can’t access them

Yep, so you're presumably PLAIN-only

yeah

With the SASL2 FAST stuff, the client would be able to upgrade from password auth to token auth, and the token auth supports channel binding

token auth? oh, like doing authentication once and then generating a token?

So 99% of the time you'd be protected, unless you had to log in with your password again for some reason

Yeah

yes, that’d be ideal :P

Are clients expected to scream murder when they were once offered channel binding, but not any longer, for a particular domain?

i’m assuming it’s still being implemented in clients and servers as of now, though

https://blog.prosody.im/fast-auth/ has some info - it's still early days, but it's surprisingly widely implemented already

Guus, we leave that problem up to client developers and UI designers :P

that seems very impressive

MattJ: should we? Isn't that the only way to reliably (?) offer channel binding and other Auth mechanisms at the same time?

i’d like to see that in ejabberd if it isn’t already :o

Otherwise, a mitm attack would simply silently drop the channel binding, right?

unix.dog, you and lots of people :)

I assume it will come, but I think they just haven't found someone to implement it yet

yeah, that’s just how it is i think

i do want to pick up erlang so i can contribute some..

> https://blog.prosody.im/fast-auth/ has some info - it's still early days, but it's surprisingly widely implemented already best, both the client and server are supported for secondary authentication。（2FA） ✏

2fa alone doesn't help prevent mitm like it was done, I think.

The critical operations on the server need to be confirmed. Important, must be 2FA （2FA is not popular so far）. 2FA is more popular and acceptable than other schemes.

https://notes.valdikss.org.ru/jabber.ru-mitm/ it real?

华南网友: yes, ongoing discussion

>> ```Details for xmpps-client check >> Certificate expires at 2023-12-06T16:45:38Z. >> SASL mechanisms: PLAIN, SCRAM-SHA-1, SCRAM-SHA-1-PLUS, X-OAUTH2``` >> Should I disable all methods besides SCRAM-SHA-1-PLUS to force channel binding? > raver, I’m curious how you check this I've checked the supported mechanisms here: https://connect.xmpp.net/ ↺