Bug 1455029

------- Comment From chavez.com 2017-05-24 11:26 EDT-------
Raised a ticket with Java L3 regarding this problem and will update the bug when I get an update from them.

------- Comment From chavez.com 2017-05-25 14:46 EDT-------
From Java L3:

"So if I understand the problem correctly, you're previously enabling a list of cipher suites in a specific order.
After that, you're using the property "javax.net.ssl.SSLParameters.setUseCipherSuitesOrder(boolean honorOrder)" which receives a boolean.
Even with those two things, you still don't see the order you configured, correct?

If that's the case, I have some follow up questions:
- How are you enabling the cipher suites? System property? code?
- I JSSE SSL Client or SSL Server?

I think you need to send me a standalone java code to demonstrate the issue so I can see if the API is actually being used correctly.
Thanks!"

Created attachment 1282484 [details]
SSL server standalone application

Exactly.

So I have created standalone application where you can reproduce this behavior.

Please read README.md for detailed steps.

Created attachment 1282930 [details]
L3 supplied testcase


------- Comment on attachment From chavez.com 2017-05-27 15:58 EDT-------


Response from Java Security L3:

So in the customer's testcase, JSSE is acting as SSL Server.
According to the following link:
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

----------
During TLS handshaking, the client requests to negotiate a cipher suite from a list of cryptographic options that it supports, starting with its first preference. Then, the server selects a single cipher suite from the list of cipher suites requested by the client. Normally, the selection honors the client's preference. 
However, to mitigate the risks of using weak cipher suites, the server may select cipher suites based on its own preference rather than the client's preference, by invoking the method SSLParameters.setUseCipherSuitesOrder(true).
----------

Unfortunately, I was not able to run the customer's testcase. Maybe it's a runtime issue with my Eclipse IDE or something else.
So I created my own version of a SSL Server testcase to test the above. Please find it attached to this email.

Just need to compile it and run it (java -Djavax.net.debug=true ServerJsse).
As you can see, I'm enabling the cipher suites in the following order:
----------
params.setCipherSuites(new String[] {"SSL_RSA_WITH_AES_128_GCM_SHA256","SSL_RSA_WITH_AES_128_CBC_SHA256"});
----------

And I'm using the following OpenSSL command to send a ClientHello to JSSE:
openssl s_client -connect localhost:8443 -cipher AES128-SHA256:AES128-GCM-SHA256

The equivalents to those ciphers are as follows:
TLS_RSA_WITH_AES_128_CBC_SHA256 -> AES128-SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256 -> AES128-GCM-SHA256

With that command, the SSL Server ALWAYS receives the following ClientHello:
----------
*** ClientHello, TLSv1.2
RandomCookie:  GMT: -741961463 bytes = { 99, 227, 227, 12, 190, 228, 242, 8, 169, 200, 161, 233, 206, 125, 177, 48, 11, 119, 25, 212, 245, 91, 230, 151, 187, 77, 98, 70 }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_AES_128_CBC_SHA256, SSL_RSA_WITH_AES_128_GCM_SHA256, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Unsupported extension type_35, data: 
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3, signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA
Unsupported extension type_15, data: 01
----------

So as you can see, OpenSSL is sending the CBC first and after that it sends GCM. However, I instructed JSSE to ignore the SSL Client's preference and use my own list. So JSSE sends back the following ServerHello:
----------
*** ServerHello, TLSv1.2
RandomCookie:  GMT: 1495829286 bytes = { 194, 139, 45, 111, 218, 30, 145, 161, 241, 12, 58, 245, 228, 243, 205, 244, 135, 70, 8, 211, 6, 91, 38, 24, 19, 61, 176, 44 }
Session ID:  {89, 41, 139, 38, 163, 2, 26, 113, 152, 143, 47, 9, 209, 0, 135, 145, 46, 147, 101, 7, 150, 204, 192, 33, 16, 82, 32, 30, 187, 202, 228, 253}
Cipher Suite: SSL_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, ri_length: 0, ri_connection_data: { null }
----------

As you can see, the instruction is actually working because JSSE is selecting the GCM cipher suite even though it comes second in the ClientHello.
If I eliminate the following instruction from my code:
----------
params.setUseCipherSuitesOrder(true);
----------

JSSE sends back the following ServerHello:
----------
*** ServerHello, TLSv1.2
RandomCookie:  GMT: 1495829206 bytes = { 104, 188, 252, 23, 101, 229, 68, 228, 162, 27, 221, 161, 90, 187, 7, 110, 98, 23, 5, 134, 58, 44, 91, 222, 234, 103, 31, 240 }
Session ID:  {89, 41, 139, 214, 166, 53, 10, 96, 20, 190, 160, 23, 74, 37, 45, 52, 41, 80, 59, 178, 95, 132, 120, 203, 232, 19, 56, 42, 251, 212, 51, 71}
Cipher Suite: SSL_RSA_WITH_AES_128_CBC_SHA256
Compression Method: 0
Extension renegotiation_info, ri_length: 0, ri_connection_data: { null }
----------

