-->
Page 1 of 1

Overarching security concerns when deploying ESP8266

PostPosted: Sat Oct 05, 2019 4:25 am
by MegaTux
I have a series of ESP8266 connecting to my AP which is set to use WPA2-Personal with AES. These are transmitting temperature data to my MQTT server. On domotics forums I've read that people tend to think that using WiFi in home automation is more insecure than relying on Zigbee and other radio based network. Yet, I'm not quite sure I understand why. If my access point is set to WPA2-AES, then surely the ESP modules must be using this protocol to communicate securely. That said, its not very transparent to me how this happens. In my Arduino sketch, I call the ESP8266WiFi.h library and all I specify is the SSID an the wifi password. How do I know if the transmission is secure and data is not being transmitted in clear. Do i assume that the AP would not allow a connection that wasn't established on WPA2-AES principles?

I was reading the page (https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi/readme.html) which suggests, under the section "BearSSL Client Secure and Server Secure", that encrypted communication can be set up but is memory hungry. Does this mean that its not setup as default? Of course, my confusion as a newbie is quite clear in all this, so I was hoping someone could point me in the right direction in terms of understanding security from a network point of view when it comes to ESP8266. Basically, my biggest concern is that my password can be sniffed.

Of course, I could set up virtual wifi networks and the like but this is not the point. I just want to understand how I can make the communication between AP and ESP as secure as possible relying solely on the ESP8266WiFi.h library alone. Then I can add extra levels of security with virtual networks, etc.

I guess the other side of the security problem is that people who have physical access to my ESP8266 devices could hack into the unit, download the code and obtain my network password? I believe the ESP32 overcomes this problem (i.e. better to use a ESP32 rather than a ESP8266 for a device sitting in my garden and easily accessible by intruders)?

Interested to delve into the high level principles which I seem to be missing :D

Re: Overarching security concerns when deploying ESP8266

PostPosted: Sun Oct 06, 2019 5:06 am
by btidey
There are 2 separate things here.

The ssid / password / WPA2 secures the low level connection with encryption between the client and the AP to prevent packets on this link being decoded by outside sniffers. Normally an AP set up with WPA2 security will not allow clients to connect by any other means other than using the correct ssid and password.

The BearSSL library is the means by which one can use SSL data encryption when passing data to and fro between a client and a server. This is equivalent to using https instead of http to access a server. This means that the data can't be decoded no matter what route is being taken between the client and the server.

So for example if you access a server on the internet using http then although the data is encrypted locally across the wifi link to your first AP then the data is sent in plain text onwards to the server and can be sniffed. This comprises the security of the data messages but not the wifi link ssid and password. Using SSL (https) prevents the data being sniffed.

In practice, if your server is local and using the same AP as the client then using SSL is unnecessary as the data is not travelling over the internet and is already secured by the wifi encryption.

Re: Overarching security concerns when deploying ESP8266

PostPosted: Sun Oct 06, 2019 4:13 pm
by MegaTux
Thanks for explaining that. Very helpful. Basically, only if I were to open my internal network to the internet should I be worried.

Re: Overarching security concerns when deploying ESP8266

PostPosted: Mon Oct 07, 2019 3:15 am
by btidey
Yes. That's right.

It is not a specific problem if the router (AP) has normal internet access itself. Normal good precautions are to have a decent management password on the router and confine management access to local if possible. Then only allow external access by port forwarding through the router when you know the target is safe.