You’ll read on our homepage that Teserakt’s first product brings end-to-end encryption to the MQTT protocol. But before describing our solution, let’s find out how MQTT works and where it’s used.
The MQTT site describes it as “a machine-to-machine (M2M)/’Internet of Things’ connectivity protocol”, although the Message Queue Telemetry Transport existed long before the term IoT was coined, namely since the late 90’s. Today MQTT is for example used for cloud infrastructure telemetry, in critical infrastructure systems such as dams or power plants, in connected cars, and in Facebook messenger.
One reason behind the success of MQTT is its simplicity. MQTT involves three types of entities:
- Publishers, which create messages, tag them with a topic, and send them to a broker.
- Subscribers, which subscribe to one or more topics, and then receive all messages tagged with these topics from a broker.
- Broker servers, which dispatch messages from publishers to subscribers, and manage clients’ authentication and authorizations.
A client device can act as both publisher and subscriber. Publishers are for example sensors sending telemetry data to a back-end that runs the business logic (analytics, reporting, and so on). The broker and the back-end sometimes run on the same infrastructure.
In the example below, the clients on the left publish messages and the client on the right subscribes to the topics associated to these messages. After requesting the broker to subscribe to a topic, a client receives a SUBACK message from the broker, which confirms that the broker has registered the subscription.
You’ll notice that in the PUBLISH messages, we’ve set the “retain” flag to true, which means that the broker will retain the last message associated with a given topic, and will send it to a client even if it subscribes after the message was published. The diagram can thus be read in different ways: with the PUBLISH messages happening before the SUBSCRIBE messages, or the other way around.
You can play with MQTT by installing the mosquitto open-source broker and its suite of tools. First, start the broker locally by running the
mosquitto command (add
-d to run it as a background process). This will start an MQTT broker instance listening on port 1883. Then you can start a client instance that will connect to this broker and subscribe to topic
mosquitto_sub -h localhost -p 1883 -t mqttest
In another terminal, publish a message to this topic:
mosquitto_pub -h localhost -p 1883 -t mqttest -m hello
hello will then appear on the first terminal running the subscribed client instance. You can try first publishing the message with the flag
-r (telling the broker to retain the message) and subscribe afterwards. Don’t forget to stop your broker after running this test.
Mosquitto is a popular open-source broker, but if you use MQTT in production environments and need high availability and/or technical support, several options are available. Vendors such as HiveMQ and VerneMQ offer enterprise-ready broker software, and cloud platforms of AWS, Google, and IBM offer hosted MQTT brokers (note that MQTT is the only non-web protocol supported by their IoT platforms).
MQTT is super simple, but not very secure by default. Most deployment will (at best) run client–broker connections in TLS tunnels, for example in order to protect authentication credentials from eavesdropping. In subsequent posts we’ll show you how our technology addresses MQTT’s inherent security limitations, and we’ll also talk about brokers’ software security.