[OpenBeken] Securing IoT access, local access restrictions and security

Hello

I am wondering about the issue of securing access to control IoT systems with openbeken on board. Has anyone already discussed this topic?

I know this is a relatively young project, and my big nods to all who are developing this code.
The question that concerns me is - how will the security access to the device itself ultimately be resolved.
In the interface itself, I don't see any settings for local access restrictions. The http can be accessed without anything from the LAN, both to the web interface and to commands over the API. Including commands that can reset/change settings, rendering the device unusable.

So for the moment probably the only way to secure it is to put such devices in an isolated subnet. Only then it gives us an all-or-nothing restriction. Well, and then you have to deliberately fiddle with the WIFI AP settings.
Of course, control selectivity can then be achieved via an application layer above, e.g. homeassistant. At least, this is how it seems to me.

If I would like to release MQTT traffic from openbeken over a public network, to my own remote server, then probably only via a vpn tunnel, e.g. from a local router.

Is it possible to disable in openbeken the log dump on port tcp 9000? I understand that in the development version this is useful. But production-wise I would still prefer to be able to disable it. There it even shows the wifi password. Maybe it is worth adding a cfg option 'do not show log'.

I join my colleague @janek_wro's question regarding securing access to an IoT device with OpenBeken firmware uploaded.

I found such a thread on guthub
https://github.com/openshwprojects/OpenBK7231T_App/issues/668

I realise the limited hardware resources in these uCs to accommodate a functioning TLS there.

I am curious how the original manufacturers' solutions communicate "with the cloud". Do they have encrypted communication. I rather expect that they do. Although I have not had the opportunity to check. Someone did the reverse-eng?

In the days I expect a few pieces of such devices, different manufacturers, then I will at least preview the communication by tcpdump, see how encrypted.
Because for the analysis of the batch I have too little knowledge.

@janek_wro Tuya IoT Core SDK includes Mbed TLS with support for SSL v3.0 and TLS v1.2. From the sources of this SDK it also appears that MQTT uses TLS. The code for this SDK is under the MIT licence.

This means that TLS as a client should fit.

There remains the problem of the local (in the sense of OB-embedded) HTTP server, with its API, which would already be a bit more difficult to wrap in TLS.
If encryption is already at TLS level, then the usual http-auth can be done, and access already protected.
But the usability of such a solution would be a problem. Because no one from the CA will issue an official cert to a LAN address. We can always issue it through our own CA, or even self-signed. But then the browser will scream that it has a cruel 'security threat'. I don't think self-signed can even be added as an exception any more, I heard something somewhere. I haven't checked.

Of course this could work without problems at the level of the M2M API inside its own ecosystem, because then it's just a matter of setting up the clients properly.

And is anyone able to recall where the post-http API applies in this case in OBK? I am thinking of use outside of the web configuration panel.

@janek_wro Tasmota and ESPHome versions for ESP32 support Secured MQTT. Tasmota even has CA already built in. Link Link It is also possible to use TLS in Tasmota for ESP8266, but this requires building a binary with the MQTT_TLS_ENABLED option enabled.