TLS handshake proof of private key posession At what stage in below TLS connection setup did the server prove to client that it possesses the private key corresponding to its public RSA key.

I have used TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Cipher suite to successfully setup a server client mutually authenticated connection. I am just curious how it works. I have a rough idea about Diffie Hellman key generation(I believe it is independent of authentication, and just for generation of secret to create symmetric key) but I could not understand in below sequence diagram, where did the server prove its possession of private key(I know that only private key decrypts what public key encrypts, but any hacker could send a copy of public certificate of any server)
I have used TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384


That means that client and server are using ECDHE for the key exchange and RSA for verification of the server sent parameters. This is what perfect secrecy does, every time that a TLS handshake occurs, the servers sends with the certificate a list of parameters used for the key exchange along with a digital signature over these, in this case RSA signature. These parameters + signature are contained in the ServerKeyExchange field.


  but any hacker could send a copy of public certificate of any server)


You as a client can validate if the presented certificate matches the entity that you want to connect to. This is done by validating that the received certificate on ServerCertificate field belongs to the entity that you are connecting to (CN &amp; SubjectAltName fields) and that the certificate chain is valid (the Root CA has sign the intermediate CA that has sign the leaf certificate AKA the entity's certificate).

So if the validation is successful you proceed to validate the ECDHE parameters sent by the server in ServerKeyExchange field to prove that the server posses (as you ask) the private key associated to the RSA public key. Just take the RSA public key of the leaf certificate and verificate the digital signature of those parameters. If the digital signature matches the digest (hash) of the parameters + ClientHello.random + ServerHello.random, then you know that those ECDHE parameters have been sent by the server and not by an eavesdropper that tries to establish a symmetric key to impersonate the server.