Understanding SSL

21Jun08

Content for this post is taken from the book “SSL & TLS Essentials, Security the Web” written by Stephen Thomas. This post consists only the theoretical overview of the working mechanism of SSL. I will soon post another article explaining the implementations.

The Secure Sockets Layer protocol defines two different roles for the communicating parties. One system is always a client, while the other is a server. The distinction is very important, because SSL requires the two systems to behave very differently. The client is the system that initiates the secure communications; the server responds to the client’s request. In the most common use of SSL, secure Web browsing, the Web browser is the SSL client and the Web site is the SSL server. These same two roles apply to all applications that use SSL.

When SSL clients and servers communicate, they do so by exchanging SSL messages. Technically, SSL defines different levels of messages. Some of the SSL messages are Alert, ApplicationData, Certificate, CertificateRequest, CertificateVerify, ChangeCipherSpec, ClientHello, ClientKeyExchange, Finished, HelloRequest, ServerHello, ServerHelloDone, ServerKeyExchange.

Establishing Secure Communications
The most basic function that an SSL client and server can perform is establishing a channel for encrypted communication. Figure below shows the SSL message exchange this operation requires.

Description:
Step 1: Client sends ClientHello message proposing SSL options.
Step 2: Server responds with ServerHello message selecting the SSL options.
Step 3: Server sends its public key information in ServerKeyExchange message.
Step 4: Server concludes its part of the negotiation with ServerHelloDone message.
Step 5: Client sends session key information (encrypted with server’s public key) in ClientKeyExchange message.
Step 6: Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 7: Client sends Finished message to let the server check the newly activated options.
Step 8: Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 9: Server sends Finished message to let the client check the newly activated options.

Ending Secure Communications
Although as a practical matter it is rarely used, SSL does have a defined procedure for ending a secure communication between two parties. As the figure below shows, the two systems each send a special ClosureAlert to the other.

Authenticating the Server’s Identity
Although above section explained how SSL can establish encrypted communication between two parties, that may not really add that much security to the communication. With encryption alone neither party can really be sure of the other’s identity. The typical reason for using encryption in the first place is to keep information secret from some third party. But if that third party were able to successfully masquerade as the intended recipient of the information, then encryption would serve no purpose.

To avoid this type of attack, SSL includes mechanisms that allow each party to authenticate the identity of the other. In this section, lets look at how SSL enables a server to authenticate itself. Picture below shows the steps involved.

Description:
Step 1: Client sends ClientHello message proposing SSL options.
Step 2: Server responds with ServerHello message selecting the SSL options.
Step 3: Server sends its public key certificate in Certificate message.
Step 4: Server concludes its part of the negotiation with ServerHelloDone message.
Step 5: Client sends session key information (encrypted with server’s public key) in ClientKeyExchange message.
Step 6: Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 7: Client sends Finished message to let the server check the newly activated options.
Step 8: Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 9: Server sends Finished message to let the client check the newly activated options.

Separating Encryption from Authentication
The previous section explained how a server can send a Certificate message instead of a ServerKeyExchange message to authenticate itself. One consequence of this approach is that the same public key information used to verify the server’s identity is also used to encrypt key material in the client’s ClientKeyExchange message. This constraint is not always desirable; indeed, in some cases it is actually impossible to support.

Following figure shows the steps involved in separating server authentication from the encryption as applied by SSL. The figure highlights the three messages that are significant for separating encryption and server authentication. They are the Certificate, ServerKeyExchange and ClientKeyExchange messages.

Description:
Step 1: Client sends ClientHello message proposing SSL options.
Step 2: Server responds with ServerHello message selecting the SSL options.
Step 3: Server sends its public key certificate in Certificate message.
Step 4: Server sends the public key that the client should use to encrypt the symmetric key information in a ServerKeyExchange; this public key is signed with the public key in the server’s certificate.
Step 5: Server concludes its part of the negotiation with ServerHelloDone message.
Step 6: Client sends session key information (encrypted with server’s public key) in ClientKeyExchange message.
Step 7: Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 8: Client sends Finished message to let the server check the newly activated options.
Step 9: Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 10: Server sends Finished message to let the client check the newly activated options.

Authenticating the Client’s Identity

Since SSl includes mechanisms to authenticate a server’s identity, it is natural to expect that the protocol also defines a way to authenticate a client’s identity. Indeed, that is the case; the mechanism is very similar to that for server authentication. The whole process can be seen in the figure below, which highlights the important messages.

Description:
Step 1: Client sends ClientHello message proposing SSL options.
Step 2: Server responds with ServerHello message selecting the SSL options.
Step 3: Server sends its public key certificate in Certificate message.
Step 4: Server sends a CertificateRequest message to indicate that it wants to authenticate the client.
Step 5: Server concludes its part of the negotiation with ServerHelloDone message.
Step 6: Client sends its public key certificate in a Certificate message.
Step 7: Client sends session key information (encrypted with server’s public key) in ClientKeyExchange message.
Step 8: Client sends a CertificateVerify message, which signs information about the session using the client’s private key; the server uses the public key from the client’s certificate to verify the client’s identity.
Step 9: Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 10: Client sends Finished message to let the server check the newly activated options.
Step 11: Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send.
Step 12: Server sends Finished message to let the client check the newly activated options.

Filed under: E-Commerce, security   |  1 Comment
Tags: Authentication, Certificate, CertificateRequest, CertificateVerify, ChangeCipherSpec, Secure Communication, SSL, TLS