Securing the z-wave js websocket

What are options for locking down what can connect to Z-Wave JS’s websocket?

ZUI is running on Debian. Use iptables to accept connections to port 3000 from a specific MAC address?

If I put a proxy in front of the websocket could HA use wss://?

Any options or plans like secure websockets and a shared api key similar to ESPHome?

Thanks,

Firewall that only allows HA’s mac address

Might have to test my house guests to see if they know how to spoof a MAC address…

If you’re simply looking for access control:

  1. Basic auth credentials are supported in the ws schema (ws://username:password@url. Two problems though: 1) of course the credentials are sent in the clear without secure websockets, and 2) the credentials are exposed in the UI as the server URL.
  2. A firewall rule allowing only the HA IP address (instead of MAC address), if it’s a static IP.

If you need encryption as well, then you’d need some kind of proxy or alternative transport. I use Tailscale, as it provides both access control and encryption.

I have never heard of any plans to support any security functionality. The target users have always been HAOS users who are running the local Z-Wave JS app. You’d have to start a dialog with the devs about supporting new features.

I know you can setup auth for the ZUI web interface. I don’t see basic auth set up in the config for the websocket in the UI though. Or did you mean doing that with a reverse proxy?

Ok, I agree that IP makes as much sense and MAC, but curious why you noted that.

I’ve been meaning to play with Tailscale. I should also see if a simple SSH tunnel could be made to work. Might be the simplest.

Yeah you’re right, it would require a proxy. I tried it years ago so I’ve forgotten the details.

Because the other conversation mentioned using a firewall rule based on MAC and I was providing an alternative for the same idea.

Should work fine, unless you’re using HAOS. There would be no way to create a permanent connection (AFAIK, unless there’s some kind of app). It’s simpler in concept but keeping the SSH proxy running may not be.

I played around with this earlier today – it’s just a fun exercise, TBH.

I installed Caddy as a reverse HTTPS proxy on the machine (Rpi3b) running ZUI, and that all works. But, since it’s self-signed cert, connecting from HA (using wss://) results in CERTIFICATE_VERIFY_FAILED, and I doubt the zwave_js integration has a way to disable certificate verification, right?

Using a simple SSH tunnel is pretty easy to setup and the zwave_js integration connects just fine over the tunnel to ZUI, of course.

I was hoping I could just drop the ssh command into the Advanced SSH & Terminal init_commands configuration, but that doesn’t work. That’s something to research later.

Creating the tunnel in Python is simple, too. My guess is that it would be an easy custom integration to create the tunnel(s) – asyncssh is already in core. I’ll give that a try when I have some time.