fetchmail-users

[fetchmail-users] User poll: how do you expect --sslcertpath to behave?

[Matthias A. <mat...@gm...>]

This is a short user poll. It is meant to figure out what people think how  
a particular SSL/TLS option should behave, so I can gear the upcoming  
6.3.17 release to create least surprises. The poll is free-form, on the  
list, and runs until I feel I have sufficient feedback.


Background:

* for a SSL or TLS connection, the server presents its server certificate  
(and possibly those of intermediate certification authorities in the  
so-called "certificate chain" if an entire hierarchy of SSL/TLS  
signing/trusting authorities is used) to fetchmail. Fetchmail validates  
those certificates, and checks if finds the certificate of the "root"  
certification authorities (issuer, signer) in one of the locations where  
OpenSSL or the fetchmail user keeps trusted certificates (see below).

* fetchmail versions 6.3.1 and newer have either used certificates from  
the directory you specified with --sslcertpath, or those from the default  
OpenSSL locations (usually /etc/ssl/certs, /usr/ssl/certs, or  
/usr/lib/ssl/certs, and the default CAfile). 6.3.0 and older have never  
loaded the default OpenSSL locations, which was considered a bug by users  
and fixed.

* OpenSSL actually allows adding multiple locations (in an  
include-as-well) where it is supposed to look for the certificates. It  
will search all of them, in a particular order. We need not decide for  
just one.

* I have committed a patch for the future version 6.3.17 that adds  
--sslcertfile so that fetchmail can use a CA bundle file in a non-default  
location. This is to obviate the need to run c_rehash.

* OpenSSL 1.0.0 (new) uses a different hash function for the directories  
you give to --sslcertpath MYCADIR than OpenSSL 0.9.8 (widespread in  
distributions) and older used to use. This caused bogus bug reports that  
fetchmail 6.3.16 broke SSL for users when they forgot to run "c_rehash  
MYCADIR".

The two poll questions are:

(1) Should fetchmail add the default OpenSSL certificate locations even if  
you specify --sslcertfile or --sslcertpath? You will be able to choose the  
other behaviour by setting an environment variable (I don't plan to add  
yet another option). Optional: why?
Explanation:
  - yes means that fetchmail would look into the OpenSSL default locations  
AND additionally into those you specify. From a usability point of view  
this option is preferred, because Linux, *BSD and other distributions will  
often run c_rehash on the system directories automatically, so that this  
can mask the user's forgetting to run c_rehash.
  - no means that fetchmail will only look into those you specify. If  
neither of these two options are present, fetchmail will instead look into  
the OpenSSL default places. This is preferable from a security point of  
view, to only look into specified locations in order to be as mistrustful  
as possible.

(2) If you answered the previous one with "yes", should the fetchmail or  
the OpenSSL directories be checked first?

Thank you.

-- 
Matthias Andree

Re: [fetchmail-users] User poll: how do you expect --sslcertpath to behave?

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

On Mon, Apr 19, 2010 at 09:04, Matthias Andree <mat...@gm...> wrote:
>
> The two poll questions are:
>
> (1) Should fetchmail add the default OpenSSL certificate locations even if
> you specify --sslcertfile or --sslcertpath? You will be able to choose the
> other behaviour by setting an environment variable (I don't plan to add yet
> another option). Optional: why?
> Explanation:
>  - yes means that fetchmail would look into the OpenSSL default locations
> AND additionally into those you specify. From a usability point of view this
> option is preferred, because Linux, *BSD and other distributions will often
> run c_rehash on the system directories automatically, so that this can mask
> the user's forgetting to run c_rehash.
>  - no means that fetchmail will only look into those you specify. If neither
> of these two options are present, fetchmail will instead look into the
> OpenSSL default places. This is preferable from a security point of view, to
> only look into specified locations in order to be as mistrustful as
> possible.

No (or at least if yes then no should be the default - a secure
solution by default is IMO preferable)

I'd suggest that when running fetchmail with one of the ssl options
then a message should be printed or logged reminding people to run
c_rehash (with a link to a document providing details of when to do
that).

> (2) If you answered the previous one with "yes", should the fetchmail or the
> OpenSSL directories be checked first?

