Bug 58275 - TLS prefixed ciphers are discarded with IBM JRE
Summary: TLS prefixed ciphers are discarded with IBM JRE
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.54
Hardware: PC All
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2015-08-23 15:11 UTC by Ajay Ponnappan
Modified: 2015-09-07 19:31 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Ajay Ponnappan 2015-08-23 15:11:48 UTC
Regarding IBM JRE ciphersuites, below IBM documentation says that 


Note: In the following list, the string "SSL" is interchangeable with "TLS" and vice versa. For example, where SSL_RSA_WITH_AES_128_CBC_SHA is specified, TLS_RSA_WITH_AES_128_CBC_SHA also applies.

However if I set TLS prefixed ciphers using the setCiphers method of org.apache.coyote.http11.Http11Protocol object, it is not taking effect. I see the following bugzilla thread which says 


IBM uses SSL_XXX for all it ciphers although it will accept TLS_XXX. When Tomcat compares the available ciphers against the requested ciphers it can't tell that SSL_XXX and TLS_XXX are the same.

My request here is to see we have some option to avoid this check of cipher list against the available ciphers?. If not, can we have such option, as a JVM parameter or something, so that we can make use of it to allow TLS prefixed ciphers with IBM JRE?
Comment 1 Ajay Ponnappan 2015-08-23 15:16:29 UTC
FYI that I am working on IBM Integration Bus product and we have our customers finding difficulty in setting TLS prefixed ciphers. IBM Integration Bus internally uses tomcat for all its listeners. So is my request to see if we have any such option there by we can avoid the rejection of TLS prefixed ciphers
Comment 2 Mark Thomas 2015-08-24 15:26:56 UTC
If the cipher suites are specified using the SSL_xxx form of the name rather than the TLS_xxx form does it work then?

My current thinking is that we can detect if we are running on an IBM JVM and then add the SSL_xxx form of the cipher after the TLS_xxx form in the list of ciphers so both are present.
Comment 3 Ajay Ponnappan 2015-08-24 16:21:32 UTC
Yes, if cipher suites are specified using SSL_xxx then it works perfectly. However, customers who are familiar with Oracle JRE are tend to specify TLS prefix:P. So is the need to address this issue

I have done a similar kind of patch for the time being where if we are running on IBM JRE, replace all TLS prefix with SSL prefix before calling setCiphers()

However the check for a specific JRE provider and then renaming the actual cipher names doesnt sound right to me.  So is this my request to get your thoughts to have a  more generalized solution
Comment 4 Mark Thomas 2015-09-07 19:31:40 UTC
I think the ideal solution would be if IBM reported both the TLS_XXX and SSL_XXX forms of the cipher suite names (and any other support aliases) when asked which cipher suites it supports. Not doing this makes input validation rather tricky.

Do you know anyone who works for IBM that has had a problem in this area that could advocate within IBM for the change? ;)

I've added a work-around for IBM JREs in trunk, 8.0.x (for 8.0.27) and 7.0.x (for 7.0.65).