TLS Hardening

[andrewo]

Hi Guys,

We ran a vulnerability scan against our ProxMox Mail Gateway (5.0-61) and it came back with several issues all relating to TLS. Summary of the issues below:

1. TLS 1.0 supported, which is insecure
2. TLS 1.1 supported, which is insecure
3. SSL Anonymous ciphers supported

After some digging, turns out these issues can be addressed by modifying main.cf by adding something like the following:

smtpd_tls_protocols = TLSv1.2,!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_ciphers = high

The issue is after saving main.cf and rebooting the appliance the changes are reverted to default. Also, at the top of the config it says "# auto-generated by proxmox" leading me to believe this is overwritten by ProxMox.

Can somebody clarify how we can harden our deployment to close these security gaps?

Thanks,
Andrew

 

[dcsapak]

you should not modify the main.cf directly, but copy and use the template for that, see
https://<your-pmg-host>:8006/pmg-docs/pmg-admin-guide.html#_service_configuration_templates
for that

 

[andrewo]

Thank you for these additional details. Just so I'm completely clear, can you confirm the below steps are accurate?
1. Copy /var/lib/pmg/templates/main.cf.in to /etc/pmg/templates/main.cf.in
2. Edit /etc/pmg/templates/main.cf.in and add the config I referenced in my post
3. Save /etc/pmg/templates/main.cf.in
4. Run the following command to apply the changes: pmgconfig sync --restart 1

 

[dcsapak]

yes

 

[andrewo]

Thanks! Does location of where I dump the new config in main.cf.in matter?

 

[dcsapak]

Thanks! Does location of where I dump the new config in main.cf.in matter?

it should not matter

 

[heutger]

Hi Andrew,

be careful. I tried to harden my SMTP configuration as well such a way a long time ago and stopped doing so. You will reject many senders and the German federal information security office recommends either also to allow NULL ciphers because of worse configured incoming or outgoing mail server partners. So for HTTP it works well to harden the configuration, but for mail servers, I won't be too strict, if you don't want to reject legit senders, which are just using mail servers of lame admins.

Regards,
Christian

 

[andrewo]

Hi Andrew,

be careful. I tried to harden my SMTP configuration as well such a way a long time ago and stopped doing so. You will reject many senders and the German federal information security office recommends either also to allow NULL ciphers because of worse configured incoming or outgoing mail server partners. So for HTTP it works well to harden the configuration, but for mail servers, I won't be too strict, if you don't want to reject legit senders, which are just using mail servers of lame admins.

Regards,
Christian

Hi Christian - Thank you for your comment. Since we leverage opportunistic TLS, will it not simply fallback to sending an unencrypted message if it is not possible to do so using strong encryption? Let me know your thoughts.

 

[heutger]

Hi Christian - Thank you for your comment. Since we leverage opportunistic TLS, will it not simply fallback to sending an unencrypted message if it is not possible to do so using strong encryption? Let me know your thoughts.

I thought the same, but I found, that if someone is entering the STARTTLS dialogue, why stay in this dialogue and it can result, that they then get declined because of incompatible cipher suites. It looks like they then won't fall back to no TLS again. That were my experiences with large providers like 1&1, which don't support modern cipher suites and therefor connection has been dropped and they can't send me mails anymore. Sad but true it's like SPF, on HTTP(S) harder requirements are running well, but on mail way, they don't. However, best encryption is end-to-end encryption on the mail way, e.g. with S/MIME.

 

[heutger]

I had my recent test with 1&1, HUK and others some time ago, so it's time to do a retest. I now worked a bit on mail security and on success I will report on my Advancing Thread also. So I first set up MTA-STS for enforced STARTTLS (similar to HSTS).

Additional I now harden the Postfix TLS configuration. As delivered it's really weak, weak protocols, weak and insecure ciphers and most worse, no server preference on cipher suites.

Last although feeling bad with that, I set up SPF as well. SPF is no good concept, as seen by experts as well, and it's not recommended to hard fail on SPF (which is been done, if SPF is enabled and records provide -all), but however, I want to have as much green as possible in Hardenize, so I now also set a SPF record. ^^

So what I did is changing the TLS section like this:

[% IF pmg.mail.tls %]
smtp_tls_security_level = may
smtp_tls_policy_maps = hash:/etc/pmg/tls_policy
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/pmg/pmg-tls.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_mandatory_ciphers = medium
tls_medium_cipherlist = AES128+EECDH:AES128+EDH
tls_preempt_cipherlist = yes
[% IF pmg.mail.tlslog %]

New should be only

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_mandatory_ciphers = medium
tls_medium_cipherlist = AES128+EECDH:AES128+EDH
tls_preempt_cipherlist = yes

I had taken this one from https://cipherli.st which is a somehow good source for CipherSuite recommendations. However, my web server has been stronger setup with my last update, I removed all weak cipher suites from SSLlabs test, however for mail servers should be a bit less strict.

 

[heutger]

I'm still testing, I added some more ciphers to my cipher list and added TLSv1 as well as TLSv1.1 to be supported. Reason is, that some servers do not yet support TLSv1.2 and then send via clear text. It's better to use a weak protocol than sending in plain text. All servers being able to send via TLSv1.2 also don't fall back to TLSv1 or TLSv1.1. TLSv1.1 never has been used, but when supporting TLSv1 also TLSv1.1 could be supported.

Current setup is:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_mandatory_ciphers = medium
tls_medium_cipherlist = AES128+EECDH:AES256+EECDH:AES128+EDH:AES256+EDH
tls_preempt_cipherlist = yes

But I would also add a line for smtp_tls_ciphers (because mandatory would only been chosen by mandatory encryption, as it's set to may, should be also set, however, default is already medium).

 

[heutger]

I'm still testing, but my setup looks fine now. I will use my advancing thread to keep information updated. I recently just changed the order (first 256 bit AES, then 128 bit AES) and added the line as mentioned above. I will see, if I can leave out 128 bit at all and I will test with a 4096 bit key instead of 2048 bit as well. Then I will finalize my tryouts. Meanwhile I started testing with this "relaxed" configuration, cipherli.st updated their recommendations to use GCM ciphers only. However, I already recognized, that I won't recommend to do so, as beside Amazon and Amazon SES I still have some sites, which do not support GCM ciphers at all and I won't want to keep them off sending me mail with transport encryption.

Current (and finally for this thread) setup is:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_ciphers = medium
tls_medium_cipherlist = AES256+EECDH:AES128+EECDH:AES256+EDH:AES128+EDH
tls_preempt_cipherlist = yes