homelab

Security comes in layers. If someone compromises your DNS server, or switch, (or does arp poisoning, etc etc) for example, but not the reverse proxy, (and it resolves backend via DNS and it doesn't validate/pin certs), they could intercept the traffic transparently. If you have SSL on that link, it massively reduces the attack potential.

The MITM risk is pretty minimal, but operationally it makes life a ton easier if everything has valid SSL certs

One use case I've seen professionally is that if you're in a datacenter shared with other people, one could easily plug a laptop or change your switch ports or whatever and see your database traffic or whatever. Or in the case of the cloud, it makes it so nobody can snoop on your traffic at the router or hypervisor level.

I've seen VMs getting traffic they shouldn't be getting, so even if you trust your provider, bugs happen.

On smaller, regular LAN, some devices are pretty innocent on their own but may have vulnerable firmware and become part of a botnet, which then can be used for attacks like ARP spoofing.

I've had a conference room IP phone with a public IPv6, from another country, that triggered CPU warnings. It was being used to crawl our website and it was hitting some heavier pages and was trying all sorts of known exploits.

On my own home LAN, I just have VLANs and SSIDs based on trust level, but for the most part nothing that would be sensitive. I guess you could copy all of my Linux ISOs.

There are actually technical requirements for HIPAA compliance (HITRUST or HITECH, or maybe both, idr any more). Essentially no HPI (healthcare information about an individual), unencrypted, in transit, ever. Also, not unencrypted on disk, ever. The idea is that if your network security slips and someone manages to place a traffic snoop somewhere, they still can't listen in.

It's almost never a requirement (and very rarely implemented) in mid- to low-risk security situations, and even for HIPAA entitties, encryption in transit is usually implemented with an encrypted layer 3 of some kind. But I could see a fairly simple high-risk app needing the network to contain nothing in plaintext.

Unless you're Jason Bourne, I doubt you need it for your homelab.

I imagine the primary reason for having SSL between a reverse proxy and servers is to align with a zero-trust model. You're exactly correct that you'd rather expect that you don't know who is on the network and can monitor the traffic, so encrypt traffic rather than trust the network is secure and leave the traffic unencrypted.

Although best-practice is likely to always have SSL, especially in a corporate environment or in an environment where you don't control the proxy or the server (since this also rules out man in the middle attacks as you can verify the proxy an potentially the client), in a LAN where you control both elements and know what's likely to be on the network (like a home network) you can probably get away without SSL for the convenience.

It depends on how much other people care about your data, and how much physical control you have over the devices. If you're in "nation states would like to have it" territory, you should never have unencrypted data at rest, or on the wire. If you're a regular home user and all your computer stuff is inside your own house, you're probably fine. In between, there's a lot of possibilities. Encryption is cheap.

accessible to any device on the LAN.

Only if that traffic is using broadcasts. Wired networking on moden hardware is strictly point-to-point, PC1 is completely unaware of any traffic between PC2 and your home server or whatever.

Wireless is different and can ostensibly be snooped by anything that knows your network key, but I'd assume that you're not running services on wireless devices.

Its worth considering to do SNI routing without decryption in the reverse-proxy, but usually it is not a major issue to just terminate.