Why MQTT Is Everywhere, and the Security Issues It Faces

The Architecture of MQTT

Before we continue, here's a definition of MQTT:

Because of its simplicity, MQTT does not require much processing or battery power from devices, and it does not require much bandwidth (the message headers can be really small). It's also possible to define different Quality of Service levels for messages, so that you can control how many times messages are sent and what kind of handshakes are required. All of this make MQTT useful for many different kinds of networks.

At the core of its concept are servers and clients. These are able to send messages to each other using the following:

• Topics. These are a way of categorizing the kind of messages that might be sent. For example: if a sensor measures temperature, the topic might be defined as “TEMP”, and the sensor sends messages out labeled as “TEMP”.
• Publishers. Devices can be configured to send out messages containing data. Using the example above, the sensor measuring temperature publishes this data.
• Subscribers. Devices or systems can be configured to receive only messages of a specific topic. They can also subscribe to multiple topics.
• Broker. This is the server that is at the center of it all, which transmits the published messages to servers or clients that have subscribed to specific topics.

The architecture looks something like this:

All of this means that servers can publish messages, and other servers or clients can be set up to “listen” for specific messages. It’s a very simple, elegant solution.

It’s not the only solution, however. And yet it has somehow become one of the most-used in IoT environments. Why is this?

Why MQTT Is So Ubiquitous

There are several alternatives to MQTT. Before we consider why MQTT has become an industry standard, let's take a look at some of the other options.

HTML

A decade ago, the most obvious solution might have been HTML, but it is not really well-suited to the requirements of the IoT. The important aspect is the way that HTML handles events: in an IoT set up, you usually have events that trigger events or statuses. To use an example from one of our Maker Monday episodes: when we built a smart mailbox, the event of mail being put into the mailbox had to trigger a notification light to come on. If we used HTML as the message protocol, the controller managing the light would need to continuously poll to check if the event of mail being delivered had happened. This is not very efficient and requires extra processing and battery power. With MQTT, on the other hand, a message is sent once the event has occurred. The subscribed device “listens” for the message, and there is no need for continuous polling.

AMQP

Another option is an enterprise messaging system like AMQP (Advanced Message Queuing Protocol). I won’t go too much into this protocol here, but will say that the choice between MQTT or AMQP boils down to the flexibility required in a specific environment or implementation. Blogger Clemens Vasters provides an excellent analysis of the merits of MQTT and AMQB, and has this to say about the two protocols:

AMQP is a more verbose protocol on the wire as a cost for its greater flexibility. For publishing messages to a node, you first need to establish a link, allow flow over the link, and then transfer the message. MQTT doesn’t need any of that ceremony. However, AMQP rewards longer-lived sessions with amortizing the initial handshake effort by anchoring the target address for the transfer on the link rather than on the individual transfer operation. The effect is that the actual bytes transferred over a longer-lived AMQP link may quite well be fewer than for equivalent MQTT publish operations, especially if the topic name is very long.

Clearly, if you need scalability and flexibility, then AMQP might be a better option. But the fact is that many IoT solutions might require both AMQB and MQTT, and solutions like RabbitMQ even offer a combination. The point is, even in environments where more complex messaging solutions are used, MQTT is often still required for areas that need a lightweight, low-footprint option. This has also enabled MQTT to find its way into so many applications and implementations.

CoAP

Another good solution for environments needing a low footprint is Constrained Application Protocol (CoAP). It is similar to HTTP, but designed for constrained devices. And, unlike MQTT, it runs over UDP. The primary difference between the two is noted in a newsletter from eclipse.org (the emphasis is mine):

MQTT is a many-to-many communication protocol for passing messages between multiple clients through a central broker. It decouples producer and consumer by letting clients publish and having the broker decide where to route and copy messages. While MQTT has some support for persistence, it does best as a communications bus for live data.

CoAP is, primarily, a one-to-one protocol for transferring state information between client and server. While it has support for observing resources, CoAP is best suited to a state transfer model, not purely event based.

Because many IoT implementations are event-based, MQTT is quite often selected as the protocol of choice.

Security Problems

We’ve looked at MQTT’s meteoric rise to fame, and we’ve now considered why it’s become so popular. But where is it at now, and what’s the future for it?

Very recently, MQTT came under fire for security issues. Well, actually, let’s put it this way: MQTT is involved in security issues. An article from Avast explains that as a protocol, MQTT is secure; it’s the way that it is implemented and configured that can cause issues. In some ways, this is the same as in any IT environment: if the configuration is insecure, then the entire environment is compromised. However, with MQTT, the problem is exacerbated by the fact that if the environment is insecure, and a third party gets access to it, that third party can subscribe to all MQTT messages being passed around (MQTT allows subscribers to use “#” to listen for all messages).

That same Avast article I mentioned earlier, which was published in August 2018, has some concerning figures. They found around 49,000 exposed MQTT servers that were accessible from the Internet. The really bad news? Over 32,000 of those servers had no password protection. A follow-up study examined the potential impact on large-scale implementations like IIoT systems and smart cities, and the researchers were able to get access to all kinds of exposed data, such as environmental measurements, GPS data, and more. 

In all fairness, the security problems facing MQTT are the same as the IoT (of which we’ve already written articles here and here about). But, until those implementing these systems  become better informed and educated about how exactly to configure secure environments, security will continue to be the biggest danger for the future of the IoT. However, MQTT's ease of use and simplicity means that it will continue to form a big part of the IoT revolution that is currently happening.