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

[Xuelei Fan]

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