Mark,
On 12/19/25 7:32 AM, Mark Thomas wrote:
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.
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?
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.
So if a user "explicitly lists TLSv1.2 ciphers" then I don't see why
they would get *any* TLSv1.3 ciphers at all.
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?
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.
This really just seems doable to me; maybe I'm missing some subtle yet
important point.
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]
