Re: the GMT timestamp given in the trace is sometimes wrong

[Xuelei Fan]

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