cannot allow TLS1.0, TLS1.1 in exim

W

wtptrs

Verified User
Joined
Jul 13, 2015
Messages
324
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.
Click to expand...

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.
 
wtptrs said:
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.
Click to expand...


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().
Click to expand...
 
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.
 
mxroute said:
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
Click to expand...

I mean how vulnerable is tls 1.1 anyway? Have they cracked the chiphers? No, they upgrade the standard.

But oops, they are also locking out people who have legacy software, and what do you know, it's 2025 now and there is this EPIC Windows TPM2.0 push to get your head right into the cloud.

So who has the false sense of security (privacy) now?

If it ain't broke don't fix it... You will find one day that you are so upgraded you can't even function
 
Hetzner DirectAdmin said:
I mean how vulnerable is tls 1.1 anyway? Have they cracked the chiphers? No, they upgrade the standard.

But oops, they are also locking out people who have legacy software, and what do you know, it's 2025 now and there is this EPIC Windows TPM2.0 push to get your head right into the cloud.

So who has the false sense of security (privacy) now?

If it ain't broke don't fix it... You will find one day that you are so upgraded you can't even function
Click to expand...

Look, TLS 1.1 has actual documented vulnerabilities that have been exploited in the wild. BEAST attack from 2011 can decrypt HTTPS cookies through CBC mode weaknesses. CRIME and BREACH can extract session tokens and passwords by exploiting compression. These aren't theoretical - they've been demonstrated.

And it's missing modern protections - no AEAD ciphers, no perfect forward secrecy by default, still allows RC4 which is cryptographically broken at this point.

The fact that they upgraded the standard is exactly the point. They didn't upgrade for fun - they did it because the old versions were inadequate. There's a reason every major browser dropped support for TLS 1.0/1.1 in 2020 and PCI DSS banned it for payment processing back in 2018.

Just because something hasn't been cracked in your specific case doesn't mean it's secure. It means you haven't been a target worth the effort. With email servers you're handling sensitive data constantly - why leave that door open when there's zero reason to still be running 1.1?

If you're going to allow yourself to be vulnerable, don't lecture me about how your software NEEDS to be given a fake, server-side message telling it that it has a secure and encrypted connection. That's your problem. Either stop using outdated and insecure software, or stop demanding that the server lie to you about having a secure connection.
 
mxroute said:
There's a reason every major browser dropped support for TLS 1.0/1.1 in 2020 and PCI DSS banned it for payment processing back in 2018.
Click to expand...

I absolutely agree TLS1.1 should not be used for payment processors and even websites. But to send private emails, one has to balance security with accessibility, they are still private communications, and, are the cornerstone of any "20th century" state democracy.

We have a lot of of blocking out TLS 1.2 at this point, and a lot of new software that seem to have only one goal in mind.

Now having said that, I do not want to get into the politics of why the planet desperately needs to eliminate privacy for its own survival and well being.

But still, locking down TLS1.1 and TLS1.2 just for "security" and for your "safety"?
 
The real issue is you can't tell a customer they have a secure connection when they don't. Malicious client-side software can force protocol/cipher downgrades. If you allow insecure protocols, local malware can transparently downgrade the connection without the user knowing. That's the problem: they think they're secure when they're not.

Being insecure should be a conscious choice. That's why supporting plain non-SSL connections alongside modern TLS makes sense. When someone connects without encryption, it's explicit and they know what they're getting.
 
You must log in or register to reply here.
Back
Top