SSL hand shake

Posted on 2009-12-21
Last Modified: 2012-08-14
1)When a gmail user opens gmail dot com in his web browser, the user is directed to https.
2)now the ssl hand shake goes through process-
      first the gmail client says hello
      gmail server says hello
      gmail server sends the public key certificate
      gmail server hello done
      client key exchange
      client change cipher spec
      client encrypted handshake message
      server change cipher spec
      server encrypted handshake message

now the client uses the public key to encrypt the message it sends to gmail server and gmail
server uses his private key to decrypt the message.
My question is, which key gmail server is going to use to encrypt the message( his private or public key)
and can any one explain the things happening in each of those 9 process.
Question by:sanfran83
    LVL 31

    Expert Comment

    The answer to the primary question is: neither.  The negotiated synchronous key will be used on both ends - the public/private key is not used past the process you just laid out.
    LVL 31

    Expert Comment

    I will post the breakdown of communications in the morning - if anyone else wants to jump on that feel free.
    LVL 7

    Expert Comment

    >>> My question is, which key gmail server is going to use to encrypt the message( his private or public key) and can any one explain the things happening in each of those 9 process?
    The initial encryption/decryption takes place using  Public / Private Keys, using which a symetric key is later exchanged and latter used for encrypting and exchanging the payload. Remember in case of pub keys crypto, always the pub key is used for encrypting and the private keys are used for decrypting.

    How how SSL works with https refer to the following link:

    SSL Handshake:

    Hope this helps!
    LVL 7

    Assisted Solution

    >>> now the client uses the public key to encrypt the message it sends to gmail server and gmail
    server uses his private key to decrypt the message.
    SSL uses Pub and Priv keys for init exchange a client / server random. Later the client generate a pre-master secret and sends it the server. Now both client and server know client / server random + pre-master secret which is used to generate a master secret - which is actually becomes the shared symetric key between the client and the server. Later on the handshake is completed with establishing the master secret with the client and server which is actually used to encrypt and decrypt the payload.

    Hope this helps
    LVL 31

    Accepted Solution

    Here's a few other links:
    MS description of SSL handshake:

    Troubleshooting SSL:

    The SSL v3 specification - see section 5.6:

          first the gmail client says hello
          gmail server says hello
    - Hopefully these 2 are self explanatory as SYN & ACK, if you need these broken down more let me know.  They start the general network session anyways - nothing encrypted yet.  this may be resent later to renogiate another session (e.g. to prevent session expiration) but can be done at any time.

    *      gmail server sends the public key certificate
    - Server sends his cert with the public key so the client can use it to encrypt back.  

    *      gmail server hello done
    - server passes the microphone to the client to talk and goes into listen mode.  

    (if there was a client certificate, that would be passed here between these steps)

    *      client key exchange
    - The client checks the digital signatures and revocation lists to make sure it is trustworthy.
    - Client starts chatting.
    - Opening statement for the next step in the process.
    - A pre-master token is established from the server's public key and is used for negotiation.

    *      client change cipher spec
    - The client uses the server's public key to encrypt what synchronous key (e.g. RC-4, 3DES, AES, etc.) it supports to use for the main session, as well as the strength.  Typically the strongest algorithm will be used by default (except Windows picks AES-128 before AES-256 for some reason), but the order can be changed (sent in order of preference, which is usually the strongest first).
    - If the server supports that then they will both be happy, otherwise they keep handshaking - if you remember modems handshaking for connection speed - its like that only choosing cipher methodologies and strengths supported.  Start at the top and move down the list if no match, if no match by the end then no connection.

    *      client encrypted handshake message
    - A message is sent to establish the session encryption key and is encrypted with server's public key.  If accepted, it will later become the new session encryption method (synchronous key).

    *      server change cipher spec
    - this would be if the server did not support the client's suggested algorithm.  For example, client requests AES but server only supports up to 3DES.  Server sends best algorithm back to client as next step in handshake.  Further client and server change cipher specs may follow until agreement is reached or both lists are exhausted.
    - server's private key is used to decrypt the message of suggested protocols

    *      server encrypted handshake message
    server accepts encrypted session key from client, decypts using server's private key, and establishes the encrypted session ID which it will relate to the client.  Since they both have the secret key and they can transfer this securely now, reducing the likelihood of an eavesdropper catching the new session and understanding the communications.  Now that they agree, the pre-master token is dropped and the new master token is used

    - The certificate is now out of the picture.
    - Finish is sent to complete the handshake.
    LVL 31

    Expert Comment

    Quick terminology:
    Synchronous key/encryption - both sides use a preshared secret (a password) as the encryption and decryption method.  Examples include RC-4, DES, 3DES, AES and many more.  This is common for zip files, flash drives, etc. - you type a password to encrypt it and you type the same password to decrypt it.

    Asynchronous encryption/public-private keyset - PKI / certificate stuff.  A certificate represents the identity and is trusted by the client.  The certificate contains information about the server's public key, which the client will then use to encrypt.  The server is the only place where the private key should exist, and will be used to decrypt any encrypted message from the client.

    Synchoronous is much much faster than Asynch since the bit lengths are typically shorter they require less computation - this also results in smaller sizes of the ciphertext.  The security is in the secret key being secret.

    Asynch is slower and requires much more CPU to do the calculations.  Since half of the keyset is public, the key lengths are much larger to slow down potential attacks.  The private key is the secure part and remains private on that server.

    For SSL, email encryption, EFS, whatever - generically speaking the same type of process happens - you use the initially more secure asynch process to negotiate a common synch key and to pass the password, then everything is synch after that.

    Author Closing Comment


    Featured Post

    Free Trending Threat Insights Every Day

    Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

    Join & Write a Comment

    Ransomware continues to be a growing problem for both personal and business users alike and Antivirus companies are still struggling to find a reliable way to protect you from this dangerous threat.
    Healthcare organizations in the United States must adhere to the guidance of both the HIPAA (Health Insurance Portability and Accountability Act) and HITECH (Health Information Technology for Economic and Clinical Health Act) for securing and protec…
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…
    In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor ( If you're interested in additional methods for monitoring bandwidt…

    755 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    23 Experts available now in Live!

    Get 1:1 Help Now