OpenSSL directories first (just as with a path the user's directories
should be last so that you can't trivially get people to run your
version of "ls").

-- 
                 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

[fetchmail-users] (was: User poll: how do you expect --sslcertpath to behave?)

[Matthias A. <mat...@gm...>]

Rob MacGregor wrote on 2010-04-19:

> I'd suggest that when running fetchmail with one of the ssl options
> then a message should be printed or logged reminding people to run
> c_rehash (with a link to a document providing details of when to do
> that).

Something like that would be printed (regardless of the --sslcertpath  
option) if there are typical errors for such situations, such as unknown  
local issuer, self-signed certificates, or thereabouts:

http://gitorious.org/fetchmail/fetchmail/commit/d73d7527142850442b16883628de5e87f99a57ea

If you want to propose a different wording for the stuff displayed on  
green (for the red-green color blind, click "side by side" and check the  
right column) or white, feel free.

-- 
Matthias Andree

Re: [fetchmail-users] (was: User poll: how do you expect --sslcertpath to behave?)

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

On Mon, Apr 19, 2010 at 11:23, Matthias Andree <mat...@gm...> wrote:
> Rob MacGregor wrote on 2010-04-19:
>
>> I'd suggest that when running fetchmail with one of the ssl options
>> then a message should be printed or logged reminding people to run
>> c_rehash (with a link to a document providing details of when to do
>> that).
>
> Something like that would be printed (regardless of the --sslcertpath
> option) if there are typical errors for such situations, such as unknown
> local issuer, self-signed certificates, or thereabouts:
>
> http://gitorious.org/fetchmail/fetchmail/commit/d73d7527142850442b16883628de5e87f99a57ea
>
> If you want to propose a different wording for the stuff displayed on green
> (for the red-green color blind, click "side by side" and check the right
> column) or white, feel free.

Looks good to me.

-- 
                 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

Re: [fetchmail-users] User poll: how do you expect --sslcertpath to behave?

[Michael B. <bo...@gm...>]

(1) Yes.  Personally, I think that fetchmail should check the default
OpenSSL directories by default, even if you do specify an additional
path.  There should definitely be a way (through the environment
variable) for the particularly paranoid to turn this feature off
though.  I would imagine the typical use case here is people running
self-signed certificates on their own servers.  What they want to be
able to do is add their own certs so they can be validated, while still
having the normal ones validate correctly.
For example, if I run fetchmail from gmail.com and personal.com, I
should be able to find one certificate for my domain and put it in a
folder for fetchmail to find, without breaking gmail.  It's alot easier
to find the certificate you are using, than to figure out which chain of
authorities is needed to validate a particular certificate.

(2) Offhand, I think that your personal ones should be checked first, so
if you have a custom certificate, it gets used before the general ones. 
But I don't understand why this matters.  Won't a certificate check
succeed if it finds a matching authority?  Whether its checked first or
second, it shouldn't be visible to the users.  Unless someone wants to
replace a particular root cert with their own personal version (which is
really weird), in which case the one they gave should be used first.

--Michael

Re: [fetchmail-users] User poll: how do you expect --sslcertpath to behave?

[Matthias A. <mat...@gm...>]

Am 20.04.2010, 01:23 Uhr, schrieb Michael Banack:

> (2) Offhand, I think that your personal ones should be checked first, so
> if you have a custom certificate, it gets used before the general ones.
> But I don't understand why this matters.  Won't a certificate check
> succeed if it finds a matching authority?  Whether its checked first or
> second, it shouldn't be visible to the users.  Unless someone wants to
> replace a particular root cert with their own personal version (which is
> really weird), in which case the one they gave should be used first.

Hi Michael,

Thanks for your input.

I am just picking out (2) to reply to: it appears to matter because the  
OpenSSL documentation - the manual page  
SSL_CTX_load_verify_locations(3ssl) reads, as of 0.9.8,

       "... Certificate matching
        is done based on the subject name, the key identifier (if present),  
and
        the serial number as taken from the certificate to be verified. If
        these data do not match, the next certificate will be tried. If a  
first
        certificate matching the parameters is found, the verification  
process
        will be performed; no other certificates for the same parameters  
