Question about CA’s for the smtp client

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about CA’s for the smtp client

J Doe
Hi,

I have a question regarding specifying where the list of trusted CA’s are in regards to the smtp client.

In man 5 postconf, I can see there are two configuration parameters regarding this:

    smtp_tls_CAfile
    smtp_tls_CApath

The documentation (as I understand it), notes that:

1. smtp_tls_CAfile

— Specifies file that contains CA certs of root CA’s trusted to sign either remote SMTP server certificates or intermediate CA certificates

2. smtp_tls_CApath

— Specifies directory with PEM format CA certs that smtp client uses to verify remote SMTP server certificate
— Preferred over smtp_tls_CAfile when the number of trusted roots is large

On one of my installations of Postfix 3.1.0 on Ubuntu 16.04 LTS, I use CAfile to specify the file that stores all the CA certs:

    smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

My questions are:

1. Is that correct ?

2. Is there any other guidance on when to prefer smtp_tls_CApath over smtp_tls_CAfile ?

Thanks,

- J
Reply | Threaded
Open this post in threaded view
|

Re: Question about CA’s for the smtp client

Viktor Dukhovni


> On Dec 11, 2017, at 5:40 PM, J Doe <[hidden email]> wrote:
>
> I have a question regarding specifying where the list of trusted CA’s are in regards to the smtp client.

The recommended set of trusted CAs for the Postfix SMTP client is
*empty*.  TLS in SMTP is opportunistic, and email sent whether or
not the peer appears to be authenticated.  So any trusted CAs you
might configure are largely just wasted memory and CPU.

> In man 5 postconf, I can see there are two configuration parameters regarding this:
>
>    smtp_tls_CAfile
>    smtp_tls_CApath
>
> The documentation (as I understand it), notes that:
>
> 1. smtp_tls_CAfile

Generally avoid this entirely.  It does however work "better"
with chroot jails, since the file is loaded into memory before
chroot.

> 2. smtp_tls_CApath
>
> — Specifies directory with PEM format CA certs that smtp client uses to verify remote SMTP server certificate
> — Preferred over smtp_tls_CAfile when the number of trusted roots is large

Let's say that "large" is 5 or more.  By the time you have more
CAs than you've carefully curated after thinking about each one,
you're probably better off with CApath, to the extent that you
bother to configure either.

> On one of my installations of Postfix 3.1.0 on Ubuntu 16.04 LTS, I use CAfile to specify the file that stores all the CA certs:
>
>    smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

The recommended setting is empty.

> My questions are:
>
> 1. Is that correct ?

What are you using the certificates for?  Have you configured
any destinations with a "security level" of "verify" or "secure"?

> 2. Is there any other guidance on when to prefer smtp_tls_CApath over smtp_tls_CAfile ?

Set both empty.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Question about CA’s for the smtp client

J Doe
Hi Victor,

> On Dec 11, 2017, at 6:13 PM, Viktor Dukhovni <[hidden email]> wrote:
>
>> On Dec 11, 2017, at 5:40 PM, J Doe <[hidden email]> wrote:
>>
>> I have a question regarding specifying where the list of trusted CA’s are in regards to the smtp client.
>
> The recommended set of trusted CAs for the Postfix SMTP client is
> *empty*.  TLS in SMTP is opportunistic, and email sent whether or
> not the peer appears to be authenticated.  So any trusted CAs you
> might configure are largely just wasted memory and CPU.

Ok.  If I am understanding you correctly, you are saying that if the SMTP client is configured to use opportunistic TLS, the mail will be delivered regardless of whether the remote peer is *authenticated* ?

In my case, I use opportunistic TLS for the SMTP client:

    /etc/postfix/main.cf
        smtp_tls_security_level = may

I then had the CA list set up:

    /etc/postfix/main.cf
        smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

I did not have any per-destination rules set up - all mail via the SMTP client used these settings.  When I send a test message in to my server and the SMTP client sends it out to my test Gmail address, I note that the TLS log line in mail.log is:

Dec 11 20:40:44 server postfix/smtp[2559]: Trusted TLS connection . . .

But when I remove the CA list the log line is:

Dec 11 20:40:44 server postfix/smtp[2559]: Untrusted TLS connection . . .

