Home Assistant can not be secured for internet access | Hacker News Reader

Home Assistant can not be secured for internet access

frederikbraun.de

11 pointstodsacerdoti38 comments

The author reports two main "security issues":

1) No HTTP basic auth. This isn't a security issue in any way, shape, or form. Author has a personal preference for basic auth but this doesn't mean that changes the security posture.

2) No support for reverse proxy so you can change the root to something non-standard. This is simply security through obscurity and once again has zero bearing on the security posture.

I think the author would do well to understand basic web services security before he starts casting stones here. VPNs work fine if that's what you need, but of course they are too complicated for the author so that solution is dismissed.

The author doesn't explain it well, but I use home assistant and I share the same view. Home assistant is not a very secure app. I would be fine putting it behind Nginx with basic auth, because Nginx is quite battle hardened and basic auth is a small attack surface.

I've solved it instead by using Wireguard and keeping home assistant on my private network. No idea why the author thinks VPN is not a good solution. It's also helpful for several other apps I don't feel safe exposing to the internet.

> I've solved it instead by using Wireshark and keeping home assistant on my private network.

What is wireshark for? Or did you mean wireguard and get autocorrected?

Indeed wireguard. Fixed, tnx

Nginx isn't suggested on the remote access manual page for sure https://www.home-assistant.io/docs/configuration/remote/

But there's addons in the package manager:

> Want to protect the website with a username/password? Well, it can do that too!

https://github.com/hassio-addons/addon-nginx-proxy-manager

> Nginx isn't suggested on the remote access manual page for sure

This makes it seem like they advise against it on that page, which is not true. Nor would it make any sense, putting a reverse proxy in front of a web application before exposing it to the open internet is about as typical as things get.

The problem the author describes is that doing this is not compatible with the mobile app. It doesn't support http basic auth and also can't present a client certificate (that's what I used to secure remote access to other browser based apps)

Home Assistant's Android app does work with client certificates.

https://companion.home-assistant.io/docs/getting_started/#tl...

You misunderstood, the main issue is that there's some user/pass auth code of unknown quality exposed, instead of basic auth done by some battle tested httpd implementation like apache/nginx. Which in ideal case, is also split from the application and can be independently updated if needed. That certainly does affect security posture.

> This is simply security through obscurity and once again has zero bearing on the security posture.

Not to defend the author or the idea, but this is very clearly untrue. Something similar is routinely done to intentionally break hotlinking usually (tokenized URLs and URL signing). It's ages old and does work, as it's no different to cracking a long and difficult password.

No, those two points you raise are completely false.

> Author has a personal preference for basic auth

Adding web server basic auth (and thus adding multi layer security) is objectively more secure than only application level security. Of course some other way of adding web server authentication would be equally okay, but the Home Assistant app doesn't have support for it either.

> This is simply security through obscurity

A secret subpath is not security by obscurity at all. The path isn't obscured in any way; it's a secret. It does have the downside that user agents don't treat URLs as secrets (i.e. it's saved as history), but in this case that isn't too much of a concern.

I understand complexity of VPN as a reason to give up, but not the other two.

Wouldn’t it just be the server which needs to be accessed from the outside? And the control interface is not that bandwidth-hungry.

> Bandwidth Limitations: A VPN could bottleneck the performance for some devices.

> Device Compatibility: Not all devices can reliably connect to a VPN.

I run the HA app on my phone with Tailscale as the VPN. Having set up various openvpn/ipsec/ssh based tunnels over the years I don’t get the authors take here

Tailscale or wireguard are waaaaay easier to configure and maintain than HomeAssistant. Like, orders of magnitude easier.

I can set up the former in 15 minutes on any device I have. It took me two days to rebuild my HA and reconfigure all the integrations after a crash, and I had backups.

If you are already committed to HA, then adding a VPN is cake in 2024

The HA maintainers also refuse anything that has to do with SSO. I'm not even talking about implementing it themselves, there have been many contributions over the years to add OAuth support

> My aim was to configure my home's heating to switch off when my family is away and turn back on when we return. This is achieved with home assistant, a popular open-source home automation platform, with location/presence notifications from mobile devices. To do this, the home assistant server needs to be accessible from the internet, as mobile devices must communicate with it remotely.

Does it really need to be accessible from the internet? I've never used Home Assistant so maybe what follows would not work, but how about:

• Your mobile device could upload the location/presence notifications to a server outside of your LAN, such as virtual machine at an inexpensive hosting service like Hetzner or Amazon Lightsail.

Something on your LAN could poll that and talk to the Home Assistant server.

• Your mobile device could email the notifications to you. Something on your LAN could monitor your email and process the notifications. A good tool for that is imapfilter [1].

[1] https://github.com/lefcha/imapfilter

VPNs are used in businesses around the world and nobody has issues with performance. What kind of ancient hardware are we talking? Performance used to be an issue with HW not supporting AES accel, but since we have wireguard this doesn't seem to be an issue.

