the GMT timestamp given in the trace is sometimes wrong

[Eugène Adell]

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
> >