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

[Matthias A. <mat...@gm...>]

Am 06.02.20 um 03:07 schrieb grarpamp:
> 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.

grarpamp,

I need to say that very bluntly, posts like these are becoming annoying.

We don't change established option names and break everyone's
configuration in minor releases.

> 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.

So you're going to teach Aunt Tillie how to do that for each and every
service she uses, and also support her via this list? Unless you're
committed to getting things practical, none of this is going to happen.
And this includes telling them to watch all the typical suspect places
for changes, and watch canaries if the service posts one, and what not.

And what prevents a state order ...

> 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...

...from telling them to tee out the decrypted traffic behind the
certificate, or just the mail, and at the same time forcing them to STFU
and not tell anyone.

I see no difference to state orders forcing the mail service to reveal
unencrypted information. If you'll want really secure communication,
you're not going to achieve that with e-mail via SMTP/IMAP/POP3, but
you'll need to set up quite a different system.

> 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.

This is implying that Mozilla (who are normally the source for the trust
lists) were shipping trust recommendations for "completely untrustable"
CAs. I think they have removed CAs that were involved in scandals such
as issuing wildcard trusts or other betrayals.

> 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.
Oh they do serve a purpose, and that's permitting delegating server
authentication.
> 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.
Those that mess with certificates, will, too.
> 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.
Which is, in current fetchmail versions 6.4.x, is rather an argument to
not use the MD5 fingerprint but instead use stronger certification.
> 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,
...alleviating the need to keep huge CRLs.
> Fetchmail's TLS fingerprint check fails upon every new CA sig.

Which is its very purpose. Nobody claims X.509 certificate
fingerprinting were particularly practical, and historically you'd find
tons of instructions on The Net that would describe how to manually
implement something like TOFU or manual certificate pinning, and I don't
ever recall those documents telling people how to validate the
fingerprints *in practice.

And cURL's option and instructions "PUBLIC KEY EXTRACTION" here

> https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html
> --pinnedpubkey <hashes|file>

IMPLICITLY follows an INSECURE!!! trust-on-first-use setting so is
actually just as useful or useless as --sslfingerprint (assuming I were
to implement SHA256/384/512 and other hashes), I don't see how that's
more secure.

The priority with the 6.4 release was getting TLS 1.1/1.2/1.3 support
out, and disentangling "talk-TLS-right-away" vs. STARTTLS schemes from
the protocol version. Also the recommendations (use STARTTLS to preserve
the IANA port vs. preferring talk-TLS-directly services) have changed
over time.

Adding more features and testing those (for the ancient system that 6.4
is to support) would have deferred that release even longer, which
wasn't an option.

>> 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.
> Users should always choose TLS wherever possible instead of
> any sort of plaintext. And pin TLS to 1.3 or latest possible.

In the past we haven't cared too much if TLS was negotiated over the
separate port directly or in-band after STARTTLS, but you might want to
lobby all the mail service providers to actually upgrade their TLS stuff
to be v1.3 capable.

None of this fixes any problem inherent with e-mail being transmitted
and/or stored in plain text somewhere, somehow, even if the fetching
channel is secured, the transmission channel often only has
opportunistic TLS.

If you need really secure communications, e-mail certainly isn't going
to provide that, look elsewhere, and I have yet to see a proper argument
why and where fetchmail alone were the weak link of the chain and could
fix that. You're arguing about attaining perfection and perfect security
on the final link between MSP and user, but that seems out of
perspective for the mail transmission chain between the sender and the
fetchmail user as a whole system.


The only take-home message from your lengthy post for me was a plea to
add SHA256 and stronger hashes for fingerprinting and/or comparing the
entire public key. Which in itself wasn't a new request, it only
couldn't make 6.4 - that release branch had to be cut somewhere.