Hacker News Reader

Comment by idatum | Hacker News Reader

HA provided a fix and broadcast the security issue reasonably effectively. Here we are discussing on HN. Good.

The vulnerability boils down to having a port open to HA (direct or proxy) exposed to the internet, or if your LAN is already compromised.

Many HA users will make the upgrade. Some HA users will not upgrade. Perhaps those are locked into a specific version, maybe because of the various integrations that cause issues when upgrading, etc.

It's interesting now the trade-off between "local" and "cloud". Home automation generally has this tension right now. Users want access to their "local" HA instance from a coffee shop, say, but don't want to deal with privacy issues and security breaches of "cloud".

View on HN

> Users want access to their "local" HA instance from a coffee shop, say, but don't want to deal with privacy issues and security breaches of "cloud".

My personal solution for HTTP stuff that should be private but I want to access from anywhere is to add another independent authentication layer.

I've so far settled on SSO using oauth2-proxy[1] out of convenience, but probably even basic http auth is enough.

That means that even if the running service authentication is broken, or like in this case, bypassed, it will still be caught by the first layer of authentication. See my HA instance[2] for an example.

For home assistant the tradeoff is that the native app doesn't work, but I'm sure there's a smart way to whitelist requests just for my device, I just haven't gotten around to it since the web page has been sufficient so far.

[1] https://github.com/oauth2-proxy/oauth2-proxy

[2] https://ha.emilburzo.com/

An alternative solution is to connect through Wireguard. On Android(not sure about iOS) you can force certain applications to use the VPN connection. WG uses UDP to establish connection so the exposure is minimal.

I haven't tried Wireguard so far, but from past experiences VPNs usually make mobile devices use more battery, I assume because they keep the radio on more than required (keepalive? just having to process VPN broadcast traffic?) and can't sleep so much.

Plus, personally I'm trying to reduce the amount of "trusted just because it's on the LAN" stuff and go more for a "zero-trust" approach as much as possible.

WG can live without keepalives(though it can use them), there is no real "session" concept. A peer will just connect back when the traffic starts flowing.

I keep an eye out on my battery usage and never noticed it being in the list.

On the zero-trust front - it's not really meant to completely replace authentication but it does help with minimizing attack surface. It does help with encrypting traffic, especially for stuff that does not talk https.

Nice, I need to try out Wireguard then, it sounds like things really improved in the VPN world.

Yeah, having worked with an OpenVPN setup in the past - wireguard is definitely a breath of fresh air. It can be a little bit tough to setup depending on the rest of the network stack(openrc/network manager/systemd/systemd-network, etc), but it's very flexible.

Wg-quick (typically comes as part of wireguard-tools on distros) is extremely handy for the initial testing.

A big problem with VPNs on mobile devices is that you can only have one running at a time. A completely arbitrary limitation as far as I know, but I haven't found any way around it on Android.

Worse yet, some network filtering solutions also use the VPN feature.

Hm, yes, I never noticed that.

One (maybe a bit involved) way around it is to route the packets on "server" if rolling your own VPN and setup the filtering there. It does defeat the purpose of the local apps though.

I would love to use my auth proxy with Home Assistant without having it break the Home Assistant app. Unfortunately it can't be done (without also whitelisting the whole API path in the process).

(Yes I know about WG but VPN just isn't an option for me)

Reply on news.ycombinator.com