unispa > Getting Started > Network security

Network security

When building your own IoT network, protecting against unauthorized access is paramount. Due to the limitations of the ESP8266 in terms of memory and computational power, full support for TLS/SSL protocols for internet communication is not feasible. Therefore, alternative security measures are necessary.

Much of the security for unispa devices is inherited from the local network to which they are connected. It is imperative to only connect unispa devices to trusted, secured local networks with restricted access. Using public or inadequately secured wireless networks will compromise security.

HTTP

unispa devices use HTTP connections for communication with users. While all relevant URLs intended for HTTP communication are protected with usernames and passwords, they naturally lack a TLS/SSL layer. This setup is sufficient for operation within a protected local network but is inadequate for use in unrestricted networks or accessible from the internet.

The username and password protection, although available, may not be sufficient to protect against potential attackers who have access to the same network, as without encryption, credentials are susceptible to interception. However, this vulnerability cannot be exploited if the potential attackers do not have access to the local network.

SSL protection by intermediary

To address the lack of direct TLS/SSL support on unispa devices, a possible workaround involves setting up a locally hosted intermediary service like Node-RED. This intermediary is capable of adding an additional layer of security by establishing an SSL-protected connection externally. This secure connection forwards messages to the unispa device's unprotected local IP address, mitigating security concerns.

Do not forget to properly set up the SSL-protected listener port on the MQTT broker to ensure that this strategy works.

*Node-RED* working as an intermediary adding an *SSL* layer.

MQTT

Multiple unispa modules with Wi-Fi connection to the local network.

Connection via MQTT consists of two legs, each with different security options:

unispa to MQTT broker: The connection between unispa devices and MQTT brokers typically lacks SSL encryption and should only be used within a protected local network.
MQTT broker to User Device: The link between the MQTT broker and user devices can typically be encrypted with an SSL layer, providing more secure communication externally from user devices such as smartphones or PCs.

This implies that while unispa device's connection with an MQTT broker is only safe as long as it is taking place within a secured local network with no access from the outside, connection to the MQTT broker established from the user's mobile device or PC can be secure also externally.

Many MQTT servers can maintain both SSL-protected and non-SSL ports simultaneously, serving both secured and unsecured devices concurrently. It's common practice to expose only the SSL-protected listener port to the internet while keeping the unprotected listener inaccessible from outside the secured local network, serving only devices within the network.

Don't forget to properly configure firewalls and network rules to fortify overall network security. It is also recommended to regularly update firmware/software on IoT devices and maintain best security practices to mitigate emerging threats.