With the emphasis on IOT security SSL has become the de facto solution for MQTT connections.
In fact the majority of the questions I get are SSL related .
What I find surprising is that not many appear to be considering using payload encryption instead of SSL and certificates.
Payload encryption has in my opinion many advantages over using SSL. The main ones are:
- It is end to end and not link based.
- There is no broker configuration required.
- The technique can also hide topic names.
The Rational for SSL and the Problems with SSL
SSL is used extensively on the web e.g shopping websites, Gmail etc.
SSL is secure and provides good link encryption.
Link encryption is sufficient in a client server environment where the server hosts the actual application.
However in the example of Gmail. link encryption is not really sufficient as the email needs to be forwarded across the email network and so for end to end encryption the entire link chain needs to be encrypted.
Therefore SSL encryption has shortcoming when dealing with a message based system like email , and MQTT.
For an MQTT message to be secure then the publisher and subscriber must both use SSL.
Also any bridged connections must also use SSL.
In addition ACL( access control lists) must also be used as any client can subscribe to the data unless it is restricted.
Encrypting Message Payloads.
This is quite a straightforward process in Python and node-red. I did a Python example some time ago.
How to Encrypt MQTT Payloads with Python – Example Code
and will also be doing a node-red flow shortly.
Topic Obfuscation
Another option in addition to payload encryption is topic obfuscation using the playfair cipher or Caesar cipher for example.
I am not really sure if this is really of any use but maybe you have an example.
Summary Pros and Cons
Payload encryption gives you
- End to end and also data storage security.
- Doesn’t require broker setup
- Doesn’t require additional broker security like ACLs
SSL gives you:
- Link security
- Requires ACLs to be setup on the broker in addition to SSL
- Requires broker setup
Comments
This post is a discussion post and I would be very grateful for any thoughts you may have on this topic.
Related Tutorials and resources:
Steve, we too have been thinking about that SSL issue for MQTT, and came to the same conclusion: that in most cases the data doesn’t need a secure connection. If it does, then encrypt the payload. I assume SSL won’t be a fast as non SSL, and speed for IoT is paramount. (Also with the ESP-32 some of my builds using SSL for REST connections blow up. So adding more SSL isn’t a great path.)
That said, the only information that get’s exposed without SSL are the username/password of the MQTT user (using wireshark to view. ) In my case, these are the same as the users’ node-red accounts, so my plan is create new name/pass for one of the accounts.
I will look forward to your articles / videos using payload encrytion for Node-RED. I also think such techniques would have far wider appeal if they could be used with MQTT on devices such as ESP8266 / ESP32 using the Arduino or platformIO IDE’s or C / C++ coding rather than python. I believe Nick O’Leary’s PubsubClient library is the most widely used MQTT client on those devices. So, if it were possible to use payload encrytion along with that library it would be very useful.
Bob
Nice to hear from you. I agree and I will take a look.
Rgds
Steve
Hi Steve, your blog posts are always very appreciated. On the topic of codes for C/C++, I have been using CBOR to serialize my MQTT payloads in an ESP32 and the COSE protocol based on CBOR offers encryption capabilities. While Python has got a pyCOSE library which is very easy to use, I haven’t been able to find any easy way to implement COSE on tinyCBOR (the CBOR library I use on the ESP32 module). It’d be interesting if in the future to see some of these aspects and especially for C/C++ environments, maybe on the topic of payload serialization, since CBOR is especially suited for M2M communications compared to JSON.