Re: [Fetchmail-users] sslfingerprint: needs to match any of multiple listed fingerprints

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

Am 19.02.2017 um 21:45 schrieb grarpamp:
> On Sun, Feb 19, 2017 at 2:36 PM, Matthias Andree <mat...@gm...> wrote:
>> TLS1.2 into a formal release that won't hicc-up the day TLS1.3 appears,
> If the client is speaking 1.2 to a 1.3 capable server that
> still offers 1.2 (or below), is any hiccup expected to happen?
It's rather having the TLS 1.3 bits in place on the assumption that
OpenSSL's API remains in line, and I have written code that works with
OpenSSL's Git master branch as of a few days ago. With what I have, I
can negotiate TLS v1.3 connections to a web server, but am not aware of
any IMAP or POP3 server that talks TLSv1.3 yet.

>> authoritative. Are your ISP faxing their finger prints to you?
> Out of band could happen in relatively unchanging deployments,
> perhaps corporate environments. Also rare would be pgp
> signed cert statements that web of trust back to you.
> I've seen some services that post them on a
> webserver for download, like the CA's do with their roots.
> It's not exactly out of band, but is better than only
> receiving them via each TLS connection itself.
So bottom line it's TOFU = trust-on-first-use, possibly aided by
certificate verification, your manual implementation of certificate
pinning.
> Then you have the cert observatory projects.
None of which is used by fetchmail, and if I need to implement or link a
web browser to fetch that information, (or to log in anywhere, OAuth was
proposed but servers a different purpose), it's rather unlikely to happen.

> Google for example is notorious for server cert churn,
> under three months. However it has it's own long term
> intermediate CA signed by a root, and that int-CA is
> reasonably verifiable. Users could just trust those
> int-CA fingerprints and let all the server certs they sign
> pass as ok, which is what browsers do.
> Don't know if fetchmail supports that mode of checking
> but it would be useful (in sslfingerprint and in cert file).
Fingerprint checking in fetchmail only applies to the server
certificate, not to the intermediate signers' certificates.

You can use fetchmail with an isolated "trusted roots" store (see the
manual page, --sslcertfile, --sslcertpath) if you want to limit what
signers to trust, so that you could only put the intermediate CA if you
don't want to trust the root, and only deal with it as that expires,
usually on the scale of years. The latest 6.4.0 betas may "hide" the
sslcertfile documentation under --nosslcertck due to a forgotten .TP
directive in the manual page, fixed in Git (but upload to sourceforge
doesn't work currently, see Gitlab
<https://gitlab.com/fetchmail/fetchmail/commits/legacy_64> instead).