the GMT timestamp given in the trace is sometimes wrong

[Eugène Adell]

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