[collaboration] secure all the things

Share your Projects!
1

Hi everybody,

perhaps we can make this a collaboration thread for setting up things as securely as possible in Home Assistant…? I used not to care about things being secure as “it is all in my local network, anyway”. While this is still the case, I started securing my mosquitto broker and all tasmota devices connected to it, then realized even though it is all local *at the moment, it wouldn’t hurt to have security/encryption whenever possible, so that is what I am currently working on.

What I managed to secure already:

  • MQTT
    • mosquitto broker
    • mqtt client in Home Assistant
    • tasmota with TLS support
    • zigbee2mqtt with TLS support

What I am not sure can be secured by using encryption (only things I personally work with, so not a complete list):

  • Nuki
    • seems to only use http, not https for API access
  • ESPHome
    • can be password protected, but does it use encryption?
  • Home Assistant
    • Android app will not work when using self-signed certificates
    • might work when using official certificats (letsencrypt), not tested

Securing mqtt broker

I just followed this tutorial; it took me a couple of attempts as I didn’t follow instructions step by step and/or thought they missed something and just added it on my own. Don’t do this, just follow the tutorial and it’ll work fine :wink:

mqtt client in Home Assistant

Using the ca.pem we created following the tutorial above, we can implement a TLS connection between Home Assistant and the mqtt broker. This is what I added to my configuration.yaml

mqtt:
  broker: !secret mqtt_host
  port: !secret mqtt_port
  username: !secret mqtt_username
  password: !secret mqtt_password
  certificate: /home/<me>/.homeassistant/packages/cert/ca.pem
  tls_insecure: !secret mqtt_tls_insecure
  tls_version: !secret mqtt_tls_version
  discovery: true
  discovery_prefix: !secret mqtt_discovery_prefix
  birth_message:
    topic: !secret mqtt_topic
    payload: !secret mqtt_payload_online
  will_message:
    topic: !secret mqtt_topic
    payload: !secret mqtt_payload_offline

You don’t need to create secrets for everything; especially not the topics and payloads, but I am currently recreating Home Assistant from scratch (switching from docker to virtualenv) and want to make all my config files as interchangable/shareable as possible, so using secrets for everything seemed right to me.

certificate as obviously the ca.pem we already created. It is essential that you set tls_version: 1.2 as other version seem not to work - at least not when following the tutorial from above and with mosquitto. I set tls_insecure: true as this is a self-signed certificate that might not be accepted otherwise (please correct me if I am wrong).

tasmota with TLS support

Official tasmota page on this. After creating the ca.crt, I downloaded tasmota-fingerprint to the same directory the certificate was in and ran ./tasmota-fingerprint ca.crt. It created the fingerprint checksum that had to be included in the tasmota configuration before compiling the .bin file.

Steps

  • git clone https://github.com/arendst/Tasmota
  • cd Tasmota/tasmota
  • $EDITOR my_user_config.h

I changed the lines for MQTT to

#define MQTT_FINGERPRINT1      "<fingerprint from tasmota-fingerprint"  // [MqttFingerprint1]
#define MQTT_FINGERPRINT2      "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"  // [MqttFingerprint2]

This should check whether the mqtt server tasmota communicates with has the correct fingerprint; if so, good. If not, accept whatever other fingerprint it has (that’s what all the zeros mean). Again, if I got this wrong, please correct me. But that’s how I understand the tutorial.

You also need to uncomment #define USE_MQTT_TLS in the my_user_config.h. I personally enter all my other information (wifi, mqtt credentials, web server password, etc.) in that file, so I only need to build and flash the .bin. You can uncomment #define USE_HOME_ASSISTANT as well so any device will automatically be discovered by Home Assistant as it sends the required payloads via mqtt.

You can build the binary by following one of the countless tasmota tutorials, or (if running linux) pip install -U platformio (might have to run this as root), then cd to the directory you cloned Tasmota to. In the directory that also contains the platformio.ini you can then run pio run; this will compile all versions of the binary unless you specify otherwise… but I won’t go into details as this is not about compiling tasmota…

Nuki

Is there a way to only communicate with Nukis API via https? I haven’t found a way yet. http works, and there doesn’t seem to be a way forcing https in the nuki android app.

ESPHome

If you use mqtt on ESPHome, you can insert a fingerprint as well; however, if you only use the API, is there a way to communicate securely? I assume that if you use https for Home Assistant itself, communication via API might be secure, but do not know if this is actually the case…?

Home Assistant

As stated above… when using self-signed certificates, the android app will not connect to Home Assistant. At least it never did for me, if I understand correctly, this is due to the android app using the android browser under the hood, which will not accept self-signed certificates.

What other devices/services have you connected to Home Assistant, and how did you assure them to be secure?

I have VLANs for different things in my network… untrusted IOT devices (and all my no-name ip cameras) cannot access anything other than their VLAN; only my devices can access the VLAN my Home Server (and therefore, Home Assistant) is in. Other devices that are trusted, but no operated by myself, can access permitted ports (i.e. 8123 on my Home Server, but not the VLAN it is in, nor any ports I didn’t manually allow).

While this should all be relatively secure, especially considering that this is a Home Network. Guests get internet access via a separated VLAN. Newly connected devices cannot access any devices in any VLAN until I manually set a DHCP address for them. But as mentioned above, this is more about the learning experience and to have security just because you can - I doubt anybody will get in my network in the first place, and even if they were to, they wouldn’t be able to sniff traffic (to, for example, sniff the Nuki API key to unlock my door), but I’d still have everything as secure as possible, regardless of how likely it is that anybody gets into my network at all…

2 Likes