the GMT timestamp given in the trace is sometimes wrong

[Xuelei Fan]

The ClientHello.random has been changed to use "random number" since TLS 
1.3 (See RFC 8446).  The 4 leading bytes are not more used to indicate 
clock in the current implementation.  For more details, please consider 
this doc (https://tools.ietf.org/id/draft-mathewson-no-gmtunixtime-00.txt).

Xuelei

On 10/31/2019 2:36 PM, Eugène Adell wrote:
> Hello,
> 
> with Java 8 and earlier (and probably some later that I didn't check),
> the timestamp is correct half of the time, incorrect the other half,
> because of the bad shifting that I pointed in my first post. One
> incorrect clock is not supposed to be correct 50% of the time, for
> example it would be 1 minute late all the time.
> 
> With Java 11 the clock is always incorrect, and even it can't be
> considered a clock anymore when your clock is years late, it's still
> more consistent than the previous behaviour.
> 
> "Please don't have the application rely on the gmt_unix_time value."
> Sure, and anyway a Java application cannot access to this value from
> what I know. Having a correct time is however useful when analyzing
> logs produced with javax.net.debug property, or correlating with a
> network capture. This is how I went to see that problem, by
> investigating an issue, and we shouldn't underestimate the very few
> tools that allow troubleshooting.
> 
> best regards
> E.A.
> 
> 
> Le jeu. 31 oct. 2019 à 21:50, Xuelei Fan <xuelei.fan at oracle.com> a écrit :
>>
>> 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
>>>