How SSL Handshake Works

* An SSL session always begins with an exchange of messages called the SSL handshake.
    
* Here is summary of the steps involved in the SSL handshake. 

1. The client sends the server the client's SSL version number, cipher settings, randomly generated data, 
and other information the server needs to communicate with
 the client using SSL.

2. The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL.

 The server also sends its own digital certificate and, if the client is requesting a server resource that requires client authentication, requests the client's digital certificate.

3. The client uses the information sent by the server to authenticate the server.If the server cannot be authenticated, the user is warned of the problem that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds.

4. Using all data generated in the handshake so far, the client creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's digital certificate), and sends the encrypted pre-master secret to the server.

5. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and the client's own digital certificate to the server along with the encrypted pre-master secret.

6. If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session is terminated. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, then performs a series of steps which the client also performs, starting from the same pre-master secret to generate the master secret. 

7. Both the client and the server use the master secret to generate session keys which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.

8. The client informs the server that future messages from the client will be encrypted with the session key. It then sends a separate encrypted message indicating that the client portion of the handshake is finished.

9. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate encrypted message indicating that the server portion of the handshake is finished.

10. The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

SSL Alert Protocol

* The SSL Alert Protocol signals problems with an SSL session.

* Alert messages convey the severity of the message and a description of the alert.

* Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. 

* The client and the server must communicate that the connection is ending to avoid a truncation attack. 

* Either party may initiate the exchange of closing messages. 

* Normal termination occurs when the close_notify message is sent.

* This message notifies the recipient that the sender will not send any more messages on this connection. 

* The session becomes un-resumable if any connection is terminated without a proper close_notify message. 

The following error alerts are defined:-

 handshake_failure
 no_certificate
 bad_certificate
 certificate_expired
 unsupported_certificate
 certificate_unknown

Cipher-Spec-Protocol

* The change cipher spec message is sent by both the client and server to notify the receiving party that subsequent records will be protected under the just-negotiated CipherSpec and keys.


* It exists to update the cipher suite to be used in the connection. 

* It permits a change in the SSL session occur without having to renegotiate the connection.

* The message consists of a single byte of value 1. 

* There are two states for the change cipher spec message.
    * Read Current
    * Read Pending 

* The change cipher spec message is normally sent at the end of the SSL handshake.
   
@ A cipher suite is a set of cryptographic algorithms.

   * The SSL handshake protocol determines how the client and server negotiate which cipher suites they will use. 

@ The most commonly used cipher suites are:

    DES (Data Encryption Standard)
    DSA (Digital Signature Algorithm)
    KEA (Key Exchange Algorithm)
    MD5
    RC2
    RC4
    RSA
    SHA-1 (Secure Hash Algorithm)
    SKIPJACK
    Triple DES