Hello,
I tested well with: "cipher preference: server" , the openssl_options:
"+cipher_server_preference" , but I hadn't done enough tests.
Indeed, they correctly describe the order of the encryption algorithms, it
works.
Thank you very much for your help.
Regards
-----Message d'origine-----
De : Exim-users <exim-users-bounces+jmedard=amv-sa.fr@???> De la part
de Russell King via Exim-users
Envoyé : vendredi 11 octobre 2019 12:06
À : jmedard@???
Cc : exim-users@???
Objet : Re: [exim] Define preferred encryption algorithms
On Thu, Oct 10, 2019 at 04:30:29PM +0200, jmedard--- via Exim-users wrote:
> Hello,
>
>
>
> More and more Internet security diagnostic tools (such as Immuniweb
> and
> Hardenize) specify that mail servers should be able to offer their
> preferred encryption algorithms. They consider it a security risk if
> the server must not be configured to select the best-available suite.
>
>
>
> They say: "The server does not prefer cipher suites. We advise to
> enable this feature in order to enforce use of the best cipher suites
selected."
>
>
>
> On Exim the order of the encryption string, present in
"tls_require_ciphers"
> does not matter, the order is not used.
>
>
>
> I think this requires the switch to "Server preference", via the
> openssl_options: "+cipher_server_preference", but it is not enough for
> the server to define a recommended encryption algorithm.
Hi,
I don't know whether you're subscribed to the list or not, so I'll Cc my
reply to you.
Some background in SSL/TLS may be beneficial.
When SSL starts up, the client sends a "Client Hello" that identifies the
ciphers it supports (and other data.)
The server compares the list with its own cipher list to identify those
ciphers supported by both ends. The server then selects one of those
ciphers and sends the selected cipher back in the "Server Hello".
The way openssl under exim selects the cipher depends on this
"+cipher_server_preference" flag:
- If this flag is not set, the first common cipher in the order of
the client's list will be selected. This means the client has the
power to select which cipher will be used. The client _could_ list
weak ciphers before strong ciphers, and you'd end up with a weak
cipher.
- If this flag is set, the first common cipher in the order of the
server's list will be selected. Provided the server's list is in
the order of strongest..weakest, it gives the server the ability
to select the strongest supported common cipher irrespective of
what the order of ciphers that client has sent.
So, "+cipher_server_preference" is what you want.
What may be causing your problem is the way you are specifying the ciphers
to the server. There are various prefixes to that change how the cipher
list is created.
To see the list of ciphers, use:
$ openssl ciphers <whatever-you-have-in-tls_require_ciphers>
It's worth pointing out that you have to be _very_ careful with the cipher
list, because ciphers can move around depending on how you specify them in
the list. Here's what the prefix characters mean (grabbed from the openssl
ciphers man page):
If ! is used then the ciphers are permanently deleted from the
list. The ciphers deleted can never reappear in the list even if
they are explicitly stated.
If - is used then the ciphers are deleted from the list, but some
or all of the ciphers can be added again by later options.
If + is used then the ciphers are moved to the end of the list.
This option doesn't add any new ciphers it just moves matching
existing ones.
Beware of the "+" prefix - even if you explicitly list a strong cipher at
the start of the list, it can have the effect of moving that cipher lower
down in the list.
As an example:
kEECDH:kRSA:kEDH:kPSK:+CAMELLIA128:+AES256:...
on some versions of openssl, can result in the first cipher being
ECDHE-RSA-AES128-GCM-SHA256, with ECDHE-RSA-AES256-GCM-SHA384 being way
lower in the list (because +AES256 moved it there, after the
CAMELLIA128 ciphers.) Removing the + from AES256 in that string results in
the first four being:
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
Note: I am not recommending any particular ciphers in this post, I am just
pointing out how this works and the pitfalls that you might be falling in
to.
Personally, I use
https://github.com/drwetter/testssl.sh to test non- https
services, which has similar functionality to a popular online checker for
https.
Hope this helps.
--
Russell King
--
## List details at
https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
