Docker-mailserver: en.internet.nl says mail servers supports insufficiently secure parameters for DH key exchange

[Rillke]

At least one of your mail servers supports insufficiently secure parameters for Diffie-Hellman key exchange.

I haven't manually changed any Ciphers or DH KEX Parameters, use the defaults the Image generated/ specified, however I use Let's Encrypt (if this matters).

Configuration:

OVERRIDE_HOSTNAME=
DMS_DEBUG=1
ONE_DIR=1
POSTMASTER_ADDRESS=
PERMIT_DOCKER=
# empty => modern
# modern => Enables TLSv1.2 and modern ciphers only. (default)
# intermediate => Enables TLSv1, TLSv1.1 and TLSv1.2 and broad compatibility ciphers.
# old => NOT implemented. If you really need it, then customize the TLS ciphers overriding postfix and dovecot settings
#        (https://github.com/tomav/docker-mailserver/wiki/)
TLS_LEVEL=
SPOOF_PROTECTION=1
ENABLE_SRS=0
ENABLE_POP3=
ENABLE_CLAMAV=1
ENABLE_FAIL2BAN=1
ENABLE_MANAGESIEVE=
POSTSCREEN_ACTION=enforce
SMTP_ONLY=
# Please read [the SSL page in the wiki](https://github.com/tomav/docker-mailserver/wiki/Configure-SSL) for more information.
#
# empty => SSL disabled
# letsencrypt => Enables Let's Encrypt certificates
# custom => Enables custom certificates
# manual => Let's you manually specify locations of your SSL certificates for non-standard cases
# self-signed => Enables self-signed certificates
SSL_TYPE=letsencrypt
VIRUSMAILS_DELETE_DELAY=
ENABLE_POSTFIX_VIRTUAL_TRANSPORT=
POSTFIX_DAGENT=
POSTFIX_MAILBOX_SIZE_LIMIT=512000000
POSTFIX_MESSAGE_SIZE_LIMIT=10240000
REPORT_RECIPIENT=0
REPORT_SENDER=
REPORT_INTERVAL=daily
ENABLE_SPAMASSASSIN=1
SA_TAG=2.0
SA_TAG2=6.31
SA_KILL=6.31
SA_SPAM_SUBJECT=***SPAM*****
ENABLE_FETCHMAIL=0
FETCHMAIL_POLL=300
ENABLE_LDAP=
LDAP_START_TLS=
LDAP_SERVER_HOST=
LDAP_SEARCH_BASE=
LDAP_BIND_DN=
LDAP_BIND_PW=
LDAP_QUERY_FILTER_USER=
LDAP_QUERY_FILTER_GROUP=
LDAP_QUERY_FILTER_ALIAS=
LDAP_QUERY_FILTER_DOMAIN=
DOVECOT_TLS=
DOVECOT_USER_FILTER=
DOVECOT_PASS_FILTER=
DOVECOT_MAILBOX_FORMAT=maildir
ENABLE_POSTGREY=1
POSTGREY_DELAY=306
POSTGREY_MAX_AGE=35
POSTGREY_TEXT=Delayed by graylisting
POSTGREY_AUTO_WHITELIST_CLIENTS=5
ENABLE_SASLAUTHD=0
SASLAUTHD_MECHANISMS=
SASLAUTHD_MECH_OPTIONS=
SASLAUTHD_LDAP_SERVER=
SASLAUTHD_LDAP_SSL=
SASLAUTHD_LDAP_BIND_DN=
SASLAUTHD_LDAP_PASSWORD=
SASLAUTHD_LDAP_SEARCH_BASE=
SASLAUTHD_LDAP_FILTER=
SASLAUTHD_LDAP_START_TLS=
SASLAUTHD_LDAP_TLS_CHECK_PEER=
SASL_PASSWD=
SRS_SENDER_CLASSES=envelope_sender
SRS_EXCLUDE_DOMAINS=
SRS_SECRET=
DEFAULT_RELAY_HOST=
RELAY_HOST=
RELAY_PORT=25
RELAY_USER=
RELAY_PASSWORD=

