I have added a fix for CVE-2017-5589 + which impacted many other clients (in addition to Monal iOS <4.2 and Monal Mac <2.5) and checks for CVE-2019-16235+ seen in Dino. These will be in the next 4.2 iOS beta and the next Mac beta.

What I hope is the final beta for iOS 4.2 is out. This is a massive update that touches every part of the code and should be a huge improvement for everyone using Monal. Still no progress on adding to the french app store sadly. It will have to wait for at least 4.3 in 2020. I will be adding all of these changes to the macOS app next.

This is a large update with a lot of changes fixing or improving:

• OMEMO key exchange
• roster versioning
• push support (tested Tigase too)
• contact list accuracy
• chat synch and catchup (MAM)
• issues joining, rendering and leaving group chats (MUC)
• discovery of HTTP upload on some servers
• Ipad translucency issues
• numerous UI glitches, dark mode quirks
• many bugs that impacted stability

Smack’s OMEMO implementation recently a security audit a while ago (huge thanks to the Guardian Project for providing the funding!). Radically Open Security , a non-profit pentesting group from the Netherlands focused on free software and ethical hacking went through the code in great detail to check its correctness and to search for any vulnerabilities. In the end they made some findings, although I wouldn’t consider them catastrophically bad (full disclosure – its my code, so I might be biased :D). In this post I want to go over two of the finding and discuss, what went wrong and how the issue was fixed.

Finding 001: Inactive Devices break Forward Secrecy

Inactive devices which no longer come online retain old chaining keys, which, if compromised, break
confidentiality of all messages from that key onwards.

Penetration Test Report – Radically Open Security

• Vulnerability Type: Loss of Forward Secrecy.
• Thread Level: High

Finding 003: Read-Only Devices Compromise Forward Secrecy

Read-only devices never update their keys and thus forfeit forward security.

Penetration Test Report – Radically Open Security

• Vulnerability Type: Loss of Forward Secrecy.
• Thread Level: Elevated

These vulnerabilities have the same cause and can be fixed by the same patch. They can happen, if a contact has a device which doesn’t come online (Finding 001), or just doesn’t respond to messages (Finding 003) for an extended period of time. To understand the issue, we have to look deeper into how the cryptography behind the double ratchet works.

Background

In OMEMO, your device has a separate session with every device it sends messages to. In case of one-to-one chat, your phone may have a session with your computer (you can read messages you sent from your phone on your computer too), with your contacts phone, your contacts computer and so on.

In each session, the cryptography happens in a kind of a ping pong way. Lets say you send two messages, then your contact responds with 4 messages, then its your turn again to send some messages and so on and so forth.

To better illustrate whats happening behind the scenes in the OMEMO protocol, lets compare an OMEMO chat with a discussion which is moderated using a “ talking stick ” (or “speachers staff”). Every time you want to send a message, you acquire the talking stick. Now you can send as many messages as you want. If another person wants to send you a message, you’ve got to hand them the stick first.

Now, cryptographically OMEMO is based on the double ratchet. As the name suggests, the double ratchet consists of two ratchets; the Diffie-Hellman-Ratchet and the Symmetric-Key-Ratchet.

The Symmetric-Key-Ratchet is responsible to encrypt every message you send with a new key. Roughly speaking, this is done by deriving a fresh encryption key from the key which was used to encrypt the previous message you sent. This procedure is called Key Derivation Function Chain (KDF-Chain). The benefit of this technique is, that if an attacker manages to break the key of a message, they cannot use that key to decrypt any previous messages (this is called “ forward secrecy “). They can however use that key to derive the message keys of following messages, which is bad.

This is where the Diffie-Hellman-Ratchet comes into play. It replaces the symmetric ratchet key every time the “talking stick” gets handed over. Whenever you pass it to your contact (by them sending a message to you), your device executes a Diffie-Hellman key exchange with your contact and the resulting is used to generate a new key for the symmetric ratchet. The consequence is, that whenever the talking stick gets handed over, the attacker can no longer decrypt any following messages. This is why the protocol is described as “self healing”. The cryptographic term is called “ future secrecy “.

