SSL Principle

SSL/TLS is an optional protocol between application layer (HTTP protocol) and transport layer (TCP protocol) with an architecture as follows:

If SSL/TLS is not used in HTTP communication, all the messages will be transmitted in clear text, which will resulting in the following risks:

• Eavesdropping: The communication content is obtained by the third party
• Tampering: The communication content is changed by the third party
• Pretending: The third party takes part in the communication by use of someone else's identity

SSL/TLS protocol is developed to deal with these risks. The protocol is designed to:

• Transmit all the messages in an encrypted way to prevent the third party from eavesdropping.
• Support verification mechanism that allows the two sides to immediately discover the fact that the communication content has been tempered with.
• Avoid identity theft by providing ID certificate.

Currently, SSL/TLS is supported by most mainstream browsers.

How does SSL/TLS Protocol work

SSL/TLS protocol works based on the encryption with public key. Client sends a request for a public key to the server, then uses the public key to encrypt the message and sends it to the server; after receiving the encrypted message, the server decrypts it with its private key.

There are two issues to deal with:

• How to prevent the public key from being tempered with?
  Solution: Put the public key into a digital certificate. As long as the certificate is credible, the public key is credible.
• How to reduce the time consumed in the heavy computing for public key encryption?
  Solution: In each session, both client and server will generate a "session key" for encryption. The "session key" uses symmetrical encryption and operates very fast. The server's public key is only used to encrypt the "session key". In this way, the time consumed in the encryption operation can be shortened.

SSL/TLS protocol works as follows:

• Client sends a request for public key to the server and verifies the public key
• The two sides generates a"session key" through negotiation
• The two sides achieves encrypted communication with the "session key".

The first two steps in the above procedure are known as "handshake".

Work Flow of Handshake

"Handshake" involves four communications, with all the messages transmitted in clear text.

Request from Client (ClientHello)

The client (usually a browser) sends a request for encrypted communication to the server. The request is commonly known as ClientHello.

In this step, the client mainly provides the following information to the server.

• Supported protocol version, e.g. TLS 1.0
• A random number generated by the client, which will be used to generate "session key" later.
• Supported encryption method, e.g. RSA public key encryption
• Supported compression method

Please note that the message sent from the client does not contain server's domain. That is to say, the server can only have one website in theory, otherwise it can be confused about which website's digital certificate should be provided for the client. This is why a server can only have one digital certificate.

However, this is inconvenient for the users of virtual host. In 2006, TLS protocol was supplemented with a Server Name Indication Extension to allow the client to provide the server with the domain name it requests.

Response from Server (SeverHello)

After receiving the request from the client, the server sends a response to the client, which is commonly known as "SeverHello". The response includes the following information:

• The encrypted communication protocol version to be used, such as TLS 1.0. If the version supported by the browser is different from that by the server, the server will disable the encrypted communication
• A random number generated by the server, which will be used to generate "session key" later
• The encryption method to be used, e.g. RSA public key encryption
• Server certificate

In addition to the above information, the server may send another request for the "server certificate" to the client if the sever needs to verify the client's identity. For example, a financial institution only permits the verified customers to connect to their network, so they will provide a USB key containing a client certificate to the regular customers.

Response from Client

After receiving the response from the server, the client will verify the server certificate first. If the certificate is not issued from a trusted certificate authority (CA), the domain name in the certificate is different from the actual domain name, or the certificate is expired, the visitor will receive a warning message that allows the visitor to select whether to continue the communication.
If no problem is found with the certificate, the client will get the public key from the certificate and send the following information to the server:

• A random number that will be encrypted with the server public key to avoid being eavesdropped.
• Encoding change notification that indicates that the messages transmitted since now will be sent using the encryption method and the key agreed by both sides.
• Client handshake termination notification that indicates that handshake stage on client has ended. This is also the hash value for all the content sent in the previous steps and is used by the server for verification.

The random number here is the third random number during the handshake stage, which is also called "pre-master key". With this number, both client and server have three random numbers, and then each of them will use the agreed encryption method to generate the same "session key" used in this session.

For the RSA key exchange algorithm, pre-master-key itself is a random number, which together with the random numbers in hello messages will be exported as a symmetric key by a key exporter.

The reason why pre-master exists is that SSL protocol doesn't consider that each host can generate a totally random number. The key generated from the three random numbers (the ones generated from client and server, plus pre-master) is unlikely to be cracked. A pseudo-random number may not be totally random, but three ones are nearly random.

In addition, if the server requests for the client certificate in the previous step, the client will send the certificate and relevant information in this step.

Final Response from Server

After receiving the third random number "pre-master-key" from the client, the server will generate the "session key" used in this session, and then send the following information to the client:

• Encoding change notification that indicates that the messages transmitted since now will be sent using the encryption method and the key agreed by both sides.
• Server handshake termination notification that indicates that handshake stage on server has ended. This is also the hash value for all the content sent in the previous steps and is used by the client for verification.

Now, the handshake stage ends completely. Next, the client and server start the encrypted communication by using HTTP protocol, with the communication content encrypted with the "session key".

A simple example can be given here to illustrate this. If A (SSL client) communicates with B (SSL server), the encrypted messages will be enclosed in [] to highlight the difference between these messages and the messages in clear text. The description of the actions performed by both sides will be enclosed in parenthesis "()".

• A:

"I want to communicate with you securely. I have the symmetric encryption algorithms DES and RC5, key exchange algorithms RSA and DH, and digest algorithms MD5 and SHA."

• B:

"Let's use the combination of DES, RSA and SHA. This is my certificate with my name and public key. You can use it to verify my identity."

Send the certificate to A.

"That is all."

• A:

Check whether B's name is correct in the certificate, and verify the authenticity of B's certificate with an available CA certificate. If one of them is wrong, A will send a warning and disconnect with B. This step can ensure the authenticity of B's public key.

Generate a secret message, which will be used as an encrypted key after being processed to encrypt initialization vector (IV) and the key for hmac. Encrypt this secret message (called per_master_secret in protocol) with B's public key, and encapsulate it into a message called ClientKeyExchange. The use of B's public key can prevent the third party from eavesdropping.

"I have generated a secrete message and encrypted it with your public key. Here it is." Send ClientKeyExchange to B. "Please note that I will send messages to you in an encrypted way!"

Process the secret message, generate an encryption key, and encrypt IV and the key for hmac.

[Over.]

• B:

Use its own key to decrypt the secret message in ClientKeyExchange, and then process this message, generate an encryption key, and encrypt VI and the key for hmac. Now, the two sides have agreed on a set of encryption methods securely.

"Please note that I will also send messages to you in an encrypted way!"

[Over.]

• A:

[My secret is...]

• B:

 [Others will never know this secret...]