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
