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/
