Re: [exim] Define preferred encryption algorithms

[Viktor Dukhovni via Exim-users]

On Mon, Oct 14, 2019 at 12:34:34PM +0200, jmedard--- via Exim-users wrote:

> Sorry, i don't understand why you prefere blacklist to whitelist !

Because it does not preclude future ciphers, less prone to typos,
and gets the cipher order roughly right.  Basically, less prone to
cargo-culted poor choices compounded by further errors.

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

[jmedard--- via Exim-users]

Sorry, i don't understand why you prefere blacklist to whitelist !



-Message d'origine-
De : Exim-users  De la part
de Viktor Dukhovni via Exim-users
Envoyé : samedi 12 octobre 2019 19:49
À : exim-users@exim.org
Cc : Viktor Dukhovni 
Objet : Re: [exim] Define preferred encryption algorithms

> On Oct 12, 2019, at 9:36 AM, Mike Tubby via Exim-users
 wrote:
> 
> # OWASP Widest Compatibility (List C)
> tls_require_ciphers = 
> TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SH
> A256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES
> 256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-R
> SA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE
> -RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128
> -SHA

Explicit lists like this are still a bad idea.  With the noop TLS 1.3 names
removed, the above is a proper subset of the more sensible:

DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS:!kRSA

(for comparison also add the optional exclusions !SRP
 and !PSK, as they're not enabled without explicit
 additional configuration and callbacks in the application)

which for no good reason leaves out the ECDSA ciphers (and there are some
systems with just ECDSA certs):

  ECDHE-ECDSA-AES128-GCM-SHA256
  ECDHE-ECDSA-AES128-SHA
  ECDHE-ECDSA-AES128-SHA256
  ECDHE-ECDSA-AES256-GCM-SHA384
  ECDHE-ECDSA-AES256-SHA
  ECDHE-ECDSA-AES256-SHA384
  ECDHE-ECDSA-CHACHA20-POLY1305

and all TLSv1.2 CHACHA ciphers:

  ECDHE-ECDSA-CHACHA20-POLY1305
  DHE-RSA-CHACHA20-POLY1305
  ECDHE-RSA-CHACHA20-POLY1305

Your list also leaves out all RSA key exchange ciphers, which is still IMHO
premature for SMTP.  You'll not be able to complete a handshake with systems
that don't do server-side DHE/ECDHE forward-secrecy.  It is somewhat safer
to disable these just in your SMTP acceptor, but not such a good idea to do
in the SMTP transport.  Therefore I'd like to suggest
instead:

   DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS

>From which you can subtract anything any stray code points you're sure you
don't like.  Avoid cipher whitelists, use blacklists instead.

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


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

[Viktor Dukhovni via Exim-users]

On Sun, Oct 13, 2019 at 06:43:48PM +0100, Jeremy Harris via Exim-users wrote:

> Poking around the openssl sources I find a "Changes" note:
>  the definition for "DEFAULT"
>  (SSL_DEFAULT_CIPHER_LIST) now is just "ALL:!aNULL:!eNULL", but
>  remains equivalent  to
>  "AES:ALL:!aNULL:!eNULL:+aECDH:+kRSA:+RC4:@STRENGTH"

That note is not (or is no longer) accurate, the resulting order
is not the same.

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

[Viktor Dukhovni via Exim-users]

On Sun, Oct 13, 2019 at 09:51:42AM -0700, Phillip Carroll via Exim-users wrote:

> This thread has given me a much deeper understanding of how to manage 
> cipher negotiation in exim. As a result of this thread I have adopted 
> Viktor's setting for tls_require_ciphers. (Thanks Viktor)

One thing I forgot to mention is starting with OpenSSL 1.1.0, the
"ALL" and "DEFAULT" cipherlists are by default restricted further
by the "security level".  The default "level 1" sets a floor of
roughly 80-bit or better security across all the various algorithms,
so you get:

- SHA1 or stronger, no MD5 in TLS or in X.509 certificate
  chains other than root CA self-signatures.
- RSA with 1024-bit or longer keys in all X.509 certificates
- Diffie Hellman with 1024-bit or larger primes
- ECDSA with 160-bit or stronger curves (rarely less than 256)
- ECDHE with 160-bit or stronger curves

The security level can be specified in the cipherlist by adding
"@SECLEVEL=", for a suitable choice of .

