THE SSL PROTOCOL

　　Recall that the MASTER-KEY is given to the server in the CLIENT-MASTER-KEY message. The CHALLENGE is given to the server by the client in the CLIENT-HELLO message. The CONNECTION-ID is given to the client by the server in the SERVER-HELLO message. This makes the resulting cipher keys a function of the original session and the current session. Note that the master key is never directly used to encrypt data, and therefore cannot be easily discovered.

　　The CLIENT-MASTER-KEY message must be sent after the CLIENT-HELLO message and before the CLIENT-FINISHED message. The CLIENT-MASTER-KEY message must be sent if the SERVER-HELLO message contains a SESSION-ID-HIT value of 0.

　　CLIENT-CERTIFICATE (Phase 2; Sent encrypted)
　　char MSG-CLIENT-CERTIFICATE
　　char CERTIFICATE-TYPE
　　char CERTIFICATE-LENGTH-MSB
　　char CERTIFICATE-LENGTH-LSB
　　char RESPONSE-LENGTH-MSB
　　char RESPONSE-LENGTH-LSB
　　char CERTIFICATE-DATA[MSB<<8|LSB]
　　char RESPONSE-DATA[MSB<<8|LSB]

　　This message is sent by one an SSL client in response to a server REQUEST-CERTIFICATE message. The CERTIFICATE-DATA contains data defined by the CERTIFICATE-TYPE value. An ERROR message is sent with error code NO-CERTIFICATE-ERROR when this request cannot be answered properly (e.g. the receiver of the message has no registered certificate).
CERTIFICATE-TYPE is one of:

　　SSL_X509_CERTIFICATE
The CERTIFICATE-DATA contains an X.509 (1988) [3] signed certificate.

　　The RESPONSE-DATA contains the authentication response data. This data is a function of the AUTHENTICATION-TYPE value sent by the server.
When AUTHENTICATION-TYPE is SSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE-DATA contains a digital signature of the following components (in the order shown):

　　the KEY-MATERIAL-0
　　the KEY-MATERIAL-1 (only if defined by the cipher kind)
　　the KEY-MATERIAL-2 (only if defined by the cipher kind)
　　the CERTIFICATE-CHALLENGE-DATA (from the REQUEST-CERTIFICATE message)
　　the server's signed certificate (from the SERVER-HELLO message)

　　The digital signature is constructed using MD5 and then encrypted using the clients private key, 　formatted according to PKCS#1's digital signature standard [5]. The server authenticates the client by verifying the digital signature using standard techniques. Note that other digest functions are supported. Either a new AUTHENTICATION-TYPE can be added, or the algorithm-id in the digital signature can be changed.

　　This message must be sent by the client only in response to a REQUEST-CERTIFICATE message.

　
　　CLIENT-FINISHED (Phase 2; Sent encrypted)
　　char MSG-CLIENT-FINISHED
　　char CONNECTION-ID[N-1]

　　The client sends this message when it is satisfied with the server. Note that the client must continue to listen for server messages until it receives a SERVER-FINISHED message. The CONNECTION-ID data is the original connection-identifier the server sent with its SERVER-HELLO message, encrypted using the agreed upon session key.

　　"N" is the number of bytes in the message that was sent, so "N-1" is the number of bytes in the message without the message header byte.

　　For version 2 of the protocol, the client must send this message after it has received the SERVER-HELLO message. If the SERVER-HELLO message SESSION-ID-HIT flag is non-zero then the CLIENT-FINISHED message is sent immediately, otherwise the CLIENT-FINISHED message is sent after the CLIENT-MASTER-KEY message.

2.6 Server Only Protocol Messages

　　There are several messages that are only generated by servers. The messages are never generated by correctly functioning clients.

　　SERVER-HELLO (Phase 1; Sent in the clear)
　　char MSG-SERVER-HELLO
　　char SESSION-ID-HIT
　　char CERTIFICATE-TYPE
　　char SERVER-VERSION-MSB
　　char SERVER-VERSION-LSB
　　char CERTIFICATE-LENGTH-MSB
　　char CERTIFICATE-LENGTH-LSB
　　char CIPHER-SPECS-LENGTH-MSB
　　char CIPHER-SPECS-LENGTH-LSB
　　char CONNECTION-ID-LENGTH-MSB
　　char CONNECTION-ID-LENGTH-LSB
　　char CERTIFICATE-DATA[MSB<<8|LSB]
　　char CIPHER-SPECS-DATA[MSB<<8|LSB]
　　char CONNECTION-ID-DATA[MSB<<8|LSB]

