I wish there was an easy way to do mutual TLS auth with pre-shared keys that can be stored and copy/pasted just like normal passwords or API keys without having to maintain a CA and handle certificate issuing & renewal (sure, technically forever-lived certificates aren't as secure, but even those would already be a major upgrade compared to the status quo).
I personally use cert-manager to run the CA, then create a cert for each app and have k8s inject it. It is more manual than a service mesh, but many applications support this strategy out of the box. (I will say that creating a certificate resource is a lot easier than the old days of some directory of shell scripts acting as your CA, though. And the same code manages my letsencrypt certs.)
For example, I have Grafana backed by Postgres, and they both understand this authentication scheme out of the box. Postgres is happy to be provided with a cert to present to connecting applications, and is happy to check the cert that applications present against the CA cert.
The main problem with my setup is that I use a ClusterIssuer CA, so really anyone in the cluster can get a valid certificate. This is not amazingly secure and things like Istio do a bit more provenance checking of the application before issuing a cert, which I like. But this is simple, and does protect against the attack this article covers -- as long as you don't go out of your way to present the application's cert when proxying a connection. (Which is probably an easy mistake to make, so be careful.)
Shameless plug (I really did not intend to promote this yet but it can help so figured I'd mention it in case you are interested), but if you are using Kubernetes you could get pretty darn close with MeTaLS[1]. Generate self-signed certs that last for 10 or more years and copy/paste them into environment variables for your service, and you've got it. Of course I don't recommend that as it's not as secure as doing things "the right" way but it's definitely better than no mTLS at all (as you pointed out).
MeTaLS won't provide you with client-related stuff, but most clients and client libs make it easy to set a certificate/key with a request.
Huh? TLS has PSK ciphers. They're popular in low-power IoT devices, because even ecc crypto is rather expensive, compared to e.g. AES.
I'm not sure if any of the PSK modes manage to work with perfect forward secrecy though. Otherwise, leaking the PSK would also allow decrypting any previously-sniffed traffic.
