the GMT timestamp given in the trace is sometimes wrong

[Sean Mullan]

On 10/14/19 4:13 PM, Eugène Adell wrote:
> Hello,
> 
> I've posted this issue below 2 months ago and still did not see any
> reply. I also suggested how to correct.
> 
> Can anyone please check ?

It does seem like an issue, but what version of the JDK are you using? 
The RandomCookie code has changed in later versions of the JDK such that 
it may not be an issue anymore. I would recommend checking with JDK 11 
or later. If it is still an issue, please file a bug at 
https://bugreport.java.com/bugreport/.

Thanks,
Sean

> 
> Eugene
> 
> 
> Le lun. 12 août 2019 à 01:26, Eugène Adell <eugene.adell at gmail.com> a écrit :
>>
>> Hello,
>>
>> When using the well-known javax.net.debug=all property we get outputs
>> similar to this :
>>
>> ...
>> Ignoring unsupported cipher suite:
>> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
>> Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>> for TLSv1.1
>> Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
>> for TLSv1.1
>> %% No cached client session
>> update handshake state: client_hello[1]
>> upcoming handshake states: server_hello[2]
>> *** ClientHello, TLSv1.2
>> RandomCookie:  GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18,
>> 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17,
>> 205, 121, 220, 52, 127, 169, 241 }
>> Session ID:  {}
>> Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
>> TLS_RSA_WITH_AES_256_CBC_SHA256,
>> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
>> ...
>> Compression Methods:  { 0 }
>> Extension elliptic_curves, curve names: {secp256r1, secp384r1,
>> secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1,
>> sect571r1, secp256k1}
>> Extension ec_point_formats, formats: [uncompressed]
>> Extension signature_algorithms, signature_algorithms: SHA512withECDSA,
>> SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA,
>> SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA,
>> SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
>> Extension extended_master_secret
>> Extension server_name, server_name: [type=host_name (0),
>> value=bugs.openjdk.java.net]
>> ***
>> [write] MD5 and SHA1 hashes:  len = 229
>> 0000: 01 00 00 E1 03 03 5D 50   90 3C 77 58 CE 54 68 12  ......]P.<wX.Th.
>> 0010: 38 6E 9D A2 32 F7 8E 2F   2E 0B 85 C4 15 6C 11 CD  8n..2../.....l..
>> 0020: 79 DC 34 7F A9 F1 00 00   56 C0 24 C0 28 00 3D C0  y.4.....V.$.(.=.
>> 0030: 26 C0 2A 00 6B 00 6A C0   0A C0 14 00 35 C0 05 C0  &.*.k.j.....5...
>> ...
>>
>> However converting the timestamp found in the RandomCookie 1565495356
>> gives 5D4F903C and not 5D50903C, which is the value found in the debug
>> trace (line starting by "0000:")
>> This of course doesn't break anything but I guess this is not the
>> expected behaviour.
>> The problem is reproducible depending on the current time. From my
>> tests, the GMT value is wrong, and the value sent in the handshake
>> itself is right. Probably RandomCookie.print() is facing the
>> endianness problem, and I suggest the following patch that I
>> unit-tested but not in JSSE itself :
>>
>> --- a/RandomCookie.java 2019-08-12 00:43:56.458000000 +0200
>> +++ b/RandomCookie.java 2019-08-12 01:18:06.874000000 +0200
>> @@ -70,10 +70,10 @@
>>       void print(PrintStream s) {
>>           int i, gmt_unix_time;
>>
>> -        gmt_unix_time = random_bytes[0] << 24;
>> -        gmt_unix_time += random_bytes[1] << 16;
>> -        gmt_unix_time += random_bytes[2] << 8;
>> -        gmt_unix_time += random_bytes[3];
>> +        gmt_unix_time = ((random_bytes[0] & 0xFF) << 24) |
>> +          ((random_bytes[1] & 0xFF) << 16) |
>> +          ((random_bytes[2] & 0xFF) << 8) |
>> +          ((random_bytes[3] & 0xFF) << 0);
>>
>>           s.print("GMT: " + gmt_unix_time + " ");
>>           s.print("bytes = { ");
>>
>>
>> best regards
>> Eugene Adell