Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #4 from Jeremy Harris <jgh146exb@wizmail.org> ---
OpenSSL has separate API calls for TLSv1.3 and pre-1.3 ciphersuites.
If you don't call either, you get a default set for that version of TLS.

I'd expect it to, if a (set of) 1.3 ciphers was requested which did
not match those selected by a peer, to fall back to using a cipher from
the pre-1.3 set, on a 1.2 connection (assuming there was one). But it does
not; the server rejects the Client Hello with a "Handshake faiied" alert.

This is less than useful, it means a server cannot restrict the 1.3 ciphers
it offers yet still offer both 1.3 and 1.2 service with a single configuration.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #5 from help@novo.media ---
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.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #6 from help@novo.media ---
One has to think of TLS 1.3 as a completely new protocol. Apart from its name,
it has nothing in common with TLS 1.2 anymore. Not only are the cipher names
completely new, but also the entire handshake structure of TLS 1.3 is faster.
At its conception, there were even discussions if it should be named TLS 2.0
instead of TLS 1.3 because the changes were so fundamental.

In terms of ciphers, there are only generic names available anymore with a
general description of what algorithm and its hashing strength. Gone are the
days, where one has to define the type of DH exchange (DH, DHE or ECDHE) or
type of certificate (DSA, RSA or ECDSA) within a cipher but instead one
'generic name' per cipher is defined and the library - in this case OpenSSL -
handles the rest.

There can't be any version downgrade-ability, simply because the information in
a 'generic TLS 1.3 ciphersuite name' does not contain the information needed
for a specific TLS 1.2 cipher. There is no such thing as "the same cipher" for
TLS 1.2 and 1.3 or vice versa. And that is just on the cipher side. The
handshake is different too, which makes the prospect a complete
interchangeability even "more impossible".

TLS 1.3 has 'nothing' to do with TLS 1.2 anymore. They are like siblings but
from different parents, so to speak.

A simple but great rule to help throughout this confusion is the question:
Would this kind of outcome considered to be good/right/expected, if TLS 1.3 is
the only version (ever) existing. If the answer is yes, then everything works
as expected. Even if TLS 1.2 is around or beside.

In case of the TLS 1.3 issue mentioned before: Would a TLS 1.3 connection
termination because of a cipher-mismatch considered to be good/right/expected,
if TLS 1.3 is the only version (ever) existing? Yes, absolutely. Therefore
everything works as expected. TLS 1.2 has absolutely nothing to do with this
anymore.

I hope this could clear up some misconceptions.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #7 from Jeremy Harris <jgh146exb@wizmail.org> ---
(In reply to help from comment #6)
> There can't be any version downgrade-ability

I disagree. If you configure the sever for no-1.3 and hit it with an
OpenSSL-default 1.3 + 1.2, you get a 1.2 connection. I call that a
working downgrade, from the point-of-view of the client.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #8 from help@novo.media ---
(In reply to Jeremy Harris from comment #7)
> (In reply to help from comment #6)
> > There can't be any version downgrade-ability
>
> I disagree. If you configure the sever for no-1.3 and hit it with an
> OpenSSL-default 1.3 + 1.2, you get a 1.2 connection. I call that a
> working downgrade, from the point-of-view of the client.

I'd call that a selection rather than a downgrade. A downgrade would constitute
the start of a TLS session in a certain version and the ending of that session
with a different, lower version.

But actually it does not matter how we call it. For the sake of the argument,
it doesn't change anything.

> This is less than useful, it means a server cannot restrict the 1.3 ciphers
> it offers yet still offer both 1.3 and 1.2 service with a single
> configuration.

With a single configuration? Yes. Within a single connection/session? No. And
that's a good thing.

> I'd expect it to, if a (set of) 1.3 ciphers was requested which did
> not match those selected by a peer, to fall back to using a cipher from
> the pre-1.3 set, on a 1.2 connection (assuming there was one). But it does
> not; the server rejects the Client Hello with a "Handshake faiied" alert.

Once a TLS 1.3 session is negotiated, there is no possibility for it to become
a TLS 1.2 session anymore. For good reasons! (Security)

I do not understand where or what the opposition here exactly is. Nobody would
expect a TLS 1.2 session to be downgraded to TLS 1.1 on a cipher-mismatch, so
why the different standard for TLS 1.3 here?

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #9 from help@novo.media ---
And apart from all of this, how does the (in)ability of a user to the define
custom ciphersuites address any of the issues raised by you? Exim/TLS behaves
still the same even if a user can not define custom ciphersuites.

I am kind of baffled. What exactly is the issue here at all?

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #10 from Jeremy Harris <jgh146exb@wizmail.org> ---
(In reply to help from comment #8)
> > This is less than useful, it means a server cannot restrict the 1.3 ciphers
> > it offers yet still offer both 1.3 and 1.2 service with a single
> > configuration.
>
> With a single configuration? Yes.

With a single configuration, no. It doesn't work (in a reasonable way).


> Once a TLS 1.3 session is negotiated, there is no possibility for it to
> become a TLS 1.2 session anymore. For good reasons! (Security)

Misconception. A 1.3 connection is not negotiated, with the attempted
matching of 1.3 configurations, even though there is a matching 1.2
cipher available. No TLS connection is successfully made.
The server refuses the TLS connection.

Result, for SMTP: either a) (when one end insists on TLS or nothing)
no SMTP communication OR b) SMTP standard downgrade to in-clear
communications.

It's not a good situation. And making the facility in Exim config to restrict
the 1.3 ciphersuites makes the occurrence of the problem combination more
likely -
because administrators of systems will make different choices -
which will mean more support queries, and perception of Exim being unreliable.

For what it's worth, OpenSSL and GnuTLS do the same here.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #11 from help@novo.media ---
There is a fundamental philosophical difference between my understanding and
the developers, in that, Exim tries to be consistent/compatible over different
libraries, TLS versions, connection directions and settings.

An attempt I consider futile. Nonetheless, my proposals were always listened to
with an open mind, exemplary professionalism and formidable endurance.

For that, I kindly thank everyone participating.

I now proceed with disabling all my TLS settings in each daemon/config and set
the appropriate configurations globally within openssl.cnf.

This solution is somewhat limiting in regards to outgoing connections, but it
is also nice to have all TLS settings within one file!

Thanks again.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##