On Fri, Dec 19, 2025 at 1:33 PM Mark Thomas <[email protected]> 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. 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
I agree with option A. I wanted to avoid it since it sounded horrible. However, having to configure ciphers for TLS 1.3 is not likely at all. As a result, I think this is the way to go. Rémy > Mark > > > --------------------------------------------------------------------- > 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]
