B4R Question HTTP and HTTPS connections from MCU

[peacemaker]

Hi, All

1) How correctly should HTTPS URLs be used for connections from MCUs?
2) Does it mean some root SSL-certificate must be included into the sketch ?
3) How WiFiClientSecure class works, if we do not use any certificate ?
4) Is any use of WiFiClientSecure instead of just WiFiClient if no ssl-certificate for MCU security ?

Here https://www.b4x.com/android/forum/t...rked-your-mcu-without-reboot-maximally.167360 it proved that HTTPS connections in ESP32 MCUs are buggy, cannot work stable for many days (HTTP - can).
So, maybe for just ESP32 sensors - no HTTPS is important to transfer data and HTTP is enough for security ?

What do you think ?

p.s. any B4R code example of the really secure HTTPS connections ?

 

[Cableguy]

My comment may be beside the point, but...
Why read individual sensors (mcu's) across the internet? Even HTTPS is not safe, and you need to encrypt the data stream for increased security level.
Why not have a "central" node (maybe a RPi) and let THAT be the broker between the MCU's and the Internet...?
The architecture of the RPi is way more suite for HHTP(S) communication

 

[peacemaker]

beside the point

Thanks for comment anyway. But indeed, if there is a broker already (project web-site) - we have to use just HTTP-requests directly, without MQTT.
But it needs to understand if HTTPS for MCU periodical technical postings is really must or not...

 

[Cableguy]

Thanks for comment anyway. But indeed, if there is a broker already (project web-site) - we have to use just HTTP-requests.
But it needs to understand if HTTPS for MCU periodical technical postings is really must or not...

not necessarily.... if you send a request from outside network to the RPi, then upon receiving the request, the RPi can respond, either by submitting already gathered data, or by prompting the connected MCUs and then returning the data to the requester

 

[peacemaker]

BTW, MQTT over TLS/SSL (8883 port instead of standard 1883 one) - also requires the same HTTPS and server's certificate.
This means that anyway MCUs cannot work stable for days...

 

[Cableguy]

BTW, MQTT over TLS/SSL (8883 port instead of standard 1883 one) - also requires the same HTTPS and server's certificate.
This means that anyway MCUs cannot work stable for days...

because you are connecting to them directly... and there's a flaw.
But if you create a star like connection between your MCU's and a central RPi in a Master Slave config, where the RPi is the master... you only need to request the master t*for the data, and it will do the rest!

Anyway, can you give more details on the real world application? like, is it a single, isolated location MCU? Can you, or you plan to create a network of MCU's at this location?

 

[peacemaker]

real world application

Multi-apartment houses, groups of houses belong to the owners.
Each house water pipes control.
One owner has one own web-host for control.
Each MCU controls 2-6 pipes ventiles.
Several MCUs are the point behind a WiFi-Internet router with mobile internet.
For ex...

 

[Cableguy]

Do you know the application "Home Assistant"? It works like a local hub that can then be accessed either by local or remote network.
Something like that can be built using, for example, ABMaterial, and with ABMaterial ability to Live Plug-Ins, adding new "sensors" would not be that difficult, and you could either scale it up (1 Raspberry Pi per appartement building/complex) or down (1 Raspeberry Pi per "Owner") making your solution a lot more market friendly

 

[peacemaker]

Thanks, but what about the topic subject ?

 

[Cableguy]

Thanks, but what about the topic subject ?

You wouldn't need the MCU to communicate via HTTPS with the RPI... you could use some other protocol that would not have those memory leaks, like HID, or even use LORA able MCU's for extended radio distance.
What I am saying is, if there's no easy solution to the problem, then it would be easier, and even maybe more convenient to 'go around' the problem and build a more robust solution

 

[peacemaker]

build a more robust solution

It's all clear. But question is so as it is. Principally about HTTPS. Only about HTTPS from MCUs. Not RPi, but MCUs. Not my case, but the world wide case with MCU that can\should work with HTTPS.

Personally, i'm sure that small MCUs with limited memory must not work without periodical reboot. And in my case also.

But just question of the principle. Why not just HTTP instead of buggy HTTPS in MCU via open Internet ? Via some HTTP API on web-server.
What is the danger ?

 

[Cableguy]

It's all clear. But question is so as it is. Principally about HTTPS. Only about HTTPS from MCUs. Not RPi, but MCUs. Not my case, but the world wide case with MCU that can\should work with HTTPS.

Personally, i'm sure that small MCUs with limited memory must not work without periodical reboot. And in my case also.

But just question of the principle. Why not just HTTP instead of buggy HTTPS in MCU via open Internet ? Via some HTTP API on web-server.
What is the danger ?

Why not? it all depends of how sensible your data is... and of how good your encryption is...
You CAN use HTTP instead of HTTPS, it is your decision to make.
What you need to make that decision is analyzing the risk of each, and what the worst case scenario if your data gets hacked is!

 

[peacemaker]

if your data gets hacked is

1) It is the root. Access to the data (reason1) and access to the server (reason2 that controls an equipment using the data).
2) That are the aim to hack.
3) If data is not secret, and for the technological sensors (periodically sending one-kind non-secret data) it's always true - no reason1 to hack the connection.
4) The data integrity is protected by API_KEY with a secret password at both ends. And data is ignored if API_KEY is wrong. And protected by the non-hacked server. reason2 is also not granted.
5) The server is controlling the data losing and makes the alarm.

So, i can make conclusion that the non-secret repeated and non-hacked data packet does not require HTTPS strongly.
And it does not need the server certificate to prove the host.

Doesn't this logical ?

 

[Cableguy]

if the data being sent is already encrypted, then I would say you don't really need the HTTPS, specially if the physical structure you are monitoring is not of any critical importance