Re: [fetchmail-devel] Assorted minor bugs

[Matthias A. <ma...@dt...>]

Brian Candler <B.C...@po...> writes:

> There's some more detailled output at
> http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008516.html
>
> Basically, each verify callback operation causes this warning to be shown,
> and with fetchmail -v you get this in addition to the other verification
> warning associated with that callback. So with fetchmail -v I get (snipped a
> little):
>
> fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
> fetchmail: Warning: server certificate verification: unable to get local issuer certificate
> fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
> fetchmail: Warning: server certificate verification: certificate not trusted
> fetchmail: Server CommonName mismatch: webmail.example.com != pop3.example.com
> fetchmail: Warning: server certificate verification: unable to verify the first certificate
>
> That's with 6.2.5, I've not tried your snapshot yet.
>
> Now, if I run fetchmail without -v, then the intervening verification errors
> are not shown, so I just see the CN mismatch errors three times. Perhaps you
> only see them once because you have root certs installed in the correct
> places, or maybe it's a difference in our versions of openssl.
>
>> Anyways, I would not want to limit this warning to verbose
>> or strict mode or similar, it's an important information and needs to be
>> printed unconditionally.
>
> Well, I disagree that this information is any more important than
> "certificate not trusted" or "unable to verify signature" or the various
> other errors that only fetchmail -v or fetchmail sslcertck will show.
>
> In particular: fetchmail (without -v) will not generate any warning for a
> self-signed certificate where the CN is correct. However, if you have a
> valid signed certificate from a known CA, but the hostname does not match,
> you get the warning (three times in my case).
>
> Both are violations of the SSL trust model. In the latter case, you know
> that the server admin did at least manage to persuade a known and trusted CA
> to sign a certificate, albeit for a different hostname. Whereas, in the
> first case you could be the subject of a man-in-the-middle attack, and you
> get no warning at all.
>
> That's why my preferred solution was to silence this message without -v or
> sslcertck: because more serious messages are already silenced.

I see you have some understanding of the SSL certificate/trust model and
verification process.

May I ask you to come up with a small patch that fixes _all_ violations
of the trust model in a first round, so that we _unconditionally_ print
all warnings, self-signed certificates, common name mismatches and so
on. These _are_ important warnings, if they are shown only in verbose
mode, that is a serious bug. For this first round, all problems should
always print a warning regardless of verbosity or logging
settings. sslcertck should make any validation failure an error that
aborts the connection to that server and skips to the next.

A second step (longer-term than the next release), i. e. after the next
official release, should then make strict checking the default and offer
the user options to relax checking for the case when the configuration
(client or server) cannot be fixed on short notice.

The whole point of SSL is avoiding the credentials to be revealed to
anything but the "real" server, and lax checks that do not prevent MITM
attacks defeat the whole purpose of SSL. I'd think creating a false
sense of security is worse than not offering security.

-- 
Matthias Andree