1. The client sends "client hello" and a number of specifications in plain text, such as the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use.
  2. The server picks the TLS protocol version for further communication, responds with "server hello", decides on a ciphersuite from the list provided by the client, attaches its certificate and public key and sends the response back to the client. Optionally, the server can also send a request for the client’s certificate and parameters for other TLS extensions.
  3. Assuming both sides are able to negotiate a common version and cipher, and the client is happy with the certificate provided by the server.The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.
  4. The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.
  5. The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message.
  6. Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client.
  7. Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.

Reference