Have you considered MQTT over TLS using the Tasmota software? https://tasmota.github.io/docs/TLS/
1 Like
For esp32 it seems the Tasmota32 is in early alpha state, don't know if that version also supports TLS and if it feels mature enough to use?
Otherwise, all depending on how skilled the topic starter is with esp development, maybe this project could be of interest. ESP32 with MQTT incl secure connection
Just to confirm, I tested the esp32 project presented in the video. Just modified it a bit using a ds18b20 temperature sensor instead, not so funny editing c-code and OT in this forum I assume
Anyway, my ESP32 is now connecting to CloudMQTT via SSL and reporting the room temperature to Node-RED at the other end of the room (it seems via Amazon Web Services US-East-1 (Northern Virginia), what a round-trip!!!)
SSL is better than nothing I guess, now I only have MQTT connections to CloudMQTT over SSL
1 Like
What did you want that is better than SSL?
Is TLS to prefere?
Oh I see. Which end doesn't support TLS?
Dear Colin,
Just based on what I have been able to discover so far, I think the esp32 firmware, the project I used, just supports MQTT over SSL. Maybe later TLS might be supported by some distribution like Tasmota or so but honestly, I'm not that in depth regarding esp32, c-code and related. Anyway, I did not transfer any certificate to the ESP32 so I believe it is just signing in with username and password, hopefully encrypted using SSL, I can at least see that it is establishing the connection through the SSL port
The CloudMQTT supports as standard MQTT, MQTT over SSL and Websockets. I have also seen that with a payed plan, you can upload custom certificates:
If you want to use a custom domain for your instance you have to provide your own certificate to use with MQTT+TLS and Websockets. Certificates must be PEM encoded and the privte key unencrypted
I guess that would then support connections over TLS, but for now, it will not help to make the ESP32 connection more secure. Currently, for my experiment, just sending a temperature reading, I think it is ok but for more critical usage, I believe it will need improvements, i.e. supporting TLS 1.3
I am not too sure about this, but I am pretty sure that mqtt over ssl is all you need, unless you want to verify the brokers certificate, or have the broker check your certificate so that only you can connect. The main thing you do get is that the user/pwd is encrypted so no-one can connect provided you use a good pwd, and no-one can snoop as it is encrypted. That is all you get normally get over https after all.
2 Likes
What is the threat or risk analysis? There is a qualified need for this to be done, bare with me here. When you design secure solutions you have to ask one key question... what is the risk of failure? In this case, even if the secured communication channel is compromised in some way, what is the risk or impact of this? So they can send fake weather information? Because your SSL is isolated, and have SSL in place to protect MQTT messages, what they can do, is read or write messages into your channel worst case?
With the expectation that you have secured your environment, will have a serious firewall in place, and other isolation of elements of your local network, they should not have any visibility to any devices other than the secured channel you have now created, worst case, no?
I am not pointing out issues here, per se, just using a mindset, procedural process, I used for years designing these very same solutions, for business and commercial firms. The open of traffic to the internet is always something to approach with care, of course, thus you want to validate that you have the correct protection, around, this solution, not just in this specific solution.
The joke we often noted with secure access models, firewalls was... ok, so you have a good bucket to bail water when needed? No one can steal your bucket? But the boat has several holes present? Does the good bucket, no one can steal, really matter then?
Well, sure...as you say, worst case would be wrong temperature injected by "someone". In my case it doesn't really matter, this is just a test setup anyway. But it would be good to know if it could be better secured so if you have any thoughts & experience in respect to that, I assume several users here would be interested to hear
I think mqtts with a good password is effectively unbreakable by any normal hacker isn't it?
Of course anything we come up with, some day, maybe cracked. NSA has proven to have many 0-day exploits that they, on purpose, never tell anyone about, including Norton, McAfee, MicroTrend, etc. But I digress. For what we are talking about, and how it will be used, you have to decide what is sufficient not what is possible. To get to what is possible is big $$$ expense, time and effort.
Thats a general discussion I heard since the early 80's, is nothing new
We, at least I am, just targeting to secure my home automation system (and home network) good enough to prevent from "normal to mid" exploits. I'm unfortunately not running my own national bank
Oh so true! The stories I could tell about what, when, and who. Seriously, I think what you have is good due diligence, and reasonable, for the given use case.
Why not simply install a local MQTT broker (such as Mosquitto) and not expose your control system to the internet? In my home I have a separate wifi network that doesn't advertise it's SSID that I use. If you need to send alarms or status to a mobile device while you are away from home, you can use an email node and your wireless carrier's SMS gateway to send alarm or status messages to your phone, and send command messages back with email.
Yes,yes, that is all basic and the obvious way for a local solution but if you have the need to link multipel sites with each other or simply have a remote site to connect to, like your vacation residens
I use my phone. Everything is local network scope, I only send alerts and status reports external to the infrastructure, using google voice API or SMS for example. Only link to my local wifi when I am on site. Thus nothing in my setup crosses the internet other than the alerts as noted above, and these are cellular based.
1 Like
I did not understand that you were linking multiple sites from reading the thread.
Best of luck with securing these ESP32 nodes from inbound attack.
I wonder if adding a local gateway device that provides a VPN connection to the cloud based server would make sense?
I would think something as inexpensive as the Raspberry Pi Zero might be capable of serving as a gateway.
The very first post was about having the ESP32 and NR on separate "sites" and connected via internet
Using a secure MQTT Cloud connection is one easy way of establishing this connection, I did show "how to" using Cloud MQTT with MQTT over SSL
Setting up a VPN server to access NR on your local network is not complicated in itself but I do not know if the ESP32 can run a VPN client which I think in that case would be required
I have also tested to activate internet sharing on the mobile and then connected it to my local VPN server. This obviously gives apps on the phone access to my local network but it does not give other clients connected to the phone hotspot access to the same. At least not with my iPhone, which is good I think
Thank you for explaining the topography of your network sites. I did not notice the earlier posts.
I wasn't proposing use of a VPN within a site, but rather to connect the sites to one another. Hence, the suggestion for a gateway at each site.
If your long term plan would be to use the cloud based MQTT broker, then my suggestion of an approach using gateways at the edge of each site only adds a level of complexity. It would, however, free a user from constraints in the ESP32 nodes.
It's interesting to know that other devices tethered to your iPhone via wifi do not have access to the VPN tunnel. This might make the iPhone a candidate for an IOT gateway for emergency backup or temporary disaster response applications on a critical infrastructure application (such as potable water filtration).
