Prev: (mailscanner?) Installing smtp auth did not help my spam issueBelow is example
Next: Setting mime-header checking
From: "Jan C." on 9 Jun 2010 12:39
On Wed, Jun 9, 2010 at 6:35 PM, Victor Duchovni
<Victor.Duchovni(a)morganstanley.com> wrote:
> Probably, although I don't think we've reached a final decision yet...
> My preference is to not trust some random list of CAs that came with the
> O/S OpenSSL package when the user specifies an explicit CAfile/CApath,
> but this would be an incompatible change.
>
> In my case, the OpenSSL package I use is built by me, and has an empty
> default list of trusted CAs, so I never notice the extra default certs.
>

ok, could you please point me to the place where one can set those
paths while building OpenSSL ?

Jan

From: Wietse Venema on 9 Jun 2010 13:34
Victor Duchovni:
> On Wed, Jun 09, 2010 at 11:25:50AM -0400, Wietse Venema wrote:
>
> > > to sum it up, when smtp_tls_CApath is not empty, CAs from
> > > /etc/ssl/certs are trusted regardless the value of smtp_tls_CApath.
>
> This is done primarily by OpenSSL, but as Wietse observes:
>
> > Victor will have to confirm or deny this, but we may have to update
> > the main code in function tls_set_ca_certificate_info():
> >
> > if (CAfile || CApath) {
> > if (!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) {
> > msg_info("cannot load Certificate Authority data: "
> > "disabling TLS support");
> > tls_print_errors();
> > return (-1);
> > }
> > + } else {
> > if (!SSL_CTX_set_default_verify_paths(ctx)) {
> > msg_info("cannot set certificate verification paths: "
> > "disabling TLS support");
> > tls_print_errors();
> > return (-1);
> > }
> > }
>
> We could make this change, but it would be an incompatibility with past
> behaviour. This code dates back to the original TLS patch for Postfix
> releases prior to 2.1, and augments the default system CA paths, instead
> of replacing them.
>
> I guess our documentation has never promised the use of system CAs when
> CApath or CAfile are set, failing to override the system settings is
> counter-intuitive, so I can support this change. We'll also have to
> document the semantics of "CAfile == CApath == <empty>".

The empty setting would correspond with the default system-supplied
CA certificates.

There is at least one Postfix feature that relies on the ability
to override the default system-supplied CA certificates:

permit_tls_all_clientcerts
Permit the request when the remote SMTP client certificate is
verified successfully. This option must be used only if a spe-
cial CA issues the certificates and only this CA is listed as
trusted CA, otherwise all clients with a recognized certificate
would be allowed to relay. This feature is available with Post-
fix version 2.2.

It would seem then that permit_tls_all_clientcerts is broken.

What else would be broken by the current practice of always including
the default CA certificates? If there is nothing else, then most
sites would not be affected, but a lot of sites could be at risk of
breaking when we change the CAfile/CApath behavior.

Therefore it would be desirable to provide a compatibility switch
that is "incompatible" for Postfix 2.8 and "compatible" for the
earlier releases.

Wietse

From: Victor Duchovni on 9 Jun 2010 14:03
On Wed, Jun 09, 2010 at 01:34:53PM -0400, Wietse Venema wrote:

> > I guess our documentation has never promised the use of system CAs when
> > CApath or CAfile are set, failing to override the system settings is
> > counter-intuitive, so I can support this change. We'll also have to
> > document the semantics of "CAfile == CApath == <empty>".
>
> The empty setting would correspond with the default system-supplied
> CA certificates.
>
> There is at least one Postfix feature that relies on the ability
> to override the default system-supplied CA certificates:
>
> permit_tls_all_clientcerts
> Permit the request when the remote SMTP client certificate is
> verified successfully. This option must be used only if a spe-
> cial CA issues the certificates and only this CA is listed as
> trusted CA, otherwise all clients with a recognized certificate
> would be allowed to relay. This feature is available with Post-
> fix version 2.2.

Good point, oops! This too pre-dates Postfix 2.2, but it is rather unsafe
when the default system CA list includes all the usual suspects.

> It would seem then that permit_tls_all_clientcerts is broken.

Yes, for Postfix distributions where the vendor helpfully populates the
OpenSSL "ssl/certs/" directory.

> What else would be broken by the current practice of always including
> the default CA certificates? If there is nothing else, then most
> sites would not be affected, but a lot of sites could be at risk of
> breaking when we change the CAfile/CApath behavior.

Trusting unwanted CAs on the server side means:

1. The "Received:" header (Client CN, ... verified OK) could
be misleading.

2. The "smtpd_tls_req_ccert" feature may be more permissive
than desired.

3. As you observed "permit_tls_all_clientcerts" is unsafe.

4. Policy service requests may pass client CNs that are not
intended to be trusted.

5. Milters may process the client subject and issuer CN.

On the client side, we only use server certificates for destinations
with a "verify" or "secure" policy, so here the risk is MITM if one
of the public CAs issues certs that one has good cause to not trust.

> Therefore it would be desirable to provide a compatibility switch
> that is "incompatible" for Postfix 2.8 and "compatible" for the
> earlier releases.

Works for me. And of course a new warning in the
"permit_tls_all_clientcerts" postconf(5) entry.

--
Viktor.

From: Wietse Venema on 9 Jun 2010 19:41
Victor Duchovni:
> I guess our documentation has never promised the use of system CAs when
> CApath or CAfile are set, failing to override the system settings is
> counter-intuitive, so I can support this change. We'll also have to
> document the semantics of "CAfile == CApath == <empty>".

Why do we have to document or change Postfix default behavior?

Default Postfix behavior (empty CAfile and CApath) is a NOOP.
Postfix calls neither SSL_CTX_load_verify_locations() nor
SSL_CTX_set_default_verify_paths().

First, I don't see why we should change Postfix default behavior:
the problem is with non-default settings.

Second, I don't see how we could document existing Postfix default
behavior (empty CAfile and CApath), when that behavior is not
defined by the OpenSSL API.

OpenSSL source code does not count as a definition, nor do words
from OpenSSL programmers or code examples. They can change program
behavior because they are not bound by the contract of an API.

Wietse

From: Victor Duchovni on 10 Jun 2010 08:32
On Wed, Jun 09, 2010 at 07:41:51PM -0400, Wietse Venema wrote:

> Victor Duchovni:
> > I guess our documentation has never promised the use of system CAs when
> > CApath or CAfile are set, failing to override the system settings is
> > counter-intuitive, so I can support this change. We'll also have to
> > document the semantics of "CAfile == CApath == <empty>".
>
> Why do we have to document or change Postfix default behavior?

Sorry, failed to look at the code closely. We can leave the default
behaviour alone.

--
Viktor.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: (mailscanner?) Installing smtp auth did not help my spam issueBelow is example
Next: Setting mime-header checking