Re: [exim] Define preferred encryption algorithms

Startseite
Nachricht löschen
Nachricht beantworten
Autor: jmedard
Datum:  
To: exim-users
Betreff: Re: [exim] Define preferred encryption algorithms
Be careful, think about switching to 4.92.3. There is a flaw on 4.92.2 and
all previous versions.

I have exactly the same confused with a few ready details.
In the "tls_require_ciphers" list, TVL1.3 algorithms are not taken into
account. So you can delete:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256,
it is useless.

The TLS1.3 algos are managed by OpenSSL through another list.

In your list you have an error on the last but one: "DHE-RSA-ES256-SHA" does
not exist, it is: "DHE-RSA-AES256-SHA"

On the other hand, you have an extra algo: "DHE-RSA-ESA-ESA-ES256-SHA" which
does not exist a priori.

Unless I'm mistaken, here's the complete list:

tls_require_ciphers =
DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA
384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:
ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-R
SA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA

JME

-----Message d'origine-----
De : Exim-users <exim-users-bounces+jmedard=amv-sa.fr@???> De la part
de Mike Tubby via Exim-users
Envoyé : samedi 12 octobre 2019 15:36
À : exim-users@???
Objet : Re: [exim] Define preferred encryption algorithms


We use Exim 4.92.2 compiled with OpenSSL on Devuan 3.0 Beowulf with GCC
version 8.


#
# Enable TLS with strong ciphers
#
MAIN_TLS_ENABLE = true
openssl_options = -all +no_sslv2 +no_sslv3 +no_compression
+cipher_server_preference


If you use a contracted (short) cipher list like these:

# tolerant cipher list
#tls_require_ciphers =
aNULL:-aNULL:HIGH:MEDIUM:!SSLv2:!RC4:!kECDH:!kDH:@STRENGTH

# strong but tolerant
#tls_require_ciphers = AESGCM:AES256:aNULL:-aNULL:HIGH:MEDIUM:!RC4:@STRENGTH

I think you should put the @STRENGTH modifier at the end to ensure that
they are sorted "strongest to weakest" so you don't pick common weak
ones by default.


More recently (for the last year or so) our production mail servers have
been using the OWASP "Widest comparability" list (List C):

# OWASP Widest Compatibility (List C)
tls_require_ciphers =
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:D
HE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA3
84:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:E
CDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RS
A-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA

as an explicit list of ciphers and I see no failures to negotiate a
common cipher and good use of TLS 1.2 and TLS 1.3 with strong ciphers.

Here a few from the logs:

2019-10-12 10:34:07 HELO: Client 94.143.107.222:44135 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:36:28 HELO: Client 204.92.31.128:15346 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:46:16 HELO: Client 12.130.136.74:37137 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:46:32 HELO: Client 167.89.34.9:50592 using SSL/TLS cipher:
TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:51:29 HELO: Client 185.138.250.49:55619 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:52:43 HELO: Client 199.182.216.132:12305 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:56:32 HELO: Client 204.92.31.128:21385 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 10:56:34 HELO: Client 2a00:2381:19c6::2500:55038 using
SSL/TLS cipher: TLSv1.3:TLS_AES_256_GCM_SHA384:256
2019-10-12 10:56:36 HELO: Client 66.175.222.12:40090 using SSL/TLS
cipher: TLSv1.3:TLS_AES_256_GCM_SHA384:256
2019-10-12 10:56:51 HELO: Client 146.101.78.222:48029 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:02:41 HELO: Client 94.143.106.221:47155 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:03:02 HELO: Client 34.240.114.231:50607 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:03:38 HELO: Client 69.72.46.158:20785 using SSL/TLS
cipher: TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:04:07 HELO: Client 94.143.107.222:49533 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:04:07 HELO: Client 94.143.105.16:44709 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:06:30 HELO: Client 185.90.21.204:58814 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:16:38 HELO: Client 204.92.31.128:7811 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:27:10 HELO: Client 66.165.183.84:43717 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:29:35 HELO: Client 198.2.139.240:58812 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:29:59 HELO: Client 198.2.183.130:55943 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:32:42 HELO: Client 94.143.106.221:38197 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:34:08 HELO: Client 94.143.105.16:39023 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:34:08 HELO: Client 94.143.107.222:38438 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:36:42 HELO: Client 204.92.31.128:18223 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:37:56 HELO: Client 91.230.170.243:4212 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:42:11 HELO: Client 2a01:111:f400:fe08::82b:3614 using
SSL/TLS cipher: TLSv1.2:ECDHE-RSA-AES256-SHA384:256
2019-10-12 11:45:27 HELO: Client 185.90.23.251:11105 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 11:50:42 HELO: Client 66.175.222.12:54346 using SSL/TLS
cipher: TLSv1.3:TLS_AES_256_GCM_SHA384:256
2019-10-12 11:56:48 HELO: Client 204.92.31.128:7688 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:00:06 HELO: Client 2a00:2381:19c6::1800:33305 using
SSL/TLS cipher: TLSv1.2:DHE-RSA-AES256-SHA256:256
2019-10-12 12:02:42 HELO: Client 94.143.106.221:52382 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:04:09 HELO: Client 94.143.107.222:51019 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:04:09 HELO: Client 94.143.105.16:35600 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:07:58 HELO: Client 51.158.22.225:33103 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:12:30 HELO: Client 66.175.222.12:59936 using SSL/TLS
cipher: TLSv1.3:TLS_AES_256_GCM_SHA384:256
2019-10-12 12:16:55 HELO: Client 204.92.31.128:24423 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:26:29 HELO: Client 66.175.222.12:51246 using SSL/TLS
cipher: TLSv1.3:TLS_AES_256_GCM_SHA384:256
2019-10-12 12:32:44 HELO: Client 94.143.106.221:53748 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:34:10 HELO: Client 94.143.107.222:38561 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:34:10 HELO: Client 94.143.105.16:47292 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:37:01 HELO: Client 204.92.31.128:18643 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:37:08 HELO: Client 66.165.183.84:36301 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:49:11 HELO: Client 66.175.222.12:51332 using SSL/TLS
cipher: TLSv1.3:TLS_AES_256_GCM_SHA384:256
2019-10-12 12:52:03 HELO: Client 193.0.158.7:47672 using SSL/TLS cipher:
TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 12:57:05 HELO: Client 204.92.31.128:15896 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 13:02:45 HELO: Client 94.143.106.221:46102 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256
2019-10-12 13:04:11 HELO: Client 94.143.105.16:33434 using SSL/TLS
cipher: TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256


Mike



On 11/10/2019 16:32, Viktor Dukhovni via Exim-users wrote:
>> On Oct 10, 2019, at 10:30 AM, jmedard--- via Exim-users

<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.
>



--
## 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/