TLS Fingerprint Pinning Needed [ex: for NFS-over-TLS client]

grarpamp grarpamp at
Sat Mar 21 16:54:50 UTC 2020

People appear to be talking about using and
"authenticating / verifying" TLS certs now with at least
perhaps this NFS, and certainly with other apps.

If so, it's required critical thing for the admins and users to have
the option to pin the certificate pubkey fingerprints in four ways...

- Ignore the CA chain / expiry / etc, validate only the fingerprint.
- Validate the CA chain / expiry / etc, and validate the fingerprint.
- Validate the CA chain / expiry / etc, ignore the fingeprint.
- A TOFU mode.

No application that uses TLS should be considered completely
featured and security capable without fingerprint pinning functions.

For some background reasons on why --pinnedpublickey <sha256//b64hash>
implementations are now showing up in softwares that speak TLS,
and for sample code, and related infos, see the links...
--pinnedpubkey <hashes | file>
Tells curl to use the specified public key file (or hashes) to verify the
peer. This can be a path to a file which contains a single public key in PEM
or DER format, or any number of base64 encoded sha256 hashes preceded by
'sha256//' and separated by ';'
When negotiating a TLS or SSL connection, the server sends a certificate
indicating its identity. A public key is extracted from this certificate and
if it does not exactly match the public key provided to this option, curl will
abort the connection before sending or receiving any data.

Please note this option is rightly more specific covering only the
isolated pubkey, not the DER form of the entire "CA signed" cert
(ie: not the typically referenced coverage of "openssl x509 -fingerprint").

When fully implemented, this enables a local admin and user environment
of more flexible certificate validation service cababilities and security model
hardening when subject to various third party things and adversaries like...

- Environment of rogue / forced / spy MITM CA's, TLS termination / proxy
cloud MITM, VPN / overlay / WiFi networks MITM, etc.
- Annoying "expired" certs awaiting tax revenue from their captured audience.
- Assigning pinned trust to intermediate CA's such as Lets Encrypt, Google,
and corporate schemes, to let edge server certs they sign be freely
rotated and or freshly signed without need to update pin.
- Avoid need to update pin every "expiry" period.
- Avoid CA's by using cert owners publicly available and out of band self
certification attestations found on keybase, social, observatories, PGP, etc.
- As mentioned above, optionally in combination with other CA / expiry / etc
checks, or ignoring the CA altogether.
- CRL checks are a massive metadata privacy and user monetization
leak that some users might not want exposed to.
- Pinning one or both of: pubkey (herein) and or CA (openssl x509 -fingerprint)

Another very useful security feature to have is a trust on first use TOFU
mode that stores, pins, and subsequently validates against those fingerprints,
similar to SSH model. This is useful for both known comms partners such as
client-server model, and in more distributed group or even p2p applications
to help keep things a bit more locked down by default.

Defense (like this pubkey pinning) in depth... you can use it :)

References (obviously TLS_1.3 is todays version to use)...

More information about the freebsd-current mailing list