How SSL(Secure Socket Layer) Works

• An SSL certificate is a file that binds a cryptographic key to a hostname (ex: google.com).

• Data sent using an SSL certificate is scrambled and can only be deciphered with a matching decryption key.

• An SSL certificate file contains two different keys; a private key, and a public key. (Called keys because they act like a key for a door) Public keys are used to encrypt files, like locking a digital door, and private keys let you decipher the encryption, like unlocking the same door.

• An “SSL handshake” authenticates the website and the web browser.  This is an exchange of data that lets the client (your browser) and a server establish trust to share information.

• SSL is a protocol that provides privacy and integrity between two communicating applications using TCP/IP. 

• The Hypertext Transfer Protocol (HTTP) for the World Wide Web uses SSL for secure communications.

• The data going back and forth between client and server is encrypted using a symmetric algorithm such as DES or RC4. 

• A public-key algorithm-usually RSA-is used for the exchange of the encryption keys and for digital signatures. 

• The algorithm uses the public key in the server's digital certificate. With the server's digital certificate, the client can also verify the server's identity. 

• Versions 1 and 2 of the SSL protocol provide only server authentication. Version 3 adds client authentication, using both client and server digital certificates. 

• SSL session always begins with an exchange of messages called the SSL handshake.

A simplified overview of how the SSL handshake is processed is shown in below diagram.

Explanation

1. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number.
2. The server responds with a server "hello" message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number.
   Note:
   The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite.
3. The server sends its digital certificate. (The server uses X.509 V3 digital certificates with SSL.)
   If the server uses SSL V3, and if the server application (for example, the Web server) requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.
4. The server sends a server "hello done" message and waits for a client response.
5. Upon receipt of the server "hello done" message, the client (the Web browser) verifies the validity of the server's digital certificate and checks that the server's "hello" parameters are acceptable.
   If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory.
6. The client sends a "client key exchange" message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code(MAC) keys, encrypted with the public key of the server.
   If the client sent a digital certificate to the server, the client sends a "digital certificate verify" message signed with the client's private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate.
   Note:
   An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails.
7. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then the client sends a "change cipher spec" message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the "finished" message) is the first message encrypted with this cipher method and keys.
8. The server responds with a "change cipher spec" and a "finished" message of its own.
9. The SSL handshake ends, and encrypted application data can be sent.
10. SSL Certificate has following:
1. CA Certificate
2. Domain certificate
3. Private key