According to this source about TLS, there are 3 stages (I'm over simplifying):

  1. Set up. Server client hello and select TLS version + Cipher
  2. Server Sends. The server sends Certificate = Public Key + Signature

(SSH connection requires the same kind of arrangement, the server holds a private key, and the client a public key. Not sure if this comparison is correct.)

  1. Client Sends. The client generates a master key also called Session Key, send back the server

Why does this last step occur?

My poor model tells me: the information travels, was encrypted using the cipher, and the "safe" can also be opened private key or public key.

So, again, why a master key?

  • 1
    "... the information travels, was encrypted using the encryption key, ... " - where does this encryption key comes from? You don't mention it earlier. In fact, the keys for encryption of application data are derived from the master key. Apart from that SSH is not the same as SSL/TLS. Commented Dec 10, 2020 at 5:14
  • server sends public key to client. server has private key. why need of anything else? @SteffenUllrich. Also, as a basic level, isn't a similar thing SSH? uses a key on each side & probably tcp protocol to send data through
    – Minsky
    Commented Dec 10, 2020 at 5:25
  • 4
    @Minsky Public-key encryption is not suitable for direct use on bulk data. Almost everything that uses public-key encryption actually does hybrid encryption, where the public & private keys are used to protect the exchange of a shared secret key, which is then used with a symmetric encryption algorithm for the actual data. There are often additional layers/complications, and TLS is no exception: generally Diffie-Hellman key exchange (the exchange signed with the server's private key) is used to agree on a master key, which is then used to derive the actual encryption keys. Commented Dec 10, 2020 at 6:10
  • 1
    @Minsky Key and Cipher are two very different things.
    – user163495
    Commented Dec 10, 2020 at 10:15
  • 1
    You're reading some explanation that appears to describe the deprecated RSA key exchange which was not allowed for HTTP/2 in 2015 and is not present in TLS1.3 (2018). We've known for a while that it is a bad idea because it does not provide forward secrecy. Though in the RSA key exchange, the server does not send signature. When the server does send signature, a Diffie Hellman key exchange is used. These days ECDHE. Read on that. Also read the existing answers for how TLS works.
    – Z.T.
    Commented Dec 10, 2020 at 11:55

1 Answer 1


Because asymmetric cryptography is slow.

Asymmetric encryption and decryption has some wonderful properties, but speed is not one of them. In fact, asymmetric cryptography is among the slowest encryption and decryption algorithms there are.

As such, if you wanted to download a very large file, then the process of encrypting that file on the server and decrypting it on the client would take very long. Magnitudes longer than it does now.

On the other hand, symmetric cryptography is very fast. AES-128-CBC can be as fast as 600 MB/s for encryption and 2300 MB/s for decryption. The problem with symmetric ciphers is that you need to distribute the keys somehow.

As such, by combining symmetric and asymmetric cryptography, we can share the key (which is rather small by comparison, just 16 or 32 bytes) using asymmetric cryptography, and then encrypt the actual data using fast, symmetric cryptography.

Because you want forward secrecy.

Wikipedia defines Forward Secrecy as follows:

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.

What that means is, imagine an attacker captures HTTPS traffic between you and a server, and it's all simply encrypted by RSA - no master key, no symmetric ciphers. This alone doesn't compromise anything, but an attacker can keep the captured data and wait. Later, the private key of the server is leaked or otherwise compromised, and suddenly your communication with the server from back then can be decrypted.

On the other hand, if a cipher with Forward Secrecy is used, then the master key is generated for this session alone. Compromise of the long-term secret - in this case, the private key of the server - does not lead to compromise for the previously captured message.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .