Hi Alex, Has you confirmed that JDK-8014618 is the root cause of the failure? If no, would you mind enabled JSSE debug log (using system property, "javax.net.debug=all"), reproduce the bug and send me the debug log that contains the fall SSL/TLS handshaking messages of the failure? A reproducible test and the debug log would help us a lot to find the underlying problem.
Thanks, Xuelei On 7/10/2014 11:24 PM, Alex Bligh wrote: > I'm investigating an intermittent failure of TLS to connect to certain > hosts with a JDK6 based client. The symptoms look identical to JDK-8014618, > i.e. a failure of SSL negotiation approximately one in 256 times. > > The relevant bug report > > https://bugs.openjdk.java.net/browse/JDK-8014618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > states this was introduced in 7.0. This was fixed in JDK-8 and > backported to JDK-7 - see > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-July/007042.html > where the fix is identical > > However, looking at the patch to fix it in JDK-8: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6407106f1b1c > > (i.e. changeset 7273:6407106f1b1c) the vital lines seem to be: > > @@ -403,8 +403,9 @@ > } > return skey; > } else if (algorithm.equals("TlsPremasterSecret")) { > - // return entire secret > - return new SecretKeySpec(secret, "TlsPremasterSecret"); > + // remove leading zero bytes per RFC 5246 Section 8.1.2 > + return new SecretKeySpec( > + KeyUtil.trimZeroes(secret), "TlsPremasterSecret"); > } else { > throw new NoSuchAlgorithmException("Unsupported secret key " > + "algorithm: "+ algorithm); > > > JDK-6 has the following lines (starting at line 414): > > return skey; > } else if (algorithm.equals("TlsPremasterSecret")) { > // return entire secret > return new SecretKeySpec(secret, "TlsPremasterSecret"); > } else { > throw new NoSuchAlgorithmException("Unsupported secret key " > + "algorithm: "+ algorithm); > } > } > > It therefore seems to me that JDK-6 suffers from the same problem. > > The backport is larger than it might be due to refactoring whether > trimZeroes takes place and the addition of two test case files which > are about a hundred times the size of the change. It would be possible > to come up with a less intrusive patch by duplicating trimZeroes. > > Is this suitable for a backport to JDK-6? >
