use of smtp(d)_tls_CAfile with opportunistic TLS?
email builder
I'm wondering about the usefulness of smtp(d)_tls_CAfile(path) when using
opportunistic encryption in both incoming and outgoing connections. The
TLS_README suggests that certificate and key files be left empty for
opportunistic smtp processes, but it doesn't talk specifically about
smtp_tls_CAfile(path).
Am I correct to infer that both smtp(d)_tls_CAfile settings only serve a purpose
when you want to verify client/server certificates? If that's the case, why does
the example at the bottom of TLS_README use both the CAfile settings with only
opportunistic encryption?
Our system seems to work without any CAfile/CApath settings under opportunistic
encryption both incoming and outgoing. Is there a performance or security
difference between using them or not?
Sorry in advance if my shaky grasp of TLS is the problem here.
Thank you!
Victor Duchovni
> I'm wondering about the usefulness of smtp(d)_tls_CAfile(path) when using
> opportunistic encryption in both incoming and outgoing connections. The
> TLS_README suggests that certificate and key files be left empty for
> opportunistic smtp processes, but it doesn't talk specifically about
> smtp_tls_CAfile(path).
For the SMTP server, you should NOT leave the cert file empty, as many
clients won't support aNULL ciphers. Rather, you need to set a self-signed
cert, if one of the usual CAs is not suitable.
For the SMTP server, since you probably won't ask for client certs, you
never need a CAfile or CApath.
For the SMTP client, indeed, generally, your key and cert should be set
empty. On the other hand, it is a good idea in most cases to have a CAfile
and/or CApath with a few trusted roots.
> Am I correct to infer that both smtp(d)_tls_CAfile settings only serve
> a purpose when you want to verify client/server certificates?
> If that's the case, why does the example at the bottom of TLS_README
> use both the CAfile settings with only opportunistic encryption?
This reduces log noise, and improves the audit trail.
> Our system seems to work without any CAfile/CApath settings under opportunistic
> encryption both incoming and outgoing. Is there a performance or security
> difference between using them or not?
You should probably throw in a few trusted root CAs.
--
Viktor.
email builder
> > opportunistic encryption in both incoming and outgoing connections. The
> > TLS_README suggests that certificate and key files be left empty for
> > opportunistic smtp processes, but it doesn't talk specifically about
> > smtp_tls_CAfile(path).
>
> For the SMTP server, you should NOT leave the cert file empty, as many
> clients won't support aNULL ciphers.
Oops, sincere apologies. I meant the docs suggest empty cert and key
for SMTP *client* only. I was originally asking only about the client, then
changed my inquiry but forgot to change this. Anyway, sorry.
> Rather, you need to set a self-signed
> cert, if one of the usual CAs is not suitable.
Right. Check.
> For the SMTP server, since you probably won't ask for client certs, you
> never need a CAfile or CApath.
OK, got it.
> For the SMTP client, indeed, generally, your key and cert should be set
> empty. On the other hand, it is a good idea in most cases to have a CAfile
> and/or CApath with a few trusted roots.
>
> > Am I correct to infer that both smtp(d)_tls_CAfile settings only serve
> > a purpose when you want to verify client/server certificates?
> > If that's the case, why does the example at the bottom of TLS_README
> > use both the CAfile settings with only opportunistic encryption?
>
> This reduces log noise, and improves the audit trail.
Hmm, OK, not to imply these things are not important, but are these the
only reasons you'd have a CAfile or CApath?
> > Our system seems to work without any CAfile/CApath settings under
>opportunistic
>
> > encryption both incoming and outgoing. Is there a performance or security
> > difference between using them or not?
>
> You should probably throw in a few trusted root CAs.
1) Is there a place to get a file with the usual suspects already in it?
2) Does postfix add new CAs to it when it sees a new one from a client?
3) Does it make much difference between CApath or CAfile? I suppose
using CApath only makes sense if the answer to question 2 is "yes"? (File
probably sufficient if it is static and not that big)
Noel Jones
>>> Am I correct to infer that both smtp(d)_tls_CAfile settings only serve
>>> a purpose when you want to verify client/server certificates?
>>> If that's the case, why does the example at the bottom of TLS_README
>>> use both the CAfile settings with only opportunistic encryption?
>>
>> This reduces log noise, and improves the audit trail.
>
> Hmm, OK, not to imply these things are not important, but are these the
> only reasons you'd have a CAfile or CApath?
With opportunistic TLS you don't gain any extra security by
verifying the remote cert. This is what makes self-signed
certificates adequate for opportunistic TLS.
>
>>> Our system seems to work without any CAfile/CApath settings under
>> opportunistic
>>
>>> encryption both incoming and outgoing. Is there a performance or security
>>> difference between using them or not?
>>
>> You should probably throw in a few trusted root CAs.
>
> 1) Is there a place to get a file with the usual suspects already in it?
Most OS's have a package of common root certs available. For
example, FreeBSD provides the security/ca_root_nss port.
>
> 2) Does postfix add new CAs to it when it sees a new one from a client?
No. The CA file/path is a trust list. It would be
inappropriate for a program to add trust automatically.
> 3) Does it make much difference between CApath or CAfile? I suppose
> using CApath only makes sense if the answer to question 2 is "yes"? (File
> probably sufficient if it is static and not that big)
Performance may be better with CApath for a large number of
certificates, but mostly this is about how the certs are
bundled for you.
-- Noel Jones
email builder
Thank you and Victor.