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
- Description: (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
and with openssl s_client 1.1.1c:
Protocol : TLSv1.2 / Cipher: ECDHE-RSA-AES256-GCM-SHA384
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
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