With opportunistic TLS, where handshake failure falls back to
transmission in the clear, Postfix explicitly selects "@SECLEVEL=0",
removing the safety net, because even weak crypto should be better
than none.  The "@SECLEVEL=1" setting only applies for destinations
for which TLS is mandatory (e.g. DANE, but also mandatory local
policy to enforce TLS encryption with or without authentication).

Exim may not have automatic tuning of the security level based on
mandatory vs. opportunistic TLS, so setting "@SECLEVEL=0" for the
smtp router, unless that router is dedicated to just opportunistic
TLS, and perhaps sites with weak DH or MD5 signatures in their RSA
certs are no longer sufficiently common to warrant accommodating.

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

[Viktor Dukhovni via Exim-users]

On Sun, Oct 13, 2019 at 09:51:42AM -0700, Phillip Carroll via Exim-users wrote:

> Following is the cipher list result I see on CentOS 7.7.1908
> with openssl 1:1.0.2k-19.el7:
> > [root@localhost ~]#openssl ciphers 
> > 'DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS:!PSK'|tr : '\n'
> > [...]
> 
> My previous setting (last visited about 4 years ago) resulted in a list 
> more than double the length of this, with some ciphers considered very 
> weak included. Although, TLS connections (both directions) typically 
> result in a TLS1.2 connection using one of the top ciphers in the list.
> 
> I also tried adding '@STRENGTH' to the setting but found it produced the 
> exact same order. Does exim add that, or does openssl automatically sort 
> by strength?

In OpenSSL 1.0.0 (long time ago now), Bodo Möller implemented a
revised cipher selection mechanism that automatically results in
the "ALL" cipherlist being sorted in order of preference.  (I played
a small part in encouraging him to start that work).  All the other
elementary cipherlists are obtained from "ALL" by applying filters
and so, consequently, they too are sorted.  In OpenSSL 1.0.x the
sort order is by cipher strength.  For example, running either
OpenSSL 1.0.0 or OpenSSL 1.0.2 I get:

$ for c in ALL DEFAULT HIGH MEDIUM AES kRSA aRSA aECDSA kEECDH
  do
c1=$(openssl ciphers -v "$c")
c2=$(openssl ciphers -v "$c:@STRENGTH")
printf "%-12s %2d ciphers\n" "${c}:" "$(echo "$c1" | wc -l)"
diff -u <(echo "$c1") <(echo "$c2")
  done
ALL: 70 ciphers
DEFAULT: 44 ciphers
HIGH:39 ciphers
MEDIUM:  17 ciphers
AES: 20 ciphers
kRSA:22 ciphers
aRSA:35 ciphers
aECDSA:   5 ciphers
kEECDH:  15 ciphers

Where none of the tested elementary cipher strings produced "diff"
output between their default value and explicitly sorted order.

In OpenSSL 1.1.x, forward-secrecy takes precedence over cipher
strength, with the PFS ciphers in key length order, and then the
non-PFS ciphers.  So sorting by key length (@STRENGTH) results in
a different order, with forward-secrecy preferred only within each
key length.  Eliminating the non-PFS ciphers shows no effect from
key-length sorting:

$ for c in ALL DEFAULT HIGH MEDIUM AES aRSA aECDSA kEECDH
  do c1=$($openssl110 ciphers -v "$c":'!kDH:!kECDH:!kRSA')
c2=$($openssl110 ciphers -v "$c":'!kDH:!kECDH:!kRSA:@STRENGTH')
printf "%-12s %2d ciphers\n" "${c}:" "$(echo "$c1" | wc -l)"
diff -u <(echo "$c1") <(echo "$c2")
  done
ALL: 64 ciphers
DEFAULT: 49 ciphers
HIGH:56 ciphers
MEDIUM:   8 ciphers
AES: 40 ciphers
aRSA:22 ciphers
aECDSA:   9 ciphers
kEECDH:  23 ciphers

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

[Jeremy Harris via Exim-users]

On 13/10/2019 17:51, Phillip Carroll via Exim-users wrote:
> I also tried adding '@STRENGTH' to the setting but found it produced the
> exact same order. Does exim add that, or does openssl automatically sort
> by strength?

Exim takes no special action.

Poking around the openssl sources I find a "Changes" note:
 the definition for "DEFAULT"
 (SSL_DEFAULT_CIPHER_LIST) now is just "ALL:!aNULL:!eNULL", but
 remains equivalent  to
 "AES:ALL:!aNULL:!eNULL:+aECDH:+kRSA:+RC4:@STRENGTH"
-- 
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] Define preferred encryption algorithms

[Phillip Carroll via Exim-users]

