Bug 58275

Summary: TLS prefixed ciphers are discarded with IBM JRE
Product: Tomcat 7 Reporter: Ajay Ponnappan <ajponnap>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: major    
Priority: P2    
Version: 7.0.54   
Target Milestone: ---   
Hardware: PC   
OS: All   

Description Ajay Ponnappan 2015-08-23 15:11:48 UTC 
Regarding IBM JRE ciphersuites, below IBM documentation says that 

https://www-01.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.71.doc/security-component/jsse2Docs/ciphersuites.html

+++++++
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 

https://bz.apache.org/bugzilla/show_bug.cgi?id=57718

+++
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).