Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

Am 26.01.2015 um 07:18 schrieb grarpamp:
> On Sun, Jan 25, 2015 at 7:58 PM, Matthias Andree <mat...@gm...> wrote:
>> Am 25.01.2015 um 22:23 schrieb Jerry:
>>
>>>> As pop.google.com has an "official" certificate, there is no need for
>>>> a fingerprint check. Just let fetchmail know your root ca certs. I
>>>> only use sslfingerprint for self-signed certs, as an override where
>>>> root ca cert verification fails. You don't seem to use sslcertck, but
>>>> better you should.
>>
>> Martin's proposal is the same I'd have made:
>> 1. add sslcertck
>> 2. remove sslfingerprint + the hash.
>>
>> You need the root certificates installed locally.
> 
> Yes Google has their own intermediate CA. So if you put the
> full path of CA's just short of the server cert in the file that
> should prevent user from being annoyed at having to change
> prints all the time. I don't think fetchmail has an OSCP
> checking option yet. For that and other reasons I've covered
> previously, just know that prints do serve real security purposes
> that you cannot achieve with CA checking.

Fetchmail will probably not grow an OSCP option yet - most browser
vendors that played with it quickly found out it's a non-starter because
it limits availability.  Too many sites running broken OSCP servers, or
forgetting to run or check on them...

Either you dumb OSCP checking down and treat "not reachable" (in the
broadest sense) as "permit", which opens you up to using b0rked
certificates if some attacker DDoS'es the OSCP server out of the
network, or you treat "not reachable" (in the broadest sense) as fatal
failure, which then causes connection refusal.

I experimented with OSCP checking myself a bit, and quickly found out
many sites aren't up to the task.

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

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.  There has been too much abuse with self-signed certs being
stuffed in the root; "abuse" meaning that people have been downloading
the certificate over the same channel because some web sites instructed
them to do so without giving proper security considerations.  Or
encouraged people to believe they weren't under MITM attacks while they
were downloading the certificates.

> Didn't know about thise selction. Figured OS just dumped them
> all in. For non browsing use, it's easy enough to cherry pick
> only the CA's you need to support your mail service rather
> than exposing yourself all the CA's.

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

This also only works with recent fetchmail versions.

>> And you also need up to date versions of fetchmail and OpenSSL.
> 
> You may wish to try out fetchmail 7.x, it's TLS and other
> designs are being updated and coming along perhaps to
> another beta/release in a while.

I propose that unexperienced users stay away from alphas.
I am in the process of getting a 6.4 version out with only a few TLS
revisions but not the other rummaging as a stop-gap release.  Once that
is released, I will discontinue 6.3 altogether.  This shifts some
support burden on the distribution, because - as usual - the reply on
the lists will be "use the latest formal release if you want support
from the fetchmail list".

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

This URL above isn't used for/by fetchmail. The two below may be useful,
however.

> http://svnweb.freebsd.org/ports/head/security/ca_root_nss/
> http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/ca_root_nss-3.17.3_1.txz
> 
> Or you can use the Mozilla + parser links I've previously posted.