Bug 1123342

Summary: [openssl syntax with JSSE] Forcing usage of JSSE variant with TLS in name can result in cipher not match in case JAVA supports only that cipher with SSL in name
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Radim Hatlapatka <rhatlapa>
Component: WebAssignee: Emmanuel Hugonnet (ehsavoie) <ehugonne>
Status: CLOSED EOL QA Contact: Michael Cada <mcada>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.3.0CC: rmaucher
Target Milestone: ---   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-19 12:46:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1123304, 1149776    
Bug Blocks: 1123356, 1166610    

Description Radim Hatlapatka 2014-07-25 11:33:06 UTC 
Description of problem:
There are ciphers which can exist with both SSL and TLS in its name but some JDKs can support only one of those.

E.g. when using [1] the java recognizes only SSL variant of DHE_RSA_WITH_3DES_EDE_CBC_SHA => SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (it doesn't know cipher TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, which results in server not being able to match appropriate cipher when using DHE-RSA-DES-CBC3-SHA as cipher suite name



[1] JDK 1.7 with security unlimited
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Comment 1 Rémy Maucherat 2014-09-11 15:12:35 UTC 
r2509 in web rebases on the Tomcat code since this needs support for alias names. Other fixes and improvements are included in the rebase.
Comment 2 Kabir Khan 2014-10-08 12:16:43 UTC 
Should be fixed by component upgrade to 7.5.0.Beta3 1149776
Comment 3 Radim Hatlapatka 2014-10-21 08:23:02 UTC 
Verified with EAP 6.4.0.DR5
Comment 4 Radim Hatlapatka 2015-01-19 10:16:20 UTC 
When checking with EAP 6.4.0.ER1, I have found that ciphers on IBM JDK have only SSL variant without having TLS variant using [1] which results in "no cipher match" match error for ciphers not having defined alias even though they should be supported on given JDK.

E.g. if you define cipher-suite as "AES+SHA" there are multiple ciphers which should match this criteria, nevertheless due being defined as TLS_... without SSL_... as alias the connector fails to start with "no cipher match" error.

E.g. one of matching ciphers to "AES+SHA" which is supported on IBM JDK is SSL_RSA_WITH_AES_128_CBC_SHA, and in org.apache.tomcat.util.net.jsse.openssl.Cipher there is only TLS_RSA_WITH_AES_128_CBC_SHA without defined alias to SSL_RSA_WITH_AES_128_CBC_SHA


[1] method for getting default vs supported ciphers in used JAVA
 public static synchronized Set<String> getDefaultCipherSuitesFromJDK() {
      SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault();
      // String[] cipherSuites = factory.getDefaultCipherSuites(); // for default ciphers
      String[] cipherSuites = factory.getSupportedCipherSuites(); // for supported ciphers
      return new HashSet<String>(Arrays.asList(cipherSuites));        
 }
Comment 5 Radim Hatlapatka 2015-01-22 10:23:31 UTC 
When retrieving supported ciphers on IBM JDK, there are retrieved only the SSL variants. Thereby on IBM JDK this issue has higher impact => increasing severity.