*HOWEVER* you are saying that the authentication status (“Trusted” / “Untrusted”), is actually irrelevant as the mail will still be delivered to Gmail regardless.  The fact that I receive successful authentication (“trusted”), is irrelevant compared to no authentication (“untrusted”), because the mail goes through either way so in effect all I am doing is wasting compute resources ?

Apologies if this is a basic question - I do appreciate your help.  

After Postfix configuration ins and outs, I have a book ready on cryptography that I am going to read to get a better handle on this.

- J
Reply | Threaded
Open this post in threaded view
|

Re: Question about CA’s for the smtp client

Viktor Dukhovni


> On Dec 11, 2017, at 8:55 PM, J Doe <[hidden email]> wrote:
>
>> The recommended set of trusted CAs for the Postfix SMTP client is
>> *empty*.  TLS in SMTP is opportunistic, and email sent whether or
>> not the peer appears to be authenticated.  So any trusted CAs you
>> might configure are largely just wasted memory and CPU.
>
> Ok.  If I am understanding you correctly, you are saying that if the SMTP
> client is configured to use opportunistic TLS, the mail will be delivered
> regardless of whether the remote peer is *authenticated*?

Correct, and indeed with Opportunistic TLS Postfix does not attempt to
check the peer hostname against any names in the certificate.  And so,
even if the certificate chain is issued by a trusted CA, it may well
be for some unrelated hostname.

> In my case, I use opportunistic TLS for the SMTP client:
>
>    /etc/postfix/main.cf
>        smtp_tls_security_level = may
>
> I then had the CA list set up:
>
>    /etc/postfix/main.cf
>        smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
>
> I did not have any per-destination rules set up - all mail via the
> SMTP client used these settings.  When I send a test message in to
> my server and the SMTP client sends it out to my test Gmail address,
> I note that the TLS log line in mail.log is:
>
> Dec 11 20:40:44 server postfix/smtp[2559]: Trusted TLS connection . . .
>
> But when I remove the CA list the log line is:
>
> Dec 11 20:40:44 server postfix/smtp[2559]: Untrusted TLS connection . . .
>
> *HOWEVER* you are saying that the authentication status (“Trusted” /
> “Untrusted”), is actually irrelevant as the mail will still be delivered
> to Gmail regardless.

Correct.

> The fact that I receive successful authentication (“trusted”), is
> irrelevant compared to no authentication (“untrusted”), because the
> mail goes through either way so in effect all I am doing is wasting
> compute resources?

Essentially, yes.  Some might argue that there's forensic value in
the logs, and that this type of "tamper-evidence" might even deter
some kinds of attacks.  I remain skeptical about that.

So for most users, an empty CA list works just fine, and you get
to STARTTLS to protect against passive monitoring, while remaining
vulnerable to active attacks.

See https://tools.ietf.org/html/rfc7435 for my views of opportunistic
security.  See also:

        http://www.postfix.org/TLS_README.html#client_tls_dane
        https://tools.ietf.org/html/rfc7672#section-1.3

A small, but growing fraction of SMTP domains (currently ~175k domains
out of ~5.1 million DNSSEC-signed domains I've been able to find) have
deployed DNSSEC and have TLSA records for their MX hosts.  You can enable
DANE outbound in your SMTP client, and get authenticated email delivery
to these domains, with mail deferred when authentication fails (either
due to an actual MiTM attack, or operational error on the receiving side).
At present ~177 of the 175k domains are affected by what appear to be
operational issues, this number fluctuates as errors are fixed, with a
floor around ~130 domains that don't receive or ignore failure notices.

Deploying DANE inbound (publishing TLSA records for your own MX hosts)
requires some operational discipline.  This coordinated changes in
the DNS and SMTP configurations when server keys and/or certificates
change:

   http://tools.ietf.org/html/rfc7671#section-8.1
   http://tools.ietf.org/html/rfc7671#section-8.4
   https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
   https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
   https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022

When updating the certificate chain you need to temporarily pre-publish
multiple TLSA records matching the current and future certificate:

   https://dane.sys4.de/common_mistakes#3

However, with "3 1 1" + "2 1 1", the rollover process can be
substantially simplified:

   http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
   https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

--
        Viktor.