2. SSL Handshake Protocol Specification
2.1 SSL Handshake Protocol Flow
The SSL Handshake Protocol has two major phases. The first phase is used to establish private communications. The second phase is used for client authentication.
Phase 1
The first phase is the initial connection phase where both parties communicate their "hello" messages. The client initiates the conversation by sending the CLIENT-HELLO message. The server receives the CLIENT-HELLO message and processes it responding with the SERVER-HELLO message.
At this point both the client and server have enough information to know whether or not a new master key is needed. When a new master key is not needed, both the client and the server proceed immediately to phase 2.
When a new master key is needed, the SERVER-HELLO message will contain enough information for the client to generate it. This includes the server's signed certificate (more about that later), a list of bulk cipher specifications (see below), and a connection-id (a connection-id is a randomly generated value generated by the server that is used by the client and server during a single connection). The client generates the master key and responds with a CLIENT-MASTER-KEY message (or an ERROR message if the server information indicates that the client and server cannot agree on a bulk cipher).
It should be noted here that each SSL endpoint uses a pair of ciphers per connection (for a total of four ciphers). At each endpoint, one cipher is used for outgoing communications, and one is used for incoming communications. When the client or server generate a session key, they actually generate two keys, the SERVER-READ-KEY (also known as the CLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also known as the CLIENT-READ-KEY). The master key is used by the client and server to generate the various session keys (more about that later).
Finally, the server sends a SERVER-VERIFY message to the client after the master key has been determined. This final step authenticates the server, because only a server which has the appropriate public key can know the master key.
Phase 2
The second phase is the authentication phase. The server has already been authenticated by the client in the first phase, so this phase is primarily used to authenticate the client. In a typical scenario, the server will require something from the client and send a request. The client will answer in the positive if it has the needed information, or send an ERROR message if it does not. This protocol specification does not define the semantics of an ERROR response to a server request (e.g., an implementation can ignore the error, close the connection, etc. and still conform to this specification).
When a party is done authenticating the other party, it sends its finished message. For the client, the CLIENT-FINISHED message contains the encrypted form of the CONNECTION-ID for the server to verify. If the verification fails, the server sends an ERROR message.
Once a party has sent its finished message it must continue to listen to its peers messages until it too receives a finished message. Once a party has both sent a finished message and received its peers finished message, the SSL handshake protocol is done. At this point the application protocol begins to operate (Note: the application protocol continues to be layered on the SSL Record Protocol).
2.2 Typical Protocol Message Flow
The following sequences define several typical protocol message flows for the SSL Handshake Protocol. In these examples we have two principals in the conversation: the client and the server. We use a notation commonly found in the literature [10]. When something is enclosed in curly braces "{something}key" then the something has been encrypted using "key".
2.2.1 Assuming no session-identifier
client-hello C -> S: challenge, cipher_specs
server-hello S -> C: connection-id,server_certificate,cipher_specs
client-master-key C -> S: {master_key}server_public_key
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {new_session_id}server_write_key
2.2.2 Assuming a session-identifier was found by both client & server
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
server-finish S -> C: {session_id}server_write_key
2.2.3 Assuming a session-identifier was used and client authentication is used
client-hello C -> S: challenge, session_id, cipher_specs
server-hello S -> C: connection-id, session_id_hit
client-finish C -> S: {connection-id}client_write_key
server-verify S -> C: {challenge}server_write_key
request-certificate S -> C: {auth_type,challenge'}server_write_key
client-certificate C -> S: {cert_type,client_cert,
response_data}client_write_key
server-finish S -> C: {session_id}server_write_key
In this last exchange, the response_data is a function of the auth_type.
