fetchmail-users

[Fetchmail-users] Constantly changing ssl fingerprints

[Jerry <je...@se...>]

I do not know if there is an easy way around this problem, so I thought I
would simply ask for assistance.

I have several users here that use Google's "gmail". Google has been changing
their SSL certificate on a nearly monthly basis. This causes havoc with our
mail system.

Fetchmail is configured to fetch mail from 11 different "gmail" accounts. Each
account has a different "user name" and "password". The config line in the
global fetchmailrc file read like this:

user 'us...@gm...' there with password 'SECRET' options forcecr dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'

Every time Google changes certs, I have to get their new fingerprint and
change it on all of the gmail accounts. Fetchmail does not send a notice to
the user that SSL has failed. Therefore, it is sometimes a day or two before
anyone actually knows it has happened. That is rare though. Most of the time
they realize it after not receiving any mail for 24 hours.

My question are:

1) Is it possible to configure fetchmail to send an error notice to the user
immediately if an ssl error has occurred?

2) How else could I configure fetchmail to simply not check the fingerprint?

I did notice that "fetchmailconf" will print out the new fingerprint when
used to access gmail. Is there a way to have fetchmail send that to the user.
I currently use openssl to download the certs and extract the fingerprint.

By the way, I use fetchmail > Postfix > Dovecot. I have never been able to
get fetchmail > Dovecot without using Postfix as the intermediary.

I am open to any suggestions?

-- 
Jerry

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Gene H. <ghe...@wd...>]

On Sunday 25 January 2015 08:48:28 Jerry did opine
And Gene did reply:
> I do not know if there is an easy way around this problem, so I thought
> I would simply ask for assistance.
> 
> I have several users here that use Google's "gmail". Google has been
> changing their SSL certificate on a nearly monthly basis. This causes
> havoc with our mail system.
> 
> Fetchmail is configured to fetch mail from 11 different "gmail"
> accounts. Each account has a different "user name" and "password". The
> config line in the global fetchmailrc file read like this:
> 
> user 'us...@gm...' there with password 'SECRET' options forcecr
> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> 
> Every time Google changes certs, I have to get their new fingerprint
> and change it on all of the gmail accounts. Fetchmail does not send a
> notice to the user that SSL has failed. Therefore, it is sometimes a
> day or two before anyone actually knows it has happened. That is rare
> though. Most of the time they realize it after not receiving any mail
> for 24 hours.
> 
> My question are:
> 
> 1) Is it possible to configure fetchmail to send an error notice to the
> user immediately if an ssl error has occurred?
> 
> 2) How else could I configure fetchmail to simply not check the
> fingerprint?
> 
> I did notice that "fetchmailconf" will print out the new fingerprint
> when used to access gmail. Is there a way to have fetchmail send that
> to the user. I currently use openssl to download the certs and extract
> the fingerprint.
> 
> By the way, I use fetchmail > Postfix > Dovecot. I have never been able
> to get fetchmail > Dovecot without using Postfix as the intermediary.
> 
> I am open to any suggestions?

This is a new bit of news to me as I have fetchmail scanning a very little 
used account at gmail, one my ISP farmed out to gmail when they disco'd 
their own mail server about 2 years ago, and it is not logging any 
failures.  OTOH I do not use it except as a pop3 fetcher, feeding procmail 
which runs it thru SA and clamav. Those accounts do have the  line "ssl" 
in their stanza.

I did have a 2nd, real gmail account, but it died, presumably from their 
dance with ssl, and since I haven't actually used it for a list 
subscribing address for several years, I just turned off the poll stanza 
as I couldn't care less if they save 50Gb of spam in an account I can't 
access.

But on a reread of the man page for fetchmail, I see no mention of a way 
to make such a failure verbose enough in the logs that it leaves a failure 
hint there.  Perhaps it needs to "grow" such a reporting option?

Or, if as you state, fetchmailconf can fetch the missing fingerprints, 
then obviously the code to do so exists, why not transfer it to fetchmail 
with a daemon option to enable it?

That way, the fix could be automated.  It would be nice if the 
"postmaster" got a message that the new fingerprint fetch was done though.
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Jerry <je...@se...>]

