Bug ID: JDK-7180100 Need to get shared shell working with Java 1.7

Type: Bug
Component: security-libs
Sub-Component: javax.net.ssl
Affected Version: 7

Priority: P5
Status: Closed
Resolution: Incomplete
OS: generic
CPU: generic

Submitted: 2012-06-27
Updated: 2015-01-13
Resolved: 2015-01-13

In order to overcome the incompatibility between jre 1.6_29 and shared shell, this CR is to test a beta shared shell server running Java 1.7
Reason for running Java 1.7 for sharedshell
1. ability to upgrade jdk going forward
2. avoid beast vulerability.
3. compatability issue using different jre's on client /server after changes made
aroung jdk 1.6.0_29
Problem manifests as follows during a shared shall connection
Using jdk 1.7.0_5 on tunnel server and on client

On Tunnel Server, the following stack trace:
     [java] 2012-06-27 17:34:08.828 INFO [T28 TunnelProtocolFilter.execute] DBG TunnelProtocolFilter.execute.2 tmh=TunnelMessageHeader(version=2.0,source=0,destination=32766,type=1,flags=0x0,channel=0,conferenceID=null,expectLength=0) isValid=true
     [java] 2012-06-27 17:34:13.258 INFO [T27 TunnelProtocolFilter.execute] DBG TunnelProtocolFilter.execute.1 bufcnt=1 < TMH.SIZE 30
     [java] 2012-06-27 17:34:13.259 INFO [T26 TunnelProtocolFilter.execute] DBG TunnelProtocolFilter.execute.2 tmh=TunnelMessageHeader(version=0.-1,source=-129,destination=-512,type=12800,flags=0x0,channel=0,conferenceID=null,expectLength=129964) isValid=false
     [java] 2012-06-27 17:34:13.259 SEVERE [T26 TunnelProtocolFilter.execute] Invalid msg header:<-----problem here TunnelMessageHeader(version=0.-1,source=-129,destination=-512,type=12800,flags=0x0,channel=0,conferenceID=null,expectLength=129964)

On client side (javaws)

Jun 27, 2012 5:35:39 PM com.sun.srs.tunneling.util.misc.TunnelMessageReceiver run
WARNING: Exception: incomplete TunnelMessageHeader occurred during message reception. Receiver terminating.
java.io.EOFException: incomplete TunnelMessageHeader
        at com.sun.srs.tunneling.util.api.TunnelMessageHeader.readHeader(TunnelMessageHeader.java:631)
        at com.sun.srs.tunneling.util.api.TunnelMessage.readMessage(TunnelMessage.java:438)
        at com.sun.srs.tunneling.util.misc.TunnelMessageReceiver.run(TunnelMessageReceiver.java:135)

No additional information from Assignee, closing for now. Please reopen and reassign if needed. If it should stay with javax.net.ssl, please provide additional information.
13-01-2015
Since you mentioned BEAST in relation to the Shared Shell Failure in bugdb 13396940, our understanding of the root cause of that bug is that the Shared Shell did not properly read all of the data from the connection when working with block ciphers like. If the peer sent "ABC...", it would be broken up into two TCP/SSL packets, "A" and "BC...". When the BEAST fix was put in place, we saw several instances of code that grabbed the current data (first packet), which would return just "A". They would then try to process an incomplete application request. Of course, that would fail. e.g. "G" and "ET / HTTP/1.0" The fix is to make sure that the entire request is present. Applications must be able to handle fragmentation at the TLS and TCP layers. That's why that bug was closed as not a bug. One workaround is to use a non-block cipher like RC4, but RC4 has its own problems.
08-04-2014
Just looking back through the notes. The problem seems to be cipherSuitesRegex" value="_AES_.*_SHA"/ The workaround was to use SSL_RSA_WITH_RC4_128_SHA The testcase I would write for this problem would be to use AES in CBC mode and see if one could send a long stream of numbers increasing sequentially from one machine to another using this protocol + multithreading. If the sequence of numbers could be read off without error at the receiving end then I would be confident that the implementation actually works post the changes for beast vulnerability. If that is the case then it would be acceptable to close this out , if not then the fix may need to be looked at again. Thanks Henry S
08-04-2014
Pinged Responsible Engineer. Sustaining plans to close if no further progress. Is this the same as: https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=13396940
03-04-2014
Has this really been assigned to JDK dev? If so, the Assignee needs to be cleared/changed. Has this been run on a recent build? These are all at least a year old, and there were some minor tweaks done in later releases.
02-09-2013
WORK AROUND You can work around problem by chnaging the cipher suites <entry key="cipherSuitesRegex" value="_RC4_._SHA"/> in conf/tunserver.xml from <entry key="cipherSuitesRegex" value="_AES_._SHA"/>
28-06-2012