Re: Problem with GMail changing sslfingerprint

Am 18.01.21 um 00:32 schrieb grarpamp:
> "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.

I am not so sure that applications on the whole that use a TLS library
should reinvent all the checks and implement new mechanisms. There is a
specified and established approach, and that is working through the
certificate chain until you find a trust anchor. Traditionally, this
would then be a root CA. In practice, there is a list of 100+ CA
certificates that many applications trust, and this list is curated by
Mozilla as part of the NSS library based on certain policies.

Lots of code is present from the OpenSSL 0.9.Xy releases from aeons ago
that would not perform the typical checks on certificates beyond pure
signature verification, so applications resorted to doing their own
checks on top.
Also, some ten years ago many service providers did not really care
about even providing proper certficate chains, so that applications
hardly ever could really establish trust. This changed when browsers and
GUI-based mailers started verifying SSL chains by default.

I would propose most of this mechanism and default policy actually
belongs into the crypto libraries such as OpenSSL.

LibreSSL has libtls which does some of such heavy lifting, but LibreSSL
itself has issues on its own, especially around TLS v1.3 and
OpenSSL-compatible API, so it's currently not viable.

> 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.
Can you draft a specification on how this should look? fetchmail 7.x
might make that change because effectively most of the code is already
there and we'd rewrite it to look into other places for the sig, and to
make that change clear, rename the options.
> 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.
Pretty much wishful thinking to implement this in an all-too
programmable way. If that makes it harder to explain to users, I don't
think I will want that. And I certainly don't want a fetchmail
configuration to look like Exim concepts or make indirections. fetchmail
needs to be usable by normal users.
> 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.

Text editors have had "search/replace" functions for about as long as I
can remember. Maybe longer. I therefore don't see a need to write
gazillions of lines of a new domain-specific language specification
along with documentation, test suite and whatnot. Would look a bit
overengineered to me.

It might be easier to refactor fetchmailconf into a configuration
parsing/writing module under a new name and the GUI module unter
fetchmailconf name that uses the former so you can programmatically
read/modify configurations.