As you can see, it's the SSL Client's preferred cipher suite.
So, the setUseCipherSuitesOrder is actually working and JSSE does not ignore it. Hence, it's a code issue in the customer's testcase.
Please ask him to check my example and fix their code.

------- Comment From chavez.com 2017-05-30 20:07 EDT-------
Hello,

Java L3 was asking if there are any questions since the last update or about the provide testcase.

Hi, 
I am not able to download attachement "L3 supplied testcase".
What is type of attachement?

(In reply to mchoma from comment #8)
> Hi, 
> I am not able to download attachement "L3 supplied testcase".
> What is type of attachement?
.
... it's a zip file ... I am correcting the attachment type in this RHBZ ...

I can't confirm what you see. When I try your reproducer with this ibm java 

java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp2-20170322_01(SR4 FP2))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20170314_340265 (JIT enabled, AOT enabled)
J9VM - R28_20170314_2309_B340265
JIT  - tr.r14.java.green_20170314_134138
GC   - R28_20170314_2309_B340265_CMPRSS
J9CL - 20170314_340265)
JCL - 20170318_01 based on Oracle jdk8u121-b13

I get different (wrong) behaviour

Server preference:
params.setCipherSuites(new String[] {"SSL_RSA_WITH_AES_128_GCM_SHA256","SSL_RSA_WITH_AES_128_CBC_SHA256"});
params.setUseCipherSuitesOrder(true);

Client preference:
TLS_RSA_WITH_AES_128_CBC_SHA256 -> AES128-SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256 -> AES128-GCM-SHA256

Chosen: SSL_RSA_WITH_AES_128_CBC_SHA256

// I need to generate different keystore. With keystore you have provided give me SSLHandshakeException: no cipher suites in common
keytool -genkeypair   -keystore testkeys   -alias test   -keyalg RSA   -keysize 2048   -validity 36500   -storepass passphrase   -keypass passphrase -dname "CN=test, OU=QE, O=Redhat, L=Brno, C=CZ"
javac ServerJsse.java
java -Djavax.net.debug=true  ServerJsse
openssl s_client -connect localhost:8050 -cipher AES128-SHA256:AES128-GCM-SHA256

------- Comment From chavez.com 2017-06-01 16:03 EDT-------
Reply from Java L3:

Thanks for the JVM information.
With that, I can successfully reproduce the customer's behavior. With Java 8 SR4 FP2, we didn't have the latest fixes to our JVM.
Can you please ask the customer to upgrade to Java 8 SR4 FP5 or if possible to FP6?
Thanks!

https://developer.ibm.com/javasdk/downloads/sdk8/

I confirm with Java 8 SR4 FP6 reproducer works as expected.

Could you provide us please link to issue tracking system. I couldn't find it myself.

[1] https://www.ibm.com/developerworks/java/jdk/fixes/

(In reply to mchoma from comment #12)
> I confirm with Java 8 SR4 FP6 reproducer works as expected.
> 
> Could you provide us please link to issue tracking system. I couldn't find
> it myself.
> 
> [1] https://www.ibm.com/developerworks/java/jdk/fixes/
.
fyi ... IBM Java 8 SR4 FP5 was released on RHN at 05/10/2017 ...
... see https://access.redhat.com/errata/RHSA-2017:1220 ...
.
... IBM Java 8 SR4 FP6 was released by IBM at 05/31/2017
(see https://developer.ibm.com/javasdk/downloads/sdk8/ ...)
and is not yet available from RHN ...

------- Comment From chavez.com 2017-06-05 14:14 EDT-------
(In reply to comment #20)

I asked Java L3 about this and here what the developer said:

"Unfortunately, we don't have a link that we can share publicly.
The APARs that fixed this bug involved several components and they are internal to our JTC teams (Austin defects).
What I can tell you is that our JVM was failing to read some properties... hence, not taking any effect. The module was there, but it never received the instruction.
Please let me know if you have any other questions."

------- Comment From chavez.com 2017-06-07 18:20 EDT-------
At this point I am going to close the support ticket with the Java L3 team as we are now waiting for Red Hat to package the IBM Java 8 SR4 FP6 that fixed the problem. Any objections?

Hello Red Hat / Jiri,
... with IBM Java 8 SR5 FP5 available on RHN since 11/27/2017 
(see https://access.redhat.com/errata/RHSA-2017:3264 ...)
I would think that this bugzilla can be closed ...
... please confirm or advise.
Thanks in advance for your support.

This is something I would like reporter to review. Thnak you for keeping an eye Joachim!

It can be closed. I have already confirmed we don't hit issue anymore [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1455029#c12

You could close it :)
TY!