will
        be searched in case of failure."

I do not currently oversee what parameter would be changed without the  
certificate being considered different in a typical failure scenario (lack  
of experience), but using the default paths first means that the user  
cannot locally override a broken/outdated/reissued system certificate  
without precluding the system path altogether. I guess such failures would  
be subtle and hard to debug because the most obvious thing, namely the  
certificate subjects and issuer, might be the same. I also guess that a  
decent CA would bump the serial number when changing, for instance,  
subjectAltNames, but then again, errors do happen even without any malice  
or cluelessness involved.

Most of these considerations apply to scenarios where the user has no  
control over the system-wide certs directory, else the user can fix the  
root cause of his/her issues.

HTH

-- 
Matthias Andree

Re: [fetchmail-users] User poll: how do you expect --sslcertpath to behave?

[Uli Z. <ul...@ri...>]

Am 19.04.2010 um 10:04 schrieb Matthias Andree:

> * fetchmail versions 6.3.1 and newer have either used certificates from the directory you specified with --sslcertpath, or those from the default OpenSSL locations (usually /etc/ssl/certs, /usr/ssl/certs, or /usr/lib/ssl/certs, and the default CAfile).

I might have a slightly different perspective here than others, as I'm using fetchmail on Mac OS X.

Mac OS X differs from other Unices in that:
a) The default location is the rather non-standard /System/Library/OpenSSL/certs/ (and I'm not even sure whether the certs subdirectory within /System/Library/OpenSSL/ exists by default)
b) This directory is empty by default as Mac OS X uses a different certificate format (a *.keychain file) that's incompatible to OpenSSL. (Alas, I wrote a utility years ago that converts the Mac OS X keychain to the OpenSSL format and keeps both in sync, but never got around to publish it so far ... :-(( )

So however fetchmail behaves, it would be important for Mac OS X users that:
a) it looks for the correct (non-standard) default directory on Mac OS X
b) it can deal with a non-existing or empty default directory

> (1) Should fetchmail add the default OpenSSL certificate locations even if you specify --sslcertfile or --sslcertpath?

No. That would sacrifice clarity for convenience, something that's really bad for security features.

I can imagine quite a lot of confusion if someone who might not even be aware of the default path, let alone fetchmail's behavior, explicitly specifies a path to his certificate files and then gets a behavior he cannot explain by the certificate files he installed.

> (2) If you answered the previous one with "yes", should the fetchmail or the OpenSSL directories be checked first?

In this case, clearly the directory specified with fetchmail should be checked first. User preferences should overwrite system defaults by definition. If I have installed my own certificate, I probably have a good reason for that and want it to be used instead of the system installed one.

            Bye
                    Uli
________________________________________________________

  Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
  http://www.ritual.org
  Fon: +49-700-ULIZAPPE
  Fax: +49-700-ZAPPEFAX
________________________________________________________

Re: [fetchmail-users] User poll CLOSED: how do you expect --sslcertpath to behave?

[Matthias A. <mat...@gm...>]

Greetings,

I'm closing the poll - the input was convincingly argued.

As per the recent commit to Git
<http://gitorious.org/fetchmail/fetchmail/commit/e87f96bd9730e2bdb407d0a9cca2a05ee0dabce5>,
fetchmail 6.3.17-pre1 (not formally available as tarball) now behaves as
follows:

- if --sslcertfile or --sslcertpath or both options are given, fetchmail
  uses only these locations for OpenSSL X.509 CA certificate trust.
  Either option is available from the rcfile, too.

- if the environment variable FETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS
  is set and is not empty, fetchmail also loads the default locations,
  that is /etc/ssl/cert.pem and /etc/ssl/certs/ on my computers.
  --sslcert???? options retain precedence over the default store, to
  avoid user astonishment, and along the policies that specifics should
  override the generics.

I hope that's one little step towards cleaning up the SSL mess.

On Sunday, I had already added some extensions to SSL error reporting,
<http://gitorious.org/fetchmail/fetchmail/commit/d73d7527142850442b16883628de5e87f99a57ea>
- this needs testing, for instance against SSL sites that provide an
incomplete certificate chain, to see if we get the right error message.

Thanks for all your input.