0

User Crover has given a very great explanation for this question: RSA or ECDHE for x.509 certificates-what does each do? I have one question to Crover and/or any other member.

What I understand from the Crover's answer, if client (a Web Browser for example) and the Web server agree on ECDHE_RSA, they will come up with the the ephemeral session keys for each side of the channel without sharing the session key with each other, then what the server's public key in the certificate is used for?

Probably just to validate that the cert belongs to who that claim it to be. For that, the client/browser has to send some data encrypted with the server's public key and client has to receive a valid answer. Server would not send the answer encrypted with the long term private key as MITM can hack that key for replay attack.

Much appreciated, and Thanks.

Imran S
  • 1
  • 1

2 Answers2

0

The public key in the certificate is used together with the matching private key (owned by the server) to authenticate the server.

This is done by the server signing some information inside the handshake with the private key, so that the client can verify that the server is in possession of the private key matching the public key of the certificate. Once this certificate ownership is verified the client can make sure that the information contained in the certificate matches the client expectations, i.e. issued by a trusted CA, not expired, issued for the URL used by the client etc. This way the expected identity of the server is verified and active MITM attacks can be detected.

For that, the client/browser has to send some data encrypted with the server's public key and client has to receive a valid answer. Server would not send the answer encrypted with the long term private key as MITM can hack that key for replay attack.

What you describe is kind of (but not exactly) RSA key exchange, which was used to both exchange the key and to make sure that the server has the private key matching the certificate. This type of key exchange is no longer available in TLS 1.3 and is should also no longer be used for earlier versions of TLS since it provides no forward secrecy.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
0

The ECDHE parameters from the server must be signed with the server's public key. Otherwise, an active man-in-the-middle attacker could simply replace those parameters with their own, so that they will know the resulting shared secret. In TLS 1.3, the server calculates the signature over the entire handshake which includes the ECDHE parameters. This also proves that the server possesses the private key which corresponds to the certificate. In TLS 1.2, the server individually signed the parameters in the ServerKeyExchange message.

In any case, a Diffie-Hellman or Elliptic-Curve Diffie–Hellman key exchange onla makes sense if the parameters are authenticated in some way. If they weren't, the client would have no idea whom they're even doing the key exchange with.

Ja1024
  • 5,769
  • 14
  • 21