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?)
-- http://bernd.eckenfels.net ________________________________ Von: security-dev <security-dev-boun...@openjdk.java.net> im Auftrag von Xuelei Fan <xuelei....@oracle.com> Gesendet: Donnerstag, Oktober 31, 2019 11:10 PM An: Eugène Adell Cc: security-dev@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....@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 >>>
