jdev - 2024-11-02

> it cannot read continously, and tell the client, read faster or i kill you lovetox: you have to do this to prevent a slowloris attack https://en.wikipedia.org/wiki/Slowloris_(cyber_attack) the hard part of course is implementing it so it'll only stop attackers and not people with slow computers/connections like you describe ↺

moparisthebest: no, it can rate limit at the s2s level

It still has to do something about slow clients right?

How many gb of stanzas are you going to buffer for a slow client?

anyway for this problem client/server isn't a meaningful difference, it applies equally to any connection

The client isn't slow in this case. The termination happens within seconds

Yes, it sounds for sure like an ejabberd problem, I'm just saying it's a tightrope they have to walk and not something that can just be disabled

There are a bunch of possible solutions, but the fundamental constraint is that you can't allow someone sending fast on the s2s side to kill the client reading at a normal speed. So either rate limit s2s to match your client limit, do backpressure, truncate the queue like prosody does, etc many options to achieve the fundamental goal. (I don't pretend to know which is the right choice or easiest to implement in the ejabberd context)

singpolyma: I think the other piece of this is Conversations gets into a pathological place syncing up MUCs where it is not reading at a normal speed

this used to happen me while waiting minutes for a room to finish joining

If that was the issue we could fix it. The premise here is that it can't be fixed client side per above discussion

singpolyma: yes but it's not only a s2s > c2s problem it's also c2s > c2s

Sure, same difference. Rate limit on out to c2s can't be smaller than rate limit on in from untrusted source