Vulnerability

So, what’s wrong with this technique?

Well, lets say you have a device that you used only once or twice with OMEMO and which is now laying in the drawer, collecting dust. That device might still have active sessions with other devices. The problem is, that it will never acquire the talking stick (it will never send a message). Therefore the Diffie-Hellman-Ratchet will never be forwarded, which will lead to the base key of the Symmetric-Key-Ratchet never being replaced. The consequence is, that once an attacker manages to break one key of the chain, they can use that key to derive all following keys, which will get them access to all messages that device receives in that session. The property of “forward secrecy” is lost.

Smack-omemo already kind of dealt with that issue by removing inactive devices from the device list after a certain amount of time (two weeks). This does however only include own devices, not inactive devices of a contact . In the past I tried to fix this by ignoring inactive devices of a contact, by refusing to encrypt message for them. However, this lead to deadlocks, where two devices were mutually ignoring each other, resulting in a situation where no device could send a message to the other one to recover. As a consequence, Smack omitted deactivating stale contacts devices, which resulted in the vulnerability.

The Patch

This problem could not really be solved without changing the XEP (I’d argue). In my opinion the XEP must specify an explicit way of dealing with inactive devices. Therefore I proposed to use message counters, which gets rid of the deadlock problem. A device is considered as read-only, if the other party sent n messages without getting a reply. That way we can guarantee, that in a worst case scenario, an attacker can get access to n messages. That magical number n would need to be determined though.
I opened a pull request against XEP-0384 which introduces these changes.

Mitigation for the issue has been merged into Smack’s source code already

As another prevention against this vulnerability, clients could send empty ping messages to forward the Diffie-Hellman-Ratchet. This does however require devices to take action and does not work with clients that are permanently offline though. Both changes would however go hand in hand to improve the OMEMO user experience and security. Smack-omemo already offers the client developer a method to send ping messages

I hope I could help any fellow developers to avoid this pitfall and spark some discussion around how to address this issue in the XEP.

Happy (ethical) Hacking!

I have partnered with the good folks at dotConferences to put together some contents for a SwiftNIO workshop. The workshop will take place in Paris on February the 4th, the day after the dotSwift conference.

If you are coming to Paris for the dotSwift conference, you can make the best of your trip by also attending my SwiftNIO workshop. If you are interested by Swift Server-side or Swift cross platform development, this a good opportunity to get you started.

What you’ll learn

SwiftNIO involves many advanced concepts, that may not always be obvious for Swift developer. The concept have been refined during the 10+ years of Netty development, so despite SwiftNIO being still quite young, it comes with a steep learning curve.

The workshop will guide you through the concepts behind SwiftNIO and the architecture of the project. From there it will show how to build you client library framework as a Swift Package and how to test it on Linux. Finally, it will show how to write a mini server-side framework. The example will be illustrated with a simple but real protocol for Messaging: STOMP (Simple Text Oriented Messaging Protocol).

The workshop will covers the following topics:

• Concepts & principles of Swift NIO
• Designing networking application: The role of threading & async / await
• Understanding Futures & Promises
• Going deeper into async code: Mastering the functional operators
• Leveraging SwiftNIO provided components for HTTP
• Building a simple client library (illustrated by STOMP protocol)
• Building a simple server-side framework (illustrated by STOMP protocol)

You can learn more and book your workshop here: https://www.dotswift.io/training-swiftnio

New iOS build should show up on Thursday. Lots of group chat fixes in that update

If you have macOS catalina and are interested in trying a VERY early build of Monal, you can get it here . This is literally the iOS client. Things to note for now, hitting the x button closes the app, OMEMO doesnt work yet. I will start brining more mac code into this soon (menu bars, tool bars etc). This effort will likely improve the iOS client as well.

New versions of XMPP clients for Apple’s mobile and desktop platforms have been released.

BeagleIM 3.4

The stable release of BeagleIM 3.4 contains following changes

• Added support for setting MUC room avatar

• Simplified MUC room settings window

