Backport of JDK-8014618 to JDK6? (Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement)

[Alex Bligh]

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