Re: [exim] Define preferred encryption algorithms

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Viktor Dukhovni
Datum:  
To: exim-users
Betreff: Re: [exim] Define preferred encryption algorithms
> On Oct 12, 2019, at 9:36 AM, Mike Tubby via Exim-users <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.