Using mutual tls in place of api keys

Using mutual tls in place of api keys

1. Not sure if related, but the Gemini protocol makes use of TLS certificates to handle authentication.

   1. Thank you!

2. metadaemon

   edited 1 hour ago

   | link

   We had a pretty massively distributed network of clients speaking with a subset of APIs. We did a somewhat quick and dirty version of this because it was entirely in-network and Java removed anonymous ciphers by default. On startup, each API would create and sign its own certificate which would then be used for communication between client and API.

   This doesn’t solve the mutual problem, as clients themselves aren’t “trusted”. but it may give you some ideas for implementation if cost is a concern.

   I also did look a bit into the Noise Protocol as an alternative to TLS, but went with the above approach due to time constraints.

3. owen

   1 hour ago

   | link

   My work does this at scale today!

   In general, that’s pretty much how it works. We have a long-lived root in a vault that signs multiple leaf certs. The current leaf is in an environment that has some automation to sign client certificates. I think we run a OCSP responder to handle revocations, not positive, but we terminate most of those connections at a single box so it’s not a huge deal either way.

   The biggest downside is teaching people on the other end how to use it. The tooling/dev experience around mTLS/client-certificates is not great. We offer both flavors – mTLS & API keys – and are finding API keys are the most preferred solution.

4. symgryph

   56 minutes ago

   | link

   I would recommend looking at some kind of a acme protocol. This would enable automated certificates from both sides. There’s some very nice stuff that does this from the stepca folks. I made a very nice raspberry pie certificate server with random number generator for well under $100. You can do this on both ends and have a certified b and b certify a and would automatically do it for you.

   1. Unfortunately, I don’t believe ACME supports doing client certs. A server cert can be automated because the domain is the Common Name, but with clients that is almost certainly not the case.

      This sort of thing would be done using an Identity Provider of some kind.

5. colonelpanic

   edited 32 minutes ago

   | link

   (note: for context, my experience with this is entirely service-to-service related. Your question is ambiguous about the specific use-case)

   Cert management, renewal, and revocation is a HARD problem. So I would suggest mTLS only in exceptionally simple use-cases or exceptionally complex cases. But it’s great for those use-cases.

   For very simple cases, you can just run your own CA using something like this guide and essentially manage the certs by hand. This will only really work for a dozen or so services before it becomes really onerous.

   On the other end of the spectrum, we use a service mesh architecture for Kubernetes called Istio that performs this duty. It manages mTLS certs between services so they can talk to each-other and we don’t have to manage any of that ourselves. This works by basically running a sidecar in every namespace that tunnels traffic and transparently manages the mTLS auth for you.

   If you were really ambitious, you could potentially achieve something similar with stunnel deployed with custom mTLS certs, but it would require some Ops magic.

6. I like client certs, but in my experience the physical smart cards (to store the x509 &c) are the weak point of failure. Which reminds me, one of my credit cards’ chips seems to be failing. Doing it wholly-software is also attractive, but I just haven’t done it.

   I’m fine with having 2 cards (1 user + 1 admin), so having backups (or maybe just better hardware) would be great.