the GMT timestamp given in the trace is sometimes wrong

Thu Oct 31 23:03:29 UTC 2019

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