Thanks.
TL;DR: it sounds like we should just separate the two, one way or another - fighting against the design isn't worth it. But I don't understand the rationale for the design.
On 5/25/2023 7:01 PM, Viktor Dukhovni wrote:
TL;DR: it sounds like we should just separate the two, one way or another - fighting against the design isn't worth it. But I don't understand the rationale for the design.
On 5/25/2023 7:01 PM, Viktor Dukhovni wrote:
There are good reasons why that would work poorly. The choice to not mix oil and water is well motivated.
Could you elaborate? My expectation would be that TLS 1.2 connections would use ciphers that are allowed for 1.2, and TLS 1.3 connections would use ciphers that are allowed for 1.3, but that we'd only need to manage one list of ciphers, and a range of acceptable TLS versions.
(We could of course have separate 1.2 and 1.3 lists in the UI, but that seems like excessive complexity both in the implementation and in the UI.)
This is an unintentional artefact of the implementation. The intent is
to only match TLS 1.3 ciphersuites. Note that adding a TLS 1.2 cipher
to the TLS 1.3 ciphersuite list does not make it usable. Connections
that negotiate TLS 1.3 fail when this is done. But TLS 1.2 connections
succeed with that cipher even when all ciphers are removed from the
TLS 1.2 and prior cipher list. Compare:
$ openssl s_client -tls1_3 -connect '...' -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA -cipher '!ALL'
$ openssl s_client -tls1_2 -connect '...' -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA -cipher '!ALL'
You could open an issue. This is more of a nit than a bug, but perhaps
worth "fixing" nevertheless.
If I'm understanding you correctly, that's exactly the behavior that I would expect - given a mixed list of 1.2 and 1.3 ciphers, a 1.2 connection would be able to use only the 1.2 ciphers and a 1.3 connection would be able to use only the 1.3 ciphers. If there are no ciphers of the appropriate type allowed, the connection would fail.
Side note: we gave up on using the pre-1.3 pattern matching several years ago. It was just too hard to construct the patterns so that they would match exactly the ciphers that (a) we supported and (b) were allowed or recommended by our corporate standards. We had to evaluate a proposed pattern and then check each resulting cipher; it was easier to just start with the list of ciphers that we wanted the result to be.
-- Jordan Brown, Oracle
