On 19/12/2025 18:52, Christopher Schultz wrote:
<snip/>
I agree that there are two options.
A. Have two cipher settings, one for TLS <= 1.2 and one for TLS >=
1.3. Use the separate ones for OpenSSL. Combine them when calling JSSE.
B. Have one cipher setting. Use the single value when calling JSSE and
for OpenSSL call both OpenSSL setters with the same value.
I have been thinking about various use cases, trying to see if one
option works better than the other.
On balance, I think option A is better as with option B there is a
backwards compatibility issue. Currently, if a user explicitly lists
TLS1.2 ciphers, they will get TLS 1.2 ciphers + the TLS 1.3 default
ciphers.
Why is this the case? Because it's tough to know whether "ALL" should
apply to only the TLS.1.2 ciphers or the TLS1.3 ones, or both?
Because OpenSSL configures TLS 1.2 and TLS 1.3 completely separately.
The ciphers setting for Tomcat maps to the TLS 1.2 ciphers so Tomcat
users always get the default TLS 1.3 ciphers with OpenSSL.
Actual TLSv1.3 cipher suite names are (currently) completely unique and
there is no overlap with TLSv1.2 cipher suite names.
so the only ambiguity could be with the meta-names like "ALL" and "!CBC"
and the like.
No ambiguity. Those only apply to TLS 1.2
So if a user "explicitly lists TLSv1.2 ciphers" then I don't see why
they would get *any* TLSv1.3 ciphers at all.
Because OpenSSL configures TLS 1.2 and TLS 1.3 completely separately.
See above.
With option B this would change to just TLS 1.2 ciphers.
The drawback with option A is that excluding TLS 1.3 ciphers can't be
done with the ciphers attribute. The user would have to use protocols.
Why not allow syntax like "!TLSv1.3"? We already support syntax like
that to remove ciphers like "!CBC" so why not do the same with the
protocol-level matches? Or are those details being handled by OpenSSL
today and we'd have to implement that kind of matching ourselves if we
wanted to do this?
We currently mimic OpenSSL and OpenSSL doesn't do that. We could
implement extensions to the syntax to do that but I have multiple concerns:
- it will have different behaviour to OpenSSL which could cause confusion
- if OpenSSL ever adds a similar feature we could get a naming conflict
I will note that "!" on the command line doesn't seem to work as I expect:
$ openssl ciphers -v 'TLSv1.2'
[list of 89 cipher suites]
$ openssl ciphers -v '!TLSv1.2'
Error in cipher list
802B8C6E337F0000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no
cipher match:../ssl/ssl_lib.c:2779:
Nor does attempting to select TLSv1.3 ciphers:
$ openssl ciphers -v 'TLSv1.3'
Error in cipher list
80DB93DC417F0000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no
cipher match:../ssl/ssl_lib.c:2779:
... but maybe that's part of the problem, here.
Look at the -ciphersuites option for the ciphers command.
This really just seems doable to me; maybe I'm missing some subtle yet
important point.
My main concern is backwards compatibility. I've spent a while looking
at this and mimicking OpenSSL and having TLS 1.3 config to be completely
separate avoids all the backwards compatibility issues.
And there was me thinking the OCSP changes would be the biggest headache
with these native releases.
Mark
I'm going to proceed with option A. If I find any blockers, we can re-
evaluate.
I'm not planning on tagging Tomcat Native until I have a set of local
changes for Tomcat 12.0.x that works with then current Tomcat Native
2.0.x
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