On 10/11/2019 2:55 AM, Jeremy Harris via Exim-users wrote:

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


@Jeremy:

Apparently IBM agrees with your interpretation:
https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.15/gtpc2/cpp_ssl_ctx_set_cipher_list.html

Note what IBM support says:   "You must specify the ciphers in order of 
preference from highest to lowest."


This thread has given me a much deeper understanding of how to manage 
cipher negotiation in exim. As a result of this thread I have adopted 
Viktor's setting for tls_require_ciphers. (Thanks Viktor)


Following is the cipher list result I see on CentOS 7.7.1908
with openssl 1:1.0.2k-19.el7:

[root@localhost ~]#openssl ciphers 
'DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS:!PSK'|tr : '\n'
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA256-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-RSA-CAMELLIA128-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
CAMELLIA128-SHA


My previous setting (last visited about 4 years ago) resulted in a list 
more than double the length of this, with some ciphers considered very 
weak included. Although, TLS connections (both directions) typically 
result in a TLS1.2 connection using one of the top ciphers in the list.


I also tried adding '@STRENGTH' to the setting but found it produced the 
exact same order. Does exim add that, or does openssl automatically sort 
by strength?


Phil Carroll

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

[Viktor Dukhovni via Exim-users]

> On Oct 12, 2019, at 9:36 AM, Mike Tubby via Exim-users  
> wrote:
> 
> # OWASP Widest Compatibility (List C)
> tls_require_ciphers = 
> TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384: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-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA

Explicit lists like this are still a bad idea.  With the noop TLS 1.3
names removed, the above is a proper subset of the more sensible:

DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS:!kRSA

(for comparison also add the optional exclusions !SRP
 and !PSK, as they're not enabled without explicit
 additional configuration and callbacks in the application)

which for no good reason leaves out the ECDSA ciphers (and
there are some systems with just ECDSA certs):

  ECDHE-ECDSA-AES128-GCM-SHA256
  ECDHE-ECDSA-AES128-SHA
  ECDHE-ECDSA-AES128-SHA256
  ECDHE-ECDSA-AES256-GCM-SHA384
  ECDHE-ECDSA-AES256-SHA
  ECDHE-ECDSA-AES256-SHA384
  ECDHE-ECDSA-CHACHA20-POLY1305

and all TLSv1.2 CHACHA ciphers:

  ECDHE-ECDSA-CHACHA20-POLY1305
  DHE-RSA-CHACHA20-POLY1305
  ECDHE-RSA-CHACHA20-POLY1305

Your list also leaves out all RSA key exchange ciphers, which
is still IMHO premature for SMTP.  You'll not be able to
complete a handshake with systems that don't do server-side
DHE/ECDHE forward-secrecy.  It is somewhat safer to disable
these just in your SMTP acceptor, but not such a good idea
to do in the SMTP transport.  Therefore I'd like to suggest
instead:

   DEFAULT:!EXPORT:!LOW:!MEDIUM:!kECDH:!kDH:!aDSS

>From which you can subtract anything any stray code points
you're sure you don't like.  Avoid cipher whitelists, use
blacklists instead.

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

[Mike Tubby via Exim-users]

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  De la part
de Mike Tubby via Exim-users
Envoyé : samedi 12 octobre 2019 15:36
À : exim-users@exim.org
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-SHA3

Re: [exim] Define preferred encryption algorithms

[jmedard--- via Exim-users]

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  De la part
de Mike Tubby via Exim-users
Envoyé : samedi 12 octobre 2019 15:36
À : exim-users@exim.org
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 

Re: [exim] Define preferred encryption algorithms

[Jeremy Harris via Exim-users]

On 12/10/2019 14:36, Mike Tubby via Exim-users wrote:
> We use Exim 4.92.2 compiled with OpenSSL on Devuan 3.0 Beowulf with GCC
> version 8.

> good use of TLS 1.2 and TLS 1.3 with strong ciphers.

Note that tls_require_ciphers with OpenSSL does not affect
the choice of ciphers for TLS1.3 - the library is fully in control.
-- 
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] Define preferred encryption algorithms

[Mike Tubby via Exim-users]

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:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384: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-RSA-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 

Re: [exim] Define preferred encryption algorithms

[Viktor Dukhovni via Exim-users]

> 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

[jmedard--- via Exim-users]

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

[jmedard--- via Exim-users]

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

[Russell King via Exim-users]

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

[Jeremy Harris via Exim-users]

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/

[exim] Define preferred encryption algorithms

[jmedard--- via Exim-users]

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/