andrzej.wojcik's blog

Uncontrolled Resource Consumption with Highly-Compressed XMPP messages

Multiple implementations of XMPP core protocol (RFC 6120) supporting stream compression (XEP-0138) suffer from uncontrolled resource consumption vulnerability (CWE-400). This vulnerability can be remotely exploited by attackers to mount Denial-of-Service attacks by sending highly-compressed XMPP messages.

It has been reported that Tigase is vulnerable and it is possible to exhaust resources in one of cases reported. It is fixed in current snapshot builds of our software and new release 5.2.1, which is going to be released soon will contain fix for this issue as well.

Best practices for connecting from web browser to Tigase XMPP Server

Currently we have 2 ways to connect to Tigase XMPP Server from web browsers:

  1. BOSH (Bidirectional-streams Over Synchronous HTTP)
  2. WebSocket (XMPP over WebSocket)

You will find more informations about these ways for connecting to Tigase XMPP Server with some useful tips below.

Optimisation of BOSH for high throughput

Tigase XMPP Server by default was sending only one XMPP packet per HTTP request which caused a need for a lot of requests if there was a lot of packets to be sent to client. This caused additional network traffic as well as delay in sending packets to client.

From now on Tigase XMPP Server will detect when a lot of XMPP packets needs to be sent through single BOSH connection and it will send it batches.


Encryption and Tigase running on new JDK

During a setup of a test environment on the Tigase XMPP Server runing on JDK7 a client could not connect to the server using TLS/SSL encryption.

After investigation I discovered that the JDK7 supports TLS 1.1 and TLS 1.2, a client was using a recent version of the OpenSSL library (version 1.0.1 from Ubuntu 12.04). Knowing that I tried to connect using a command line utility from OpenSSL to connect to a secured port on the Tigase XMPP Server:

openssl s_client -debug -showcerts -connect

- another connection failure. After testing connection using a command line ultility from GnuTLS (which was successful), I knew that there was an issue with the recent version of OpenSSL library.

Apparently even that OpenSSL can be convinced to work with proper parameters:

openssl s_client -debug -showcerts -ssl3 -connect
Article type: