Historical MQTT Security

[Arlen Nipper <arlen.nipper@gmail.com>]

The primary market that MQTT was first developed for was for real-time SCADA systems in the Oil/Gas market. In the late 1990's early 2000's TCP/IP was just emerging as an available transport for the various communications providers in this market. So regardless of the physical connection (VSAT, PSTN, SS Radio, etc) the only thing we could count on is that it would be slow, expensive, and unreliable. Case and point is that there are still many MQTT monitoring solutions deployed that run over 300 baud dial up lines that use SLIP (Serial Line IP) to establish the MQTT session (I guess you could consider that security by obscurity). We knew in the beginning that security would eventually become a requirement for MQTT in many applications and that was actually one of the key decision factors as we made the decision to use TCP in lieu of UDP as the underlying transport.

So early deployments of MQTT tended to run on private VSAT/Microwave/SS (Spread Spectrum) Radio/PSTN and at the time security was not really considered as a primary concern. But over time we did have to start addressing the security aspects. One of the first was to ensure that we could authenticate an MQTT client over PSTN as customers didn't want access to the SCADA host over dial up modems. This is where we implemented one of the only changes to the original MQTT specification and added the option for Username/Password in addition to the ClientID. Some customers implemented an additional layer of authentication by requiring authentication to the modem router before setting up SLIP connection to the MQTT broker.

As the networks evolved, became faster, and somewhat more reliable, they also tended to move towards public network offerings instead of the customers running their own private TCP/IP networks. Now these networks did touch the internet and security started to become more of a concern. In some of the VSAT installations this was accomplished by setting up VPN's from the remote VSAT terminal equipment into the customers facilities. Although not part of the MQTT transport, the TCP/IP session to the broker was done over a secure VPN tunnel that was setup by the VSAT interface. But this did require some complex configuration and management of the network by the customer.

By the mid 2000's MQTT was starting to branch out into other industries and embedded systems were getting more mature OS's and TCP/IP stacks. For several medical company projects security and HIPPA compliance required a higher level of security than we had seen previously. For these systems a double SSH tunnel was used to VPN the MQTT session to the Broker. An initial SSH tunnel was created from the MQTT client to the medical facilities DMZ, and then a second SSH tunnel was created to connect to the broker. Just to note here, most of the early MQTT implementations that used a TCP/IP layer of security used SSH in lieu of SSL. The Unix/Linux community seemed quite comfortable with this technology and methodology for secure MQTT sessions.

But now TLS/SSL tend to be preferred over SSH (albeit I feel SSH tunnels are still a very viable security scheme ). Most of the deployed MQTT solutions that I am aware of use one of these methods to secure the MQTT session. In some cases it is still the VSAT terminal equipment that establishes the secure connection and in other cases it's the MQTT client implementation on the embedded device that establishes the session. 

In all of these cases, MQTT security has tended to be one off, project specific, implementations. In some cases it is done by the network equipment (i.e. router, terminal server, VSAT IDU, etc) and in some cases it's done by the platform running the MQTT client. Regardless of "where" the security it implemented, I am seeing more and more customers wanting to use MQTT and just wanting to know what "best practices" are to do this. I think that having OASIS add a security "Appendix" to the MQTT specification that would outline these best practices is an excellent idea. Just looking at the distributed "M2M Straw-Man Proposition", I think the layout of the sections would go a long way in fulfilling this request. What are the threats that customers implementing MQTT in all vertical markets need to consider, and the matrix of cyber security functions (Know, Prevent, Detect, Respond, Recover) are an excellent start in being able to address these concerns.

-Arlen