MongooseIM is a scalable and efficient instant messaging server. With the latest release 6.4.0, it has become more powerful yet easier to use and maintain. Thanks to the internal unification of listeners and connection handling, the configuration is easier and more intuitive, while numerous new options are supported.

New features include support for TLS 1.3 with optional channel binding for improved security, single round-trip authentication with FAST (which can be even faster with 0-RTT or more secure with channel binding), reduced start-up time and many other improvements and bug fixes. Let’s take a deeper look at some of the most important improvements.

Reworked XMPP interfaces

MongooseIM uses the open, proven, extensible and constantly evolving XMPP protocol, which is an excellent choice when it comes to instant messaging. To communicate with other XMPP entities, the server uses three main types of interfaces, listed in the table below.

The C2S interface was reworked and improved already in version 6.1.0 (see the blog post), making it more modern, organised and extensible. In version 6.4.0, this trend is continued by reworking the S2S and component interfaces while unifying the whole connection handling logic.

Simplified, unified and more complete

Connection accepting and handling was simplified and unified in multiple ways, allowing the addition of new features along the way. All connections are now accepted by ranch, a state-of-the-art socket acceptor pool for Erlang. Modern gen_statem behaviour is then used to handle open connections using state machines. These changes allowed for improved handling of various corner cases, removing unexpected limitations and mishandled error conditions. There is also improved separation of concerns, resulting in easier extensibility and configurability.

Another unified and improved system aspect is the TLS encryption. The legacy fast_tls library is now fully replaced with the Erlang implementation, resulting in much more straightforward configuration and implementation without a drop in performance (as evidenced by rigorous load tests). This change made it possible to fill in some gaps in functionality, such as the support for channel binding as required for TLS 1.3 (see RFC 9266 for details). Additionally, TLS is now supported for component connections. Moreover, CA certificates can be provided by the OS, reducing the need for manual certificate provisioning. As a result of these changes, your MongooseIM installation will be more secure and robust.

All these changes are reflected in the TOML configuration file. As an example, the following snippet presents the configuration of S2S and component connections:

[[listen.component]]
  port = 8190
  shaper = "fast"
  ip_address = "127.0.0.1"
  password = "secret"
  tls.certfile = "priv/ssl/cert.pem"
  tls.keyfile = "priv/ssl/key.pem"


[[listen.s2s]]
  port = 5269
  shaper = "fast"
  tls.certfile = "priv/ssl/cert.pem"
  tls.keyfile = "priv/ssl/key.pem"


[s2s]
  default_policy = "allow"

  [s2s.outgoing]
    port = 5269
    shaper = "fast"
    tls.certfile = "priv/ssl/cert.pem"
    tls.keyfile = "priv/ssl/key.pem"

When compared with the previous version of MongooseIM, there are the following improvements:

• Components can benefit from TLS connections.
• S2S options are separate for the incoming (listen.s2s) and outgoing (s2s.outgoing) connections. Common options are placed directly in the s2s section (e.g. default_policy).
• Traffic shapers are configured the same way for all types of connections, and are always referenced by their names.
• S2S outgoing connections can have traffic shaping enabled.
• All TLS options follow the same pattern throughout the configuration file. This also affects multiple options that were omitted from this example for simplicity.

Another improved layer is the instrumentation. Most changes affect XMPP traffic events – they are summarised in the table below:

We can see that there are fewer event names now, and they are more concise, making them easier to remember and reason about. This was possible due to the use of labels like connection_type and host_type, and actually, the event coverage got improved – see the element_in and element_out events, which now cover s2s and component connections. Also, the events are emitted more consistently. For incoming data, there is always one event emitted as soon as an XML element (most often a stanza) is parsed. For outgoing data, there is always one event emitted just before sending an XML element out. As a result, the metrics are consistent with actual network traffic.

Another addition is the auth_failed event for s2s and component connections. For more information, such as the translation of event names and measurements to actual metric names, see the documentation on metrics. Our blog post about release 6.3.0 can also give you more details about the instrumentation layer and its integration with Prometheus.

SASL 2, Bind 2, FAST

Over the past few releases, we have been implementing extensions, speeding up the XMPP stream negotiation and authentication:

• XEP-0388: Extensible SASL Profile (SASL2) allows a client to authenticate, resume its session and more in one round-trip.
  
• XEP-0386: Bind 2 allows a client to bind the resource and enable selected extensions (SM, carbons, CSI) as part of SASL2.
  
• XEP-0484: FAST allows a client to authenticate with a token as part of SASL2. According to the specification, this is a token-based method for streamlining authentication in XMPP, enabling fully authenticated stream establishment within a single round-trip.

As an example, let’s assume that a user with the JID alice@localhost already has a FAST token obtained during previous authentication. When opening a new connection, the client sends the following:

<authenticate mechanism='HT-SHA-256-NONE' xmlns='urn:xmpp:sasl:2'>
  <initial-response>YWxpY0VfY2xpZW50X2F1dGhlbnRpY2F0ZXNfdXNpbmdfZmFzdF80MDYA5u2CpST(...)</initial-response>
  <bind xmlns='urn:xmpp:bind:0'/>
  <user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'/>
</authenticate>

As a response, it receives:

<success xmlns='urn:xmpp:sasl:2'>
  <authorization-identifier>alice@localhost/1750-684128-573793-695021f052e299fe</authorization-identifier>
  <bound xmlns='urn:xmpp:bind:0'/>
</success>

This way, the whole connection and authentication process is performed in a single round-trip.

FAST features supported in MongooseIM

In version 6.4, additional advanced features of FAST are supported. One of them is token rotation: the server invalidates tokens after a configurable period, and provides a new token on reconnection if the current one is close to expiry (this period is also configurable). Additionally, a client can request immediate token invalidation – with or without requesting a new one.

Another addition is the support for 0-RTT (zero round-trip time) data in TLS 1.3 (see RFC 8446, section 2.3). The FAST token can be provided by the client during a subsequent handshake after reconnection, meaning that there is no additional round-trip needed after the handshake – hence the name “0-RTT”. A different extension is the tls-exporter channel binding in TLS 1.3 (see RFC 9266 for details) – it can be used with FAST, resulting in the channel binding data being passed with the FAST token, increasing the security. Note that currently it cannot be used with 0-RTT data. See the documentation for mod_fast_auth_token and the Hashed Token SASL Mechanism specification for more information.

Summary

MongooseIM 6.4.0 offers numerous improvements in various areas – from configuration to instrumentation. New features such as FAST tokens make it easier for your clients and services to connect, while TLS 1.3 makes it more protected against malicious attacks. You can discover much more in the release notes.

Don’t hesitate to visit our product page, try it online and contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and, if necessary, customise it to fit your particular needs