A Private pkg Repo Behind Mutual TLS

11 points by 0mp

nickmonad

mTLS is pretty great! It does seem criminally underutilized... I feel like we've all been told to believe certificates are radioactive and should never be touched.

tuxes
+1.

I like how some of the DNS RFCs define using mTLS where you verify just the public key's hash, rather than the usual cert verification (chain, SAN, expiry, etc.), e.g. RFC7858.

I do this for DNS UPDATEs to my authoritative nameserver: mTLS, verifying only the public keys, and it's supported out-the-box with the client and server tools provided by Knot DNS.
```
$ knsupdate -p 853 --tls --pin FHkyLhvI0n70E47cJlRTamTrnYVcsYdjUGbr79CfAVI= --certfile ecdsa_cert.pem --keyfile ecdsa_key.pem
```
That pin flag is the client verifying the server's X509 cert's pubkey's hash (the "pin"). Knot DNS self-signed the cert and just provide you with the pin. (You can of course provide it a cert/key that is signed by a CA, if you prefer).

On the server side, Knot DNS's ACL has a cert-key field for allowlisting particular client public keys.

This gives the ease of SSH/Wireguard-style key distribution, without caring about the other fields in the cert.
kev009

Most computing professionals can't handle basic cryptography administration. The only reason HTTPS generally works is the OS/browser manage the trust store.
- tuxes
  Similar convenience is coming to mTLS too: https://spiffe.io/
  
  The idea is that your environment (your service orchestrator, your CI, your OS, ...) issues your jobs with X.509 (or JWT) credentials to authenticate against external services.
  
  The typical implementation of "CI job with privileges" is:
  
  I generate the CI job's credentials.
  
  I configure the server to accept those credentials.
  
  I upload credentials to CI.
  
  I configure CI job to use those credentials.
  
  This works, but has limitations:
  
  It has many steps!
  
  The credentials are often long lived.
  
  The credentials are often symmetric, i.e. harder to securely distribute.
  
  Each external service potentially requires separate credentials, and different authentication mechanisms (Basic Auth, JWT, X.509, SSH, AWS signatures, OCI signatures, ...)
  
  With SPIFFE, my CI server will issue my CI job with credentials, e.g. a cert signed by codeberg.org with identity "tuxes/my-cool-project"
  
  The steps becomes:
  
  Configure server to accept those credentials (i.e. my server will allow certs signed by codeberg.org for tuxes/my-cool-project).
  
  Configure CI job to use those credentials to authenticate to the server.
  
  Success!
  
  Fewer steps.
  
  Short lived credentials: they need only last for the job's duration.
  
  Asymmetric, i.e. you can avoid handling key material. It even be isolated in HSMs.
  
  With network effects, clients/servers will get native support for X.509/JWT meaning the few remaining steps are trivial. Clients could even auto-discover the credentials.
  
  At first glance it looks odd to have my server trust certs signed by codeberg.org, but the trust story is no different: my CI already knows the secrets in either case. De facto, I trust the CI server.
  
  Of course, you can always use the existing method, or even use the SPIFFE creds to exchange for your preferred creds (and the trust story is no different).