the GMT timestamp given in the trace is sometimes wrong

Thu Oct 31 22:55:00 UTC 2019

On 10/31/2019 3:44 PM, Bernd Eckenfels wrote:
> It would make sense to no longer calculate and print the timestamp in 
> the debug log if we don’t want it to be relied upon. This would be less 
> missleading (and mopst likely the shifting logic can be removed?)
> 
Yes.  No timestamp, only 32 bytes random number in the debug log since 
JDK 11.

Xuelei

> 
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag 
> von Xuelei Fan <xuelei.fan at oracle.com>
> *Gesendet:* Donnerstag, Oktober 31, 2019 11:10 PM
> *An:* Eugène Adell
> *Cc:* security-dev at openjdk.java.net
> *Betreff:* Re: the GMT timestamp given in the trace is sometimes wrong
> 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
>  >>>