Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

On Mon, Jan 26, 2015 at 4:12 AM, Matthias Andree <mat...@gm...> wrote:
> vendors that played with it quickly found out it's a non-starter because
> ...
> Either you dumb OSCP checking down  [...]
> ...
> many sites aren't up to the task.

User should set their pref for the offline situation though.
I'd treat OSCP, and the various observatory projects/plugins,
as just another indication that something's wrong. ie: What if
server cert is pinned, and user know for a fact that their path and
dns to it is good etc, but for some reason the issuing CA has
CRL/OSCP'd it. User would end up still using it unaware if they
didn't see that.

Another recollection is OSCP seems done by TLS library,
so Tor users have to wrap that too. And it lets another third
party, the CA's, know what domains you're surfing.

I'd think OSCP/observatories would add some benefit to the
certchk and fingerprint. But true they don't seem production/widespread
ready just yet. Maybe a couple more years to sort out the
winners.

> Certificate pinning, and allowing to list multiple fingerprints, are
> options I am willing to allow for experimenting.

Thought I saw multiple cert in 7.x already, or maybe it was multiple
as in sha1/sha256/..., I need to go look as both had come up
earlier. I guess both multiple cert (load balancing and cert rollout)
and multiple hashes (or just better ones than broken md5 and
somewhat iffy sha1) have their place.

> Regarding listing intermediate CAs I am trying to find ways to avoid
> them being listed as trust roots, and for some sites, stuffing an
> intermediate CA into the trust store fails if the actual root is
> missing.

I think this happens because the library expects to be able
to verify all the way back to level 0 (root). Don't think I've seen
a library that would configurably stop short upon hitting some
nth level good intermediate. (I could have mixed this up, long day.)

> encouraged people to believe they weren't under MITM attacks while they
> were downloading the certificates.

Things like VPN's and Tor can actually help with this as
they give access to different views from which you can form
a consensus.

> True, best to just concatenate the desired root certificates to a PEM
> (cat root1.pem root2.pem >fetchmail-trusted.pem) and then use
> --sslcertfile fetchmail-trusted.pem to point fetchmail to it (note this
> must be in the defaults section of the rcfile, or on the command line,
> or it must be repeated for each and every poll statement, or skip
> statements where you give servers on the command line).

I think part of this relates to the thread about separating out
the config bits... servers, users, polling... all separate things.
Then flexibly strung together as needed. I hope to revisit that
draft for completeness.

> the lists will be "use the latest formal release if you want support
> from the fetchmail list".

It's a way to encourage keeping current, and not having
to be held back carrying unnecessary legacy. Fetchmail is
simple to update, even by hand.

>> http://svnweb.freebsd.org/ports/head/security/nss/

Listed it for the curious.