gokrazy
mtls : mutual tls authentication
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.
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.
