badssl.com is an amazing tool especially for testing "TLS intercepting" boxes. I've seen more than one fortune 500 company that re-sign certain broken certs with their own CA, allowing silent MITM.
TLS inspection can _never_ be implemented in a good way, you will always have cases where it breaks something and most commonly you will see very bad implementations that break most tools (e.g. it is very hard to trust a new CA because each of OS/browser/java/python/... will have their own CA store)
This means devs/users will skip TLS verification ("just make it work") making for a dangerous precedent. Companies want to protect their data? Well, just protect it! Least privilege, data minimization, etc is all good strategies for avoiding data leaking
Got acquired by a Fortune 500 and recieved new laptop. First hour I'm seeing TLS errors everywhere except the browser.
They'd half-baked their internal CA rollout, so wasn't trusted properly.
By day two I started validating their setup. The CA literally had a typo in the company name, not a great sign.
A quick check with badssl.com showed that any self-signed(!) cert was being transparently MITM'ed and re-signed by their trusted corporate cert. Took them 40 days to fix it.
Another fun side-effect of this is that devs will just turned off TLS verification, so their codebase is full of `curl -k`, `verify_mode = VERIFY_NONE`, `ServerCertificateValidationCallback = () => true`, ... Exactly the thing you want to see at a big fintech company /s
Note that this requires an authenticated user, so most redis installations are not directly at risk.
The github issue has these workarounds:
> An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.
I guess most people doesn't use the lua engine, so this is probably a good advice to disable even if upgrading to a non-vuln version of Redis.