B4R Question HTTP and HTTPS connections from MCU

peacemaker

Expert
Licensed User
Longtime User
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 ?
 
Last edited:
Sort by date Sort by votes

Cableguy

Expert
Licensed User
Longtime User
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
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
Cableguy said:
beside the point
Click to expand...
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...
 
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
peacemaker said:
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...
Click to expand...
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
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
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...
 
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
peacemaker said:
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...
Click to expand...
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?
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
Cableguy said:
real world application
Click to expand...
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...
 
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
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
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
Thanks, but what about the topic subject ?
 
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
peacemaker said:
Thanks, but what about the topic subject ?
Click to expand...
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
 
Last edited:
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
Cableguy said:
build a more robust solution
Click to expand...
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 ?
 
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
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!
 
Upvote 0

peacemaker

Expert
Licensed User
Longtime User
Cableguy said:
if your data gets hacked is
Click to expand...
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 ?
 
Last edited:
Upvote 0

Cableguy

Expert
Licensed User
Longtime User
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
 
Upvote 0
You must log in or register to reply here.

Similar Threads

  • Question
B4R Question B4R sketch uptime: how long worked your MCU without reboot maximally?
Replies
5
Views
669
peacemaker
  • Question
B4R Question rESPUI: rebooting MCU at web-page refresh
Replies
2
Views
847
peacemaker
  • Question
B4R Question MCU web-server: how to stream a file to a client ?
Replies
1
Views
632
Erel
  • Article
B4R Tutorial MCUs comparison 2023
Replies
0
Views
2K
peacemaker
  • Question
B4R Question B4R compilation strategy for several MCUs
Replies
9
Views
2K
hatzisn
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…