Re: [exim] Available ciphers with stock Debian (gnutls) exim

Góra strony
Delete this message
Reply to this message
Autor: Russell King
Data:  
Dla: exim-users
Temat: Re: [exim] Available ciphers with stock Debian (gnutls) exim
On Sat, Jul 13, 2019 at 01:19:29PM +0200, Andreas Metzler via Exim-users wrote:
> Russell King via Exim-users <exim-users@???> wrote:
> > I've been noticing a difference in behaviour between debian systems
> > (using gnutls) and rpm-based systems (using openssl) when it comes to
> > the ciphers used to transport mail using exim - and it appears to be
> > specific to whether the gnutls end is the server or not.
>
> > As an example, when debian-exim talks to rpm-exim, it uses
> > TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256. However, when rpm-exim talks
> > to debian-exim, it uses TLSv1.2:AES128-GCM-SHA256:128.
>
> > I'm not interested in debating what is a better cipher or anything
> > of that ilk, but I'd like to understand what is going on, why there
> > is this difference, whether it is intentional, or a config cockup.
> [...]
> > I get the same whether I leave tls_require_ciphers empty or set it
> > to NORMAL. Hmm, so it looks like stock debian exim4 just doesn't
> > support EC ciphers at all.
> [...]
> > Does anyone know what's going on here? Is the stock debian exim
> > 4.89-2+deb9u4 built against gnutls 3.5.8-5+deb9u4 intentionally
> > restricted to a small set of ciphers? Can anyone else reproduce
> > this?
>
> Hello
>
> Running the old exim version (4.89) in a stretch (Debian 9.9) chroot
> without setting tls_require_ciphers I get this when connecting with
> current (well, 3.6.7) gnutls-cli


This looks like you upgraded gnutls beyond what is in Stretch (which
is only 3.5.8-5+deb9u4).

Digging into this more, it looks like a gnutls issue. If I run:

# gnutls-serv --echo -p 15 --x509keyfile=exim.key --x509certfile=exim.cert

and then:

# gnutls-cli -p 15 --debug 5 localhost
...
|<4>| HSK[0x17d0818]: SERVER HELLO (2) was received. Length 85[85], frag offset
0, frag length: 85, sequence: 0
|<4>| HSK[0x17d0818]: Server's version: 3.3
|<4>| HSK[0x17d0818]: SessionID length: 32
|<4>| HSK[0x17d0818]: SessionID: 25dab9ea480a12a68e2bd3d6000f0ab12e05906199ab5c62c109fb94c1efd0c6
|<4>| HSK[0x17d0818]: Selected cipher suite: RSA_AES_256_GCM_SHA384

In other words, it seems stock Stretch gnutls can't negotiate ECDSA
ciphers with itself.

> gnutls-cli-debug reports the following info:
>                         whether we need to disable TLS 1.2... no
>                         whether we need to disable TLS 1.1... no
>                         whether we need to disable TLS 1.0... no
>                         whether %NO_EXTENSIONS is required... no
>                                whether %COMPAT is required... no
>                              for TLS 1.0 (RFC2246) support... yes
>                              for TLS 1.1 (RFC4346) support... yes
>                              for TLS 1.2 (RFC5246) support... yes
>                              for TLS 1.3 (RFC8446) support... no
> |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
>                        TLS1.2 neg fallback from TLS 1.6 to... TLS1.2
>               for inappropriate fallback (RFC7507) support... yes
>                                for certificate chain order... sorted
>                   for safe renegotiation (RFC5746) support... yes
>                     for encrypt-then-MAC (RFC7366) support... yes
>                    for ext master secret (RFC7627) support... yes
>                            for heartbeat (RFC6520) support... no
>                        for version rollback bug in RSA PMS... dunno
>                   for version rollback bug in Client Hello... no
>             whether the server ignores the RSA PMS version... no
> whether small records (512 bytes) are tolerated on handshake... yes
>     whether cipher suites not in SSL 3.0 spec are accepted... yes
> whether a bogus TLS record version in the client hello is accepted... yes
>          whether the server understands TLS closure alerts... no
>             whether the server supports session resumption... no
>                       for anonymous authentication support... no
> |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
>                       for ephemeral Diffie-Hellman support... yes
> |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
>                         for RFC7919 Diffie-Hellman support... no
>                    for ephemeral EC Diffie-Hellman support... yes
>                              for curve SECP256r1 (RFC4492)... yes
>                              for curve SECP384r1 (RFC4492)... yes
>                              for curve SECP521r1 (RFC4492)... yes
>                                 for curve X25519 (RFC8422)... no
>                       for AES-GCM cipher (RFC5288) support... yes
>                       for AES-CCM cipher (RFC6655) support... yes
>                     for AES-CCM-8 cipher (RFC6655) support... no
>                       for AES-CBC cipher (RFC3268) support... yes
>                  for CAMELLIA-GCM cipher (RFC6367) support... yes
>                  for CAMELLIA-CBC cipher (RFC5932) support... yes
>                      for 3DES-CBC cipher (RFC2246) support... yes
>                   for ARCFOUR 128 cipher (RFC2246) support... no
> |<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
>             for CHACHA20-POLY1305 cipher (RFC7905) support... yes
>                                        for MD5 MAC support... no
>                                       for SHA1 MAC support... yes
>                                     for SHA256 MAC support... no
>                      for max record size (RFC6066) support... yes
>                 for OCSP status response (RFC6066) support... no


