On 18/12/2025 17:01, Rainer Jung wrote:
Am 18.12.25 um 17:17 schrieb Mark Thomas:
<snip/>
Hmm. We currently have:
SSLContext.setCipherSuite
and
SSL.setCipherSuites
so the original name for the new method won't work. How about:
public static native boolean setCipherSuitesEx(long ctx, String
cipherSuites)
on both SSLContext and SSL
I can also reproduce the "... Tomcat interprets the [ciphers]
attribute..." warning now as well.
There are a lot of moving parts here and I want to get to the bottom
of all of the various issues we are seeing and make sure that they are
resolved - or at least documented and understood - for all the various
combinations of Tomcat version, OpenSSL version, Java version, Tomcat
Native version etc.
I think a tag this week is currently looking less likely than I
thought a few hours ago.
Since the OpenSSL methods for setting ciphers for TLS < 1.3 and == 1.3
behave so different, I wonder whether a uniform approach can work.
The httpd web server reused its existing SSLCipherSuite config
directive, but in effect you can use it like before, which only sets the
cipher list for TLS < 1.3 or you can use it with the additional token
"TLS1.3" before the ciphers, which then sets the TLS 1.3 ciphers. And
you can use it twice, once for the non 1.3 ciphers and once for the 1.3
ciphers. So httpd makes no attempt to unify those two cases. They are
configured and handled separately.
Since it might not be clear, which protocol client and server negotiate,
I am not sure how easy it is to get to a uniform cipher configuration.
Whether we provide two API methods (< 1.3 and == 1.3) or some syntactic
cipher list sugar that we can use to split the two intended cases (<1.3
and == 1.3) from one config string might be a question of style. But I
think we need a way to express different cipher configurations for < 1.3
and == 1.3.
Hope that makes sense, but maybe I did not yet fully understand the
scope of the discussion.
Thanks Rainer, I do understand where you are coming from.
Things aren't quite so clear cut in Tomcat because we need to support
both JSSE and OpenSSL, converting between the two as required.
We can't re-use the httpd trick of defining the directive twice as we
use XML configuration files. We could actually handle calling the setter
twice. It is the getter that would be the issue for the store config code.
JSSE uses a single configuration value for TLS <= 1.2 and TLS >= 1.3
ciphers whereas OpenSSL uses two.
OpenSSL will accept a combined value for both individual configuration
values and just ignore the unrecognised ciphers.
Internally, Tomcat stores ciphers using OpenSSL format and Tomcat has
code to convert between JSSE cipher names and OpenSSL cipher names as
required.
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. 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.
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
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
