When is it necessary to have SSL on the LAN side of a reverse proxy (between the reverse proxy and the server)?
Without SSL on the LAN side of a reverse proxy, I presume that all traffic between the server and the reverse proxy is unencrypted and, thus, accessible to any device on the LAN.
Which specific scenarios result in this being a concern? The primary concern that I can come up with is if you know that there are untrustworthy entities connected to the LAN (untrustworthy devices, or perhaps malicious individuals).
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.
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.
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.
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.
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.
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.
TIL of PPPoE! Could this still be circumvented through ARP spoofing, though?
I wasn't speaking about PPPoE specifically when I made my post, all wired ethernet traffic only travels from sender to recipient without being visible to any other devices that's not in the direct communication chain. This wasn't always true. A network hub will send out incoming data to every single port, but hubs haven't been in common use for decades. A network switch is aware of what is plugged in where, and will only send received data out whichever specific port the destination is connected to. If you have three PCs plugged into a network switch and PC1 needs to send a packet to PC2, PC3 has no way of even knowing it happened.
That said, your final point is correct, and ARP spoofing defeats this. It had completely slipped my mind when I made the above post.