I’ve recently begun a quest to improve security of my system anywhere I can. One of the things I wanted to do was encrypt all traffic anywhere I could related to HA. I ran into some bad blockers doing this though. I thought at the time I was probably being over-the-top and so was willing to overlook the challenges but I saw this post by pvizeli and decided I should make a feature request for it since it seems we both look at addons with skepticism:
So here goes. When trying to encrypt all traffic related to HA the issues I ran into were these:
Supervisor only accepts HTTP traffic, everything must talk to it unencrypted. And things talk to it a lot so this is a problem (especially if you use the Node RED addon). I would like supervisor to accept encrypted traffic with a self-signed certificate at https://supervisor and provide the CA cert to addons to use for communication with it. This way other addons and any other software with access to the docker network could not see unencrypted traffic with supervisor.
The /ssl folder is fully visible to most addons. Addons with SSL options generally look in the /ssl folder for the cert and key file. But there’s no way to hide files in this folder from other addons. Which means every addon can see the keys to all my certificates I use in other addons. This makes it so you can’t really encrypt communication with that addon within the docker network. The system works fine for addons you expose to the rest of your network but if your goal is to encrypt addon traffic from other HA components then you really can’t. Ideally there would be a way to provide a cert and key file as part of addon config and have it provided to that addon in a way that only it could see it.
Same as #2 but for HA, I want a private place to put files only it should be able to see, like its certificate and key file.
This issue. Granted this is optional, #1-#3 were the real problems. It was an issue that I ran into but I don’t feel like I really need to give each addon/component explicit permission for each other addon/component its allowed to talk to by way of a certificate, I just want to encrypt traffic between them. That being said if I could use it for HA I probably would to ensure nothing else could talk directly to HA from outside the docker network. There’s no way to do that right now with HassOS, it always exposes port 8123 to the network (or whatever you pick for HA)
I realize that #1 would also require the addons I use to update to use that new CA cert and the HTTPS endpoint. That’s ok, if the feature exists I will submit feature requests to them. Or pull requests if I can figure out how to do it.
A thought on a way to do this (feel free to ignore as I’m not an expert when it comes to implementation here). If #1 was implemented I imagine the supervisor container would have a private CA it used to create its certificate. It could also create a certificate for each addon as it was installed for the address https://<addon slug> and put that certificate in /etc/ssl inside that container. Then there would always be a private certificate and key file to reference for every addon that only it could see and that every other component on the network could verify (since they all have the CA cert already).
I wouldn’t suggest encrypting all the traffic to and from HA and add-ons. That is going to get expensive in terms of CPU use depending on how many add-ons you are using as SSL encryption/decryption doesn’t come for free; There is always a CPU/memory cost on the host(s) that has to do the encrypting and decrypting. This is going to increase exponentially as one adds more add-ons and/or containers.
Rather, I would suggest isolating HA (and its add-ons) on their own VLAN and block inbound/outbound access to that VLAN. A simple firewall rule of a small range of IP addresses and/or ports in and out would prevent any rouge actors on your local lan from being able to even find your instance of HA, much less sniff the traffic within the container network. Further, you could block all outbound traffic outside of that VLAN except for 8123. That way, everything (add-ons, containers, IoT devices, etc) are basically on their own, completely private lan with no way of reaching out to anything. For any rouge add-ons that are on installed in your HA instance, they can snoop and collect all the passwords they want as they can’t transmit if back to the internet… because it would be blocked by a firewall rule.
Makes sense but unfortunately not really possible for me. I would love to have everything be local, that would be great. Unfortunately far too many things have a dependency on cloud services. I’ve gotten smarter about researching local access options for the things I buy but there’s still some software/devices I haven’t gotten rid of either due to cost or lack of alternatives.
VLAN tagging is also not something I have available from my router right now simply because I didn’t know to look for that feature when I bought this one. It’s definitely top of my list in terms of features when I do replace this router though.
Although I have to say, even if I did have VLAN tagging available and all local devices/software, I’m not sure how I would cut off HA or supervisor. Cutting off those two would eliminate my ability to do basic things like use the mobile app, use a voice assistant, receive updates, etc. There’s no way I’m going to turn those things off which means I can’t really cut off HA.
Fwiw I do realize the easy answer here is simply leave supervisor, install core and do all the other containers yourself. And maybe that is the answer from the HA team, if you want this much control do it yourself. I just figured it can’t hurt to throw it out there. The HA team has typically been good about identifying ways to automatically improve the security of users when possible, thought this might be a way.
Please, not force users to climb into the network layer. It’s easier to have the option to encrypt everything everywhere. The user can easily buy additional equipment, it is not difficult for him and the purchase is one-time, if the user really needs encryption. Already, providing secure access for HA takes up half of the HA forums, it is very hard for users
