As a comparison, we run (and I think this is pretty common) nginx proxy servers that point to app servers. The proxy servers handle SSL to the outside, whilst the connection to the app servers is simply http. Pretty sure that is an acceptable solution in most cases. So then this would apply to the SSL argument here as well.

All network traffic that leaves a host should be encrypted. You could have an exception for a physically isolated network in a secure cage, if you're adventurous. But most of use are in cloud environments, so encrypted traffic is required. Even with VPCs and Security Groups, you don't want to rely on network ACLs alone to prevent data from being intercepted.

If Redis does not support encryption natively, then you have to run a gateway like stunnel on every redis host. The redis clients mostly all already support connecting to a secure socket, but the server and cli client require manual stunnel configurations. Native support for encryption just removes this extra setup.

Encrypted doesn't mean TLS necessarily, and neither it means that it has to be at layer 7.

For the use case you are suggesting, wireguard network among your hosts would be simpler and without the need for each application to handle TLS.

And how would we then connect our section of Windows workers, which are needed to run some proprietary software?

As long as wireguard is Linux-only, it's not an universal solution. TLS is.

>> Pretty sure that is an acceptable solution in most cases

No, it's not. In almost all high-security compliance audits you are required to have the data encrypted anytime it's in-flight.

Some of our systems require in-flight and at rest encryption.

You can stick a proxy in front of apps that don't have features you need like mTLS, tracing, metrics, etc. to get those. Google "service mesh" to explore that space. But to some extent, I think it's all a bit easier if your apps just do the right thing out of the box. Less moving parts. Better integration testing.

Like medicine, every piece of software you use has effects and side-effects. If the advantage of the effects outweigh the disadvantages of the side-effects, then something is a good deal. But if you can avoid the side-effects entirely, that's best.

We did, too, when we were in startup mode. Now, nothing runs unencrypted internally.

Most tooling uses TLS, because when you do this at scale, you automate your CA and it is much easier to securely deal with than, eg, ssh certs. But we do use (LDAP centralized) ssh as well, mostly for humans.