• Fixed an issue with establishing VoIP connections
• Fixed an issue with possible wrong order of messages received at the same time from the same entity
• Fixed issue with single quote to apostrophe automatic replacement in XML console
• Added timeout for presenting “composing” animation
• Fixed an issue with “Mute notifications” option not being visible

SiskinIM 5.4

This version adds support for setting MUC room avatar.

You can download both application from their respective app-stores: Beagle IM from macOS appstore and Siskin IM from iOS appstore and star them on GitHub: Siskin IM on GitHub and Beagle IM on GitHub

Welcome to the XMPP newsletter covering the month of November 2019.

Help us sustain this as a community effort, of which process is fully documented .

Articles

Edivaldo Brito has written in Portugese " Como instalar o moderno cliente Jabber/XMPP Dino no Linux via Snap " ("How to install the modern Jabber/XMPP Dino client on Linux via Snap").

Last month, the XMPP newsletter has been translated by community members:

• French: Lettre d’information XMPP, 8 novembre 2019, sprints, IoT et le début de Twitter
• German: XMPP Newsletter, 08. November 2019, Sprints, IoT und die Anfänge von Twitter
• Spanish: XMPP Newsletter, 08 Nov 2019, Sprints, IoT, y los primeros Twitter

We are extremely grateful for these contributions! If you can contribute a translation in your own language, please contact the CommTeam .

Software releases

Servers

The Ignite Realtime community has released:

• Openfire 4.4.4
• HTTP File Upload plugin 1.1.2 and 1.1.3
• inVerse Openfire plugin 5.0.5.1

Metronome IM v3.13.0 has been released, read the changelog .

Clients and applications

Movim 0.16 – Cesco has been released, with Drawing and content sharing, Attachments, Chat improvements, and Chats, chatrooms list improvements, and Search, plus more.

gajim.org features a new website. It is planned to publish a post about Gajim's development every month, starting with October and November .

SàT lead developer Goffi has published his progress note 2019-W48 .

Conversations 2.6.0 has been released.

Converse.js 5.0.5 has been released.

Libraries

xmpp.js has been released in versions 0.9.0 and 0.9.1 .

Process One has announced the released of go-xmpp 0.3.0 .

Extensions and specifications

This month, nothing in Last Call, Proposed, Obsoleted.

Message Retraction

Version 0.1.0 of XEP-0424 (Message Retraction) has been released.

Abstract:This specification defines a method for indicating that a messageshould be retracted.

Changelog:Accepted by vote of Council on 2019-10-23. (XEP Editor (jcb))

URL: https://xmpp.org/extensions/xep-0424.html

Message Moderation

Version 0.1.0 of XEP-0425 (Message Moderation) has been released.

Abstract:This specification defines a method for groupchat moderators tomoderate messages.

Changelog:Accepted by vote of Council on 2019-10-16. (XEP Editor (jcb))

URL: https://xmpp.org/extensions/xep-0425.html

Updated

