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

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Russell King
Data:  
Para: exim-users
Assunto: [exim] Available ciphers with stock Debian (gnutls) exim
Hi,

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.

The debian-exim server has tls_dhparam set to historic, so it's
using a 2048-bit DH.

I've dumped the connection, this time between openssl s_client on a
Fedora laptop and the debian system, which shows the same behaviour.
It looks like gnutls as a server doesn't want to do EC. According to
tshark:

    SSL Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 202
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 198
            Version: TLS 1.2 (0x0303)
            Random
...
            Session ID Length: 0
            Cipher Suites Length: 90
            Cipher Suites (45 suites)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
...
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
...
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 67
            Extension: ec_point_formats
                Type: ec_point_formats (0x000b)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    EC point format: ansiX962_compressed_prime (1)
                    EC point format: ansiX962_compressed_char2 (2)
            Extension: elliptic_curves
                Type: elliptic_curves (0x000a)
                Length: 10
                Elliptic Curves Length: 8
                Elliptic curves (4 curves)
                    Elliptic curve: secp521r1 (0x0019)
                    Elliptic curve: secp384r1 (0x0018)
                    Elliptic curve: secp256k1 (0x0016)
                    Elliptic curve: secp256r1 (0x0017)


but the server hello replies with:

    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 77
            Version: TLS 1.2 (0x0303)
            Random
...
            Session ID Length: 32
            Session ID: ...
            Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)


I thought maybe I needed to change tls_require_ciphers, so I tried
setting it to "tls_require_ciphers = NORMAL" and restarting exim,
but it still doesn't want to use EC ciphers, even though
"gnutls-cli -l --priority=NORMAL" lists them, e.g.

Cipher suites for NORMAL
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384                      0xc0, 0x2c      TLS1.2
...
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256                      0xc0, 0x2b      TLS1.2
...
TLS_ECDHE_RSA_AES_128_GCM_SHA256                        0xc0, 0x2f      TLS1.2


The exim manual says that tls_eccurve is ignored for gnutls, so
that can't be it.

If I use nmap to scan the available ciphers against the gnutls exim,
I get:

25/tcp open smtp
| ssl-enum-ciphers:

...
|   TLSv1.2:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CCM - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CCM - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|       TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 - strong
|     compressors:
|       NULL

|_ least strength: strong

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.

When run against the rpm-based exim server, nmap reports many more
cipher suites to choose from, which includes the EC ciphers.

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?

The debian server is not publically accessible, so please don't ask
for its address to run your own tests against!

Thanks.

--
Russell King