Solved Did exim.conf 4.5.35 create SSL issue or changed ciphers?

Richard G

Richard G

Verified User
Joined
Jul 6, 2008
Messages
14,155
Location
Maastricht
I did not see an entry in the changelog for exim.conf 4.5.35.
I updated to 4.5.35 (from 4.5.30 if I'm not mistaken) in the night of februari 1 to februari 2nd. I've seen more was updated, because amongst others also dkim.conf was updated.

Now a customer of mine had an internet outage on the 2nd and when all came back online, his printer could not send mail anymore via our system. They could send mail via another provider.

So I checked the logfiles and see this connection on the 1st when everything was working fine:
Code: 
2021-02-01 09:43:26 1l6UnS-00062F-Al <= [email protected] H=(HP9BEFF9) [178.xx.xx.xx] P=esmtpsa X=TLS1.2:DHE-RSA-AES256-GCM-SHA384:256
etc. So there it's working fine.

Now since the first attempt on the 2nd of februari it keeps looking like this:
Code: 
2021-02-02 10:30:20 TLS error on connection from (HP9BEFF9) [178.xx.xx.xx] (SSL_accept): error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
cipher

Since I've seen ssl3 mentioned in the newer log I thought the issue was on their site trying to use sslv3 which is ofcoursen not possible.
But the first part of this line says TLS error, so they are trying to make a TLS connection as before.

So what is going on here? Is this due to the change of exim.conf or why does the printer suddely provides these errors? Because they did not change anything, only they had an internet outage. And on our side only exim.conf and related stuff (like exim.dkim.conf) was updated.
 
@Driesp I had a look but I don't see anything missing, or am I looking wrong?
Code: 
nmap --script ssl-enum-ciphers -p 465 my.ser.ver.ip
Host is up (0.00011s latency).
PORT    STATE SERVICE
465/tcp open  smtps
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors: 
|       NULL
|_  least strength: strong

However, if I try the same test commend with port 587 nothing is happening while normally users can connect on port 587 with TLS, or is it normal that the command does not give a result on port 587?
 
Yes, it is normal.
587 has no encryption, but supports encryption after a TLS upgrade.
NMAP doesn't know how to do that..

Your nmap report looks fine to me.

Can you check the differences of the exim config (do a diff with the configuration from backup)
 
I don't have an exim backup or where can I find this?
However I found something else. Looking on another Centos 8 server I found this one, which is different (don't know if that printer works with that).
Code: 
465/tcp open  smtps
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

On this server I've got [/icode]ssl_cofiguration=intermediate[/icode] in directadmin.conf and this value is not on both other servers.
So where is this difference coming from as I read that this intermediate setting would be the default internal setting?
 
Here you are missing the diffie hellman ciphers.
You should check my last post on my other topic.
 
Oke will do that.
But now it gets more of an issue. On the problem server, I changed the ssl_configuration to intermediate. Restarted DA, then rewrite_confs.
After that, I rebuild exim.conf and only 2 ciphers were left over.

I thought oeps... I had 3 before, so lets change it back. Removed the ssl_configuration line in directadmin.conf and did the rest of the commands the same but still only these 2 are present now:
Code: 
465/tcp open  smtps
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|       NULL
|_  least strength: strong

So now it seems the same error occurs as you had.

I checked your other post, but if you disable dh_perm in /etc/variables.conf this will be overwritten on the next update.
So we have to look for a way to disable this in /etc/variables.conf.custom
 
I am using ssl_configuration=intermediate in custombuild.

And these parameters are active in /etc/exim.variables.conf:
tls_dhparam = /etc/exim_dh.pem
tls_dh_max_bits=4096

You can try to disable both parameters and retest.
/etc/exim_dh.pem is a 4096 bits diffie hellman, exim has by default a limit that ignores bigger diffie hellman ciphers.
 
I have this now:
Code: 
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|       NULL
|_  least strength: strong

If these are correct, you don't need to make any adjustments in /etc/exim.variables.conf but only add tls_dh_max_bits=4096 in /etc/exim.variables.conf.custom (and rebuild eximconf) so they won't be overwritten when there is a new version.
 
Still, on that one server I've got this warning in the last line:
Code: 
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A
any clue on where this warning is coming from?
 
It means that the certificate key is stronger than the cipher used in the elliptic curve key exchange.
I don't know if secp256r1 is less strong then what is available.

I am looking into this one :)
 
Great thank you, because I don't know where it can be coming from because I've configured all 3 servers the same way. Only difference was that this one allready had the ssl_configuration=intermediate present in directadmin.conf which I now also have in both others, although not needed.
But i just like everything the same on all servers. :)

Thank you in advance for looking into this.
 
bdacus01 said:
Something is going on here..
Click to expand...
Yep, same as in the other thread DriesP pointed to, he had the same problem (and others) so seems an issue/bug or unmentioned change in the newest exim.conf concerning dh_perm and loosing some ciphers with this. That should not happen.

Edit: Just seen that smtalk has fixed this now.
 
After some googeling I've found this article: http://fooolix.blogspot.com/2018/02/chasing-x25519.html
I don't know if its trustworthy, but if it is,.. well read it yourself.

Google.com (port 443) supports rsa2048 and ecdh_x25519.

I've tested port 443, 465 and 993 (apache, exim and dovecot)
cpanel: dh2048 and secp256r1.
Directadmin: dh4096 and secp256r1.
Plesk: rsa2048 and ecdh_x25519 (just like google.com)

Maybe something to look into...
 
Indeed interesting. I will read that more thourough.
However, I'm still wondering as why nmap discovers this only on 1 server while the others do not have that warning.
So I must have some configuration different somewhere and at the moment I can't imagine where as they are all the same.
Have to investigate that a bit further.

Thanks for the link!
 
After some digging, I think its fine.

I think nmap doesn't has a preference in key exchange ciphers, and if the server also doesn't, they chose one at will.
Nmap doesn't support TLS1.3 either.
I don't think we should rely on its report that much.
 
Oke I hope so, I just find it odd that on same configures servers only 1 gives a warning. Luckily this is also the least important servers which almost does no mail. Mostly php mail for a couple of radio streams.
Thanks!
 
You must log in or register to reply here.
Back
Top