If I use Caddy for reverse-proxying into another local machine... is my local connection not HTTPS?

Submitted ⁨⁨5⁩ ⁨hours⁩ ago⁩ by ⁨unknowing8343@discuss.tchncs.de⁩ to ⁨selfhosted@lemmy.world⁩

Mind that I am very noob into self-hosting, reverse proxies and the like

When I saw that Caddy automatically handled the HTTPS thingies I was like “this is my moment then to go into self-hosting”. Caddy seemed so simple.

Turns out… I am suddenly discovering that the connection between the caddy machine and the Home Assistant machine (both in the local network) is non-encrypted. So if another appliance in my local network went rogue… bum, all my info gets leaked… right?

This might sound weird because it might actually be super-duper complicated but… how come in 2025 we still don’t auto-encrypt local comms?

Please be kind. Lot’s of love. Hopefully I’ll dig my way to self-hosting wisdom.

source

Comments

Sort:hotnew top

darkan15@lemmy.world ⁨3⁩ ⁨hours⁩ ago
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.
source
FlowerFan@piefed.blahaj.zone ⁨3⁩ ⁨hours⁩ ago
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.

source
frongt@lemmy.zip ⁨4⁩ ⁨hours⁩ ago
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.

source
mike_wooskey@lemmy.thewooskeys.com ⁨4⁩ ⁨hours⁩ ago
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.

source
BioMyth@lemmy.ml ⁨4⁩ ⁨hours⁩ ago
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.

source
- BennyInc@feddit.org ⁨3⁩ ⁨hours⁩ ago
  Even better: generate a key pair to use for HA, and give the public part to Caddy to use for authenticating the HA server. If HA supports it, you could even generate a client certificate Caddy could use to authenticate against HA.
  
  source
InnerScientist@lemmy.world ⁨4⁩ ⁨hours⁩ ago
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.
source
- FiduciaryOne@lemmy.world ⁨1⁩ ⁨hour⁩ ago
  Good write-up. I also have Caddy with no HTTPS to the back end service, and was just thinking “I should set that up” when I realized…all the services are on the same ProxMox host, so that have direct access via virtualization, and so won’t be in clear text over the network at all (or at least I think so). Thanks!
  
  source