Re: which openssl options are used by exim for a tls connection

On Fri, Jun 06, 2025 at 11:25:11AM +0200, Cyborg via Exim-users wrote:

> > > when connecting with s_client to that server, a wired connection is
> > > established:
> > Which specific server?
> 
> 93.62.204.35
> > Did you actually connect to the same TCP endpoint (IP and port)?
> 
> yeap.

What I get, when running OpenSSL 3.5 built from upstream source, is:

    $ openssl s_client -starttls smtp -connect mail.femobunker.com:25 -brief
    Connecting to 93.62.204.35
    depth=3 C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
    verify error:num=19:self-signed certificate in certificate chain
    807BF6BFEA7F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key too small:ssl/statem/statem_clnt.c:2335:

When, on the other hand, on the same Fedora 41 system, I use the
distro's OpenSSL (3.2), I get:

    $ /usr/bin/openssl s_client -starttls smtp -connect mail.femobunker.com:25 -brief
    Connecting to 93.62.204.35
    CONNECTION ESTABLISHED
    Protocol version: TLSv1.2
    Ciphersuite: AES256-GCM-SHA384
    Peer certificate: CN=mail.femobunker.com
    Verification: OK
    250 DSN
    quit
    221 2.0.0 Bye

Perhaps Fedora's crypto policy manages to disable negotiation of FFDHE
ciphers by default, but Exim overrides the default???

> Lesson learned, it's also available for TLS 1.2 with RSA Kx

No, it is ONLY a TLS 1.2 cipher.  There is a similar TLS 1.3 cipher with
a different name:

    $ /usr/bin/openssl ciphers -v -s -tls1_3
    TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
    TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
    TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128)            Mac=AEAD
    TLS_AES_128_CCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESCCM(128)            Mac=AEAD

These are NOT the same thing at all, do not confuse TLS 1.2 ciphers with
TLS 1.3, the latter do not subsume key exchange and authentication.

> >      $ openssl ciphers -s -tls1_2 -v AES256-GCM-SHA384
> >      AES256-GCM-SHA384              TLSv1.2 Kx=RSA      Au=RSA   Enc=AESGCM(256)            Mac=AEAD
> > 
> > that uses deprecated RSA key exchange, instead of DHE or ECDHE.  It is
> > not clear how you ended up negotiating this cipher, because the default
> > preference order has it well below the usual PFS (DHE/ECDHE) ciphers:
>
> Judging from the TLS version check a few days ago, the cipher is
> typically/only used with TLS 1.3 , which makes sense now, because no RSA Kx
> is used in TLS 1.3

No, the cipher in question (negotiated by Fedora's s_client) is a TLS
1.2 cipher.

> The cipher is not used in TLS 1.2  connections, at least with the openssl
> default setup of Fedora.

This is again wrong. It *is* used in TLS 1.2.

> In the tls cipher summery from 2017 ( pre TLS 1.3 ), the cipher is also not
> listed for TLS 1.2 . (Summery taken with Fedora)

You've are all muddled...

> s_client seems to be happy to use it with TLS 1.2, so something else, i.e.
> the crypto-policy seems to deny the usage of that cipher with TLS 1.2 in
> Exim.

One way to get the same results from Fedora's `s_client` is:

    $ /usr/bin/openssl s_client -starttls smtp -connect mail.femobunker.com:25 -brief -cipher 'DEFAULT:!kRSA'
    Connecting to 93.62.204.35
    8042765DC87F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key too small:ssl/statem/statem_clnt.c:2314:

Perhaps, Exim disables the "kRSA" ciphers/

> I pretty sure, you are right about the RSE Kx limitation , but s_client
> should enforce that too???

You're still muddled.

-- 
    Viktor.

-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/