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.

  • BioMyth (He/Him)@lemmy.mlEnglish
    4·
    3 months 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.

    • BennyInc@feddit.orgEnglish
      1·
      3 months 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.

  • darkan15@lemmy.worldEnglish
    4·
    3 months 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.
  • InnerScientist@lemmy.worldEnglish
    3·
    3 months 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.

    • FiduciaryOne@lemmy.worldEnglish
      1·
      3 months 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!

  • Auli@lemmy.caEnglish
    1·
    3 months ago

    Your choice I don’t encrpt local comms because it is all in machine. Go to proxy and proxy goes to another container but never leaves the machine but don’t see a reason to encrypt. Even HA in a seperate machine what are they going to see.