Bug 1123342 - [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
Summary: [openssl syntax with JSSE] Forcing usage of JSSE variant with TLS in name can...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: EAP 6.4.0
Assignee: Emmanuel Hugonnet (ehsavoie)
QA Contact: Michael Cada
URL:
Whiteboard:
Depends On: 1123304 1149776
Blocks: 1123356 1166610
TreeView+ depends on / blocked
 
Reported: 2014-07-25 11:33 UTC by Radim Hatlapatka
Modified: 2019-08-19 12:46 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-19 12:46:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.