I will explain whatever I understand about SSL handshake or simply SSL.

  1. First client sends hello to server
  2. Server sends signed certificate with its public key.
  3. Client checks if certificate is valid, if it looks valid it generates its own private key, encrypts with server's public key and send back to server.

After this I don't understand-:

the server unlooks the data with it’s own private key, gets the client private key.

the server uses the client’s private key to unlook the data part of the packets send by the client.


I don't understand once client sends encrypted private key and server's public key to server. And I don't understand holistic view of how this secures TCP connection.

  • 2
    $\begingroup$ I suggest you type the code instead of adding a picture of your physical notebook $\endgroup$
    – lox
    Nov 30, 2021 at 14:04
  • $\begingroup$ It is not a code. It is handshaking diagram as shown in tanenbaum's book. I don't have the physical copy now. $\endgroup$
    – jacnab
    Nov 30, 2021 at 14:50
  • $\begingroup$ Don't use images for math or text. This makes your question impossible to search and inaccessible to the visually impaired; we don't like that. Please transcribe text and mathematics. You can use LaTeX. $\endgroup$
    – D.W.
    Dec 3, 2021 at 20:52

2 Answers 2


I don't know how it works because I've never implemented the algorithm myself. Basically, the algorithm is RSA from the NIST agency in the US (FIPS 186). From https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-175b.pdf, you can read:

The RSA algorithm is approved for the generation and verification of digital signatures in FIPS 186] and specified in PKCS 1 35 and ANS X9.31 36. FIPS 186 includes restrictions on the use of RSA to generate digital signatures, methods to generate RSA key pairs, and defines the key lengths to be used for secure interoperability.

In RSA, two keys are created. One that is private (which allows to decrypt the data) and one that is public (which allows to encrypt the data). This is known as asymmetric encryption.

The public key is sent to the client of the server. The client generates a symmetric key that is encrypted with the public key and sent back to the server. The server can thus decrypt the message with its private counterpart and then use symmetric encryption afterwards which is faster.

Meanwhile, authentication is another thing. In authentication, there is a root certificate in the web browser that is provided by the certificate authority (like Let's Encrypt, GoDaddy and others). These certificate authorities derive other keys (public keys) from that certificate and this allows to verify the authenticity of the public keys of the clients of that certain certificate authority.

For example, if I'm a client of Let's Encrypt and get a certificate from them. I derive my public key from the certificate they give me. Then, when I send this key, the web browser verifies that it's a genuine key by verifying it against the root certificate stored somewhere on your filesystem.

This allows to ensure that you get a strong warning message if you are attacked on your network with attacks such as man-in-the-middle using ARP spoofing (which is common and practical). For example, if you go on your bank account and get this warning message then don't go further and verify your network.


that article is not technically correct.

(1) TLS handshake itself does not make your connection secure, what makes it secure is what happens after the handshake. Handshake is needed to negotiate parameters, necessary to establish secure communication.

(2) After connection establishment, TLS essentially does two things: encrypts the data [confidentiality] and computes message authentication code (which is secure version of hash function), which is used to detect tampering with data [integrity] (note, contrary to what the article you link said, in Internet you cannot prevent anybody from changing your packets on the way. Integrity allows you to detect if packet was tampered with, and act accordingly). So, to answer your question, connection becomes secure because the content of the packet is encrypted and can only be decrypted by the other communication partner. The other partner can also verify that the packet was not tampered with on the way.

(3) Both encryption and message authentication codes (MAC) requires that client and server know corresponding keys (encryption key and key used to compute the MAC).

(4) There are basically two kinds of encryption schemes: symmetric encryption schemes and assymetric (or public key) encryption. Symmetric encryption requires the same key to both encrypt and decrypt the message, and this key needs to be known to both communication parties. This is usually referred to just key. Assymetic encryption uses two keys: public key to encrypt and secret key or private key to decrypt. Public keys are, well, public, in that you can just publish it. This way everybody can send you an encrypted message and be sure (well, in cryptographic terms) that you will be the only person who can decrypt and read it.

In order for two parties to communicate encrypted messages they can either communicate with symmetric cryptography, while somehow exchanging the key beforehand or with assymetric cryptography, where each party publishes its public key and the other party uses this key to encrypt the message to the other party.

The issue is that the existing algorithms for public key crypto are couple orders of magnitude slower than for symmetric crypto. This is why the common solution is to use public cryptography to exchange the symmetric keys and then use symmetric encryption for the actual payload. Exchanging symmetric keys is what handshake is accomplishing.

Note however: I believe that the prase "cliend generates private key" actually means that the client generates a symmetric key and sends it to the server. If you are talking about public key crypto, private keys are NEVER sent anywhere. Also, this is also technically incorrect. Due to some specific attacks on the handshake, and other properties, the secret key is generated from data generated by both the client and the server in a quite complicated procedure. The main point is that as a result of TLS handshake, both the client and the server can compute secret keys used to encrypt and integrity-check payload later.

(5) as explained in the other answer certificates are used for a different thing, called authentication. The idea is that the server gets an equivalent of a notary to sign him a ID, so that when the client connects to the server it can be sure that it indeed talks to the right server (its a network, there are ways somewhone can reroute client's packets not to the server, the cliend is intended to connect to). Well, how secure this is is a long story, so its a good idea to check the certificate before you insert your credit card data.

(6) P.S. there are also two ways to accertain message integrity: digital signatures which are public key schemes and message authentication codes, which are symmetric schemes. Digital signatures are basically inverse of the encryption, one signs with their private key, and everyone else can verify the signature with the public key, and be sure that the person who knows private key was the one who signed the message, and also that the message is not tampered with. Message authentication codes use symmetric key, so you can be sure that the other person who computed the code, also knows the key. Assuming that only your communication partner and you know the key, you can be sure that the code was created by your communication partner and thus the message was not tampered with by someone else. TLS use symmetric codes, and the key is computed based on data, exchanged during handshake. Digital signatures are used in certificates.


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.