0

Consider the following scenario:

  • client sends hello
  • server send a hello and its certificate
  • client generates a key and encrypts that with server's public key
  • server decrypts the key with its private key

So, they shared a key and can talk with each other.

What is the problem with this? Why does SSL require that the client and server both generate a random for the session?

schroeder
  • 125,553
  • 55
  • 289
  • 326
FIFO
  • 13
  • 3
  • How is your scenario different from TLS? – schroeder Sep 23 '20 at 10:18
  • @schroeder in TLS both client and server participate to generate session key. in this scenario just client generate the key, encrypt it with server's public key and send to server. actually server just take the key. – FIFO Sep 23 '20 at 10:20
  • You've just used the magic word: "session". – schroeder Sep 23 '20 at 10:22
  • Besides DHE or ECDHE being required for PFS, if the server does not contribute to generating the session key, a replay of the handshake by an attacker will result in exactly the same session key being generated by the server, and this is bad. The TLS RSA key exchange, which was removed in TLS 1.3 and was not allowed for HTTP/2 before that, used the server's random to ensure replay is impossible. – Z.T. Sep 23 '20 at 11:56

1 Answers1

1

You've just described RSA key exchange, which was used in the past. These days, (EC)DHE is much more commonly used. The main reason is that (EC)DHE has the added benefit of providing forward secrecy. This basically means that if the private key is compromised at some later date, it will not compromise the security of previous communications. This is not achievable with the RSA key exchange method you describe.

See this question for more details on the advantages and disadvantages of using DHE or RSA

nobody
  • 11,341
  • 2
  • 41
  • 60