• Version 1.23.1 of XEP-0001 (XMPP Extension Protocols) has been released.
• Version 1.17.0 of XEP-0060 (Publish-Subscribe) has been released.
• Version 1.0.1 of XEP-0076 (Malicious Stanzas) has been released.
• Version 1.1.4 of XEP-0084 (User Avatar) has been released.
• Version 1.0.1 of XEP-0158 (CAPTCHA Forms) has been released.
• Version 0.3.0 of XEP-0423 (XMPP Compliance Suites 2020) has been released.
• Version 0.2 of XEP-0328 (JID Preparation and Validation Service) has been released.
• Version 0.3 of XEP-0372 (References) has been released.
• Version 0.7.0 of XEP-0392 (Consistent Color Generation) has been released.
• Version 0.2.0 of XEP-0393 (Message Styling) has been released.
• Version 1.1.0 of XEP-0410 (MUC Self-Ping (Schrödinger's Chat)) has been released.
• Version 0.2.0 of XEP-0420 (Stanza Content Encryption) has been released.

Thanks all!

This XMPP Newsletter is produced collaboratively by the community.

Thanks to Nyco, Guus, Wurstsalat, MDosch, Neustradamus, Ppjet6 for their help in creating it!

Please share the news on "social networks":

• Twitter: https://twitter.com/xmpp
• Mastodon: https://fosstodon.org/@xmpp/
• LinkedIn: https://www.linkedin.com/company/xmpp-standards-foundation/
• Facebook: https://www.facebook.com/jabber/
• Reddit: https://www.reddit.com/r/xmpp/

License

This newsletter is published under CC by-sa license: https://creativecommons.org/licenses/by-sa/4.0/

A new version of the go-xmpp library, which can be used to write XMPP clients or components in Go, as been released. It’s available on GitHub .

Upon new features, it adds a websocket transport. For this reason, the minimum go version to use it is now 1.13. It also adds a SendIQ method, to send iq stanza and receive the response asynchronously on a channel.
On the component side, it fixes a SIGSEGV in xmpp_component (#126) and adds more tests for the Component code.

A small example

Writing an XMPP component

Speaking of components, here is a simple example on how to create a simple one. As a reminder, components are external services that can communicate with an XMPP service using the Jabber Component Protocol as described in XEP-0114 .

A component has its own XMPP domain and must know the server address and service port:

     const (        domain  = "mycomponent.localhost"        address = "localhost:8888"    )

The options needed when creating a new component are defined as follow (secret must match the one define in the server config):

    opts := xmpp.ComponentOptions{        TransportConfiguration: xmpp.TransportConfiguration{            Address: address,            Domain:  domain,        },        Domain:   domain,        Secret:   "secret",    }

To actually create the simplest component, just create a default route, and pass it to NewComponent, as well as the above options:

    router := xmpp.NewRouter()    c, err := xmpp.NewComponent(opts, router)

Connect establishes the XMPP connection to the server, and authenticates with it:

      err := c.Connect()

Now we can try to send a disco iq to the server:

       iqReq := stanza.NewIQ(stanza.Attrs{Type: stanza.IQTypeGet,        From: domain,        To:   "localhost",        Id:   "my-iq1"})    disco := iqReq.DiscoInfo()    iqReq.Payload = disco

In order to get the response asynchronously, the sendIq will return a channel where we expect to receive the result iq. We also need to pass it a context to set a timeout:

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)    res, _ := c.SendIQ(ctx, iqReq)

Now we just have to wait for our response:

    select {    case iqResponse := <-res:        // Got response from server        fmt.Print(iqResponse.Payload)    case <-time.After(100 * time.Millisecond):        cancel()        panic("No iq response was received in time")    }

Full example

The full program that runs a component, connects it to a XMMP server and perform a disco on it to display the result is thus as is:

package mainimport (    "context"    "fmt"    "time"    xmpp "github.com/FluuxIO/go-xmpp"    "gosrc.io/xmpp/stanza")const (    domain  = "mycomponent.localhost"    address = "build.vpn.p1:8888")// Init and return a componentfunc makeComponent() *xmpp.Component {    const (        domain  = "mycomponent.localhost"        address = "build.vpn.p1:8888"    )    opts := xmpp.ComponentOptions{        TransportConfiguration: xmpp.TransportConfiguration{            Address: address,            Domain:  domain,        },        Domain: domain,        Secret: "secret",    }    router := xmpp.NewRouter()    c, err := xmpp.NewComponent(opts, router)    if err != nil {        panic(err)    }    return c}func main() {    c := makeComponent()    // Connect Component to the server    fmt.Printf("Connecting to %v\n", address)    err := c.Connect()    if err != nil {        panic(err)    }    // make a disco iq    iqReq := stanza.NewIQ(stanza.Attrs{Type: stanza.IQTypeGet,        From: domain,        To:   "localhost",        Id:   "my-iq1"})    disco := iqReq.DiscoInfo()    iqReq.Payload = disco    // res is the channel used to receive the result iq    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)    res, _ := c.SendIQ(ctx, iqReq)    select {    case iqResponse := <-res:        // Got response from server        fmt.Print(iqResponse.Payload)    case <-time.After(100 * time.Millisecond):        cancel()        panic("No iq response was received in time")    }}