the GMT timestamp given in the trace is sometimes wrong

Fri Nov 1 14:54:15 UTC 2019

Hi Eugène,

Yes, there may be a random number stringizing problem in JDK 8.

Xuelei

On 10/31/2019 4:03 PM, Eugène Adell wrote:
> Hello,
> 
> the capture I sent shows it's TLS 1.1 and not TLS 1.3 whose RFC
> doesn't mention gmt_unix. I opened this thread because the
> implementations of TLS 1.0/1.1/1.2 are not doing what is written in
> their RFCs, and I didn't say the implementation of TLS 1.3 was wrong.
> Besides, the log was produced with Java 8 which doesn't support TLS
> 1.3.
> 
> I'm not opening a discussion whether gmt_unix is secure or not, it's
> beyond the discussion. The author of this draft forgets that a client
> which is not synchronized with an NTP server will see its clock
> deriving, making the fingerprinting hazardous, but he takes it for
> granted that clocks are not deriving and that he would track a client
> easily. Probably true on a short period of time, but in a single day
> you already have your clock derived of several seconds or even
> minutes.
> 
> E.A.
> 
> 
> 
> 
> 
> Le jeu. 31 oct. 2019 à 23:09, Xuelei Fan <xuelei.fan at oracle.com> a écrit :
>>
>> 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
>>>>>