Abstract
 Session and Connections States
 The SSL Handshake Protocol
 Short Handshke Proccess
 The SSL Change Cipher Spec Protocol
 The SSL Alert Protocol
 The SSL Record Protocol
 

SSL is a layered protocol. It is located above a reliable transport layer, such as TCP, and below an application layer. However, SSL is not TCP\IP dependant and can run under other application protocols. It takes applications' data to be sent, fragments it into manageable blocks, compresses it (optionally), applies a Message Authentication Code ( MAC ) to the data, encrypts it and then transmits the result.
When data is received, the reverse process occurs: the data is decrypted, verified, decompressed, reassembled and then delivered to the application layer.
The SSL protocol consists of two major layers: SSL Handshake protocol and SSL Record protocol. In addition, there are two other elements: SSL Change Cipher Spec Protocol and SSL Alert Protocol. The Handshake and the latter two components are responsible for the management of SSL communication setup and security parameters.
The SSL Record Protocol is the lowest layer of the SSL protocol stack and all the other parts, including application data, operate on     top of it.
 
                    

                                                               The SSL Protocol Stack

 Back to Top

Session and Connections States:
SSL protocol has 2 important states: the SSL session state and the SSL connection state.
A session state is composed of the following parameters:
    · Session ID – An arbitrary byte for identifying the session state.
    · Peer certificate – A X509.v3 certificate of the peer.
    · Compression method – Definition of compression algorithm.
    · Cipher spec – Definition of cryptography and MAC algorithms to be used when application data is to be transmitted.
    · Master secret – A secret shared value between client and server.
    · Is resumable – Flag for indicating if the session can be used for other connections.
A connection state consists of:
    · Server and client random numbers
    · SERVER-MAC-WRITE-SECRET
    · CLIENT-MAC-WRITE-SECRET
    · SERVER-WRITE-KEY
    · CLIENT-WRITE-KEY
    · Initialization vectors
    · Sequence number
Every connection is associated with one session only, but one session may include several different connections. The connection state defines the MAC parameters, while the session state defines a set of cryptographic parameters, which can be used for various connections.
Each session has 4 states: a current operating states and pending operating states for both read and write. In the current state, the CipherSuite offers neither encryption nor authentication.
When the Handshake protocol is done the pending state becomes the current state. The SSL Change Cipher Spec Protocol described below does this transfer.
 

 Back to Top

The SSL Handshake Protocol
This protocol, also called the key-exchange protocol, is responsible for establishing a secure session between two parties.
The SSL handshake protocol can be divided to several important stages:
    1. Authenticate the server to the client.
    2. Negotiation of common cryptographic algorithms, or ciphers, that both the server and the client supports.
    3. Authenticate the client to the server (optionally).
    4. Using public-key encryption to exchange cryptography parameters (shared secrets).
    5. Establish an encrypted SSL connection.

The handshake protocol’s structure is:

   
                · Type: SSL handshake message type.
                · Length: Length (in bytes) of the message.
                · Content: Parameters additional to the message.
 

There are different types of SSL handshake protocol messages:

client_hello: This message is sent by the client to initialize a session state. This message includes the following parameters:


server_hello: This is a response to the above request. This message includes the same parameters as the ones mentioned above. The version field includes the lower version suggested by the client and the highest supported by the server. It also generates a random data value that is independent of the client’s given one. Then, the server searches a match for the client’s given session ID (in nonzero cases, because if the session ID field is zero a new session is created). If the session ID is found, a short handshake process is carried out (see short handshake process below). If it is not found, the server creates a new one, and the client and server perform a full handshake. Next, the server chooses a key-exchange algorithm and a cipherSpec from the CipherSuite client list, and a compression method from those suggested by the client.

server_certificate: The server authenticates itself. It does it by sending its certificate to the client immediately following the server hello.

server_key_exchange: This message is sent in cases the server has no certificate or has a certificate that contains just a signature of its public key. Usually, the public key is taken from the certificate itself. SSL version 3.0 supports the following key-exchange algorithms:
    * RSA
    * Fixed Diffie-Hellman
    * Ephemeral Diffie-Hellman
    * Anonymous Diffie-Hellman
    * Fortezza

certificate_request: Often the server asks for a client authentication, but it is not obligatory.

server_hello_done: This message is sent to indicate that the server has finished its part in sending its cryptography and identification parameters. After sending this message the server waits for the client’s response.

client_certificate: This message is sent if the server requested for client certificate. If the client has no certificate, a no_certificate alert message is sent.

client_key_exchange: This message is dependant on the key-exchange algorithm defined by the server earlier:
- If the RSA algorithm is used the pre-master secret, generated by the client, is encrypted with the server’s public key.
- In case the Ephemeral or Anonymous Diffie-Hellman algorithms are used the Diffie-Hellman public key parameters of the client are sent.
- If the Fixed Diffie-Hellman algorithm is used, this message has no content because the Diffie-Hellman parameters were already sent in a certificate message.
- Using the Fortezza algorithm the Fortezza parameters are sent.

certificate_verify: This message is sent in order to provide definite verification of a client certificate. This message is sent following all client certificates except those including Fixed Diffie-Hellman parameters.

Now, both endpoints compute the master_secret as follows:

master_secret = MD5 ( pre_master_secret + SHA ( ‘A’ + pre_master_secret + ClientHello.random + ServerHello.random ) ) + MD5 ( pre_master_secret + SHA ( ‘BB’ + pre_master_secret + ClientHello.random + ServerHello.random ) ) + MD5 ( pre_master_secret + SHA ( ‘CCC’ + pre_master_secret +ClientHello.random + ServerHello.random ) ) ;

Then both generate the symmetric key that will be used when data application is transferred. One can imagine the master-key as a seed to the key creation function.

