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.

[Georg-Git]

What about X25519MLKEM768?

Even Apple support now this post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3.

https://blog.cloudflare.com/pq-2025/#long-road-to-50.

Edit:
I think I'll have to wait a few more months for the migration to Ubuntu 26.4 😉

[Georg-Git]

I like this Online Check:
https://www.hardenize.com/

Result without this commit:

Even though this server supports TLS 1.2, the cipher suite configuration is suboptimal. We recommend that you reconfigure the server so that the cipher suites providing forward secrecy (ECDHE or DHE in the name, in this order of preference) and authenticated encryption (GCM or CHACHA20 in the name) are at the top.

The server must also be configured to select the best-available suite.

Also https://testssl.sh/ reported:

Severity HIGH: NOT a cipher order configured

This issues are solved with this pull request.

Any schedule for a merge of this commits?

[Georg-Git]

My opinion on the initial question:

1. The sender is responsible for protecting data during transmission (but the recipient must provide the best possible options for this.)

2. Poor encryption is better than none at all.

3. And if nowadays I really should receive a poorly protected email, the content is completely uncritical in terms of confidentiality - but I still want to receive these emails!

4096-bit DH params:

it takes a really long time to generate a custom params file

For me the difference wasn't noticeable (my VPC isn't very old either).
But there is no alternative.

=>
After aplying the commits of this pull request, everthings looks fine - and I get a 100% score on https://en.internet.nl/test-mail/

@kiekerjan
Thanks for this PR!

[myfirstnameispaul]

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.

I don't know all of the ways to generate a DH params file, but running the following command prints symbols to the terminal letting users know it is calculating:

openssl dhparam -out dhparam.pem 4096

It completed in about 8 minutes on a very old 1 GB VPS.

[kiekerjan]

You shouldn´t generate the 4096 bit DH parameters anymore, but use a standard group, see explanation

[Georg-Git]

So - there are no risk we have to think about?

I like the tests with:
https://email-security-scans.org/
because a lot of emails with different use cases were sent and and evaluated.

And after applying the commits of this PR I have seen no problems with functionalitys of MiaB.

But with this PR the impact on the public image of MiaB is significant:
while the current version of MiaB get some security warnings:
https://www.hardenize.com/report/mailinabox.email/1763025142#email_tls

with this PR MiaB of @kiekerjan and MiaB of mine reached the "Hall of Fame" in the Netherlands:
https://en.internet.nl/test-mail/

=> The grapes hanging low 🤣

@JoshData
What do You think?

[Georg-Git]

I have been considering the question regarding TLSv1.0 and 1.1 again.

The security of data exchange between email servers does not concern me.
However, the protection of my credentials for my email account is a top priority.

When I consider man-in-the-middle attacks while my mobile phone is connected to Wi-Fi hotspots in hotels or airports and I am checking my email account, I am concerned. Even though I have configured my email clients to use only the secure ports 993 and 465, which only work with TLS encryption, this is useless if TLS versions < 1.2 are used.

That's why I'm a little nervous now, because I thought you couldn't configure different TLS versions on port 465 and port 25?

But even now,
box.occams.info:465
only offers TLS >v1.1.

Whereas
box.occams.info:25
also accepts TLS 1.0 and 1.1.

Long story short:
this PR is perfect 🤣