This is my first post here, after over a year starting my own Home Assistant project. This alone says a lot imho about the quality of the project: Its great! One of the best, if not THE best OpenSource projects i know at the moment!
One thing, at least in my limited visibility into Home Assistant Installations, that many are installing first is DuckDNS (20%), LetsEncrypt (10%), Nginx (7%) to setup https. There are multiple ways to achieve it and many more ways to f**ck it up on the way, or to do it wrong especially for beginners.
Since Home Assistant, specifically Home Assistant OS, goal is to be an easy and secure go to solution, i was wondering why there is no https setup with valid certificates by default when you install Home Assistant OS?
It would be great to have a proper Reverse Proxy Setup installed by default, with valid certificates for both internal URL on port 443 and external URL with configurable domainname on port 443.
Alternatively or in addition, why not make it easier with an optional DNS forwarding integration/add-on to have just one domain internally and externally. If internally resolved, it would resolve to the local HA host IP, if a client is not in the local network it would resolve to the public IP of the domain like it would normally. The only thing for an HA OS user would be to configure this DNS forwarding integration and setup their Home Router to use that DNS server in their DHCP setup. But i think to setup this, even for someone not that technically deep into networking, https, etc. this would be way easier to setup imo, if the main setup is already done.
So, a new fresh installation of Home Assistant with my proposal would lead the local Home Assistant Installation be reachable at https://homeassistant.local/. If one does not need to reach the Home Assistant externally, you would be done, so no change to the onboarding experience, except everything is now encrypted in transit also locally.
If one wants to reach their Home Assistant instance also externally, one would configure their externally reachable domain, and Home Assistant would generate a new Certificate for it. In addition, one could enable the DNS Forwarder integration, which would get the configured external domain and would advise you to add the local DNS server to your Router configuration. If enabled, one could reach home assistant wherever you are (internal or external) with the same URL.
Instead of the local DNS Forwarder, this could also be part of the Nabu Casa subscription, which would make it even easier to setup.
Maybe i am missing some technical details of Home Assistant, if so please let me know.
I do not think so. You can have https also locally. Either by a self signed certificate, or use a domain with an official TLD but do not route it externally (make it available on the internet). Or let NabuCasa generate a unique subdomain and have a cert generated for that (e.g.: xxxxxxxxx.nabucasa.com) and configure it to resolve to the local IP by default.
While I accept the advantages of using HTTPS internally, a self-signed certificate causing a big,fat browser warning would anoy people even more. And for official certificates you need to pay or make your installation publicly available at least temporary.
NabuCasa requires both, public exposure and payment.
Hey, it’s a feature request, let’s see what happens.
Still, I think there are multiple ways to solve that in a user friendly way.
Import the generated self-signed certificate to the OS for instance - At least on macOS and iOS this is pretty straight forward and could be easily documented. I think, if you have Cloud Keychain enabled for your iCloud Account it would even sync it to all your devices - but i am not sure about that.
Lets see it from the other side: There are already several howtos, docs, etc. out there to setup LetsEncrypt, DynDNS, Nginx, etc. targeted to beginners, and in my opinion, this is way more complicated than that. Some are outdated, and for beginners i think its hard to figure that out.
And for official certificates you need to pay or make your installation publicly available at least temporary.
No, not necessarily. There is LetsEncrypt.
NabuCasa requires both, public exposure and payment.
Yes and no. Public exposure, not necessarily, but i agree: NabuCasa would not want to generate subdomains for EVERY HA installation, but it could be an additional argument for a subscription for some users to have an easy peasy setup, which would not necessarily require to have your HA installation publicly available.
Out of interest, as I use LE for my services (not Home Assistant): The ACME protocoll, used by LE requires the target system to be exposed to the internet, at least during certificate assignment and renewal. Is there an alternative way, that works without?
Nabu Casa is basically a proxy service, your site needs to connect to their site, although connection is initiated by your site. I consider this “public”.
Out of interest, as I use LE for my services (not Home Assistant): The ACME protocoll, used by LE requires the target system to be exposed to the internet, at least during certificate assignment and renewal. Is there an alternative way, that works without?
if you want to use LE, thats right, at least for the time it tries to reach it, it must be available for them via the Internet.
i understand what you mean. What i suggested was just to provide a DNS Forwarder, which you could use just the same way as you use any DNS (e.g. your ISPs DNS). even though all your devices are using it, your are not considering them public, right?
I don’t get the purpose of a DNS Forwarder in the given context. But I also don’t want to bad mouth your request. I just don’t think, that it is feasible.
No worries, critique is a good thing!
Maybe i wrote too much at once…
The Basic request is to have an easier way to setup a proper HTTPS, being it optional or by default, or just easier to setup once someone wants to have it. Of course, the best case scenario would be that as a user i would get https by default for my internal and external HA URL without any interaction needed from my side.
All the other things, was basically just brainstorming of how to solve the valid points you mentioned like with LE and public domain, Self-Signed certificate and browser warning, etc.
There really is no real good reason to do that.
HTTPS internally only will not provide much security, since your internal network should be safe already.
What it might provide is a higher power usage of your sensor, since they might now have to encrypt their connections. ESP chips, which is used a lot with HA, will really feel a drop in the battery life from encryption.
HTTPS internally can be done with self-signed certificates, but you need to add them to all your devices to avoid a browser warning and the trend from the browser makers seems to be to always warn on self-signed certificates in the future.
The other solution is to use LE as suggested, but you need to approve your domain every 90 days, so you need to either open a port in your firewall, which some ISPs might block or you might already use it for another service.
Alternatively you could use a DNS challenge, but not all DNS providers support this and in the end your battery powered devices might still suffer.
Then there HTTPS externally, but everyone with knowledge in computer security will advice you to not open you HA installation up to the internet directly. HA is made with features as the primary goal and security as secondary, and its made up from multiple developers providing code pieces that are not all reviewed for security.
The correct way to open up your HA installation to the internet is a general purpose VPN or specific purpose VPN, like NabuCasa, and with this setup you can add your SSL encryption to the VPN and let HA run without.
Good point, i have not thought about that. But i just suggested to have an easier - in the best case out of the box solution - for the Web interface, not all Endpoints. How are the ESP devices communicating with Home Assistant?
Thats partly true imho. There is the Mobile App, there is the External URL configuration. Of course you want to front you HA Installation with something like Nabu Casa, CloudFront, etc. But even in that case the Front has to communicate somehow with your instance, so its HTTPS end-to-end.
But your point is also exactly my point: Make it easy/easier for not so tech savvy HA users to be able to use a default solution which offers at least “basic” security over https.
I disagree here, i do not think that this is “THE correct” way. VPN is not more secure than HTTPS when it comes to encrypting your traffic between two parties, if https is configured correctly. What VPN gives you in addition is that it gives you more privacy over your ISP because the ISP can no longer see to which sites you are connecting, which is not a problem when using Home Assistant. Also setting up VPN on the server and client is also not that easy and you can easily f*ck it up.
You have misunderstood VPN.
VPN is not to hide from your ISP.
VPNs purpose is to make a secure connection between two end points over a insecure network.
In order for that to be succesful you need to make sure that the data is safe in traffic, which both VPN and HTTPS solve, but you also need to make sure that only authenticated traffic is allowed and here HTTPS fails completely, because there is no authentication.
Authentication with a HTTPS setup is left to the services behind the connection, which means HA with all its addon and integrations from different somewhat independent developers.
Some developers might make a decision to provide a feature that is not safe for internet access, because the feature can not be provided otherwise. You have no change of knowing if this is the case and you just need one such feature to have a security hole.
Other developers use thirdparty code packs and there is examples on these having severe security holes (Log4J). You have no chance to know if any of the developers in an addon or integration you use have implemented such a code pack and you have no chance to know if the code will be updated or the addon/integration have just been abandoned by the developer.
A VPN should only provide a secure connection, so you can look in one place for updates to your main outer defense ring.
If your VPN is broken into, then you still have a defense in the depth by having HA require authentication too.
That’s a common misconception and has been replace by “zero-trust” networks. With https you get Transport Layer Security, so other (malicious) hosts in your network are unable to peek into network traffic with respect to the UI.
It’s a benefit, but it introduces - with self-signed certificates - new challenges and warnings, reducing the Wife Acceptance Factor of HA.
I am not completely into Zero-Trust networks, but if you are, then you can still use HTTPS internally too.
Only HTTPS is still not good enough for opening up HA to the internet.
I dont want to start a discussion about VPN vs. HTTPS here, because VPN is good and has its uses, and of course it can also be used to access Home Assistant as you described.
Just some things i want to point out because they are not true.
HTTPS does Authentication: It authenticates Client and Server to mitigate MITM Attacks - hence the warning in your browser if you are not using a “valid” known certificate for signing. And yes of course the Application has to do Authentication and Authorization too, doesnt matter if you use VPN, HTTPS, or anything else. its just the Transport Layer, and not the Application Layer.
Not sure if i understood your point correctly, but if you want to say that its more secure to use VPN to connect to your HA instance because Third Party Addons are installed in your local network and you can not know if they are compromised (remember you said: "the local network should be secure ), how would VPN protect you? VPN does not block outgoing traffic to the internet if an addon decides to make some malicious request?! If you mean that an addon could open up a port on your local installation which could then potentially access without any application authN/authZ then yes, VPN would protect your from that. But also, Home Assistant does not allow that by design, without giving you a hint in the addon. Even if the code could open up a port, circumenventing somehow the Kubernetes network configuration, it would not be accessible by default over the internet, cause you would need to open the port on your router in addition.
Anyways, if the easier solution would be to have a VPN installation to opt-in for new users, why not. I just think its easier for a regular user to use regular http instead of install/configure VPN on their mobile and other devices.
In the end, the discussion just points out that the HA community would benefit from an easier, being it optional or by default, solution to setup HTTPS (or any other secured transport mechanism) either only for external accessibility or, if possible in an user-friendly way, for internal and external.
Why? The whole internet builds upon it. Big Enterprises internally uses it, even my company is using it more and more in favor of VPN - with client certificates though.
HTTPS authenticates the server by using a public certified certificate or a self-signed certificate delivered out-of-band.
There is not authentication of the client and that is the issue here.
I did not mean the security hole was actually used, but instead that it was open to be used.
VPN is used to put a layer of protection between that security hole and the malicious user on the internet.
A security hole rarely open up new ports, instead it elevate rights on the existing ports being used by using bugs in the code already running behind these ports.
Its here the huge number of developers of addons and integrations become an issue.
Take a look at how much you can actually access through you ha.local:8123 address.
Grafana, Glances, InfluxDB, SSH & Web Terminal, HACS, Node-Red are all accessible through that one port, just to mention a few.
A general purpose VPN service is not always easy to setup and can depend on the ISPs network and setup too.
Just opening a port directly to the HA installation might be easier, but it is not secure.
The developers already have accepted this and made the easy solution available - It is the purpose-specific VPN called NabuCasa.
), how would VPN protect you? VPN does not block outgoing traffic to the internet if an addon decides to make some malicious request?! If you mean that an addon could open up a port on your local installation which could then potentially access without any application authN/authZ then yes, VPN would protect your from that. But also, Home Assistant does not allow that by design, without giving you a hint in the addon. Even if the code could open up a port, circumenventing somehow the Kubernetes network configuration, it would not be accessible by default over the internet, cause you would need to open the port on your router in addition.