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

Chetan Gowda
  • 119
  • 2
  • For ephemeral keyexchanges, **ServerKeyExchange content is signed** using the key matching the certificate; see rfc5246 (or predecessors) section 7.4.3. And since I just worked a relevant example, http://security.stackexchange.com/questions/143213/how-to-verify-a-server-key-exchange-packet . – dave_thompson_085 Nov 23 '16 at 10:31
  • 2
    Crosspost http://crypto.stackexchange.com/questions/41776/tls-handshake-proof-of-private-key-posession but that is correctly answered – dave_thompson_085 Nov 24 '16 at 04:24
  • 1
    I'm voting to close this question as off-topic because it is cross posted to crypto, and answered there. – Rory Alsop Dec 04 '16 at 00:14

1 Answers1

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.

Limit
  • 3,236
  • 1
  • 16
  • 35
  • 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
  • @Limit : I'm looking for the unable to decrypt "what exactly" without private key. Is it decrypt client part of Diffie Hellman ? Or some client random bytes or something else. My doubts are arising from my limited or jumbled up knowledge on this. Please pardon me. – Chetan Gowda Nov 24 '16 at 00:09
  • @ChetanGowda in the image present in the question, every message from "Certificate Verify" onwards are encrypted. After the key is established, all the messages are encrypted using the session key – Limit Nov 24 '16 at 03:30
  • 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 04:23
  • @dave_thompson_085 : I understand that symmetric keys generated by data exchanged from Diffie Hellman is used for bulk/symmetric encryption. I am just confused how RSA authenticates the server. In my knowledge, anyone can send the same public certificate as the real server, hence the server needs to prove possession of private key by decrypting and using "something" that the client encrypted with servers public key and sent to server. I am looking for what is that "something", I am guessing that "something" could be client part of data for Diffie Hellman key exchange. – Chetan Gowda Nov 24 '16 at 05:01
  • @ChetanGowda http://crypto.stackexchange.com/questions/5332/how-does-a-client-verify-a-server-certificate should help you – Limit Nov 24 '16 at 17:29
  • You may not even have a DH key exchange, and before the first `ChangeCipherSpec` message *nothing* is encrypted except the `ClientKeyExchange` message. – user207421 Mar 21 '17 at 04:27