Re: [fetchmail-devel] Downloading remote server certificate for a TLS session?

[Rob M. <rob...@gm...>]

On 8/23/07, Matthias Andree <mat...@gm...> wrote:
>
> Yes, older openssl s_client versions don't support as many protocols.

Even 0.9.8e, the most recent, appears to be less than 100% - it won't
talk TLS to my domain host's IMAP/POP servers (but fetchmail will).

<---SNIP--->
> Generally, there are two approaches of trusting the server's
> certificate:
>
> 1. The canonical and recommended one: verify the recognized
>    Certification Authority's signature on the server certificate (that
>    works for major CAs as their certificates are usually shipped with
>    the OS or available as add-on, for instance, in FreeBSD's ca-roots
>    port).  /etc/ssl/certs contains certificates of CAs we trust
>    (recognize) and is thus the configuration directory for the "trusted
>    CAs".
>
>    That is the usual way of doing things, and reasonable sites using
>    self-signed certificates provide their root CA certificates for
>    download with a web browser and usually offer a phone number you can
>    call to verify the fingerprint.
>    At least that's how my former and current universities and the DFN
>    (at a very coarse look, they provide the Internet backbone to German
>    Universities) do that.

Sadly, not all do.  I'll need to check, but I'm pretty sure one of my
current mail hosts uses a self signed certificate and no way of
downloading the CA certificate.

> 2. The less durable one: verify the server's certificate instead.
>
>    The recommendation of downloading the certificate and stuffing it
>    into /etc/ssl/certs however is just a very cumbersome alternative of
>    specifying the sslfingerprint which fetchmail already prints at -v
>    verbose level. Let's not tell users to use openssl s_client to
>    download certificates, but let's just point them to the
>    sslfingerprint option and tell them that they need a recent fetchmail.
>
>    The only technical difference is we're using a hash of the
>    certificate and are currently relying on MD5, but I'm not aware that
>    attacks are publicly known to generate a message with a specific hash
>    in a reasonable amount of time.

I'm not aware of any easy way of generating a matching MD5, with valid
content, easily.

I suppose this raises a feature request then - when a certificate
fails to verify fetchmail should email the user specified in the poll
command (or the postmaster if multiple users are listed) to tell them.

> The wording above is perhaps not as clear as it could be if I revised
> this text several times, but let's just see where it's unclear and
> revise the critical parts. (And if that's going to evolve into a "SSL
> certificate management for fetchmail" section, that's exactly what I'm
> aiming at :-))

I don't have any problems understanding it, but then I have a
reasonable understanding of how SSL works :)  I'll come back to it
later and have another read to see if I can spot anything the average
user of fetchmail may not understand.

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche