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? -- Alex Bligh
