2
$\begingroup$

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

$\endgroup$
  • $\begingroup$ Crosspost security.stackexchange.com/questions/143366/… (but better answered) $\endgroup$ – dave_thompson_085 Nov 24 '16 at 4:23
  • 2
    $\begingroup$ The answer you received in SE only covers the case that RSA is used as key exchange algorithm thus encrypting the pre-master key with the certificate's public key. In your example you use ECDHE + RSA, so a ServerKeyExchange is needed, and in this case, the RSA public key is only used for digital signature verification, not for encrypting pre-master keys. That's what perfect secrecy wants to achieve (if RSA private key gets leak/compromised/stolen all the intercepted key-exchanges would be compromised but not with ECC or DHE). $\endgroup$ – kub0x Nov 24 '16 at 4:56
  • $\begingroup$ @kub0x: Yes, I meant this Q has a better answer (yours, and for the reason you say) but I was too terse. Can't edit old comments though. $\endgroup$ – dave_thompson_085 Nov 24 '16 at 5:08
4
$\begingroup$

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

$\endgroup$
  • $\begingroup$ Nitpick: the ServerKX signature for ECDHE is on the two nonces PLUS ServerECDHParameters; see 4492 5.4, with for 1.2 the modifications in 5246 A.7 and 7.4.3. $\endgroup$ – dave_thompson_085 Nov 24 '16 at 4:33
  • $\begingroup$ Yes as stated in RFC 4492 5.4 digital signature over ECDHE params is calculated by first computing the hash: ServerKeyExchange.signed_params.sha_hash SHA(ClientHello.random + ServerHello.random + ServerKeyExchange.params); then sign it with the private key. I just didn't want to give too much technical details in order to not confuse the user. BTW I will add that info to the answer. $\endgroup$ – kub0x Nov 24 '16 at 4:44
  • $\begingroup$ @dave_thompson_085: The following line solved my confusion. "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". Thank You. $\endgroup$ – Chetan Gowda Nov 24 '16 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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