[request] public key fingerprint option for TLS trust

[matineeschwarz]

Cert checksum changes all the time when renewing. A feature to trust public key checksum will be good to enable "pinning" when CSR is re-signed without lose trust.

Maybe this can combine for 2068 as a new function which only use SHA256 checksum for trustet public keys.

[sjaeckel]

I doubt that's a good idea.

The concept of a PKI is established for exactly that reason. You usually trust a CA which issues a certificate and not the leaf certificate itself.

Also I'm not aware on an established way to only hash those parts of a certificate, which don't change when renewing. Feel free to educate me.

I would suggest that you simply trust the CA that issues the certificate and if you can't or don't want to add that one to your system trust, there's the /tls certpath option which allows you to setup a custom certificate path. [0] explains how the files in such a certificate path must be set up, in order to make it work.

Could that be a solution to your problem?

[0] https://docs.openssl.org/master/man3/SSL_CTX_load_verify_locations/#notes

[matineeschwarz]

I doubt that's a good idea.

The concept of a PKI is established for exactly that reason. You usually trust a CA which issues a certificate and not the leaf certificate itself.

Also I'm not aware on an established way to only hash those parts of a certificate, which don't change when renewing. Feel free to educate me.

I would suggest that you simply trust the CA that issues the certificate and if you can't or don't want to add that one to your system trust, there's the /tls certpath option which allows you to setup a custom certificate path. [0] explains how the files in such a certificate path must be set up, in order to make it work.

Could that be a solution to your problem?

[0] https://docs.openssl.org/master/man3/SSL_CTX_load_verify_locations/#notes

I know it's a good idea.

Pinning public key is the only practical solution to protect against rogue certificate. It is not possible to blindly trust a public CA because the network path can be interceptet to issue new cert at same public CA, with no intrusion in the host being necessary. [1]

Nominally only the provider control the private key, and is able to make new or re-use old CSR, without public key fingerprint ever changing. Private key (and extended by public key) is a immutable trust anchor in a PKI. It solve the problem and associated risk from certificate fingerprint always is in flux, no matter if provider makes new cert or MITM attacker makes a cert.

In my perspective a homegrown CA is not ideal because many mistakes can be made during inception of the root/intermediate/leaf, and is impractical for end-user to install CA cert and more. Fingerprint trust can be accomplished with single command.

I will help research libssl functions to see if there is a way to look at public key in the handshake phase.

[1] https://notes.valdikss.org.ru/jabber.ru-mitm/

(p.s. remember DANE/TLSA cover all aspect of certificate and key, with public key fingerprint being first class citizen, but AFAICT Profanity don't support DANE verification)

[sjaeckel]

OK, but that's something different from your initial proposal, at least as I understood it.

This should/must go in libstrophe first and can then be integrated in profanity.