Re: [exim] Define preferred encryption algorithms
> On Oct 10, 2019, at 10:30 AM, jmedard--- via Exim-users > wrote: > > 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. Some of these tools are developed by folks without a long history of experience in TLS for SMTP, and who may not have internalized the message of https://tools.ietf.org/html/rfc7435 In particular, with opportunistic TLS, it is more important to interoperate than to set a high strict "floor" on TLS security. The reason is that failure to negotiate common TLS parameters often results in transmission in the clear as a fallback. Which is hardly an improvement. Therefore, resist the temptation to crank up security to 11, and try to avoid being overly prescriptive in your cipher choices. You can certainly disable the most obvious obsolete ciphers that nobody uses anymore, but otherwise should generally use the default settings of your TLS library. That said, enabling server cipher preference is not unreasonable for MTAs, and should be largely harmless. If you feel you must specify the ciphers, with OpenSSL I recommend: DEFAULT:!EXPORT:!LOW:!aDSS:!kECDH:!kDH:!MD5:!RC4:!3DES:!SEED:!RC2:!RC5:!IDEA This does not exclude future strong ciphers by specifying only a specific list of current candidates, by using the default list, and only subtracting legacy ciphers that may still be enabled in your library depending on how old it is. * !DSS - disable support for DSA certificates nobody uses * !kECDH - disable support "fixed ECDH" that lacks forward secrecy, is not and should not be used * !kDH - ditto for "fixed DH" * !MD5 - Just in case you somehow failed to disable SSLv2, disabling MD5 also disables all SSLv2 ciphers. * The rest are obsolete encryption algorithms that are almost never used. In the case of RC4 and 3DES, it is possible that you'll break TLS with a tiny fraction of peers. You could check your logs for evidence of extant use after enabling server cipher preference, and leaving these enabled initially to see whether they're still needed for your mail traffic. -- Viktor. -- ## 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/
Re: [exim] Define preferred encryption algorithms
Hello, Thank you for your answer. Yes, I am talking about EXIM with the use of OpenSSL. I understand that EXIM is limited to the specifications of the OpenSSL library. Regards JME -Message d'origine- De : Exim-users De la part de Jeremy Harris via Exim-users Envoyé : vendredi 11 octobre 2019 11:55 À : exim-users@exim.org Objet : Re: [exim] Define preferred encryption algorithms On 10/10/2019 15:30, jmedard--- via Exim-users wrote: > 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. > > > > How is it possible to define a cipher algorithm preference, please? Since you mention openssl_options I'm assuming you are using an Exim built for use with OpenSSL. Please doublecheck this, as it affects the answer. We are limited by what the library provides. The openssl_options are fed to the SSL_CTX_set_options() interface (via some fairly-obvious processing). The tls_require_ciphers is fed to SSL_CTX_set_cipher_list(). http://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_conne ctions_using_tlsssl.html#SECTreqciphssl talks about order of the list of ciphers, which to me implies that the library uses that order as a preference. -- Cheers, Jeremy -- ## 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/ -- ## 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/
Re: [exim] Define preferred encryption algorithms
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 De la part de Russell King via Exim-users Envoyé : vendredi 11 octobre 2019 12:06 À : jmed...@amv-sa.fr Cc : exim-users@exim.org 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 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/ -- ## 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/
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 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/
Re: [exim] Define preferred encryption algorithms
On 10/10/2019 15:30, jmedard--- via Exim-users wrote: > 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. > > > > How is it possible to define a cipher algorithm preference, please? Since you mention openssl_options I'm assuming you are using an Exim built for use with OpenSSL. Please doublecheck this, as it affects the answer. We are limited by what the library provides. The openssl_options are fed to the SSL_CTX_set_options() interface (via some fairly-obvious processing). The tls_require_ciphers is fed to SSL_CTX_set_cipher_list(). http://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTreqciphssl talks about order of the list of ciphers, which to me implies that the library uses that order as a preference. -- Cheers, Jeremy -- ## 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/
Re: [exim] String Search - What am I doing wrong?
Graeme Fowler via Exim-users (Do 10 Okt 2019 08:45:51
CEST):
> On 10 Oct 2019, at 03:40, Rob Gunther via Exim-users
> wrote:
>
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html
>
> So it would be somehting like:
>
> ${if match{$spam_report:}{\NVIRUS[(]\N}}
The character class isn't required there
${if match{$spam_report:}{\NVIRUS\(\N}}
or w/o \N
${if match{$spam_report:}{VIRUS\\(}}
Tested on the command line:
$ exim -be '${if match{VIRUS(}{\NVIRUS\(\N}}
true
Make sure, that you do not use the string "VIRUS" as a macro in your
configuration already.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 -
signature.asc
Description: PGP signature
--
## 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/
[exim] Define preferred encryption algorithms
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. How is it possible to define a cipher algorithm preference, please? Regards, JME -- ## 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/
