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
