On 12/10/2019 15:14, jmedard--- via Exim-users wrote:
> Be careful, think about switching to 4.92.3. There is a flaw on 4.92.2 and
> all previous versions.
Sorry, typo, we're running 4.92.3 already:
root@relay1:/etc/exim# telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220-Thorcom Mail Service relay1.thorcom.net ESMTP Exim 4.92.3 Sat, 12
Oct 2019 15:38:34 +0100
> 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.
Ok, someone needs to tell OWASP then:
https://cheatsheetseries.owasp.org/cheatsheets/TLS_Cipher_String_Cheat_Sheet.html
> 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"
Cut & Paste typo error when I wrong the email - its 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.
I will look
> 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
I will compare ;-)
> 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.
>>
>
