https://bugs.exim.org/show_bug.cgi?id=2872
--- Comment #5 from help@??? ---
I think there is a misconception about OpenSSL/TLS 1.3 here. It is true, that -
if a cipher-mismatch occurs - the connection gets rejected. But this is also
true if the default ciphersuites are used.
The RFC makes five ciphersuites in TLS 1.3 mandatory. All of them are supported
by OpenSSL:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
OpenSSL however is offering only the first three(*) as the default for TLS 1.3
connections:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
So if we were to use one of the non-default ciphersuites of
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
we are getting the exact same error+disconnect. And this is the current state
of all Exim builds with OpenSSL and enabled TLS 1.3 in use right now:
################################################
openssl s_client -ciphersuites TLS_AES_128_CCM_8_SHA256 -connect novo.media:465
CONNECTED(00000003)
139795264054592:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 298 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
echo $?
1
################################################
I do not see how allowing users to define their own set of custom ciphersuites
would change anything in that regard. One is already able to produce a
cipher-mismatch with a disconnect, even without the ability to define custom
ciphersuites.
In general; I do not understand where that misconception for version
interoperability comes from. TLS 1.3 is built with a certain backwards
compatibility in mind, in the sense that a only-TLS-1.2-speaking-server is able
to handle a TLS-1.3-request-from-a-client without breakage. That does not imply
a servers ability to switch protocol versions arbitrarily. Especially not on a
cipher-mismatch and super-especially not with a version downgrade in response.
Apart from its technical impracticality - due to the different handshake
architecture - this would also have security implications on its own.
In the HTTP world, virtually every daemon like Apache, NGINX or lighttpd is
supporting custom ciphersuites. The same is true for the most popular IMAP
daemon dovecot. And in SMTP terms (may absolution is granted by you, father)
even Postfix.
All of them are using OpenSSL.
(*)
https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
--
You are receiving this mail because:
You are on the CC list for the bug.