Report result:

[hanscees]

You should not use the certificates the server provides. You should use letsencrypt certificates or other official certificates.

Then test again.

[hanscees]

However, in main.cf:

smtpd_tls_dh1024_param_file = /etc/postfix/dhparams.pem
smtpd_tls_CApath = /etc/ssl/certs

so indeed the dh seems weak and should be 2048.

You can generate a stronger one by doing (inside container)

cd /etc/postfix/
openssl dhparam -out dhparam-2048.pem 2048

mv dhparams.pem dhparams.old
mv dhparam-2048.pem dhparams.pem
supervisorctl restart postfix

[Rillke]

You should not use the certificates the server provides.

Sure, I added that to the initial issue report. I am using Let's Encrypt but didn't change any Cipher Suite or DH Params. Letsencrypt works as expected.

[Rillke]

You can generate a stronger one by doing (inside container)
cd /etc/postfix/
openssl dhparam -out dhparam-2048.pem 2048

This looks very similar to what the start-mailserver.sh already did. What would be the difference? Is en.internet.nl maybe wrong about the DH params? Have you tried with your own?

https://github.com/tomav/docker-mailserver/blob/2a6d8ca6fadcdd2d7a0f89e9d2080e12caa7a29b/target/start-mailserver.sh#L1314

[hanscees]

well, use this perhaps:
https://github.com/mimoo/test_DHparams

A better script is here:
https://github.com/portcullislabs/ssl-cipher-suite-enum

some conclusions:

./ssl-cipher-suite-enum.pl --smtp 192.168.xxx:25





0 TLSv1.0 cipher suites supported
0 TLSv1.1 cipher suites supported
[+] Preferred TLSv1.2 cipher suite on 192.168.xxx:25: DHE_RSA_WITH_AES_256_GCM_SHA384[009f] 

[+] 10 TLSv1.2 cipher suites supported

[V] 192.168.0.72:25 - Some encrypted connections may not have forward secrecy
[+] Summary of support cipher suites for 192.168.xx:25

TLSv1.2:
* DHE_RSA_WITH_AES_128_SHA
* DHE_RSA_WITH_AES_256_SHA
* DHE_RSA_WITH_AES_128_CBC_SHA256
* DHE_RSA_WITH_AES_256_CBC_SHA256
* DHE_RSA_WITH_AES_128_GCM_SHA256
* DHE_RSA_WITH_AES_256_GCM_SHA384
* DHE_RSA_WITH_AES_128_CCM
* DHE_RSA_WITH_AES_256_CCM
* DHE_RSA_WITH_AES_128_CCM_8
* DHE_RSA_WITH_AES_256_CCM_8


=== Scan Complete ===

[+] ssl-cipher-suite-enum v1.0.2 completed at Tue Feb 25 22:06:25 2020.  967 connections in 12 secs.

[casperklein]

You can check the bit size with: openssl dhparam -in /etc/postfix/dhparams.pem -text

The site is correctly detecting your dhparams as 2048 bit.

We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'.

According to them, dhparams is considered as insufficient, because it was self-generated. Here I found further explanation.

[hanscees]

Well, my knowledge is not sufficient to know if a change of dhparam to pre-defined groups is better.
A few questions:

• Will it work with other mta's or will they fall back to no encryption at all?
• same for email clients.

Unless there is evidence an enhancement will not cause a brakedown of encryption I would keep it as it is. At least we now know the dhparams are 2048. Thanks Casper!

[casperklein]

IMHO I would leave it as it is. If there were broader problems with MTAs / MUAs, more people would probably complain about it.
There should be no fall back to no encryption.

[hanscees]

IMHO I would leave it as it is. If there were broader problems with MTAs / MUAs, more people would probably complain about it.
There should be no fall back to no encryption.

agree

[erik-wramner]

Close then? If not feel free to suggest a solution.