cannot allow TLS1.0, TLS1.1 in exim

wtptrs

Verified User
Joined
Jul 13, 2015
Messages
329
I need to temporarily allow TLS1.0 and TLS1.1 in exim for a customer using an older email-client. When I set

Code:
openssl_options=+no_sslv2 +no_sslv3

in /etc/exim.variables.conf.custom and run

Code:
./build update
./build exim_conf

/etc/exim.variables.conf is updated with the edited openssl_options variable, but when I check for a mail certificate on https://ssl-tools.net/mailservers , TLS1.0 and TLS1.1 are still not allowed.

The server is running Debian 9 and the latest Directadmin, CB and exim_conf versions.

Anything I'm forgetting?

edit: if I set

Code:
openssl_options=+all

only TLSv1.2 is enabled. I can disable TLSv1.2 and it shows on the testing website, but enabling older TLS versions doesn't seem to work.
 
Last edited:
Having the same issue on CentOS 8. The same configuration worked on CentOS 7. The error message when the client tries to send mail:

TLS error on connection ... (SSL_accept (TLSv1)): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol
 
Are they using an old mail client?

And have you changed the setting in custombuild to another (eg. ssl_configuration = old)? NB: not sure if this setting is only for webservers
 
It may have to do with this: https://access.redhat.com/articles/3642912

LEGACY: This policy ensures maximum compatibility with legacy systems; it is less secure and it includes support for TLS 1.0, TLS 1.1, and SSH2 protocols or later. The algorithms DSA, 3DES, and RC4 are allowed, while RSA and Diffie-Hellman parameters are accepted if larger than 1023-bits.

The DEFAULT policy is a reasonable default policy for today's standards, aimed for a balance between usability and security. It allows the TLS 1.2 and 1.3 protocols, as well as IKEv2 and SSH2. The RSA and Diffie-Hellman parameters are accepted if larger than 2047-bits.

I am thinking that update-crypto-policies --set LEGACY will allow the client to connect. Waiting to hear back to know for sure.
 
OpenSSL 1.1.1g 21 Apr 2020

It looks like I have to reboot to see if update-crypto-policies --set LEGACY made a difference. Will do that overnight.
 
Update: update-crypto-policies --set LEGACY fixed the problem even without rebooting, although I did restart exim.
 
I need to temporarily allow TLS1.0 and TLS1.1 in exim for a customer using an older email-client. When I set

Code:
openssl_options=+no_sslv2 +no_sslv3

in /etc/exim.variables.conf.custom and run

Code:
./build update
./build exim_conf

/etc/exim.variables.conf is updated with the edited openssl_options variable, but when I check for a mail certificate on https://ssl-tools.net/mailservers , TLS1.0 and TLS1.1 are still not allowed.

The server is running Debian 9 and the latest Directadmin, CB and exim_conf versions.

Anything I'm forgetting?

edit: if I set

Code:
openssl_options=+all

only TLSv1.2 is enabled. I can disable TLSv1.2 and it shows on the testing website, but enabling older TLS versions doesn't seem to work.


Looks like there may be a similar issue in Debian: https://forum.nginx.org/read.php?2,281984,281984

Found this in Debian news, basically they've disabled TLS 1.0 / 1.1 - apps have to ask for these versions specifically:


* Instead of completly disabling TLS 1.0 and 1.1, just set the minimum
version to TLS 1.2 by default. TLS 1.0 and 1.1 can be enabled again by
calling SSL_CTX_set_min_proto_version() or SSL_set_min_proto_version().
 
Thanks twv! I think this only works on Debian 10, but we succeeded in convincing the customer to change mail clients, which is the better solution all around :)
 
Sorry to bump this once again, seems like we have a lot more customers that are using older email clients not compatible with TLS 1.2, such as Outlook 2011 for Mac and Apple Mail 9.3 . I understand this is not really Directadmin but rather Debian 9-related, but hopefully someone with the same issue reading this forum has found a solution in the past.

EDIT: I think it's working now, haven't been able to test with an older email client yet but at least the legacy protocols are showing up now when testing online.

Code:
mkdir -p /usr/local/directadmin/custombuild/custom/dovecot/conf
nano /usr/local/directadmin/custombuild/custom/dovecot/conf/ssl.conf

ssl_cert = </etc/exim.cert
ssl_key = </etc/exim.key
ssl_dh = </etc/dovecot/dh.pem

ssl_min_protocol = TLSv1
ssl_cipher_list = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

nano /etc/exim.variables.conf.custom

openssl_options=+no_sslv2 +no_sslv3
tls_require_ciphers=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA

cd /usr/local/directadmin/custombuild
./build update; ./build dovecot_conf; ./build exim_conf

It's basically what ssl_configuration=old in options.conf does for exim and dovecot, but I failed to make the connection because the exim cipher change wasn't mentioned in the tutorial below: https://forum.directadmin.com/threa...tls-1-1-and-older-for-exim-and-dovecot.60422/
 
Last edited:
You should have your clients reconsider this. Which is more important, security or the false image of security? If you're enabling vulnerable and outdated SSL standards so that your clients can have their software tell them it has a secure connection when it does not, why not instead tell them to use non-SSL settings? It is considered a significant security mistake to allow client software to claim it has a secure connection with your server when it is using a protocol that is in fact not secure.

It basically means you're configuring the server to lie to your users. I know it's a hard barrier to overcome with clients that insist on using out of date software, but the rest of them that do practice good security will thank you for your commitment.
 
Of course you're right, and I completely understand. The issue for us is that some older versions of Apple Mail seem to regularly bug out when SSL is not being used. We're allowing these older protocols on one server only, and as a temporary measure, while at the same time explaining the issue to these customers and actively encouraging them to upgrade their email-client / OS or switch to a free, up-to-date alternative such as Thunderbird.
 
Back
Top