MQTT Security: What You Did Not Consider

存储架构 DZone (源链)

So you have decided to use MQTT for your multi-billion dollar IoT product, or you have decided to IoT enable your home toaster. That’s great, but have you carefully thought about the complete security requirements for an MQTT solution?

With MQTT comes great opportunities and serious responsibilities.

MQTT is a publish/subscribe (pub/sub) protocol that easily facilitates one-to-many communication, and it does so whether you need it or not. You may have millions of devices connected to a broker, and you may have chosen to use MQTT for only pushing data from these devices to the cloud, but the protocol still allows communication between all devices.

Let’s say you have a Gmail account and someone gets hold of your password. That person will have access to your Gmail account only. However, if Gmail had been using MQTT as the protocol for mail, the person would have access to all the millions of Gmail accounts out there. To understand how this is possible, one needs to have a deeper understanding of the publish/subscribe (one to many) paradigm and the wildcard subscription feature provided by MQTT. When using MQTT, it’s important to select a broker that also enables you to enforce strict authorization. To harden an MQTT solution, wildcard subscriptions should be disabled in the broker. Make sure your MQTT broker provider supports this feature.

Unfortunately, far too many MQTT deployments fail to take the above seriously. If you plan on using MQTT, you must carefully think about the consequences for failing any of the following security considerations:

  • Is it safe to use MQTT without authentication?: no.

  • Is it safe to use MQTT without TLS?: no, password sent in cleartext.

  • Is it safe to use MQTT without strict authorization?: no.

  • Should wildcard subscriptions in the MQTT broker be disabled?: yes.

The one-to-many messaging and wildcard subscription features in the MQTT protocol forces the additional requirement of a multilayered defense system. If you have not read my multilayered defense system tutorial that also explains how to use authorization, I recommend reading it now:

The MQTT broker must be configured to require client authentication. However, how do you plan on safeguarding the credentials on the device? You may decide to use X.509 certificates as the client to broker authentication method, but note that an X.509 certificate has a distinct fingerprint and it is very easy to find the certificate inside the firmware. A hacker may extract the certificate from the firmware and use the certificate to log in to your MQTT broker using say a Python MQTT client. If you do not deploy a multilayered defense system, the hacker can compromise all devices connected to the broker should he be able to compromise one device. There are many ways to harden the device and prevent firmware extraction. The following whitepaper (PDF) goes into details on how to safeguard credentials stored in a device:

MQTT Myths

If you have been following a number of MQTT discussions, you may have heard that small devices, so-called edge nodes, cannot directly use a TLS enabled MQTT protocol stack and that you must use a gateway for communicating with the cloud. This would be true if only OpenSSL had been available as a TLS stack. Fortunately, many small TLS stacks facilitate the use of MQTT in small resource-constrained devices. If you are interested in testing MQTT on a small device, purchase an inexpensive ESP8266 WiFi chip and use the FreeRTOS/lwIP ESP8266 IDE we have put together. The SDK includes a secure MQTT stack and example code that makes it very easy for you to test a TLS enabled MQTT stack.

You may download the ESP8266 Device SDK from:

Note that the MQTT example we provide uses a broker that requires authentication and the communication is encrypted using TLS; however, the example is still not secure since the online MQTT broker does not support authorization. A real solution must use authorization, even if it is used just to control your own toaster.

Additional MQTT related security information you may find interesting:


The best (and worst) features of 7 top cloud secur... With the continuous shift to cloud service and deployment models in the enterprise technology space, tech professionals are placing more of a focus o...
Scammers Are Exploiting Hurricane Harvey to Dupe W... When tragedy strikes, criminals invariably prey on people's best intentions. Scammers have been using Hurricane Harvey -themed messages to trick pe...
Notes on GPG Security really matters these years. WannaCry gave us a global warning early this year. Before, Chinese netizens feel quite safe maybe because of ...
New infosec products of the week​: September 29, 2... Fortanix launches runtime encryption using Intel SGX Fortanix’ Self-Defending Key Management Service (SDKMS) is a cloud service delivering runtime e...
同有科技亮相“网络安全自主可控发展与推进研讨会”... 2018年5月21日,在中国工程院和国家相关部委指导下,由中国网信军民融合发展联盟自主可控专家技术委员会主办的“网络安全自主可控发展与推进研讨会”在北京举办。国家党政相关部门领导、关键信息基础设施行业用户、自主可控厂商等约300人参加了本次会议,同有科技作为力推自主可控的专业存储厂商受邀参会。 ...
DZone责编内容来自:DZone (源链) | 更多关于

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » MQTT Security: What You Did Not Consider

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录