If your concern is IoT devices, TVs, and the like sniffing on your local traffic, there are alternatives, and some of them are:

• https from reverse proxy to service.
• VLANs or Different LANs for IoT and your trusted devices (I do this one).
• Internal VPN connection between devices (like WireGuard), so the communication between selected devices is encrypted.

if you use a simple
reverse_proxy service
it isn’t https. It will make the connection using good old http. If you use
reverse_proxy https://service/
or
reverse_proxy service:443
it will be https (443 is the port for https)

This does not mean, that any other device can just intercept the packages. It depends on the routing; your router and switches are smart. They know on which cable a device is and only send it to that cable. If anything else is on that cable, they can intercept this message. Any devices not on that cable can’t.

So if you’re like me and have Caddy and HomeAssistant on the same physical server as virtual machines, you realistically shouldn’t have to worry, as the traffic should never leave your server.

I’m not familiar with Caddy at all - I use Traefik for a reverse proxy, and my knowledge there isn’t huge either. But I think that your reverse proxy terminates TLS (HTTPS) from the world and then forwards traffic to the appropriate service on your local network using HTTP by default - but if your local service can handle TLS, I think you can configure your reverse proxy to forward the traffic to it using TLS.

Yes and no. Usually you do HTTPS termination on the same device, so the traffic doesn’t actually go out onto the network. To sniff it, you’d have to be root on the machine, in which case you’re already compromised.

Like others are saying, a simple fix to this is to setup the homeassistant machine for https & a self signed cert. Then on the Caddy machine you can configure the https to not verify the origin. That would make the communications more robust, but I think it is still vulnerable to MITM attacks.

There are multiple reasons but the most important one is: You didn’t enable it.

Caddy fully supports https to the reverse proxy targets, though you’d have to get those targets trusted certificates otherwise caddy wouldn’t connect.

The default protocol for backends is http, most of the time this isn’t a problem because:

• The web server runs on the local machine
• The web server runs in containers/vms on the local machine
  • or is running in a VM and has a direct virtual connection with the caddy vm
• The connection to the Backend is encrypted with a VPN
• Caddy and the web server are directly connected or connected through an otherwise isolated network

Because https requires certificates that are somewhat difficult to set up for internal servers (and were even harder to get before) the default mostly is just to encrypt on another layer of the stack. Afaik at least.