Bug: connection dropped on long msg with unescaped UTF-8 characters

Openfire Openfire Support
1

When I send an XMPP message long enough to span several TCP packets, and if the connection is (voluntarily) not encrypted, and if the message contains Chinese characters for example, then OpenFire 3.3.0 fails to parse the packet correctly.

The result is that OpenFire sees a bunch of (\u0) characters, usually at the exact location where the XML was split across several TCP packet. If this happens to be inside an XML element, the parsing fails completely, and OpenFire closes the connection!

Here is an example of the resulting stacktrace, where the corruption occurs in the closing :

2007.05.09 16:20:21 org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandle r.java:134) Closing connection due to error while processing message: </message\u0… @1:607)

at org.xmlpull.mxp1.MXParser.parseEndTag(MXParser.java:1707)

at org.jivesoftware.openfire.net.MXParser.nextImpl(MXParser.java:103)

at org.xmlpull.mxp1.MXParser.nextToken(MXParser.java:1100)

at org.dom4j.io.XMPPPacketReader.parseDocument(XMPPPacketReader.java:317)

at org.dom4j.io.XMPPPacketReader.read(XMPPPacketReader.java:154)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:123)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:703)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:54)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:800)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:62)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:200)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:362)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt

How to reproduce:

I can reproduce this very easily using Spark (2.5.2):

  1. On the OpenFire 3.3.0 server, disallow Old SSL and TLS methods in the Security Settings.

  2. Connect to the OpenFire server using Spark 2.5.2, then open a new chatroom.

  3. Paste the following message in the chat, the result should be a message box saying that you’'re disconnected:

??? ??? ??? ??? ??? ???

This weird message is made of 57 dash characters, followed by about 420 times the unicode U6771 character.

  1. Look at the exception in the OpenFire log.

  2. If you enable TLS this does not happen, which would indicate that the SSL tunneling does a better job at preserving the UTF8 bytes.

I have had the exact same problem sending messages using Smack 3.0.2, which I could only work around by manually escaping the characters using XML entities.

If this is not a bug, please tell me how it is supposed to work

2

I have met this issue: http://www.igniterealtime.org/forum/thread.jspa?threadID=25840

But I have this issue with not encrypted and encrypted connections.

3

Ah you’'re right, Alexander, your issue seems to be exactly the same indeed!

Sorry, I hadn’'t found your post while searching the forum.

I thought that the issue only appeared with unencrypted connections, but maybe it does it with SSL too, it might just be harder to see since you can’'t actually analyze the TCP packets.

My test message for Spark doesn’‘t seem to trigger this when SSL is enabled, but that might be because the packet boundaries change and the corruption occurs inside a text element, where I don’'t see it so easily.

I’'ll see if I can find other messages to trigger it.

I noticed this issue while doing the following: I wrote a small client using Smack that polls an RSS feed every so often, and sends each new RSS entry as an XMPP message to a chatroom hosted on OpenFire 3.3.0.

The RSS entries include japanese or chinese text most of the time, and they triggered the issue almost every time while the connection was unencrypted. This didn’'t seem to occur anymore when I enabled TLS.

Another symptom is that my client’'s debug window (smackx-debug) had frequent exceptions while parsing the echo messages coming back from the server (that is, when the connection was not dropped), because when the U0 bytes occurred inside a text element they were forwarded by the server as &0;

As a workaround I am now encoding my messages’’ content using StringEscapeUtils.escapeXml from jakarta’'s commons-lang 2.3, which basically ensures that only ASCII is transmitted to the server.

4

JM-1062 to track it - I guess that no voting is required to get it resolved soon.

5

Thank you a lot LG, I’'m curious to see the analysis for this bug, and how the problem Alexander and I describe can occur.

Note that (at least in my case), it is the sender of the message that is being disconnected by OpenFire.

6

I created the message mentioned in the ticket using

echo " …) and that’'s about it…