XMPP Service Operators - 2021-05-13


  1. mike

    Chinwag.im turns six years old today. I remember around the time I set it up there was barely half a dozen people in this channel most of the time. Keep up the good work, folks.

  2. Licaon_Kter

    mike: heh, I saw your posts about how to setup, when I was looking for info for mine :) 👍

  3. mike

    Nice, yeah they still get a bit of traffic too, even though they're a bit out of date now. Glad to have been of some use. 😁

  4. Licaon_Kter

    Not sure I used them in the end, I went with the docs mostly, and harassed the ejabberd devs :))

  5. mike

    Yeah fair call, if you went ejabberd there's not much applicable. Although the page getting the most hits these days is the one where I got into how the SRV records work, might be worth give that a polish as it's more relevant than anything else.

  6. christian

    mike: witch one is it? Let me see it :)))

  7. mike

    christian: you mean the tutorial pages? It's here: https://bremensaki.com/chinwag/ Bear in mind it's six years old and uses some software and services that no longer exist. Jappix and StartSSL spring to mind.

  8. christian

    mike: OK. And you don't need that HDD space for something else?

  9. mike

    It's just a collection of blog posts, as a diary of how I started Chinwag when it was a new server it's still accurate.

  10. christian

    Software is probably the most inflationary commodity

  11. christian

    I sometimes wonder how long it takes us to understand that it's just procrastination, and that we actually need to be treated.

  12. Anhydrous

    christian: tech just got dumped hard in the stock market, interestingly enough.

  13. Anhydrous

    I wonder if they got notified by xmpp ;p

  14. Licaon_Kter

    Anhydrous: umm?

  15. christian

    I think it's much simpler, they looked at the electricity bill of the data centers that do nothing but distribute the banners that are currently blocked by them.

  16. Anhydrous

    christian: the elon musk effect on bitcoin

  17. Anhydrous

    Either way, it would be nice to see more investment in xmpp.

  18. Martin

    Link Mauve: Error from REDACTED@linkmauve.fr: Server-to-server connection failed: No route to host

  19. mathieui

    Martin: his router is still dead

  20. Martin

    Oh, I thought he was back after I had this issue the last time.

  21. rob

    I'm back, Ubuntu knocked my server out a bit. I was working on setting up a second wireguard connection and systemd resolve decided to bork DNS. All from nothing more than some wg-quick up/down, no reboots or software installation

  22. moparisthebest

    PSA: upgrade your prosody's ASAP people https://prosody.im/security/advisory_20210512/

  23. ij

    > Chinwag.im turns six years old today. I remember around the time I set it up there was barely half a dozen people in this channel most of the time. Keep up the good work, folks. Mike, I did some research the other day and it seems that I set up XMPP in November 2007… I don’t think that this MUC existed back then… ;)

  24. Licaon_Kter

    moparisthebest: > adopt the same default size limits that are already enforced by ejabberd Thase wer se bumped based on stats Holger ?

  25. Licaon_Kter

    moparisthebest: > adopt the same default size limits that are already enforced by ejabberd Thase were bumped based on stats Holger ?

  26. Licaon_Kter

    > adopt the same default size limits that are already enforced by ejabberd Those were bumped based on stats Holger ?

  27. Holger

    Not really. I wrote Matt the other day: > The current limits are a compromise of me wanting to bump them after seeing users running into avatar problems, vs. p1 always being afraid of making the server more prone to DoS attacks.

  28. Licaon_Kter

    Yeah, avatars I remember but, not much else, 10Mb seemed too big though.

  29. Licaon_Kter

    moparisthebest: your proxy exists to fix these or it helped you discover them?

  30. moparisthebest

    first :)

  31. rob

    > first :) Good to know

  32. moparisthebest

    it just makes sure too-big stanzas don't reach prosody at all though, so without a sensible limit won't help anyway

  33. moparisthebest

    if anyone runs arch and trusts me https://burtrum.org/aur/prosody-1%3A0.11.9-1-x86_64.pkg.tar.zst or build yourself https://github.com/moparisthebest/arch-ppa/tree/master/src/prosody

  34. MattJ

    FWIW "10MB" was never really meant to be a sensible limit, we added it because of well, obvious reasons. But nobody ever lowered it, and we never had good stats on what defaults to choose. I think it makes sense for the two most popular implementations to agree though.

  35. Araucaria

    Does proxy65 have any reason to be enabled?

  36. MattJ

    Yes, if you want to send large files to someone and one or both of you are behind a NAT

  37. Araucaria

    But it is obviated by http upload?

  38. rob

    Araucaria: for sending files when direct doesn't work I believe

  39. moparisthebest

    Araucaria, Conversations for instance will use that if the file is too big for your http upload limits I think ?

  40. rob

    But yes, I guess http_upload with huge limits would do the same

  41. xorman

    rob: are you aware that systemd-resolvd defaults to 8.8.8.8?

  42. Araucaria

    xorman: that is only a fallback

  43. rob

    xorman: Mine was not, it was adding a bunch like 127.0.0.1 and then two 75.x.x.x something and then I've one my local network, guessing router but only 3 are supported

  44. rob

    Either way it didn't work until I overwrote the symlink and hard-coded it

  45. rob

    But previously it worked fine so idk

  46. jl4

    heya XMPPers

  47. jl4

    just to inform you that we have a Plan in Catalonia / Barcelona to introduce XMPP in the Schools

  48. jl4

    slowly progressing,

  49. jl4 you know, technopolitics...

  50. jl4

    it would be part of Zimbra + Nextcloud + XMPP combo and bla,bla

  51. jl4

    ...

  52. moparisthebest

    awesome, what servers/clients do you plan to use ?

  53. jl4

    we are considering Prosody and ConverseJS

  54. jl4

    for now...

  55. jl4

    alpha phase (> Beta on Snikket ? )

  56. ernst.on.tour

    jl4: in 1 school or in the whole town ? Which schoolform ? Elementary school or also olders ?

  57. croax

    Aprofitat 👍

  58. tom

    » https://hg.prosody.im/trunk/rev/db8e41eb6eff I just want to state that these defaults are total rubbish and way too small, and I've always said that about ejabberd

  59. tom

    As well as this https://hg.prosody.im/trunk/rev/b0d8920ed5e5

  60. Anhydrous

    croax: catalan?

  61. jl4

    starting with some isoletd shcools and moving onto a network of Schools

  62. jl4 salut

  63. tom

    Rate limiting without active queue management is just a recipe for lag

  64. jl4

    ernst.on.tour

  65. jl4

    i'm gonna run an alpha test on a Secondary School in Madrid

  66. tom

    » https://hg.prosody.im/trunk/rev/63fd4c8465fb total rubbish

  67. xorman

    awesome

  68. tom

    This isn't a metigation

  69. tom

    1MB

  70. tom

    Come on

  71. jl4 stay tuned ...

  72. moparisthebest

    tom, the default in the configuration file matches ejabberd's 256kb for c2s and double for s2s

  73. moparisthebest

    patches to raise them without wildly unconstrained memory growth presumably welcome...

  74. moparisthebest

    if you don't apply these patches, it's easy to grow prosody's memory use to 5gb+ in seconds

  75. ernst.on.tour

    Nice... Hope anything is running well, I've lost the "fight" against the officials, only 2 private schools (church) were willing to spend some money for hardware. Raspi wasn't an alternative, first one (Raspi A+) was just released.

  76. Araucaria

    Is 1mb for s2s stanza limit too high?

  77. Araucaria

    At .5mb I had s2s disconnects due to policy violations

  78. tom

    I think it's WAAY too low

  79. moparisthebest

    512k is the default in prosody and ejabberd Araucaria

  80. moparisthebest

    it's fine, it'll reconnect

  81. tom

    Please people do not rush up updating to prosody 11.9

  82. moparisthebest

    let me be clear: if you aren't on prosody 0.11.9 and you don't apply the suggested config changes, your server can be ran out of memory *in seconds* without someone even having an account on it

  83. tom

    The only thing, besides a timing attack for muc passwords (which people rarely use anyways) it fixes are a potential dos vector with questional state size and rate limits

  84. moparisthebest

    I have a simple program that will do this

  85. moparisthebest

    if you don't believe me and wish me to point it at your server for a demonstration, I can do that for you, obviously only if you ask though

  86. tom

    Unless your actually getting ddosed, I would suggest holding off and letting this update stew for a while to come up with either A, a better solution or B, saner default limits

  87. moparisthebest

    sure, leave your server wide-open to known trivial DOS if you want, I wouldn't advise it though

  88. Araucaria

    Do most people not just run prosody from the nightly repo?

  89. tom

    moparisthebest: I would appreciate if you could send me your proof of concept program so that I could test on my own time for limits that work better for m

  90. moparisthebest

    I run the latest stable release

  91. tom

    E

  92. tom

    However my main concern is interoperability of XMPP at large

  93. tom

    I don't think people should be in a huge rush to install this update unless they are under attack

  94. tom

    Especially not all at ounce

  95. moparisthebest

    I'll release it in a sane amount of time, maybe a week or so, let's see how fast various distros update but to be clear, now that the info is released "stanza size limits are needed" anyone who can write a program that uses TCP can write this in minutes

  96. moparisthebest

    a large portion of in-the-wild XMPP servers already have these limits, it's fine

  97. tom

    Yeah but TCSR vulns have been a thing for a very long time

  98. tom

    Yet here we are

  99. tom

    (tls client-side renegotiation)

  100. moparisthebest

    so if you are absolutely crazy (my opinion) and want to run way-too-big-stanza-sizes, you still need to update to 0.11.9 right away for the other critical fixes, you can just set the stanza limits as you like then

  101. tom

    » <moparisthebest> a large portion of in-the-wild XMPP servers already have these limits, it's fine yeah, that's the problem. It's been causing lots of S2S resets from policy violations about stanza size limits, as well as severe lag

  102. moparisthebest

    the TLS and proxy65 and gc fixes are still required

  103. tom

    I've had several people move to my server due to rate limiting induced lag and stanzas being dropped

  104. tom

    They just aren't critical to me moparisthebest

  105. moparisthebest

    what kind of lag will you have when your server is using 16G of ram on demand :P

  106. moparisthebest

    how big of a server are you running on

  107. tom

    Not very big, but I already have proccess-supervisory, periodic heal-checking, and container limits setup

  108. tom

    What i'm saying is that the stanza size and rate limiting is not sane yet and needs to be though out further. I have no problems with the other mitigations

  109. tom

    But

  110. moparisthebest

    so your init system will just repeatedly kill prosody then? :P

  111. tom

    The other metigations are not new to me

  112. moparisthebest

    that'll be nice for your users

  113. tom

    It's a balance moparisthebest

  114. tom

    A balance between interoperability, latency, and security

  115. tom

    I'm not ready to adopt those insane stanza size and rate limits

  116. moparisthebest

    sure, choose between changing them to match the rest of the entire network, or your server crashing every 2 seconds

  117. tom

    The mac password timing attack is not something any of my users use passwords on their mucs

  118. tom

    I can hold off

  119. moparisthebest

    don't run proxy65 or TLS either ?

  120. Araucaria

    Updates are your friend.

  121. Araucaria

    Please update

  122. moparisthebest

    why wouldn't you just upgrade and apply the stanza size limits you wish ?

  123. Araucaria

    🐣

  124. moparisthebest

    the gc one is *very important* too btw

  125. tom

    Ok

  126. tom

    I don't think s2s or c2s rate limiting without active queue management is reasonable AT ALL

  127. moparisthebest

    if you are ok with CPU eating, sure, remove those

  128. tom

    I'm not sure what stanza size limits are good for me yet, but those defaults are definitely too small

  129. moparisthebest

    I mean rather, don't enable mod_limits

  130. tom

    This is certainly bad news for federation at least up front

  131. tom

    Does prosody support the PROXY protocol already?

  132. moparisthebest

    I see it as good news, that the 2 main implementations now agree on stanza sizes :)

  133. moparisthebest

    with mod_net_proxy yes

  134. tom

    Thanks

  135. moparisthebest

    this was my mitigation before 0.11.9 was released :) https://github.com/moparisthebest/xmpp-proxy , just prevents too-big stanzas from reaching prosody in the first place

  136. Araucaria

    What is the usecase for such large stanzas?

  137. moparisthebest

    Araucaria, the only thing I've ever seen violate them is when some idiots sets a 10mb avatar which is sent as base64'd text

  138. moparisthebest

    personally I like my server not sending those on to my clients but hey, you do you

  139. tom

    Copy-pasting news articles into mucs, large avatars such as the ones published by artists

  140. moparisthebest

    a good client would split news articles up as needed

  141. moparisthebest

    large avatars can go straight to hell, how inconsiderate of you of other people's bandwidth

  142. tom

    We don't have the luxury of disparaging clients for minute details like that

  143. tom

    And

  144. tom

    That's a subjective opinion. One that doesn't account for a host with lots of artists

  145. tom

    Or visually inclined people

  146. moparisthebest

    do clients exist where you can zoom in on avatars that much ?

  147. tom

    Yes

  148. tom

    Psi+ for one

  149. moparisthebest

    hi quality pictures shouldn't be sent over base64 in XML

  150. moparisthebest

    invent another way, probably http upload

  151. tom

    You just click on an avatar and use your scrollwheel or resize the window

  152. moparisthebest

    ah, haven't used Psi+, none of Conversations, Dino, Gajim let you

  153. tom

    No but 17MB would be a much saner limit

  154. tom

    To account for the 30% b64 overhead

  155. moparisthebest

    I'm in about 53 mucs, I don't want a 17mb avatar from any of them

  156. tom

    Google chrome and firefox doesn't do that so it's not a use case or feature worth considering. Lets apply that way of thinking to XMPP (sarcasm)

  157. Araucaria

    A 1mb news article?

  158. moparisthebest

    HTTP has good ways of delivering large binary images

  159. Araucaria

    How do disable forwarding of large avatars?

  160. Araucaria

    How to disable forwarding of large avatars?

  161. moparisthebest

    going with the default stanza limits does it

  162. tom

    moparisthebest: take some time to read about active queue management and why FIFO+burst is not adequate for interactive network communication

  163. moparisthebest

    be the change you want to see tom , fix it, I'll apply your patch :)

  164. Holger

    tom: > Unless your actually getting ddosed, I would suggest holding off and letting this update stew for a while Huh? Doesn't that update just change *defaults*?

  165. Holger

    I.e. if you don't like them you just set different values, problem solved, no?

  166. tom

    That's probably the case but i need to make sure if it and I haven't had the time to do that yet

  167. moparisthebest

    it's absolutely the case

  168. Holger

    Ah okay. I was just wondering why you're recommending others not to update.

  169. tom

    That's not what i'm doing. I'm just saying don't go barreling into an update like this that can effect federation so much

  170. tom

    Do update

  171. tom

    Don't rush this update

  172. tom

    The defaults are almost definitely not sane

  173. Holger

    I think we'll all be happy if you come to with a better solution. Until then, it's obviously a trade-off, so pretending someone is right and someone else wrong is just nonsense.

  174. moparisthebest

    sorry but the update fixes a ton of real security issues even if you don't like the defaults

  175. moparisthebest

    telling people not to update is stupid

  176. Holger

    Stronger language won't make such statements more useful.

  177. moparisthebest

    update and set different values if you like

  178. jonas’

    moparisthebest: do you intend to publish your PoC? :)

  179. tom

    These are DoS vectors, not RCEs or anything like that

  180. moparisthebest

    jonas’, sure, it's trivial for anyone to write after all, I was just going to wait ~1 week until updates were available for all the distros

  181. jonas’

    moparisthebest: :+1:

  182. moparisthebest

    tom, the proxy65 one and dialback-without-dialback are security ones close enough to RCE

  183. tom

    No it's not. » updated for safety, but due to the single-use nature of s2s dialback verification strings a timing attack on this module is not believed to be possible, or to grant an attacker any advantage if it were. And the proxy65 one just means public users can use some of your bandwidth

  184. tom

    Which for someone who already offers public internet services, is nothing new

  185. Holger

    DDoS is all fine as long as you only permit the most restrictive TLS settings 😉

  186. tom

    » May 13 10:09:51 s2sout55b25f6478b0 info Outgoing s2s stream conference.nuegia.net->dismail.de closed: policy-violation (XML stanza is too big) » May 13 10:15:55 s2sout55b264c7beb0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:15:55 s2sout55b264c7beb0 info Outgoing s2s stream conference.nuegia.net->trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:26:00 s2sout55b2603c5950 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:26:00 s2sout55b2603c5950 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:27:00 s2sout55b26034b220 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:27:00 s2sout55b26034b220 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:29:20 s2sout55b268128800 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:29:20 s2sout55b268128800 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:33:16 s2sout55b26043e620 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:33:16 s2sout55b26043e620 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:35:53 s2sout55b2608cb970 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:35:53 s2sout55b2608cb970 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:42:38 s2sout55b25f299b80 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:42:38 s2sout55b25f299b80 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 10:48:34 s2sout55b25f5e7ae0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 10:48:34 s2sout55b25f5e7ae0 info Outgoing s2s stream conference.nuegia.net->dismail.de closed: policy-violation (XML stanza is too big) » May 13 11:02:33 s2sout55b26bc55000 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:02:33 s2sout55b26bc55000 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:02:57 s2sout55b25f3e0340 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:02:57 s2sout55b25f3e0340 info Outgoing s2s stream conference.nuegia.net->creep.im closed: policy-violation (XML stanza is too big) » May 13 11:18:56 s2sout55b264342cf0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:18:56 s2sout55b264342cf0 info Outgoing s2s stream conference.nuegia.net->dismail.de closed: policy-violation (XML stanza is too big) » May 13 11:22:17 s2sout55b2643ede80 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:22:17 s2sout55b2643ede80 info Outgoing s2s stream conference.nuegia.net->onionmessenger.com closed: policy-violation (XML stanza is too big) » May 13 11:22:32 s2sout55b2640147b0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:22:32 s2sout55b2640147b0 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:34:18 s2sout55b26366e740 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:34:18 s2sout55b26366e740 info Outgoing s2s stream conference.nuegia.net->dismail.de closed: policy-violation (XML stanza is too big) » May 13 11:42:48 s2sout55b2630c1650 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:42:48 s2sout55b2630c1650 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:43:31 s2sout55b263257a20 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:43:31 s2sout55b263257a20 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:44:57 s2sout55b25f22a870 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:44:57 s2sout55b25f22a870 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:46:04 s2sout55b25f33a650 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:46:04 s2sout55b25f33a650 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:49:57 s2sout55b262b23bf0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:49:57 s2sout55b262b23bf0 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:50:46 s2sout55b25f9c67c0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:50:46 s2sout55b25f9c67c0 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:52:48 s2sout55b2643e6b90 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:52:48 s2sout55b2643e6b90 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 11:56:12 s2sout55b25f52f640 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 11:56:12 s2sout55b25f52f640 info Outgoing s2s stream conference.nuegia.net->dismail.de closed: policy-violation (XML stanza is too big) » May 13 12:00:41 s2sout55b26458f4b0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 12:00:41 s2sout55b26458f4b0 info Outgoing s2s stream conference.nuegia.net->chat.sum7.eu closed: policy-violation (XML stanza is too big) » May 13 12:00:49 s2sout55b264d2ccc0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 12:00:49 s2sout55b264d2ccc0 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 12:03:31 s2sout55b2630b3a70 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 12:03:31 s2sout55b2630b3a70 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 12:04:47 s2sout55b25f58ddd0 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 12:04:47 s2sout55b25f58ddd0 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) » May 13 12:16:06 s2sout55b265614a80 info Session closed by remote with error: policy-violation (XML stanza is too big) » May 13 12:16:06 s2sout55b265614a80 info Outgoing s2s stream nuegia.net->conference.trashserver.net closed: policy-violation (XML stanza is too big) »

  187. tom

    This is what i'm afraid of if everyone just adopts these defaults all at ounce

  188. tom

    This issue getting much worse

  189. moparisthebest

    > And the proxy65 one just means public users can use some of your bandwidth tom: and access all your private services, including those you thought were only on localhost :)

  190. tom

    Why aren't you already running a firewall?

  191. moparisthebest

    and there's nothing wrong with that, you immediately open it back up and only the giant stanzas are lost

  192. moparisthebest

    you firewall localhost ?

  193. rob

    > tom: and access all your private services, including those you thought were only on localhost :) Wait what? 😳🤓

  194. tom

    And btw, is that the case prosody's implementation of proxy65 allows local loopback and private addresses to be relayed to?

  195. tom

    If so that's a much bigger problem that needs to be addressed

  196. tom

    Not even coturn allows that

  197. moparisthebest

    maybe, that's what I think when I read "unrestricted access"

  198. tom

    No moparisthebest, that's not what the means. That

  199. tom

    S something very different

  200. tom

    Holy crap no

  201. tom

    There should be more than just an authentication token proventing loopback address relaying

  202. moparisthebest

    then they are just using your server to download kiddie porn? I doubt that's better

  203. tom

    moparisthebest: your talking to someone who runs openwireless.org and tor nodes

  204. tom

    That's a poor argument

  205. moparisthebest

    I'll be sure to use your server to DOS all the other prosody installations that refuse to set proper stanza sizes then :D

  206. moparisthebest

    (that was a joke I won't really do this)

  207. tom

    This fix is like cutting someone's foot off to prevent them from getting an infected toenail

  208. tom

    See the above logpaste for the problems it's been causing

  209. Holger

    tom: What's the proper fix?

  210. moparisthebest

    ^ this, please provide the proper fix then

  211. tom

    I don't know yet, possibly a larger stanza size limit that what's been set already, perhaps something more

  212. Holger

    I think it's just one of the cases where you need to apply limits to minimize the risk of resource exhaustion. The world of Internet services is full of such limits which have to exist short of better solutions.

  213. Holger

    tom: And if you're all about federation interop, it's weird to pretend this to be a Prosody-specific problem. Different servers running different limits is the interop issue when it comes to stuff such as avatars.

  214. Licaon_Kter

    tom: > This is what i'm afraid of if everyone just adopts these defaults all at ounce > This issue getting much worse What are they rejecting exactly?

  215. Holger

    The real problem is, there's no way the publishing client could know the s2s limits of all (future) potential remote servers.

  216. Holger

    So discussing how to handle this problem seems way more interesting to me than raging all about the actual default limit of a single implementation.

  217. moparisthebest

    and if you are concerned about interop, the 2 main implementations agreeing on defaults is obviously a good thing

  218. moparisthebest

    but sure, the best thing about XMPP is if you come up with a solution, it can be implemented :D

  219. Holger

    And if for some reason you are aware of a saner default, because you know more than we, then this would probably be good to suggest to all implementations.

  220. tom

    I'm not sure, it's not like it tells you which stanza was rejected from the perspective of an operator

  221. tom

    I have some educated guesses

  222. moparisthebest

    prosody can if you crank up the verbosity of the log to 11

  223. tom

    But it's not like we have a histogram of all stanza sizes vs time egressing our servers

  224. moparisthebest

    you could write that module too to give you that, would be helpful, maybe it already exists ? iirc jonas’ was working on some stats module

  225. tom

    That is true, however these failures and transient and unpredictable in nature

  226. tom

    I'd have to enable debug right when it happens

  227. Holger

    Right. Educated guessed that discuss both sides of the trade-off. (in different ways than "c'mon it's just a DoS who cares") sound good to me.

  228. tom

    It's not "who cares" it's not treating dos like rce

  229. Holger

    Note I've been the guy arguing for larger default limits for ejabberd. But it's less obvious to me that everyone concerned about DoS would be plain insane.

  230. tom

    Brb for a while please

  231. moparisthebest

    openssl recently had a similar release by the way, and everyone rushed to update, the only impact was a remote attacker could crash your server on demand, same thing here

  232. tom

    » <Holger> And if for some reason you are aware of a saner default, because you know more than we, then this would probably be good to suggest to all implementations. 17MB

  233. moparisthebest

    tom, ok but, prosody with the previous 10MB limit could be made to eat 5gb of ram in seconds by a single connection, so... what's your proposal to solve that

  234. moparisthebest

    also check other servers with that limit and see what happens

  235. tom

    Even with the more aggressive garbage collection?

  236. moparisthebest

    yes, and the more aggressive garbage collection causes unconstrained CPU usage without the bandwidth rate limiting you see

  237. tom

    Where exactly is the memory leak happening? In the connection buffer or the parser itself?

  238. moparisthebest

    ¯\_(ツ)_/¯ lua things....

  239. tom

    Well if only 10MB of data can be made to cause 5g resident usage in only a matter of second by a single connection something is very wrong

  240. tom

    I'm sure there's a better solution out there

  241. tom

    moparisthebest: there's no special noteworthy conditions your leaving out, like compression left on or something?

  242. moparisthebest

    this is going to come off sarcastically even though I don't mean it to be

  243. moparisthebest

    if you can come up with a better solution, great, please do so

  244. moparisthebest

    nope, no compression, though it'd probably make it worse

  245. tom

    Ok so it's not a zip bomb

  246. tom

    So

  247. tom

    This is probably site specific

  248. moparisthebest

    "stanza size limits" is really all you need to know, I'll release my POC next thursday assuming most distros have updated, but it's really just a few lines of trivial code

  249. tom

    But in general, and if we are talking about defaults here, cputime is much cheaper than ram

  250. tom

    I really wish the collateral damage of these mitigations would be taken more seriously than the dos vulnerability alone

  251. moparisthebest

    again if you are concerned about interop, having all major implementations agree on limits is a major win

  252. moparisthebest

    all the problems you see will start to drop off

  253. tom

    10mb is too small and i've had this issue before with that limit before this vuln was a concern

  254. tom

    Emailing other operators

  255. moparisthebest

    again, please do come up with a better solution, then maybe increasing them would be an option

  256. moparisthebest

    I still don't see the point, giant avatars aren't suitable for xml, please come up with a *different* solution for those if you want them, one that has caching and such

  257. tom

    There's a prosody module for that

  258. tom

    Caching muc vcards and avatars serverside

  259. moparisthebest

    one that doesn't involve cramming a bunch of binary in XML *and* has caching

  260. moparisthebest

    probably involving HTTPS but that's left as an excercise for the developer of the XEP