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@public.gmane.org)

...

...

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@imap.maths.tcd.ie 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.

On 12/26/2011 09:45 PM, Timothy Murphy wrote:

夜神　岩男 wrote:

...

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.

Thanks again for your lucid explanation.

I do feel there is a serious lack of what I would call "low-level" documentation in RedHat/CentOS/Fedora on authentication.

There is a lack, in a grand sense, but a lot of it is considered non-OS-specific specialist knowledge and is covered in other places thoroughly. To that end the Fedora and RedHat docs tend to include extensive references to security texts elsewhere. Understanding Kerberos and TLS, for example, requires at least a lay understanding of both public key and symmetric key encryption, and how those structures can be combined to make such encryption sub-systems work. Explaining those things is beyond the scope of the Fedora/RH docs, but the references to Kerberos docs, and the Kerberos references to general encryption docs do cover the subject in detail -- but most people (even system operators) tend to not follow the chain of references nearly so far as to learn all that. (Instead they get the 4-day "certification" version for "...the low, low seminar-only price of just $4,300! Come on today, bring a friend for a $1,000 cash back voucher! Impress your manager and totally snow government contract hiring departments into thinking you know your stuff!")

On your last point, I do agree that many people seem to elevate their personal security to an absurd level, as though there are people in China who are desperate to find out their "secrets". Apart from credit card and bank account details I don't think most of us have anything of interest to declare.

Generally, no. Besides, finding a single person in all the mess is itself another mess -- which is why it happens a lot less than people fear. On the other hand the principle is what is important here. I don't want you reading mail between me and my mother. Why? No real reason. But just because its my life, not yours.

Of course, if we really cared about that we'd go back to remebering that http is a broadcast, deliberately insecure protocol and can't be made secure via redirects. Period. And then maybe we'd suddenly remember that the "web" was never intended to be an applications development environment as much as it naturally *is* a massively linked bulletin system... and maybe we'd even remember that World of Warcraft is, in very real terms, cloud computing... blah blah blah. There are many places the current market is way off base today. And that's not going to change anytime soon...

Speaking of China, I do find that according to logwatch/shorewall the majority of people trying to enter my system seem to live in that country. Maybe it is just that there are so many of them? Or are chinese naturally more inquisitive?

No, the Chinese really do have a massive, concerted government cracking program to crack literally everything. They conduct what is known as mosaic intelligence, where no collected piece is considered individually important and targeted intelligence is considered infeasable, but enough non-sensitive data collected in a wide enough arc can be assembled in such a way as to predict whatever the really sensitive data should be. And this is workable with a program as large as theirs.

This used to be a specific area of speciality/concern for me for professional reasons (more on the human collection side, not signal collections, though) and it really is a concern. But it is a general threat, not a specific one, and doesn't generally need to alarm an individual as much as it should alarm large organizations and governments.

Blah blah. This is getting pretty OT, so I'll end this chain of thought here.

Back on your email question... I did push some requests around your school server our of curiosity, and the -ssh option alone works but does give a warning ("this is certificate is worthless, but I'm continuing anyway" sort of message). If you get a chance or even can it might be a good thing to talk to the admin about that -- he might not even know the situation, perhaps not being the one who set things up to begin with.