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.