　　The server sends this message after receiving the clients CLIENT-HELLO message. The server returns the SESSION-ID-HIT flag indicating whether or not the received session-identifier is known by the server (i.e. in the server's session-identifier cache). The SESSION-ID-HIT flag will be non-zero if the client sent the server a session-identifier (in the CLIENT-HELLO message with SESSION-ID-LENGTH != 0) and the server found the client's session-identifier in its cache. If the SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE, CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will be zero.

　　 The CERTIFICATE-TYPE value, when non-zero, has one of the values described above (see the information on the CLIENT-CERTIFICATE message).

　　When the SESSION-ID-HIT flag is zero, the server packages up its certificate, its cipher specs and a connection-id to send to the client. Using this information the client can generate a session key and return it to the server with the CLIENT-MASTER-KEY message.

　　When the SESSION-ID-HIT flag is non-zero, both the server and the client compute a new pair of session keys for the current session derived from the MASTER-KEY that was exchanged when the SESSION-ID was created. The SERVER-READ-KEY and SERVER-WRITE-KEY are derived from the original MASTER-KEY keys in the same manner as the CLIENT-READ-KEY and CLIENT-WRITE-KEY:

　　SERVER-READ-KEY = CLIENT-WRITE-KEY
　　SERVER-WRITE-KEY = CLIENT-READ-KEY

　　Note that when keys are being derived and the SESSION-ID-HIT flag is set and the server discovers the client's session-identifier in the servers cache, then the KEY-ARG-DATA is used from the time when the SESSION-ID was established. This is because the client does not send new KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only in the CLIENT-MASTER-KEY message).

　　The CONNECTION-ID-DATA is a string of randomly generated bytes used by the server and client at various points in the protocol. The CLIENT-FINISHED message contains an encrypted version of the CONNECTION-ID-DATA. The length of the CONNECTION-ID must be between 16 and than 32 bytes, inclusive.

　　The CIPHER-SPECS-DATA define a cipher type and key length (in bits) that the receiving end supports. Each SESSION-CIPHER-SPEC is 3 bytes long and looks like this:

　　char CIPHER-KIND-0
　　char CIPHER-KIND-1
　　char CIPHER-KIND-2

　　Where CIPHER-KIND is one of:

　　SSL_CK_RC4_128_WITH_MD5
　　SSL_CK_RC4_128_EXPORT40_WITH_MD5
　　SSL_CK_RC2_128_CBC_WITH_MD5
　　SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
　　SSL_CK_IDEA_128_CBC_WITH_MD5
　　SSL_CK_DES_64_CBC_WITH_MD5
　　SSL_CK_DES_192_EDE3_CBC_WITH_MD5

　　This list is not exhaustive and may be changed in the future.

　　The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4 cipher where some of the session key is sent in the clear and the rest is sent encrypted (exactly 40 bits of it). MD5 is used as the hash function for production of MAC's and session key's. This cipher type is provided to support "export" versions (i.e. versions of the protocol that can be distributed outside of the United States) of the client or server.

　　An exportable implementation of the SSL Handshake Protocol will have secret key lengths restricted to 40 bits. For non-export implementations key lengths can be more generous (we recommend at least 128 bits). It is permissible for the client and server to have a non-intersecting set of stream ciphers. This, simply put, means they cannot communicate.

　　Version 2 of the SSL Handshake Protocol defines the SSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. The SSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of 128 bits. However, only 40 of the bits are secret (the other 88 bits are sent in the clear by the client to the server).

　　The SERVER-HELLO message is sent after the server receives the CLIENT-HELLO message, and before the server sends the SERVER-VERIFY message.

　　SERVER-VERIFY (Phase 1; Sent encrypted)
　　char MSG-SERVER-VERIFY
　　char CHALLENGE-DATA[N-1]

　　The server sends this message after a pair of session keys (SERVER-READ-KEY and SERVER-WRITE-KEY) have been agreed upon either by a session-identifier or by explicit specification with the CLIENT-MASTER-KEY message. The message contains an encrypted copy of the CHALLENGE-DATA sent by the client in the CLIENT-HELLO message.

　　"N" is the number of bytes in the message that was sent, so "N-1" is the number of bytes in the CHALLENGE-DATA without the message header byte.

　　This message is used to verify the server as follows. A legitimate server will have the private key that corresponds to the public key contained in the server certificate that was transmitted in the SERVER-HELLO message. Accordingly, the legitimate server will be able to extract and reconstruct the pair of session keys (SERVER-READ-KEY and SERVER-WRITE-KEY). Finally, only a server that has done the extraction and decryption properly can correctly encrypt the CHALLENGE-DATA. This, in essence, "proves" that the server has the private key that goes with the public key in the server's certificate.

　　The CHALLENGE-DATA must be the exact same length as originally sent by the client in the CLIENT-HELLO message. Its value must match exactly the value sent in the clear by the client in the CLIENT-HELLO message. The client must decrypt this message and compare the value received with the value sent, and only if the values are identical is the server to be "trusted". If the lengths do not match or the value doesn't match then the connection is to be closed by the client.

　　This message must be sent by the server to the client after either detecting a session-identifier hit (and replying with a SERVER-HELLO message with SESSION-ID-HIT not equal to zero) or when the server receives the CLIENT-MASTER-KEY message. This message must be sent before any Phase 2 messages or a SEVER-FINISHED message.

　　SERVER-FINISHED (Phase 2; Sent encrypted)
　　char MSG-SERVER-FINISHED
　　char SESSION-ID-DATA[N-1]