the GMT timestamp given in the trace is sometimes wrong

[Xuelei Fan]

Hi,

The TLS spec does not require a correct gmt_unix_time:
    [RFC 5246] "Clocks are not required to be set correctly by the
    basic TLS protocol; higher-level or application protocols may
    define additional requirements."

Please don't have the application rely on the gmt_unix_time value.

Xuelei

On 8/11/2019 4:26 PM, Eugène Adell wrote:
> 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
>