On 12/24/2011 08:54 PM, Timothy Murphy wrote:
> 夜神 岩男 wrote:
>
>>> I'm trying to setup sendmail/dovecot on a new server running CentOS-6
>>> (well, CentOS-6.2 now).
>>> Everything seems to go well, but when I run fetchmail I get this warning:
>>> ------------------------------------
>>> [tim@grover ~]$ fetchmail imap.maths.tcd.ie
>>> fetchmail: Warning: the connection is insecure, continuing anyways.
>>> (Better use --sslcertck!)
>>> ------------------------------------
>>>
>>> If I do add --sslcertck (as suggested) I get the response:
>>> ------------------------------------
>>> [tim@grover ~]$ fetchmail --sslcertck imap.maths.tcd.ie
>>> fetchmail: Server certificate verification error: self signed certificate
>>> fetchmail: This means that the root signing certificate (issued for
>>> /C=IE/ST=Dublin/L=Dublin/O=School of Mathematics, Trinity College,
>>> Dublin./OU=Automatically-generated IMAP SSL
>>> key/CN=imap.maths.tcd.ie/emailAddress=postmaster-
> k8gv5eYDmBCYFDSwBDOiMg@xxxxxxxxxxxxxxxx)
>>> is not in the trusted CA certificate locations, 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.
>>> 139925738739528:error:14090086:SSL
>>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
>>> failed:s3_clnt.c:1063:
>>> fetchmail: SSL connection failed.
>>> fetchmail: socket error while fetching from
>>> tim@xxxxxxxxxxxxxxxxx fetchmail: Query
>>> status=2 (SOCKET)
>>> ------------------------------------
>
>> Its just healthier, more detailed warnings that what you got before.
>>
>> SSL/TLS relies on a third party verification of a certificate. This
>> means a third party's signature on the certificate of the site you are
>> connecting to. If, on the other hand, the site you're connecting to
>> signed their own certificate themselves, then you have no way of knowing
>> if they are really themselves because nobody outside of the 2-party
>> connection is validating that the system you're taking to today is the
>> same system you were talking to yesterday.
>
> Thanks very much for your explanation,
> which throws some light on the subject.
>
> What I still find a little puzzling is that
> "fetchmail --sslcertck imap.maths.tcd.ie"
> tells me the SSL connection failed,
> yet "fetchmail imap.maths.tcd.ie" seems to work.
>
> Also, I'm not clear if SSL will look at all the crt's
> in /etc/pki/tls/certs , or just ca-bundle.crt?
>
--sslcertck is a switch that specifically demands certificate checking,
and by strict standards a self-signed certificate is no good. The logic
being that while technically nobody between you and the system you are
directly connecting to can read your traffic, you have no guarantee that
the system you're connecting to is authentic or is an imposter executing
a man-in-the-middle attack. Most attacks involve silently passing
traffic through anyway, so there is no way to arouse the suspicions of
the victims, because they really do connect to their mail account (or
whatever resource) and things function correctly. So --sslcertck is
doing its job, denying you a chance at getting cracked.
On the other hand you'll probably have no trouble connecting using
"fetchmail --ssl imap.maths.tcd.ie" because it merely requires that some
form of SSL connection be used, but doesn't care about authenication
(which is worthless from a security perspective). It also permits a few
other things considered simply not good enough, and should be avoided.
The canonically "correct" way to use this is:
"fetchmail --sslproto 'SSL3' --sslcertck hostname.domain"
This forces tuse of SSL3, as SSL2 isn't considered good enough anymore,
and requires a correct certificate that is signed by a certificate
authority (someone with a root certificate, which can be your
university's systems operator if he knows what he' about).
As far as certs in /etc/pki/tls/certs/ ...
Yes, they are all read. Anything with the extension .crt or .pem (and if
.pem it needs to actually be in pem format, which is not always the
case) will be scanned and cached by the system. Internally my company
has a private root CA, and we just add our certificates as separate
files in the directory -- and LDAP, websites, email, etc work just fine.
Its actually pretty easy once you learn a bit about what's going on.
The hard part is developing an initial understanding of how certificates
are interpreted and managed -- and where insecurity in the system can
arise. Key and certificate management is, in fact, the hardest part of
staying cryptographically secure at the present time. Unfortunately this
seems to be too much trouble for most large system administrators, even
at enormously connected places like universities, so it just gets
ignored and MitM attacks are more commonplace than most people realise.
The effects of such are generally minimal enough that most people don't
even know they've been snooped, however, which is a testament to how
unimportant most of our private data/lives really are anyway.
BTW, Merry Christmas, list.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
