[exim-dev] Should we always load the default trust store? (w…

Pàgina inicial
Delete this message
Reply to this message
Autor: Heiko Schlittermann
Data:  
A: exim-dev
Assumptes vells: Re: [exim-dev] tls_verify_certificates forced failure vs. empty string
Assumpte: [exim-dev] Should we always load the default trust store? (was: tls_verify_certificates forced failure vs. empty) string
Hi,

Jeremy Harris <jgh@???> (Di 25 Nov 2014 10:49:47 CET):

> As you probably also saw, I added in 4.next a way of
> saying "just use the system default bundle". I've
> not changed the current behaviour with OpenSSL on
> loading both the default and the specified CAs though;
> do you think there is a need for that?
>
> The OpenSSL and GnuTLS implementations behave differently
> in this respect.


tls_verify_certificates seems to cause some trouble. I'm talking about
the main config option, but I assume that everything holds for the smtp
driver option of the same name too.

There are two (probably only loosely related issues):

    - The inconsistent results of not setting this option at all, 
      having a forced failure, and setting it to an empty value. 
      This could be talked about in another thread.


    - The confusing influence on loading a default trust store.
      This I'm talking about here and now …


The situation seems to be confusing. Let me repeat the spec (I'm
referring to the recent documents from the git master branch.)

As soon as tls_verify_certificates is set to a non empty value,
Exim loads the system default trust store (openssl version -d).

|With OpenSSL the certificates specified explicitly either by file or directory
|are added to those given by the system default location.

That means, I can't exclude CAs that I have in my system default
location. I can only *add* certificates. What's so bad with this?

There are use cases where a peer certificate has to be verified against
a small set of trusted CAs, and never ever against just any of the CAs
found in the system default location… And for several reasons it is not
an option to modify the system default trust store.

IMHO we need to add an option like 'tls_load_default_certificates'. This
option should be bool and expandable.

    [new]
    +-----------------------------+---------+-----------+--------------+
    |tls_load_default_certificates|Use: main|Type: bool*|Default: ?????|
    +-----------------------------+---------+-----------+--------------+


    The value of this option is expanded and must then be a bool value.
    With being a true value, the certificates specified explicitly in
    tls_verify_certificates are added to those given by the system default 
    location.
    [/new]


    +-----------------------+---------+-------------+--------------+
    |tls_verify_certificates|Use: main|Type: string*|Default: unset|
    +-----------------------+---------+-------------+--------------+


    The value of this option is expanded, and must then be the absolute
    path to a file containing permitted certificates for clients that
    match tls_verify_hosts or tls_try_verify_hosts. Alternatively, if
    you are using either GnuTLS version 3.3.6 (or later) or OpenSSL, you
    can set tls_verify_certificates to the name of a directory
    containing certificate files. For earlier versions of GnuTLS the
    option must be set to the name of a single file.


    [changed]
    A forced expansion failure or leaving it unset means no certificates
    at all are loaded, not even the system default location.  Setting it
    to an empty string may result in loading the system default
    (depending on tls_load_default_certificates).
    [/changed]


The question arises about the default value of
tls_load_default_certificates. The natural value should be 'no',
because then tls_verify_certificates follows the principle of least
astonishment.

Unfortunately this could break existing installations on upgrade. But it
breaks OpenSSL based installations only. For GnuTLS based installations
we would break existing installations with defaulting
tls_load_default_certificates to 'yes'.

(BTW: is GnuTLS capable of loading a system default location
additionally, or don't they have that concept?)

Any suggestions?

I'm biased to what I call the "natural" approach, even it breaks some
configurations. The broken configurations can be fixed easily, and exim
might even issue a warning on '-bV' when OpenSSL is in use and the
tls_verify_certificates is set. Packaged versions of Exim might check
the configuration and suggest the necessary change.

    Best regards from Dresden/Germany
    Viele Grüße aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
 gnupg fingerprint: 9288 F17D BBF9 9625 5ABC  285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2  7E92 EE4E AC98 48D0 359B)-