We had an incident lately where an (automated) client was sending messages to a room with an extreme large payload (like in Megabytes of text). Of course the client was slow in sending, but it had also a large impact in the other clients, which where joined to the room the message was sent to.
We are investigating how to prevent this. One solution would be a OF Plugin which monitors the incoming messages and rejects messages with an body which is above an certain limit. This will help to some extend, but you could also come up with scenario’s where the message body is small, but the actual message is huge because of added extensions. XMPP make it possible to include any extension you want, so you can include the complete English dictionary, without somebody noticing it, because it is a unknown extension, which is not understood by any client. Also in a way you are already too late as the message already has been transformed in a Stanza object and taking up memory.
Does the core code or is there any API/plugin which give the possibility to monitor the actual size of incoming stanza’s and to block these from be processed?
Hi Anno! Openfire does not have much implementation that’s specifically aimed at preventing this kind of abuse.
Since 4.8.0, we’re using the third party Netty library for most of the low-level network interaction. This library does offer traffic shaping options. Although currently not used by Openfire, this could prove to be an entry point for adding new functionality in this context.
Hi Anno, As Guus said, there is core code in Openfire which checks that the actual size of an incoming stanza does not exceed the max allowed buffer size.
In XMLLightweightParser it is checked and a flag is set to inform higher level network decoders to stop reading more data.
In XMPPDecoder the flag is checked and Openfire will be closing the connection with StreamError “Maximum stanza length exceeded”.
This code could be improved.
E.g., I’m not sure if closing the connection is always necessary. Openfire could perhaps handle this more gracefully by not processing the stanza instead.
Hello, just a small update. At first may thanxs about the fast reactions and usefull suggestions.
We did experience the incident on a 4.7.5 but are going to solving the issue for the 4.8 release
We have in the meantime tested the suggested property on 4.8.3. Initial testing shows it does do the job. We are planning to do some more refined and repeatable tests to confirm and to determine the actual value this parameter should have.
Initial testing showed that the response is not always the expected error text, as it looks like sometimes the two checks are tumbling over each other. But in the end, it does do the job. Ending an connection abrupt is never an expected scenario for the client or server.