Whenever you add devices to your network you generate additional points of potential intrusion. This is not only valid for your mobile phones and computers, but also for you Smart TV, you Alexa, or all of your SONOFF devices (ESP8266).

There are following potential risk you have to mitigate:

• Someone hacks your device and is able to login into your WLAN. (why is this a problem? 1)
• Someone hacks your device and is able to read and change any value on your MQTT server (why is this a problem? 2)
• Someone hacks your network and can interact with your devices (why is this a problem? 3)
• Someone hacks your device and use it for different things like mail bot or DOS (Denial of Service) device or WLAN jammer (why is this a problem? 4)

(1) If someone is able to get your WLAN key, he can login into your network, if he is nearby and scan for any traffic and for any devices. Many communication is not encrypted in your WLAN by default. Therefore be part of your WLAN gives the attacker a great opportunity to screw-up the rest of your infrastructure. Also be part of your WLAN does mean, that the attacker can use your IP-Adress and your traffic to do nasty things.

(2) If you can hack a SONOFF you might get access to the keys stored in the device. For example, the MQTT password allows you to read ALL of your devices and change any device at any time. With the information of the MQTT-Server user/password, it might be not required anymore to physically be in your WLAN. Maybe your MQTT Server is publicly accessible. Then the attacker can control your home from any place.

Update: 6.0.0: With this version passwords are not anymore exposed through the serial connection or through the webinterface in configuration mode. Therefore it is now not that simple to get the MQTT or WLAN password from a device. But maybe not impossible

(3) It might happen, that e.g. your Samsung SmartTV is not as secure as it should be and an attacker gets access to your network. Now he can listen to any traffic and maybe can make changes on all of your IoT devices.

(4) If someone uses your device to spam mail or do a DOS attack the impact at your home is minimal. You might have more outbound traffic, but maybe you don’t recognize this either. But thousands of hacked IoT devices can generate tremendous trouble even at the largest internet providers.

I hope these four typical scenarios ( the list is not complete) give you some idea, why you should take care, even if you’re not a terrorist and normally nobody is interested into hacking you personally.

That you should have a WLAN key and use WPA2 for encryption is a “no brainer”. This is a minimum requirement. Now think about someone can extract the password from the device. E.g. because the device is in the garden and someone with a Laptop and some USB stuff can connect and extract information.

The hacker will get the key. The ONLY possible preventive action to mitigate worst case scenario is to have a second WLAN, like the “FritzBox Guest WLAN”. Many other routers offer similar things. This guest WLAN has no access to your private WLAN. Additionally, there are some interesting switched you can configure for the WLAN. At the FritzRouter you can configure ”*network separation*”. At Fritz this is done by DISABLE ”*The wireless devices connected with the guest access can communicate with each other*”. This does mean, that a device in the network can not interact with any other device in the WLAN. It can only communicate with the Internet. This simple configuration prevents any attacker to do nasty stuff on YOUR network. Now we have to take care, that the attacker is not creating a Bot-Net and sending e.g. Spam-Mails. Normally a device in the “guest WLAN” can use any internet service. For our IoT devices and for any new device we can create a Router rule, that ONLY MQTT is allowed to our server and any other traffic is blocked. This is a great configuration because it limits the options what a hacker can do. If you have a FritzBox following configuration has to be created to get this working:

1. Create Profile to block all communication except MQTT and NTP Time services.

Internet -> Filters -> List -> “Add Network Application”

“New Protocoll” (Add four rules, This will block all but UDP123 for Timeserver and 8883 for MQTT Server)

• TCP from any to Port 1 to 8882
• TCP from any to Port 8884 to 65636
• UDP from any to Port 1 to 122
• UDP from any to Port 124 to 65636

1. Create a list of “websites” your IoT devices are allowed to access.

Internet -> Filters -> List -> “Permitted web sites” -> EDIT

yourserver
01.de.pool.ntp.org

Please replace <yourserver> with the full qualified name of your router in the internet. ntp.org please use the one you have defined in TASMOTA to be the timeserver.

1. Create a profile you can attach to your IoT devices.

Internet -> Filters -> Access profiles -> “new Access profile” “Filter Web sites” DISABLE “Allow HTTPS queries” SELECT “Permit web sites (whitelist)

1. How can I communicate with my MQTT Server in my personal WLAN, if only traffic into the internet is allowed?
2. How can I access the WebConsole of my devices to upload new Firmware and/or make investigations?

The first topic will be solved by exposing your MQTT server to the Internet (no worries, can be done securely). The second topic has only a workaround. If you want access to your devices you need to change the configuration temporary on your router and ENABLE ”The wireless devices connected with the guest access can communicate with each other”. Secondly, you must login with your Laptop into the GuestWLAN to be able to communicate. If the Webserver is running you should be able to connect and upload e.g. a new firmware.

In the world of IoT devices and more and more devices in a network, it is essential to use encryption ALL the time. The TASMOTA project is able to enable encryption for MQTT. This is great. But it cannot enable encryption on the WebServer. This is bad. As a conclusion, the Webserver must be switched OFF all the time and only be switched ON for administrative purpose. This also disables the feature to change the Relay Status with an HTTP REST call. But this option is insecure anyway and should be avoided.

