Re: [Fetchmail-users] Problem with GMail changing sslfingerprint

[grarpamp <gra...@gm...>]

"gmail pop3 settings" / account lockouts / download gaps,
are unrelated to TLS fingerprint changes, TLS checking comes
before providers ever see an account name to abuse like that.



Many services, including some from google, and every service
using LetsEncrypt puts new sigs over their certs every n months.
This forces security conscious and auto-MITM resistant
users to waste time validating and updating fingerprints when
no part of the underlying security context actually changed...

In many services doing this sig rotation model,
the underlying TLS pubkey does not change since
the key itself was never actually compromised yet,
nor was the cert swapped out for a new privkey, but
was just sig "expiring", which is bogus and dating back to
days of revenue $cam forced on services by CA's model.

Fetchmail needs to support the
--pinnedpubkey sha256//...
option of curl(1), it was posted here earlier.

It will solve many users fingerprint pinning editing pain
they experience with some services.

See the curl docs for how to print the pubkey fingerprint hash
that would eventually put in a fetchmail conf.

For interim use,
users could post a simple few line patch that would convert the
existing DER pin check in the code into a pubkey pin check.


That is for service endpoint certs that keep pubkey but update sigs.


For endpoints that are actually swapping out the entire cert/privkey...

Fetchmail would want to allow specifying fingerprint hashes,
either of pubkey, or of entire DER cert with sig, interchangably
as users desire, for each cert in the entire path from root,
down to whichever last intermediate cert is deemed static
enough by the user. This way you pin down to there, and
allow the service endpoint certificate to swap, provided it
still matches the "cert chain" checks (if configured to check
that, which you always should). Part of this can be done
with cert files, yet manual fingerprint can be useful to assure
override of untrustable system ca cert bundle/update interactions,
or to just avoid files entirely and update just one/few line hash config.

If fetchmail gets a modular labeled config for 7.x, that will make
abstracting and then constructing together the component
selections from among users, servers, protocols, cert chains, polls,
mda's, etc... into easier more flexible and even hierarchical usage contexts.

For example, users/systems/companies with multiple accounts
at an upstream service would only have to update one modular
TLS fingerprint pinning line, not per each account/employee/etc.