The HA docs funnel most folks to a Raspberry Pi. The performance eventually got so abysmal I gave up on the platform.

Personally, I run MiniPCs for HA, but RPi5 should also support aes. Older RPis should be in do-not-buy category.

For services running on my home network I use Cloudflare (Argo) tunnels. They are free, easy, and powerful. No VPN is needed since it’s a hosted reverse proxy, just running a small service inside your network. I prefer k#s but it’s also easy to run with systemd. Once the traffic is flowing you can secure with full L7 routing behind your own oauth2 provider. I used my Google workspace domain. It can also be scoped to devices and other factors.

This is definitely not a Home Assistant specific deficiency, but they would do well to explain how to implement remote access to their users as it is an incredibly common use case.

Cloudflare Access is a great product, but TLS terminates at Cloudflare. They get to see everything, probably also passwords. Cloudflare will have admin access as the HA server.

It’s not as secure as VPN which is a better choice.

The reasoning is nonsense.

There are things like Tailscale that are free for private use and make managing / connecting to a VPN as easy as possible. The connection is only limited by your own home connection. You also don’t need to route all your traffic through it.

Put a reverse proxy in front of it for basic auth and path rewrite if you think that are the ultimate security mechanism for you (I don’t think so).

Personally I host all my applications behind a VPN because I don’t trust any software and don’t want to provide any attack surface or even the possibility to being made a possible target because someone scanned me.

This plus my own domain that points to the different local IP addresses makes it as convenient as surfing the public web.

> Routing general internet traffic through a VPN introduces unnecessary complexity. (...) A VPN could bottleneck the performance for some devices. (...) Not all devices can reliably connect to a VPN.

This suggests to me the author is imagining a VPN setup that isn't split-tunnel. Why would anyone want that for this? And what device is "not reliably able to connect" via VPN that you'd want to reach Home Assistant through?

> No Basic Authentication Support: Home Assistant's mobile apps cannot handle URLs with embedded credentials (e.g., https://user:pass@hostname). Path Limitations: Home Assistant must be hosted at the root path (/), preventing the use of an obscure web host path to deter scanners.

... so put a reverse proxy in front of it?

Maybe I'm missing something, but there's nothing unusual here.

I use nabucasa's RemoteUI (which provides a secure remote connection): https://www.nabucasa.com/config/remote/

(and I pay for an account, so that I can help support this project)

Am I missing something obvious here?

Unfortunately this was absolutely Clauded out without reviewing or really understanding the software in question.

Just use Tailscale? I have all my services running in Docker containers using Tailscale or Caddy Tailscale (for automatic https cert) sidecar. A secure private cloud has never been easier.

Until you get bumped off your ISP for violating the terms of service…

What nutty ISP would kick you off for using a VPN to access your home network?

Because of what exactly?

For hosting a service despite being on a residential contract.

A service for private use? Sorry I’ve never heard of that before and would ditch that ISP immediately.

Me neither, but that's their idea I'm pretty sure. Was just explaining.

I’ve never heard of that happening in the U.S. with major ISPs. It’s completely opaque vpn traffic to them. What would the ban be for? With remote work and corporate vpns it’s extremely common to have the same traffic patterns.

Author seems to think that security from obscurity helps while in reality it does not, neither doesn't have given a thought about putting something in front of HA like nginx if they want obscurity. With their principle anything should not be online

Obscure path? Been a while since I've seen the phrase:

Obscurity is not security.

If that's something the author wants to depend on, I'm not sure we should listen.

What's the difference between guessing a path and guessing a password?

> One might suggest using a VPN to secure the connection. However, this approach is impractical for several reasons:

> Complexity: Routing general internet traffic through a VPN introduces unnecessary complexity.

I don't believe that it's that bad if your pefered option is a reverse proxy. Frankly, wireguard isn't that complex on its own merits.

> Bandwidth Limitations: A VPN could bottleneck the performance for some devices.

Nonsense; this is a VPN for a specific purpose that uses virtually no bandwidth. Obviously don't run all traffic over it, but with that done it should be fine.

> Device Compatibility: Not all devices can reliably connect to a VPN.

True... but I thought this was just for cell phones? Because wireguard at least works on (at least) iOS, Android, and postmarketos. (And I'm pretty sure most other popular VPNs do as well.)

---

> No Basic Authentication Support: Home Assistant's mobile apps cannot handle URLs with embedded credentials (e.g., https://user:pass@hostname).

> Path Limitations: Home Assistant must be hosted at the root path (/), preventing the use of an obscure web host path to deter scanners.

That is a shortcoming, but not necessarily fatal; can it sit behind a reverse proxy that handles (http basic) authentication but doesn't use another path? That should be secure enough.

> That is a shortcoming, but not necessarily fatal; can it sit behind a reverse proxy that handles (http basic) authentication but doesn't use another path? That should be secure enough.

Yes, but the author’s issue is, that the mobile app won’t work with basic auth.

Oh, the client... Yeah okay that's a pretty fatal flaw. My bad.

Reply on news.ycombinator.com