mtls : mutual tls authentication

[oliverpool]

Hi, to get rid of the credential prompt and "certificate self-signed warning", I was thinking about adding a mutual tls authentication.

The device needs one (or many) cert.pem (public certificate). It will accept all clients which present a certificate signed by this certificate. To connect to it, the client(s) will need such a certificate.

Since a self-signed certificate is already generated for https, a lazy way would be to re-use it, but to authenticate the client.

---

Usage examples:

Disable password-based authentication

gokr-packer -mtls -basic_auth=disabled

When -basic_auth=disabled is given, only mtls requests will be accepted. RequireAndVerifyClientCert of ClientAuthType

Self-signed certificate

gokr-packer -mtls

Implies -tls=self-signed if flag is not present. Otherwise, use the same certificate as -tls

VerifyClientCertIfGiven of ClientAuthType

Custom certificate

gokr-packer -mtls=<path-to-cert-a.pem>,<path-to-cert-b.pem>,<path-to-cert-c.pem>

Request will need to be signed by any of these certificates or be authenticated

VerifyClientCertIfGiven of ClientAuthType

---

I would be willing to make a PR to implement this.

I have a working proof-of-concept with a package with embedded certificates, but before attempting to integrate it into gokrazy, I would like to know your thoughts about this idea.

[stapelberg]

Hey, thanks for filing this issue and sorry for the slow reply.

In general, I don’t mind mutual TLS authentication, but I also don’t think it’s a particularly attractive feature for most cases — https://lobste.rs/s/9f3av9/using_mutual_tls_place_api_keys#c_mx7jbu expresses it quite well when it says:

Cert management, renewal, and revocation is a HARD problem. So I would suggest mTLS only in exceptionally simple use-cases or exceptionally complex cases.

Generally, gokrazy users will fall on the “exceptionally simple” use-case of this spectrum, where I would argue the complexity of MTLS is the biggest concern. We’d need to spend a lot of time and effort on producing a high-quality implementation, documentation, error messages, etc., and then keep all of that maintained indefinitely.

---

Personally, I used to use MTLS, but it was always a pain to keep certificates updated and rolled out to devices. I have had various certificates expire multiple times, and it was always a hassle to deal with the poor error messages and then run a re-newal or re-provision that you barely remember how to do because you only need it once every 3 years or so.

Eventually, I switched to using Tailscale, which also allows for password-less authentication.

Have you given any thought to using Tailscale? https://gokrazy.org/packages/tailscale/ describes the basic setup on gokrazy, but we could improve gokrazy integration for Tailscale use-cases, e.g. by allowing Tailscale auth in addition to Basic auth, and by ensuring Tailscale’s automatic TLS works transparently on gokrazy, thereby addressing both the certificate warning and password prompt UX pain points.