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

[Alex Bligh]

Xulei,

In this case I'm afraid I have confirmed that it is *not* the cause of the
particular failure we are seeing (the failure turned out to be elsewhere
after many hours debugging).

However, reading the code it would seem this should still be an issue,
and if it is an issue should presumably be reproducible using the
test case at:
 https://bugs.openjdk.java.net/browse/JDK-8014618

I'll have a go at this later if I get some time.

Alex

On 10 Jul 2014, at 23:14, Xuelei Fan <xuelei.fan at oracle.com> wrote:

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

-- 
Alex Bligh