XMPP Service Operators - 2023-10-21


  1. sagaracharya

    What DNS to set for pop3s?

  2. sagaracharya

    I have it on 995

  3. fireburner

    You mean port not fns?

  4. fireburner

    995 TCP

  5. Licaon_Kter

    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

  6. ru_maniac

    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

  7. ru_maniac

    have to use multiple

  8. ru_maniac

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

  9. MattJ

    It just needs someone to make it 🙂

  10. MattJ

    And, crucially, maintain it

  11. MattJ

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

  12. ru_maniac

    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

  13. sagaracharya

    Yes, set the SRV record

  14. ☭Mike Yellow

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

  15. Licaon_Kter

    ☭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?

  16. ☭Mike Yellow

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

  17. ☭Mike Yellow

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

  18. ru_maniac

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

  19. ☭Mike Yellow

    Licaon_Kter, did you receive that?

  20. ru_maniac

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

  21. ru_maniac

    for crying out loud

  22. ru_maniac

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

  23. ru_maniac

    their TLS configuration is not just outdated, it is dangerous

  24. ru_maniac

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

  25. Guus

    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.

  26. ru_maniac

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

  27. ru_maniac

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

  28. ben

    what are your friends using?

  29. ru_maniac

    jabber.ru as their primary server, for various reasons

  30. Licaon_Kter

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

  31. Licaon_Kter

    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"

  32. ☭Mike Yellow

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

  33. ru_maniac

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

  34. Licaon_Kter

    > 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

  35. Licaon_Kter

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

  36. Lightning Bjornsson

    > 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

  37. ru_maniac

    Licaon_Kter: known or not, this is barely an excuse

  38. Licaon_Kter

    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

  39. ru_maniac

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

  40. Lightning Bjornsson

    > 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

  41. Licaon_Kter

    ru_maniac: baby steps

  42. ru_maniac

    true enough

  43. Licaon_Kter

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

  44. ru_maniac

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

  45. ru_maniac

    afaik, 3.2 last release was around 2018

  46. Lightning Bjornsson

    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.

  47. ru_maniac

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

  48. ru_maniac

    > 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

  49. Licaon_Kter

    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_

  50. Licaon_Kter

    > 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? ¯\_(ツ)_/¯

  51. MattJ

    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

  52. ru_maniac

    >> 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

  53. MattJ

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

  54. ru_maniac

    > 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

  55. MattJ

    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

  56. MattJ

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

  57. ru_maniac

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

  58. ru_maniac

    but I may be mistaken

  59. MattJ

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

  60. ru_maniac

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

  61. basicdreams

    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)

  62. MattJ

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

  63. MattJ

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

  64. ru_maniac

    > 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

  65. MattJ

    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)

  66. basicdreams

    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

  67. basicdreams

    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)

  68. MattJ

    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)

  69. MattJ

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

  70. mekosko

    How to check if channel binding is enabled?

  71. mekosko

    In Conversations

  72. MattJ

    I don't know if it tells you, unfortunately

  73. Licaon_Kter

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

  74. MattJ

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

  75. Licaon_Kter

    ¯\_(ツ)_/¯

  76. basicdreams

    Is there any XEP that describes channel binding?

  77. MattJ

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

  78. MattJ

    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.

  79. mekosko

    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

  80. Licaon_Kter

    mekosko: "tells you the software version"

  81. MattJ

    It's not a XEP

  82. MattJ

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

  83. MattJ

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

  84. mekosko

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

  85. MattJ

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

  86. mekosko

    But you will know if cert is changed

  87. Licaon_Kter

    mekosko: maybe the real admin changed it

  88. MattJ

    Yes, it changes every 4 weeks probably

  89. mekosko

    But what if you are an admin 😉

  90. mekosko

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

  91. MattJ

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

  92. mekosko

    What if you are an admin

  93. mekosko

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

  94. clouded

    would s2s suffer from the same type of attack?

  95. MattJ

    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.

  96. iioknj

    Licaon_Kter:

  97. iioknj

    Licaon_Kter: I have something to share

  98. iioknj

    I have something to share

  99. iioknj

    Licaon_Kter:

  100. iioknj

    I have something to freely share

  101. techmetx11

    what

  102. Licaon_Kter

    techmetx11: our frenly spammer, nvm

  103. techmetx11

    yes i expected

  104. techmetx11

    they sound like that oneplus vpn guy

  105. Licaon_Kter

    Because they is

  106. ☭Mike Yellow

    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?

  107. ☭Mike Yellow

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

  108. ☭Mike Yellow

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

  109. Licaon_Kter

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

  110. Licaon_Kter

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

  111. ☭Mike Yellow

    >has te do What is this?

  112. Licaon_Kter

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

  113. Licaon_Kter

    Typos

  114. ☭Mike Yellow

    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.

  115. ☭Mike Yellow

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

  116. Martin

    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.

  117. savagepeanut

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

  118. ☭Mike Yellow

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

  119. ☭Mike Yellow

    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?

  120. ☭Mike Yellow

    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.

  121. Licaon_Kter

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

  122. raver

    ```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-SHA1-PLUS to force channel binding?

  123. raver

    ```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?

  124. MattJ

    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.

  125. sagaracharya

    Anyone uses opensmtpd?

  126. Licaon_Kter

    sagaracharya: wrong channel

  127. ru_maniac

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

  128. ru_maniac

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

  129. Guus

    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?

  130. sagaracharya

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

  131. raver

    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?

  132. sagaracharya

    That is acrucial art

  133. sagaracharya

    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

  134. Guus

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

  135. sagaracharya

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

  136. sagaracharya

    I can teach you English if you want

  137. sagaracharya

    I believe the moderators are doing their job well

  138. sagaracharya

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

  139. Guus

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

  140. sagaracharya

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

  141. sagaracharya

    Yes, I saw that interest

  142. Guus

    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.

  143. octagon

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

  144. MattJ

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

  145. MattJ

    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)

  146. Licaon_Kter

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

  147. MattJ

    "Just do what Snikket does." EOF

  148. MattJ

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

  149. unix.dog

    > ```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

  150. unix.dog

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

  151. MattJ

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

  152. MattJ

    and sometimes even SCRAM isn't possible

  153. unix.dog

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

  154. MattJ

    Yep, so you're presumably PLAIN-only

  155. unix.dog

    yeah

  156. MattJ

    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

  157. unix.dog

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

  158. MattJ

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

  159. MattJ

    Yeah

  160. unix.dog

    yes, that’d be ideal :P

  161. Guus

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

  162. unix.dog

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

  163. MattJ

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

  164. MattJ

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

  165. unix.dog

    that seems very impressive

  166. Guus

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

  167. unix.dog

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

  168. Guus

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

  169. MattJ

    unix.dog, you and lots of people :)

  170. MattJ

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

  171. unix.dog

    yeah, that’s just how it is i think

  172. unix.dog

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

  173. 华南网友

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

  174. 华南网友

    > 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)

  175. Menel

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

  176. 华南网友

    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.

  177. 华南网友

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

  178. Licaon_Kter

    华南网友: yes, ongoing discussion

  179. raver

    >> ```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/