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

Improve this question
$\endgroup$
3
  • $\begingroup$ Crosspost security.stackexchange.com/questions/143366/… (but better answered) $\endgroup$
    – dave_thompson_085
    Commented Nov 24, 2016 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
    Commented Nov 24, 2016 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
    Commented Nov 24, 2016 at 5:08

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$
3
  • $\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
    Commented Nov 24, 2016 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
    Commented Nov 24, 2016 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
    Commented Nov 24, 2016 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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