[Fetchmail-users] TLS fingerprints, and option --pinnedpublickey <sha256//b64hash>

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

On 2/5/20, Matthias Andree <mat...@gm...> wrote:
> Am 05.02.20 um 20:06 schrieb Joe Acquisto-j4:
>> chasing a gmail issue.   The  ssl fingerprint seems to change, seemingly
>> with what IP it happens to connect.
>
> SSL fingerprints are mostly non-workable for those of the big sites that
> use per-host certificates, and fetchmail won't let you list dozens, let
> a lone use a secure hash (it uses MD5).
>
> Be sure to install the Mozilla root certificates (most distributions
> have packages such as ca-certificates or nss_root_ca) that integrate
> with the default OpenSSL configuration such that the certificates can be
> verified automatically, do not use --sslfingerprint, do not use
> --nosslcertck (but do use --sslcertck on 6.3.x) and move on.

Everyone should know it's called TLS now, stop calling SSL or using SSL.

Gmail's fingerprints seem to roll globally all at once,
then remain stable till the next, roughly speaking.

Mail providers tend to be reasonably well known and well run entities,
and all the new privacy startups. Many of them PGP sign their own
TLS fingerprints, post them OOB to twitter, keybase, onions, etc.
Google and some others use intermediate certs that can be loaded.
The web is becoming self authenticating, easily validated, no need
for silly CA's anymore.

CA's have always provided exactly zero benefit to anyone (other than those
who invested stock in the CA fee and spy scam), in deference to well known
TLS fingerprints. Further, the CA's all many 100's of them, are big source of
MITM threat... bogus court orders, govt force, coersion, rogue moles,
exploit, etc...
anyone using the bundles should be afraid... look at all those completely
untrustable CA's. Do not start with a file full of exploits, start with an
empty cacert file and work up to the minimum you need to live.

Root CA's, even the Lets Encrypt, just don't serve much purpose for
services users use... they are only profiteers and nag preventers,
not MITM preventers, not server iron authentication providers, not
compromise detectors, not auditors, etc.

Good service providers will never use a compromised TLS private key,
and by extension they will never seek CA renewal over that public key.
Any service that is stupid about this principle will get publicly bashed.
Everyone knows to regenerate TLS private keys after compromise.
CA expiry is only barely marginally useful as a compromise detection
eyeball during cert swap process.

Fetchmail allows both TLS fingerprint and CA to match,
or either one if one of them is used solo.
Both MD5 and SHA1 are completely broken.

However, due in part to todays more self authenticating world,
users have big maintenance pain with any use of TLS fingerprint
for the non compromised case.

Lets Encrypt forces, (and the holders of intermediate CA's like
Google do,) very frequent renew their expired signatures over the
same old non-compromised TLS public key,
much more frequently than old CA signing periods did.
These pubkey lifetimes tend to be longer than even those periods,
arguably supported by todays ephemeral session keys.

Fetchmail's TLS fingerprint check fails upon every new CA sig.
This makes more needless work for users to update
fingerprints, even though nothing was compromised.

Keep todays TLS fingerprint option over the entire
CA signed DER form.

Reduce users work (and dependency on pointless CAs),
by adding support for fingerprint of public key itself.
If can even be used in conjunction with sslcertck and sslfingerprint.

Curl, wget, and others can use this pubkey method, here it is...


https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
--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(s)
provided to this option, curl will abort the connection before sending
or receiving any data.


> I suppose Google's non-SSL port (which would have had to use STARTTLS or
> possibly risked broken clients volunteering their password over
> unencrypted links) is firewalled and blackholes inbound traffic.

In various standards and server talks, STARTTLS seems to finally be
trending to be deprecated, with preference now to mandatory native TLS.

Users should always choose TLS wherever possible instead of
any sort of plaintext. And pin TLS to 1.3 or latest possible.