Thanks Mark.

Hi All,

I have a follow-up question on the below concern with SSL/TLS cipher 
configuration in our Tomcat deployment and need your assistance.

Issue Description:

We have explicitly configured a specific set of ciphers in our server.xml 
connector configuration, but the configuration appears to be ignored. 
Additionally, we are seeing RSA key exchange ciphers in our SSL
handshake that we did not include in our cipher list.

Environment Details:

* Tomcat Version: 11.xx
* Java Version: OpenJDK 17
* Operating System: Linux

Configuration:

xml
<Connector protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp"
           port="2309"
           maxThreads="200"
           scheme="https"
           secure="true"
           SSLEnabled="true"
           honorCipherOrder="true"
           sslProtocol="TLSv1.2+TLSv1.3"
           
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"
 />

Here the particular RSA key exchange ciphers are supported in JAVA. But not 
coming in the nmap command output even if we mention those ciphers in 
server.xml.
Questions:

1. Why are the cipher configuration properties not being recognized in the 
connector configuration?
2. Are there any Tomcat security policies that override explicit cipher 
configurations in server.xml?
3. If there are security configurations that disable certain cipher suites 
(particularly RSA key exchange ciphers), could you please provide:
   * The specific configuration files or properties involved
   * Documentation on how these security policies work
   * Methods to override or customize these policies if needed

4. What is the correct way to explicitly control cipher suites in Tomcat to 
ensure only our specified ciphers are available.

Regards,
Abirami.S

-----Original Message-----
From: Mark Thomas <ma...@apache.org>
Sent: Tuesday, August 19, 2025 5:30 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat 11 and JDK 17 application ciphers difference

On 19/08/2025 12:17, S Abirami wrote:

<snip/>

 > Questions:>
> 1. Is Tomcat 11 intentionally filtering out RSA key exchange cipher suites by 
> default? If so, where is this documented?

Yes.
https://tomcat.apache.org/tomcat-11.0-doc/config/http.html
look for the "ciphers" attribute

> 2. What is the mechanism for this filtering? Is it hardcoded in the SSL 
> implementation or configurable?

https://tomcat.apache.org/tomcat-11.0-doc/config/http.html
look for the "ciphers" attribute

> 3. Is there a system property or configuration option to disable Tomcat's 
> cipher filtering and use Java's default cipher suite selection?

No.

You could set the ciphers attribute to be the same as the Java default (quite a 
long list) but there is no setting for "use whatever the Java default is".

> Expected Behaviour:
> When no explicit cipher configuration is provided, I would expect Tomcat to 
> use the same cipher suites that are available to other Java applications 
> using the same JVM and security configuration.

The assumption that the security configuration is the same is flawed because 
Tomcat has explicit defaults rather than simply using the JVM defaults.


Tomcat has the defaults it has so that swapping between the JSSE and the 
OpenSSL based TLS implementations has minimal impact on behaviour.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to