1

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)
TLS handshake

closed as off-topic by Rory Alsop Dec 4 '16 at 0:14

  • This question does not appear to be about Information security within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

0

There doesn't have to be any explicit proof of possessing a private key.

When you present a client with your certificate, the client will respond by encrypting data with the public key present in the certificate. If you don't have the private key, you will not be able to decrypt what the client sent hence the connection will not move forward. @adam86 pointed out that my answer was not clear. What I meant was that up untill you have a Diffie Hellman key exchange, the messages are encrypted using the public key. Once a symmetric key(session key) is established, it is used for the rest of the session.

What a motivated attacker can instead do is create their own certificate and act as if they are the actual server (man in the middle). This is still possible in SSL/TLS.

  • 1
    "the client will respond by encrypting data with the public key present in the certificate" this is not true. Asymmetric ciphers are used to either exchange or generate the keying material from which symmetric “session” keys are derived. Symmetric keys are often referred to as session keys because they are used for a single session and then discarded. They are the shared secrets used for symmetric encryption/decryption of the bulk of the data. – cyzczy Nov 23 '16 at 15:14
  • @Chetan Gowda. You can see on your diagram that the second packet the server is sending towards the client is the "server certificate". The client will have to verify the server identity e.g. checking the Trusted Root CA store to see if the servers certificate was signed with a trusted certificate, this is enough to verify it's identity. – cyzczy Nov 23 '16 at 15:17
  • @adam86 : "checking the root CA store to see if the servers certificate was signed with a trusted certificate" Since server certificate/public key is exchanged on internet to make connects and easily available, my concern is that what stops a hackers from obtaining this certificate and sending it to a client and impersonate a genuine server. – Chetan Gowda Nov 23 '16 at 23:15
  • @ChetanGowda the fact that you're unable to decrypt without a private key that deters them – Limit Nov 23 '16 at 23:29
  • 1
    Every message after ChangeCipherSpec is encrypted with one of the (new) session keys; that does not include CertificateVerify. But the ciphersuite named in the question uses ECDHE key exchange, which is one form of Diffie-Hellman, and all forms of Diffie-Hellman key exchange never encrypt anything with the publickey in the server's certficate; they ONLY use the key derived from the Diffie-Hellman agreement. – dave_thompson_085 Nov 24 '16 at 4:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.