On Sun, 25 Jan 2015 11:40:50 -0500, Gene Heskett stated:

> On Sunday 25 January 2015 08:48:28 Jerry did opine
> And Gene did reply:
> > I do not know if there is an easy way around this problem, so I thought
> > I would simply ask for assistance.
> > 
> > I have several users here that use Google's "gmail". Google has been
> > changing their SSL certificate on a nearly monthly basis. This causes
> > havoc with our mail system.
> > 
> > Fetchmail is configured to fetch mail from 11 different "gmail"
> > accounts. Each account has a different "user name" and "password". The
> > config line in the global fetchmailrc file read like this:
> > 
> > user 'us...@gm...' there with password 'SECRET' options forcecr
> > dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> > sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> > 
> > Every time Google changes certs, I have to get their new fingerprint
> > and change it on all of the gmail accounts. Fetchmail does not send a
> > notice to the user that SSL has failed. Therefore, it is sometimes a
> > day or two before anyone actually knows it has happened. That is rare
> > though. Most of the time they realize it after not receiving any mail
> > for 24 hours.
> > 
> > My question are:
> > 
> > 1) Is it possible to configure fetchmail to send an error notice to the
> > user immediately if an ssl error has occurred?
> > 
> > 2) How else could I configure fetchmail to simply not check the
> > fingerprint?
> > 
> > I did notice that "fetchmailconf" will print out the new fingerprint
> > when used to access gmail. Is there a way to have fetchmail send that
> > to the user. I currently use openssl to download the certs and extract
> > the fingerprint.
> > 
> > By the way, I use fetchmail > Postfix > Dovecot. I have never been able
> > to get fetchmail > Dovecot without using Postfix as the intermediary.
> > 
> > I am open to any suggestions?

> But on a reread of the man page for fetchmail, I see no mention of a way 
> to make such a failure verbose enough in the logs that it leaves a failure 
> hint there.  Perhaps it needs to "grow" such a reporting option?

Fetchmail leaves this error message in the logs:

fetchmail: pop.gmail.com fingerprints do not match!
fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from us...@gm...@pop.gmail.com
fetchmail: Query status=2 (SOCKET)

-- 
Jerry

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Gene H. <ghe...@wd...>]

On Sunday 25 January 2015 12:22:58 Jerry did opine
And Gene did reply:
> On Sun, 25 Jan 2015 11:40:50 -0500, Gene Heskett stated:
> > On Sunday 25 January 2015 08:48:28 Jerry did opine
> > 
> > And Gene did reply:
> > > I do not know if there is an easy way around this problem, so I
> > > thought I would simply ask for assistance.
> > > 
> > > I have several users here that use Google's "gmail". Google has
> > > been changing their SSL certificate on a nearly monthly basis.
> > > This causes havoc with our mail system.
> > > 
> > > Fetchmail is configured to fetch mail from 11 different "gmail"
> > > accounts. Each account has a different "user name" and "password".
> > > The config line in the global fetchmailrc file read like this:
> > > 
> > > user 'us...@gm...' there with password 'SECRET' options forcecr
> > > dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> > > sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> > > 
> > > Every time Google changes certs, I have to get their new
> > > fingerprint and change it on all of the gmail accounts. Fetchmail
> > > does not send a notice to the user that SSL has failed. Therefore,
> > > it is sometimes a day or two before anyone actually knows it has
> > > happened. That is rare though. Most of the time they realize it
> > > after not receiving any mail for 24 hours.
> > > 
> > > My question are:
> > > 
> > > 1) Is it possible to configure fetchmail to send an error notice to
> > > the user immediately if an ssl error has occurred?
> > > 
> > > 2) How else could I configure fetchmail to simply not check the
> > > fingerprint?
> > > 
> > > I did notice that "fetchmailconf" will print out the new
> > > fingerprint when used to access gmail. Is there a way to have
> > > fetchmail send that to the user. I currently use openssl to
> > > download the certs and extract the fingerprint.
> > > 
> > > By the way, I use fetchmail > Postfix > Dovecot. I have never been
> > > able to get fetchmail > Dovecot without using Postfix as the
> > > intermediary.
> > > 
> > > I am open to any suggestions?
> > 
> > But on a reread of the man page for fetchmail, I see no mention of a
> > way to make such a failure verbose enough in the logs that it leaves
> > a failure hint there.  Perhaps it needs to "grow" such a reporting
> > option?
> 
> Fetchmail leaves this error message in the logs:
> 
> fetchmail: pop.gmail.com fingerprints do not match!
> fetchmail: OpenSSL reported: error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from
> us...@gm...@pop.gmail.com fetchmail: Query status=2 (SOCKET)

