6

About ciphers that use ECDHE as Key Exchange and RSA as Authentication:

How exactly this two algorithms work together, is ECDHE process encrypted by RSA public key? What are the DH parameters? Please explain this process as a whole, I'm in trouble to connected all parts of the authentication and key exchange process. Is ECDHE used only for PFS (forward secrecy), or there others benefits?

Johnny Willer
  • 409
  • 1
  • 4
  • 13
  • 4
    I would take a look at [How does SSL/TLS work?](http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work). I would also recommend [this question and answer on PFS](http://security.stackexchange.com/questions/65802/ecdsa-ciphers-and-forward-secrecy-question-about-key-exchange). If you have further questions, then you can edit this question with a more detailed response. – RoraΖ May 27 '15 at 14:28
  • @raz ok, I will look – Johnny Willer May 27 '15 at 14:29
  • In TLS1.2 (as of 2012) the signature algorithm constraint previously implied by the ciphersuite (and keyexchange) is removed and the server signature is instead constrained by the sigalgs extension; see rfc5246. And in TLS 1.3 (as of 2018, after this Q) keyexchange is removed from the ciphersuite and controlled separately, although the same _result_ (ECDHE signed by RSA) can still be obtained. – dave_thompson_085 Apr 18 '19 at 04:16

1 Answers1

6

Here's how it works in a nutshell:

1) The client connects to the server. The server advertises the SSL/TLS protocols that it supports, and sends its SSL certificate to the client. The certificate includes an RSA public key, and the certificate is (presumably) signed by a recognized CA that the client trusts.

2) The client verifies the certificate's CA signature, and (presumably) trusts that the certificate is valid. The client and the server agree to use ECDHE.

3) The client and the server generate a set of ephemeral ECDHE keys that are used to facilitate the secure session. The keys sent by the server to the client are signed by the server using the server's private key (which corresponds to the public key that was previously sent as part of the certificate in step 1 above). The client validates that the signature is valid using the server's public key received previously (which was previously determined to be trusted). Thus, the client can trust that the ephemeral keys that it received from the server were indeed sent from the server, and not from a man-in-the-middle attacker.

4) The client and the server proceed with secure session using the set of ephemeral keys. These keys are discarded by both the client and the server at the end of the session (and not reused) to facilitate perfect forward secrecy.

mti2935
  • 21,098
  • 2
  • 47
  • 66
  • "The keys sent by the server to the client are signed by the server using the server's private key", how the client validate this with server's public key? – Johnny Willer May 28 '15 at 12:22
  • 1
    See this question for a good explanation of how digital signature verification is done: http://security.stackexchange.com/questions/8034/how-digital-signature-verification-process-works – mti2935 May 28 '15 at 13:18
  • #1,2,4 are partly wrong (and correct in The Bear's answers linked on the Q) although the basic point that server's ephemeral ECDH key is signed by privatekey matching server's cert is correct. – dave_thompson_085 Apr 18 '19 at 04:18