key_block = MD5 ( master_secret + SHA ( ‘A’ + master_secret +ClientHello.random + ServerHello.random ) ) + MD5 (master_secret + SHA ( ‘BB’ + master_secret +ClientHello.random + ServerHello.random ) ) + MD5 (master_secret + SHA ( ‘CCC’ + master_secret +ClientHello.random + ServerHello.random ) ) ;

Change_cipher_spec: Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.
Both client and server send each other a message informing it that future messages from the client will be encrypted with the session key.

finished: This encrypted message is sent immediately after a SSL Change_cipher_spec message is sent by the client, to indicate that the communication setup is successfully done. Now, the client is waiting for the server to send its SSL Change_cipher_spec and finished messages. The finished message is sent under the new algorithm, key and secrets.

At this point the SSL Handshake Protocol is completed and the data application can be transferred through the private channel that was established.

The handshake protocol is described in the scheme below:

                            
 

 Back to Top

Short handshake process
There is an option for the client and server to resume a previous session by using its’ session ID. If that is the case, there is no need to perform the full handshake process, and only the client_hello, server_hello, change_cipher_spec and finished messages are sent.
 

 Back to Top

The SSL Change Cipher Spec Protocol
This protocol is used in the last stage of the SSL Handshake protocol in order to let the parties know to move from their pending state to their current state. This means the parties will finish using the key-exchange algorithm and will move on to use the encryption and MAC algorithms, which were defined in the phases mentioned in the Handshake protocol.
This message has one byte with content of “1” and is encrypted and compressed under the current CipherSpec.

        
 

 Back to Top

The SSL Alert Protocol
This protocol is responsible for informing about an error that occurs, during the whole connection. There are two levels of alerts: a fatal alert or a warning alert. If a fatal alert occurs, the connection is terminated immediately. Other connections of the same session may continue, but this session ID will be marked as invalid so that no new connections can be established on this session.

        
                · Level: Indicates a fatal or warning alert.
                · Alert: Indicates the specific alert.
 
 
Fatal Alert
Warning Alert
Unexpected_message- an inappropriate message was received. close_notify- notifies recipient that the sender terminates the connection.
Bad_record_mac- bad MAC calculation. no_certificate- the client has no appropriate certificate.
Decompression_failure- the length after decompression exceeded its maximum. bad_certificate-the received certificate is damaged.
Handshake_failure- indicates an error in negotiation of security parameters. Unsupported_ certificate-the certificate is of unsupported type.
Illegal_parameter- inconsistency within fields of the Handshake protocol. Certificate_revoked- the certificate was canceled by its signer.
Certificate_expired- the certificate validity expired.
Certificate_unknown- an unexpected matter arose in processing the certificate, making it unacceptable.

 Back to Top

The SSL Record Protocol
In SSL, all transmitted data is encapsulated into an object called a record, which consists of a header and data. The header includes information about the record and is transmitted before the record data.

    
 

SSL Record Header
Each record has a header 5 bytes long. The header fields are:
Type ( 8 bit ) – Indicates the record data type and which higher level protocol should handle this record data. The different types are:
    · change_cipher_spec
    · alert
    · handshake
    · application_data
Version ( 16 bit ) - holds the SSL version protocol. It is composed of a major version and a minor one.
Length ( 16 bit ) - holds the record data length.
 

SSL Record Data
The data portion of the record layer undergoes 4 stages:

                    

                                                        Record data process flowchart.
 
 

Fragmentation
The data information is fragmented into SSLPlaintext records of 2^14 bytes or less.

Compression
In this phase, the compression algorithm defined in the Handshake stage compresses the given SSLPlaintext. Compression must not lose any data. The result is called SSLCompressed. The SSLCompressed length must not exceed 2^14 + 1024.

Applying MAC (Message Authentication Code)
In this phase a MAC, which is defined in the Handshake stage, is attached to the SSLCompressed.
The MAC is computed as follows:
MAC-DATA = HASH ( MAC-WRITE-SECRET, PAD2, HASH ( MAC-WRITE-SECRET, PAD1, SEQUENCE-NUMBER, SSLCompressed.type, SSLCompressed.length, SSLCompressed.fragment ) )
The hash algorithm, used to compute the MAC, derives from the cipher suite. The MAC-WRITE-SECRET is a secret shared value between the client and server. PAD1 is 0x36 byte repeated 48 times for MD5 and 40 times for SHA. PAD2 is 0x5C byte repeated as PAD1. The SEQUENCE-NUMBER functions as a counter. Each party has two counters, one for transmitted messages and one for received ones. Every time a message is sent the counter is incremented. When a change-cipher -spec message is sent or received the counter is set to zero.
SSL supports 2 hash function algorithms:
· MD5, a 128-bit hash.
· SHA – Secure Hash Algorithm, a 160-bit hash.

Encryption
There are 2 types of cipher algorithms used in this section: a stream cipher and a block cipher. When a stream cipher algorithm is used no padding is required. When using block ciphers, the data block needs to be a multiple of the block size, if it is not, padding is used to pad out the length of the data block to be a multiple of the block size of the cipher. The total length after encryption must not exceed 2^14+2048.

The encryption algorithms that are implemented in SSL version 3.0 are:
 
Block Cipher  Stream Cipher 
IDEA - 128 bit 
RC2 - 40 bit
DES - 40 bit
DES - 56 bit
3DES - 168 bit 
Fortezza - 80 bit 		 RC4 - 40 bit
RC4 - 128 bit 

Remark: The SSL Handshake Protocol and the SSL Change Cipher Spec Protocol, which are used to control the SSL communication setup and security parameters, are encapsulated in the Record layer. However, the MAC, padding and encryption are not computed because they haven’t been defined yet and will be defined in those protocols
 

 Back to Top