That is very similar to what I saw at the time. Then it went away for a 
couple weeks then came back and I just quit polling it. I'd long since 
moved all my mailing lists subs off it, mainly due to their duplicate 
policy.  Its not open for discussion, I tried. So I just moved everything 
back to my lifetime account on a qmail server at the tv station.  Lots 
more spam but hey, it also Just Works(TM).

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Martin K. <mk...@gm...>]

Hi Jerry,

>>>> I have several users here that use Google's "gmail". Google has
>>>> been changing their SSL certificate on a nearly monthly basis.
>>>> This causes havoc with our mail system.
>>>>
>>>> Fetchmail is configured to fetch mail from 11 different "gmail"
>>>> accounts. Each account has a different "user name" and "password".
>>>> The config line in the global fetchmailrc file read like this:
>>>>
>>>> user 'us...@gm...' there with password 'SECRET' options forcecr
>>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
>>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'

why socomplicated? I use this snippet:

defaults:
 	proto pop3 timeout 300 sslproto 'TLS1' ssl
 	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
 	sslcertck
 	limit 50000000 warnings 86400


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

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Carlos E. R. <car...@op...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-01-25 19:48, Martin Koeppe wrote:
> 
> Hi Jerry,

>>>>> user 'us...@gm...' there with password 'SECRET' options forcecr
>>>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
>>>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> 
> why socomplicated? I use this snippet:
> 
> defaults:
>  	proto pop3 timeout 300 sslproto 'TLS1' ssl
>  	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
>  	sslcertck
>  	limit 50000000 warnings 86400

mine is simpler:

poll imap.gmail.com with interval 0 proto imap timeout 50, and tracepolls
        user G_NAME, with password PASSWORD, is LOCALUSER here, expunge 20, and ssl, and fetchall


I get this typical response:

<2.6> 2015-01-20 16:04:22 Telcontar fetchmail 2433 - -  6.3.26 querying imap.gmail.com (protocol IMAP) at 2015-01-20T16:04:22 CET: poll started
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  Trying to connect to 74.125.71.109/993...connected.
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  Server certificate:
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  Issuer Organization: Google Inc
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  Issuer CommonName: Google Internet Authority G2
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  Subject CommonName: imap.gmail.com
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  Subject Alternative Name: imap.gmail.com
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  imap.gmail.com key fingerprint: CC:06:25:2E:A6:3C:F5:61:DE:BF:25:E2:26:09:7F:0E
<2.6> 2015-01-20 16:04:23 Telcontar fetchmail 2433 - -  IMAP< * OK Gimap ready for requests from ...


I don't have to specify the certificate paths.

- -- 
Cheers / Saludos,

		Carlos E. R.
		(from openSUSE 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlTGZOYACgkQtTMYHG2NR9U7zgCfcvBL1cYSZh7WeZmDUDJk9mg1
LmIAnArNzM3Hzt06fiMG7gzzSHqVdx9O
=JSen
-----END PGP SIGNATURE-----

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

Am 26.01.2015 um 17:01 schrieb Carlos E. R.:

> mine is simpler:
> 
> poll imap.gmail.com [...]

> I don't have to specify the certificate paths.

Yeah, simpler and simply dangerous.  You're not using the "sslcertck"
option.  Meaning that passing certificate checks is not required.
No wonder you don't need to install certificates.  You'd need to read
your logs carefully to learn that something's wrong.

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Jerry <je...@se...>]

On Sun, 25 Jan 2015 19:48:25 +0100 (CET), Martin Koeppe stated:

