Disabling Weak Cipher Suites in Exim Configuration

As part of our ongoing efforts to enhance security, it has come to our attention that certain cipher suites used for encryption in Exim may be considered weak and vulnerable to security threats. To mitigate these risks, we are seeking guidance on how to effectively exclude these weak cipher suites from our server’s configuration.

Specifically, we are looking to disable the following weak cipher suites:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048)
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048)
TLS_DHE_RSA_WITH_AES_128_CCM (dh 2048)
TLS_DHE_RSA_WITH_AES_256_CCM (dh 2048)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048)

Could you please provide instructions or guidelines on how to achieve this in our Exim server configuration? Any insights or recommendations you can offer would be greatly appreciated.

Thank you for your attention to this matter.

See section 4.

As @linkp said, you could take a look to the Exim doc but not section 4, instead check section 5 because Exim4 in Debian and Ubuntu uses gnutls instead of openssl.

Also check priority strings:

The default from Hestia is this:

tls_require_ciphers = PERFORMANCE:-RSA:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3:%SERVER_PRECEDENCE

Checking it with sslscan and testssl.sh show a couple of issues:

sslscan

Command used: ./sslscan --show-sigs hestia.server.tld:465

It shows an issue with Server Signature Algorithm that allows the use of rsa_pkcs1_sha1 from client side:

imagen

testssl.sh

Command used: ./testssl.sh hestia.server.tld:465

And it shows 3 issues.

1.- Server is offering obsolete CBC ciphers

2.- As sslscan also said, it is showing that our mail server is able to use a weak signature algorithm RSA+SHA1:

imagen

3.- Testing vulnerabilities… as we are using CBC, it shows that we could be potentially vulnerable to LUCKY13:

And now, what I use in exim conf:

tls_require_ciphers = SECURE128:-RSA:-VERS-ALL:!SHA1:!SHA256:!SHA384:+VERS-TLS1.2:+VERS-TLS1.3:%SERVER_PRECEDENCE

With above conf, it doesn’t allow the use of weak sha1 signatures and also doesn’t allow CBC ciphers.

Checking it again with sslscan and testssl.sh it doesn’t show issues anymore:

sslscan

imagen

testssl.sh

imagen

imagen

So this conf I think it is secure enough (at least for my needs). If you want another thing, you should play with priority strings and/or allow only the ciphers you want to use.

3 Likes

Effective immediately, we have implemented changes to enhance the security of our email communications. Specifically, we have transitioned to exclusively utilize TLS 1.3 encryption standards.

Here’s the exact configuration we’ve implemented:

tls_require_ciphers = SECURE192:!VERS-SSL3.0:!VERS-TLS1.0:!VERS-TLS1.1:!VERS-TLS1.2:!VERS-DTLS0.9

This configuration ensures that our email server only accepts connections using TLS 1.3 protocol, enhancing the security and confidentiality of our communication channels. By employing this setup, we aim to mitigate potential vulnerabilities associated with older encryption protocols.

SERVER_PRECEDENCE - Could you please provide an explanation of what this parameter does and how it can be used to control our server’s behavior in terms of cipher selection during the TLS handshake?

Scan:

nmap -sV -p 587 -T4 -A -Pn --script ssl-enum-ciphers xx.xx.xx.xx

PORT STATE SERVICE VERSION
587/tcp open smtp
| ssl-enum-ciphers:
| TLSv1.3:
| ciphers:
| TLS_AKE_WITH_AES_256_GCM_SHA384 (secp384r1) - A
| TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (secp384r1) - A
| cipher preference: client
|_ least strength: A
| fingerprint-strings:
| GenericLines, GetRequest:
| 220 ESMTP
| unrecognized command
| unrecognized command
| Hello:
| 220 ESMTP
| Syntactically invalid EHLO argument(s)
| Help:
| 220 ESMTP
| 214-Commands supported:
| AUTH STARTTLS HELO EHLO MAIL RCPT DATA BDAT NOOP QUIT RSET HELP
| NULL:
|_ 220 ESMTP

Yes, that config provides enhanced security but it is reducing compatibility but if that fits your needs, perfect :wink:

%SERVER_PRECEDENCE The ciphersuite will be selected according to server priorities and not the client’s.

1 Like