Now let’s work on the MQTT configuration. Also here an attacker can get access to user and password. To minimize the impact EVERY and really EVERY device must have a unique USER and a unique password. If you don’t follow this rule the attacker get one device he can control ALL devices. With the USER/PASSWORD he now can control the one device he already holds in his hands. ok, no big deal. How to configure Mosquitto?

The TASMOTA in general store data in stat/<topic>/+ and tele/<topic>/+. or cmnd/<topic>/+ to control something. If we use the <topic> as username we can make some quite nice and straight forward configuration.

Example: Topic: ESP_123456 User: ESP_123456 (must be the same to Topic) password: 987654321

Configurationfile: /etc/mosquitte/conf.d/jp.acl

user root
topic read #
topic write #

pattern read cmnd/%u/#
pattern write stat/%u/#
pattern write tele/%u/#

My user root is allowed to do everything. This is used in my home-automation to control all devices and listen to all devices. The “pattern” is used for ALL other users and the %u is a substitute. The great thing is that the device can read its configuration but cannot write to it. And the status information it posts to the status but is not able to read it afterward. With this minimal configuration, TASMOTA devices are running.

To add the different user to Mosquitte the following two commands work fine. There is also a re-read available, but a restart works better for me.

sudo mosquitto_passwd -b /etc/mosquitto/conf.d/jp.pw ESP_123456 987654321
sudo /etc/init.d/mosquitto restart

If this is running we switch the Mosquitto to secure communication on Port 8883 and disable all insecure options.

/etc/mosquitto/conf.d/user.conf

#User Config
password_file /etc/mosquitto/conf.d/jp.pw
acl_file /etc/mosquitto/conf.d/jp.acl

allow_anonymous false

listener 8883

cafile   /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key
require_certificate false

How to generate the certificates in mosquitto please look at:

• Mosquitto SSL Configuration - MQTT TLS Security
• Adding TLS to connect to Mosquitto
• Internet of Things messaging MQTT with TLS
• Enable Secure Communication with TLS and the Mosquitto Broker

At the TASMOTA configuration, you need to enable to use the TLS Version. This is done by enable USE_MQTT_TLS and change the port number to 8883. Additionally, you should change the MQTT_FINGERPRINT.

The fingerprint is now calculated over the server’s Public Key and no more its Certificate. The good news is that Public Key tend to change far less often than certificates, i.e. Letscencrypt triggers a certificate renewal every 3 months, the Public Key fingerprint will not change after a certificate renewal. The bad news is that there is no simple command to retrieve the server’s Public Key fingerprint.

So to simplify your task, we have added two more options: 1/ auto-learn of fingerprint, 2/ disabling all-together the fingerprint validation.

Option 1: Fingerprint auto-learn. If set, Tasmota will automatically learn the fingerprint during the first connection and will set the Fingerprint settings to the targer fingerprint. To do so, use one of the following commands:

MqttFingerprint1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

or

MqttFingerprint2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Option 2: Disable Fingerpring. You can completely disable server fingerprint validation, which means that Tasmota will not check the server’s identity. It means that your traffic can possibly be intercepted and read/changed. This should be used only on trusted networks, i.e. with an MQTT on your local network. YOU HAVE BEEN WARNED!

To do so, set one of the Fingerprints to all 0xFF:

MqttFingerprint2 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Starting with 6.5.0.15, AxTLS has been replaced with BearSSL. This allows a much lighter use of memory - typically 6.0k constantly, and an additional 6.8k during TLS connection. This makes TLS now compatible with Web and Hue/Wemo emulation.

The main limitations are:

• Your SSL/TLS server must support the TLS 1.2 and the ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher - which is the case with default Mosquitto configuration
• The server certificate must have an RSA private key (max 2048 bits) and the certificate must be signed with RSA and SHA256 hash. This is the case with default Letsencrypt certificates.
• Your SSL/TLS should support TLS 1.2 MFLN to limit buffer to 1024 bytes. If MFLN is not supported, it will still work well as long as the server does not send any message above 1024 bytes (which should be ok, since Tasmota cannot parse MQTT messages above 1024 bytes)

Before v 6.5.0.15: to the value you’re getting from the mosquitto server. To get the fingerprint you can use the following command on your MQTT server:

openssl s_client -connect localhost:8883 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin

Note: The openssl output will most likely be a Colon separated fingerprint

A5:02:FF:13:99:9F:8B:39:8E:F1:83:4F:11:23:65:0B:32:36:FC:07

Tasmota requires the fingerprint expressed as 20 space separated bytes

A5 02 FF 13 99 9F 8B 39 8E F1 83 4F 11 23 65 0B 32 36 FC 07

Note that when you create your certificate, you should make sure to set the CN field to the value of MQTT_HOST. Setting your CN to a domain name but your MQTT_HOST to an IP address will cause the signature verification on the sonoff to fail.