I'm very new to Node Red but already love the capabilities of it!
Currently, I'm working on a project where I would like to send/receive data from an ESP32 to Node-Red.
The idea is that the ESP32 will be connected to the internet using a WiFi hotspot from a mobile phone.
Node Red will be running on my Windows home computer.
So far I get the data communication working whilst both devices are on the same network.
As the network part is new for me I don't know exactly how to continue. I've been reading up on port forwarding etc. but would like ask how I could accomplish this in a secure way?
Indeed, while reading up on port forwarding there where so many disadvantages, mainly concerning security, that for somebody inexperienced as I am on this topic another solution would be highly appreciated!
You mention the order is being important, would it work if you add a followup id to the data so that upon arrival you can verify that the order is correct or sort it so that it will match up?
You know even quite a few commercial, businesses, have tried to secure ESP32, ESP8266 devices. Use of HTTPS with proper DNS (validation), is about the most straight forward option. You have to validate that both ends of the connection agree that they a really are who they claim to be. What you send over the wire can be any protocol you want once you have this established channel, if you will. The big threat I think you are trying to avoid is a two part problem, you want a custom protocol, to avoid inherited vulnerabilities with established protocols? And you don't want to rely on something external to your control, such as DNS, VPN, etc.? If you do use an established protocol, you can always add your own validation. For example PXE is completely open, has to be due to its nature.. but once PXE has established an end to end channel, what comes over the channel can be uniquely protected, such as initial end point validation of your own design, thus this is how you can avoid MiM attacks, and end point spoofing. After using an open protocol to established a secure protocol, is what in effect VPN does, glossing over some of the deeper details of VPN.
Short answer is yes... but likely over kill. Ask your self this... how do public web sites secure communication and get that nice little green/locked icon next to the URL in a browser? Typically they use HTTPS, certificates, and then once the channel is confirmed valid end to end, i.e. both ends agree they know each other, validated they know each other, they communicate in some defined protocol, which may or may not be secured or encrypted.
So you have to confirm you are using a safe DNS source, confirm that both ends agree (certificates), and then you have your communication protocol you use, whatever it is.
I have a few ESP32/8266 based devices that are commercial wifi relays, to turn off lights in the house via my smart phone... my phone talks an internet public server, then the server sends commands to the wifi relay, just really a ESP32/8266 device linked to a common relay.
They do this via HTTPS over the public internet, it is secure with in reason. But it does have some potential issues, known bugs or vulnerabilities in HTTPS, DNS protocols can be exposed so they have download updates to the devices from time to time, for example.
I have not reviewed this to know how good it is of an implementatiion, but it is at least an option to review...
ESP32 -- WiFi hotspot -- "secure" MQTT Cloud service -- Node-RED via secure MQTT
The ESP32 connects to my local WiFi hotspot (should work the same if I would use my IPhone instead) and then connects to CloudMQTT using user name and password. So not encrypted what I understand. (I do not know if it is yet possible to use SSL connections on the ESP32, at least it is not supported by ESPHome, only for ESP8266 and then using SSL Fingerprints)
a) I created & configured a ESPHome project and uploaded it to the ESP32 (a bit off-topic going into the details) and it started publishing data, in this case the room temperature using a 1-wire sensor
b) Just checking the CloudMQTT I could see the events being correctly published
c) Next was to configure Node-RED. For this MQTT connection I could use TLS/SSL to hopefully make at least the connection between Node-RED and CloudMQTT more secure
If your id and password is not encrypted, i.e. send over HTTPS at a minimum, then step 1 your have an issue. For example, many of our email connections to our local ISPs are not secure by default, so every time your email clients logins to the ISP mail service, it is visible to anyone that can capture the network traffic.
Could i suggest you run Zerotier One (or Wireguard) on both the mobile phone and the WIndows PC.
THis essentially gives you a Software defined VPN between the two devices that will be completely transparent - the advantage here is you will be able to also communicate easily from NR back to the ESP32 to send commands etc
I'm using esp8266 communicate to node-red using tcp/udp. you have to ensure that you can reach your server from internet from the tcp port. for example, you need to ues port 3000 between esp and node-red
goto your router, looking for wan ip. note it.
goto https://www.whatismyip.com/ and looking for your public ip address. if they are the same, goto next, otherwise it's a lot more complicat to setup.
at your home router, forward all incoming tcp traffic port 3000 to your server port 3000
deploy node-red tcp node listen for port 3000
from your mobile, try using telnet to port 3000. see if it's working.
if not work, depend on os of your server, e.g. linux or windows, open firewall on port 3000
once you can telnet to port 3000, the esp should be able to communicate to node-red on port 3000
once you can connect to your server, you can improve security later.
I do not mean open permanently. Just for testing to see if everything configure correctly. The data can pass from esp to reach node-red. We have to secure it after that. I have secure it with nginx.
But if we want to use tcp, there is no choice because all other secure protocols are sit on top of tcp. The tcp has to be open along the way and node-red flow have to filter unrelevent traffic out.