> 
> Hi Jerry,
> 
> >>>> I have several users here that use Google's "gmail". Google has
> >>>> been changing their SSL certificate on a nearly monthly basis.
> >>>> This causes havoc with our mail system.
> >>>>
> >>>> Fetchmail is configured to fetch mail from 11 different "gmail"
> >>>> accounts. Each account has a different "user name" and "password".
> >>>> The config line in the global fetchmailrc file read like this:
> >>>>
> >>>> user 'us...@gm...' there with password 'SECRET' options forcecr
> >>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
> >>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
> 
> why socomplicated? I use this snippet:
> 
> defaults:
>  	proto pop3 timeout 300 sslproto 'TLS1' ssl
>  	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
>  	sslcertck
>  	limit 50000000 warnings 86400
> 
> 
> 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

That doesn't work here:

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: Broken certification chain at: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from ad...@se...@pop.gmail.com
fetchmail: Query status=2 (SOCKET)

-- 
Jerry

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

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.

> isn't a one-stop solution.  ca-certificates, ca_root_nss are packages
> that Ubuntu and FreeBSD offer.  Some distributions require you to select
> which certificates you want to install into the trust store.

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.

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

FreeBSD bits here.
http://svnweb.freebsd.org/ports/head/security/nss/
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.

Re: [Fetchmail-users] Constantly changing ssl fingerprints

[Martin K. <mk...@gm...>]

Hi Jerry,

On Sun, 25 Jan 2015, Jerry wrote:

> On Sun, 25 Jan 2015 19:48:25 +0100 (CET), Martin Koeppe stated:
>
>>>>>> user 'us...@gm...' there with password 'SECRET' options forcecr
>>>>>> dropdelivered smtpname ssl sslcertpath /usr/local/etc/postfix/certs
>>>>>> sslfingerprint '26:85:9C:DD:04:26:70:C2:20:0A:A0:A2:24:E4:CF:30'
>>
>> why socomplicated? I use this snippet:
>>
>> defaults:
>>  	proto pop3 timeout 300 sslproto 'TLS1' ssl
>>  	sslcertfile /usr/ssl/certs/ca-bundle.trust.crt
>>  	sslcertck
>>  	limit 50000000 warnings 86400
>>
>>
>> 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
>
> That doesn't work here:
>
> fetchmail: Server certificate verification error: unable to get local issuer certificate
> fetchmail: Broken certification chain at: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
> fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
> fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from ad...@se...@pop.gmail.com
> fetchmail: Query status=2 (SOCKET)

seems you have some box on the way to Google which does 
man-in-the-middle. I see the certificate for pop.gmail.com signed from 
"Google Internet Authority G2" (sha1 fingerprint: bb dc e1 3e 9d 53 7a 
52 29 91 5c b1 23 c7 aa b0 a8 55 e7 98)  which in turn is signed by 
"GeoTrust Global CA" (sha1 fingerprint: de 28 f4 a4 ff e5 b9 2f a3 c5 
03 d1 a3 49 a7 f9 96 2a 82 12). No "Equifax" at all.


Martin

Re: [Fetchmail-users] Constantly changing ssl fingerprints

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

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
> 
> That doesn't work here:
> 
> fetchmail: Server certificate verification error: unable to get local issuer certificate
> fetchmail: Broken certification chain at: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
> fetchmail: This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about.  For details, please see the README.SSL-SERVER document that ships with fetchmail.
> fetchmail: This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
> fetchmail: OpenSSL reported: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
> fetchmail: SSL connection failed.
> fetchmail: socket error while fetching from ad...@se...@pop.gmail.com
> fetchmail: Query status=2 (SOCKET)

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.

Many distributions package Mozilla's certificate package for OpenSSL,
but the various distros have various names for the package, so there
isn't a one-stop solution.  ca-certificates, ca_root_nss are packages
that Ubuntu and FreeBSD offer.  Some distributions require you to select
which certificates you want to install into the trust store.

Some info is in <http://www.fetchmail.info/fetchmail-FAQ.html#K5> but I
haven't tried it recently, so I'm not sure if it applies. Let me know if
it does not so that I can revise or remove that.

And you also need up to date versions of fetchmail and OpenSSL. There
used to lurk bugs in older versions of both.

Tell us your distro and version, and chances are that someone knows what
packages you need to install and perhaps configure and responds to the list.

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.

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.