Can request from different software on same machine to a server be identified to be from same origin by tracking TLS handshakes?

Question

If two different users visit an website from two different browsers via HTTPS, can they be identified by the server to be from same origin (same client machine) using information available from TLS handshake (except just IP)?

As far as I can understand- since TLS is below application layer, so the Session ID (from Server Hello during TLS handshake) can be same for both requests from different browsers. Thus the server can determine both requests to be from same machine- is that correct?

And, as per the following statement from this article-

The connection will stay open while both sides send and receive encrypted data until either side sends out a “closure alert” message and then closes the connection. If we reconnect shortly after disconnecting, we can re-use the negotiated keys (if the server still has them cached) without using public key operations, otherwise we do a completely new full handshake.

The article quoted above implies that even after disconnection the same negotiated keys can be used to continue data exchange. Does it mean even after changing IP, the server can trace (just based on TLS) that the requests are coming from same machine?

Is there anything else commonly known that a server can use to confidently relate two different HTTPS requests to be originating from same machine (but different browser)?

Apologies if this is not the right place to ask OS specific question.

Answer 1

If two different users visit an website from two different browsers via https, can they be identified by the server to be from same origin(client machine) using information available from TLS handshake?

In some cases, yes.

For example, your question states that the requests come from the same client machine. If this machine has a static IP address then all the IP packets will have the same source IP address in the IP header. IP header information is not protected by TLS. TLS handshake packets are TCP packets, which are then encapsulated in IP packets, which contain the source IP information. Here I am considering this header information to be "part of" the TLS handshake since the remote server will certainly know it.

---

Edit/Update (to more directly address the question and comment):

As far as I can understand- since TLS is below application layer, so the Session ID (from Server Hello during TLS handshake) can be same for both requests from different browsers. Thus the server can determine both requests to be from same machine- is that correct?

TLS is below the application layer in a sense, but it is also above the transport layer, since it relies on the underlying TCP.

Since processes communicate via TCP, you would not see two different web browsers (each a different application/process) running over the same TLS connection. Each browser will establish its own TLS connection, each will send its own client_hello, and each will receive its own server_hello. For example, if I use Chrome to connect to www.website.com, and then I use Internet Explorer to connect to www.website.com, I will be able to see (e.g., with Wireshark) two different server_hello packets from www.website.com and those packets have different Session ID values.

So, this would not be a good method of determining that the different browser requests are from the same machine. Whereas, the IP address method mentioned above does have a chance of working.