Update security settings for ssl and tls

[kiekerjan]

Update of the tls and ssl settings according to:

• The various Mozilla recommendations from https://ssl-config.mozilla.org
• internet.nl security recommendations

The only thing I did not include was removal of support for TLS v1.0 and v1.1, following the comment "some mail servers out in the world are very far behind and if we disable too much, they may not be able to use TLS and won't fall back to cleartext. So we don't disable too much."
I don't know what the email landscape looks like. Should we also disable TLS v1.0 and v1.1? Do we also need older cipher that are disabled by this pull request? Love to hear feedback on this, how do we weigh security against supporting older installations?

[downtownallday]

This is great. Thanks for doing this.

Can submission and smtpd have different settings? I feel like submission could be >=TLS1.3 as all the major email UA's support it, but incoming mail from non-users (smptd) be less restrictive (not sure on TLS level). I looked briefly and it appears like the postfix TLS configuration applies to both submission and smtpd, so maybe not doable.

I would also like to see smtpd_tls_loglevel = 1 added to main.cf in setup/mail-postfix.sh so we can see, in the future, what TLS level is actually chosen for incoming connections in /var/log/mail.log like we do for outgoing connections.

[kiekerjan]

Can submission and smtpd have different settings? I feel like submission could be >=TLS1.3 as all the major email UA's support it, but incoming mail from non-users (smptd) be less restrictive (not sure on TLS level). I looked briefly and it appears like the postfix TLS configuration applies to both submission and smtpd, so maybe not doable.

You can actually make a difference between the two. However, it is not on submission versus smtpd, but by looking at the smtpd_tls_security_level parameter. When encryption is required, the _mandatory_ tls parameters are applied. In Mail-in-a-Box configuration, smtpd does not require encryption, while submission does. (This pull request does not change that.) For submission, the smtpd_tls_security_level is indeed set to encrypt (see master.cf)
In this pull request, the smtpd requires TLS1.0, but only if encryption is actually applied (opportunistic). The submission port requires at least TLS1.2 at all times. I'm not sure we can require TLS1.3 as it also depends on what the other side has configured to use. The sources I reference actually do not require TLS1.3.

I would also like to see smtpd_tls_loglevel = 1 added to main.cf in setup/mail-postfix.sh so we can see, in the future, what TLS level is actually chosen for incoming connections in /var/log/mail.log like we do for outgoing connections.

Noted on wishlist 😉

[downtownallday]

👍

[dms00]

According to Mozilla's SSL config page (cool tool, btw), it only adds @SECLEVEL=0 if you configure for "old" which they describe as "Compatible with a number of very old clients, and should be used only as a last resort".
This page describes what SECLEVEL 0 means: https://docs.openssl.org/3.5/man3/SSL_CTX_set_security_level/#description.

I'm wondering why we're going with the weakest config here unless people are reporting that they're running into problems communicating with ancient servers. Won't this effectively weaken our security?

[kiekerjan]

I think the logic is indeed that we don't want to be too strict. I didn't change the logic, the current Mail-in-a-Box configuration also references Mozilla's "Old" recommendations. I just updated them with the versions of postfix and openssl we're now using.
Note that there are a few more ciphers excluded (see line 146)

[kiekerjan]

I did some more thinking and looked more carefully at the internet.nl email security test. I think I was a little too enthousiastic on which ciphers to exclude.
My reasoning:

• for opportunistic encryption, if no cipher can be agreed between client and server, it will fall back to no encryption. Reasoning that any encryption is better than no encryption, less secure and older stuff is allowed. E.g. TLS must be at least 1.0, which is pretty old.
• for mandatory encryption: encryption is more strict, as we want to be sure to be able to depend on it. E.g. TLS must be at least 1.2, which is deemed secure at this time.

Implementing this logic still gives a 100% score on the internet.nl email test, but it leaves some remarks as tlsv1.0 and 1.1 and some ciphers are marked to be phased out. Note you need to have DNSSEC enabled, otherwise DANE won't function.

Further changes:

• change smtp tls loglevel to 1 as recommendation on the postfix config page
• explicitly set the smtp[d]_tls_mandatory_exclude_ciphers so we know that it is set to a known value
• include smtp_tls_note_starttls_offer

For further reference: gmail also allows TLS1.0 and 1.1 by default (see https://support.google.com/a/answer/9795993?hl=nl&ref_topic=9973342&sjid=2864150685381691207-EU)

[Lawkss]

To get a better score on internet.nl:

To upgrade the security I changed the following in Postfix:

DH set to 4096 instead of 2048:

smtpd_tls_dh1024_param_file=PATH TO 4096.pem

You can do the same for dovecot.

For example: https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe4096.pem

To disable TLS 1.0 and 1.1:

smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

And remove some ciphers from the medium list:

AES256-GCM-SHA384 
AES128-GCM-SHA256 
AES256-SHA256 
AES256-SHA 
AES128-SHA256 
AES128-SHA 
DES-CBC3-SHA 

[Synchro]

As @kiekerjan said, we know that turning everything up results in a better score, but it also makes it more likely that messages will be sent with no encryption at all, which is a worse outcome despite having stricter settings — email is not the web!

One problem with using 4096-bit DH params is that it takes a really long time to generate a custom params file (sometimes > 1h on a slow machine), and if it's done during installation, it's likely that users will think it's crashed/hung/died.

[Lawkss]

Not acceptable to use the standard group for DH I posted?

To avoid the runtime costs associated with finding a group, you typically you use a standard group, like those published in RFC 3526 or RFC 7919

Catering to careless admins with TLS 1.0 or 1.1 for Millennia is a mistake in my opinion. They are already showing neglect. Until something breaks, these people never move on.

But thats just my personal opinion, I fully understand your viewpoint.

But right now I am not aware of statistics on this matter, aka if mail really gets more lost and or sent unencrypted because of tighter requirements.

[Synchro]

Indeed, I'm not sure of the stats either.

Regarding DH param files, the standard ones are flagged by Qualys' SSL Labs checks, if we are angling to score points...

[kiekerjan]

DH set to 4096 instead of 2048:

smtpd_tls_dh1024_param_file=PATH TO 4096.pem

You can do the same for dovecot.

For example: https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe4096.pem

This is actually part of this pull request. That indeed means no long generation time.

AES256-GCM-SHA384
AES128-GCM-SHA256
AES256-SHA256
AES256-SHA
AES128-SHA256
AES128-SHA
DES-CBC3-SHA

In this pull request, they are not available for the Mandatory TLS connections.

Regarding DH param files, the standard ones are flagged by Qualys' SSL Labs checks, if we are angling to score points...

Is that positive or negative? The internet.nl email checks recommend to use the standard group.

Note: I get a 100% score on https://en.internet.nl/test-mail/ when running this pull request.