gnutls-cli-debug against gnutls-serv on the same host:

unknown protocol 'netstat'
GnuTLS debug client 3.5.8
Checking localhost:15
                             for SSL 3.0 (RFC6101) support... no
                        whether we need to disable TLS 1.2... no
                        whether we need to disable TLS 1.1... no
                        whether we need to disable TLS 1.0... no
                        whether %NO_EXTENSIONS is required... no
                               whether %COMPAT is required... no
                             for TLS 1.0 (RFC2246) support... yes
                             for TLS 1.1 (RFC4346) support... yes
                             for TLS 1.2 (RFC5246) support... yes
                                  fallback from TLS 1.6 to... failed (server requires fallback dance)
              for inappropriate fallback (RFC7507) support... yes
                               for certificate chain order... sorted
                  for safe renegotiation (RFC5746) support... yes
                    for encrypt-then-MAC (RFC7366) support... no
                   for ext master secret (RFC7627) support... no
                           for heartbeat (RFC6520) support... no
                       for version rollback bug in RSA PMS... dunno
                  for version rollback bug in Client Hello... no
            whether the server ignores the RSA PMS version... no
whether small records (512 bytes) are tolerated on handshake... yes
    whether cipher suites not in SSL 3.0 spec are accepted... yes
whether a bogus TLS record version in the client hello is accepted... yes
         whether the server understands TLS closure alerts... yes
            whether the server supports session resumption... yes
                      for anonymous authentication support... no
                      for ephemeral Diffie-Hellman support... no
                   for ephemeral EC Diffie-Hellman support... no
                             for curve SECP256r1 (RFC4492)... no
                             for curve SECP384r1 (RFC4492)... no
                             for curve SECP521r1 (RFC4492)... no
           for curve X25519 (draft-ietf-tls-rfc4492bis-07)... no
                  for AES-128-GCM cipher (RFC5288) support... yes
                  for AES-128-CCM cipher (RFC6655) support... yes
                for AES-128-CCM-8 cipher (RFC6655) support... no
                  for AES-128-CBC cipher (RFC3268) support... yes
             for CAMELLIA-128-GCM cipher (RFC6367) support... yes
             for CAMELLIA-128-CBC cipher (RFC5932) support... yes
                     for 3DES-CBC cipher (RFC2246) support... yes
                  for ARCFOUR 128 cipher (RFC2246) support... no
            for CHACHA20-POLY1305 cipher (RFC7905) support... no
                                       for MD5 MAC support... no
                                      for SHA1 MAC support... yes
                                    for SHA256 MAC support... no
                              for ZLIB compression support... no
                     for max record size (RFC6066) support... yes
                for OCSP status response (RFC6066) support... no
              for OpenPGP authentication (RFC6091) support... no


So it basically looks like stock Stretch gnutls-3.5.8-5+deb9u4 does
not support EC ciphers as a server, which is really strange.

Maybe it's something to do with the certs/key?

--
Russell King