[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA2…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: admin
Datum:  
To: exim-dev
Alte Treads: [exim-dev] [Bug 2872] New: Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
Betreff: [exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872

--- Comment #8 from help@??? ---
(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.