How to follow cipher sequence for mail?

Richard G

Richard G

Verified User
Joined
Jul 6, 2008
Messages
13,409
Location
Maastricht
When doing a mail test, it seems the cipher sequence is not followed. This is for all Directadmin servers.
Oke this is done with Google Translate since I'm not English, but this is what it says:
Server discredited cipher order:
Receiving mail servers enforce their cipher preference during negotiation with sending mail servers, and do not accept preference from the sending mail servers. (Requirement level: Required);
Click to expand...

We would like to fix this, so this is working correctly. It can be done it seems, but I don't know how.
 
Richard G said:
When doing a mail test, it seems the cipher sequence is not followed. This is for all Directadmin servers.
Oke this is done with Google Translate since I'm not English, but this is what it says:


We would like to fix this, so this is working correctly. It can be done it seems, but I don't know how.
Click to expand...
This is wen you do that test in English internet.nl for example
Verdict:

At least one of your mailservers does not enforce its own cipher preference ('I').

Test explanation:​


We check if your receiving mail servers (MX) enforce their own cipher preference ('I'), and offer ciphers in accordance with the prescribed ordering ('II').
If your mail servers support 'Good' ciphers only, this test is not applicable as the ordering has no significant security advantage.
I. Server enforced cipher preference: The receiving mail servers enforce their own cipher preference while negotiating with sending mail servers, and do not accept any preference of the sending mail servers. (requirement level: Required);
II. Prescribed ordering: Ciphers are offered by the receiving mail server in accordance with the below prescribed order in which safe and fast ciphers are preferred.
A. Prefer 'Good' over 'Sufficient' over 'Phase out' ciphers (requirement level: Required);
B. Within a particular security level, proceed as follows:
  1. Ciphers that perform key exchange based on elliptic curves are preferred over those that use finite fields. Both are preferred over ciphers that use a static key exchange (requirement level: Recommended);
  2. Ciphers that do bulk encryption based on AEAD algorithms are preferred over alternatives (requirement level: Recommended);
  3. Ciphers that do certificate verification based on ECDSA are preferred over RSA (requirement level: Recommended);
  4. Ciphers are preferred in descending order of their key and then hash size (requirement level: Recommended);
  5. AES-256 is preferred over ChaCha20 (requirement level: Optional).
In the above table with technical details only the first found out of prescribed order algorithm selections are listed, with the violated prescribed ordering rule shown next to it.
See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B2-5.
Click to expand...

Download

english.ncsc.nl

IT Security Guidelines for Transport Layer Security (TLS)

These guidelines are intended to aid during procurement, set-up and review of configurations of the Transport Layer Security protocol (TLS). TLS is the most popular protocol to secure connections on the Internet.
english.ncsc.nl english.ncsc.nl

And Yes defaults on DA servers give those errors there.

I also don't know how to solve.

CENTOS 8 here. latest DA , EXIM, Exim.conf and dovecot
 
Last edited:
I found this which could help. Seems you need to choose the order in which the need to be applied or tried.

www.acunetix.com

Recommendations for TLS/SSL Cipher Hardening | Acunetix

Many common TLS misconfigurations are caused by choosing the wrong cipher suites. Old or outdated cipher suites are often vulnerable to attacks. If you use them, the attacker may intercept or modify data in transit. Below is a list of recommendations for a secure SSL/TLS implementation.
www.acunetix.com www.acunetix.com
 
Yes I found that and others too, but I would like to know how to adjust this in DA.
And also why this is not by default, while that would be a good thing.
 
Seems I missed something.
The site give some explanation somewhere that the result can also issue this warning if only good ciphers are supported.
Since we only use TLS 1.2 maybe there is nothing wrong.
 
Richard G said:
Seems I missed something.
The site give some explanation somewhere that the result can also issue this warning if only good ciphers are supported.
Since we only use TLS 1.2 maybe there is nothing wrong.
Click to expand...
Uh no while we have one with more tls versions and same problem 1.3 and 1.2 default DA centos 8
 
But DA only has a few ciphers. If you do the test and check cipher sequence, it says this:
Code: 
Als je mailserver alleen 'Goede'ciphers ondersteunt, dan is deze test niet van toepassing aangezien de volgorde geen significant beveiligingsvoordeel oplevert.
So I don't know what DA could do about it then.
 
Richard G said:
But DA only has a few ciphers. If you do the test and check cipher sequence, it says this:
Code: 
Als je mailserver alleen 'Goede'ciphers ondersteunt, dan is deze test niet van toepassing aangezien de volgorde geen significant beveiligingsvoordeel oplevert.
So I don't know what DA could do about it then.
Click to expand...
Ok i understand you point.

Still if so only good cipher, still then for future proof it stay's relevant to have a good cipher order , also in combinations when they become older and no good, or you have to support old ones and so on.
 
Correct. I've seen test were this was green from other providers working also with DA and cloudlinux linke Vimexx and Antagonist. But I don't know if they have more ciphers. However, if the test isn't applicable like stated in that quote, it should get green or grey and not a red cross.
So I'm still a bit confused about this.
 
I'm using DA and get a perfect 100% score on website and email, using these ciphers:

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
 
sysdev said:
I'm using DA and get a perfect 100% score on website and email, using these ciphers:

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
Click to expand...
Did you customize them or is this the standard da config?
 
sysdev said:
I'm using DA and get a perfect 100% score on website and email, using these ciphers:
Click to expand...
I have the default ones. These:
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
Seems the same you're having.
 
@sysdev Did you do the website test or the e-mail test? Because the issue about the cipher sequence is only shown when doing the email test.
I don't see this issue when doing the website test either.
 
Richard G said:
@sysdev Did you do the website test or the e-mail test? Because the issue about the cipher sequence is only shown when doing the email test.
I don't see this issue when doing the website test either.
Click to expand...
Both a 100% score. No issues here. What's the domainname you're trying?

If you're using tlsa, there's a bug in the ../scripts/tlsa.sh at line 168 where it needs another dot (.) after the domainname to pass the internet.nl dane/tlsa check
 
You must log in or register to reply here.
Back
Top