Re: [fetchmail-users] Want a "How can I use fetchmail with Gmail's POP3 servers?" FAQ?

[Charles L. <cha...@gm...>]

* On Monday 2005-08-15 at 00:34:08 +0200, Jakob Hirsch wrote:
> 
> And I didn't see any broken HTML,
> maybe Michelle received a broken mail.

Maybe it's my peculiar (but still valid)
SGML/HTML coding/formatting style that throws
some tools off.


> Anyway, would have been better to put the file
> on some web server and post the link here.

I have uploaded it here:

   <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html>


> But what is so special about gmail that it needs its own documentation?

Remember, this is the original document I wrote
with the Gmail Help Center in mind.
I am willing to evolve it for the fetchmail FAQ.

Change the Gmail-specific details (such as the
URL for Thawte's root certificate bundle) and
it can become generic.
Although, it could be nice to document how to
figure out who the server certificate issuer
is in the first place, and to list a few URLs
for the most important CAs (such as Thawte
and Entrust).


> The SSL stuff is really helpful, I had some problems setting this up
> properly, but not only with gmail.

This is something (configuration of the
fetchmail/OpenSSL combination) I had not seen
documented in one place anywhere before.
This was a big part of my motivation to write
this.

For instance, my system comes with a
/usr/share/ssl/certs/ca-bundle.crt file with
all the root certificates one could want, but
fetchmail/OpenSSL is unable to use it in this
form (i.e., all in a single file).

I had to figure out from various sources that:

   -- you need the root certificate installed
      alone in its own file for fetchmail's
      sslcertck to be able to pick it up and do
      its checking-job;

   -- you have to run c_rehash to generates the
      symlinks, because those are the only file
      names that will be looked up;

   -- each of these files needs to have a ".pem"
      extension for c_rehash to pick it up in the
      first place (".txt" or ".cer" won't do).


> btw, AFAIK fingerprint is only useful if the cert is not signed by a CA.

That's why I used the word "mitigated", as
opposed to a stronger word such as "necessary".
It still has some useful value in this case;
see below.


> The downside is that is has to be changed if the cert changes (e.g.
> expired).

Without CRL verification, the following scenario
is possible.
Remember that this is about security, so you
either attempt to provide it fully or you don't.

   -- The old server certificate, which forever
      remains properly signed by its issuer CA,
      is revocated (and so is included in the
      CRL) because its associated private key
      was compromised.

   -- The legitimate server starts using a new
      non-compromised server certificate.

   -- A man-in-the-middle attacker with the
      compromised private key pretends to be
      this server.
      I.e., it seems from our point-of-view that
      it has either the IP address or maybe just
      the domain name of the legitimate server.

   -- This attacker provides the old server
      certificate at SSL connection establishment.
      This server certificate's common name (CN)
      matches the domain name.
      This server certificate still is properly
      signed by its issuer CA (forever).

   -- We didn't configure fetchmail to verify
      the server certificate's MD5 signature.

   -- Fetchmail, as SSL client, cannot do CRL
      verification and so then fully accepts
      this form of authentication by the fake
      server pretending to be the legitimate one.
      Fetchmail then proceeds to feed (i.e.,
      reveal to) this rogue server the client
      authentication information using POP3's
      USER and PASS commands, within the SSL
      connection.

Checking the MD5 signature will at least alert
us that the server certificate has changed if
we succeed in connecting at least once to the
legitimate server after this change.
We will still be an unaware victim if
(or, as long as) we are _systematically_
man-in-the-middled with the above scenario every
single time after the change.


The pop.gmail.com server certificate does point
to the CRL's URI:

   <http://crl.thawte.com/ThawteServerCA.crl>

In this case, it's a 99978-octet file that is
updated every day and that has a sliding 28-day
validity period.

Fetchmail/OpenSSL doesn't but should download it
_after_ the server certificate has been validated
(so we know that this URI is dependable) and
check the validity of the CRL itself (signature
and time period) and the absence of the server
certificate in it.
Having fetchmail cache the CRL somewhere in /var
or in a user-specified directory would also be
a possibility.