This section describes the SSL sub-protocol calledThe SSL Record Protocolfrom the (SSL) Lower Layer as indicated in Figure 3.1.
3.3.1 The SSL record protocol processing
The record protocol is an encapsulation protocol. The record protocol is responsible for fragmenting the data that into the chunks of 214 bytes or less. The multiple handshake messages and the application layer data can be combined together into a single plaintext fragments provided the data inside the fragments are of same type. If a single message is too long to fit into the plaintext fragment boundaries then such message may be fragmented across several records [30]. The SSL specification does not provide a guideline on how to determine the message boundaries. The boundaries of the messages could be one-to-one with application data write calls [29].
Once the plaintext fragments are ready, these fragments are optionally compressed by the compression method agreed through handshake protocol. The length of the compressed fragment should be less than 214+ 1024. The MAC (Message Authentication Code) is calcu- lated and concatenated at the end of the (compressed) data fragment. This data is applied with the padding in the case of the block cipher mode to match the size of the block in the cipher. This whole content is then encrypted. The length of this encrypted fragment is allowed to be 214+ 2048 at the max. This encrypted block is then pre-appended with SSL record header. An overview of the record protocol processing is given in Figure 3.3. The final product of this process is called SSL record. Generally, such processing (MAC calculation, encryption, padding) of the data fragment is not applicable for the handshake messages that are transmitted before the change cipher spec protocol message because a connection state is initialized after sending thechange cipher specprotocol message. More information about the connection state is given in Section 3.3.2.
The SSL record is divided into two parts. The record header and the record body. Figure 3.4 shown the pictorial view of the SSL record. The record header consists of the record type (Handshake protocol, change cipher spec protocol, alert protocol and application data protocol), version of the SSL/TLS protocol that is being used, the length of the record payload i.e. the length of the record body (in bytes). The record body consists of the protocol specific data. The record body is formatted as described in Figure 3.3. The plaintext (optionally compressed text) is appended with the padding data so as to match the size of the message data with the block size of the cipher. The padding consist of the set of bytes. The last byte of the padding data indicates the size of the padding and rest of the padding data consist of the bytes of value equal to the pad length. The padding is not required when no encryption is performed or the stream cipher is used to encrypt the data.
3.3.2 SSL connection state
The SSL connection state is an operating environment of the SSL Record protocol [30]. There are always two connection states maintained at server and client side. They are calledCurrent
3.3 SSL Protocol: Lower Layer 23
Figure 3.3: The SSL Record Protocol Processing (source: [5])
State andPending State. It (Connection state) specifies a compression algorithm, encryption algorithm and a MAC algorithms.
The Change Cipher Specprotocol is responsible for changing the Pending State to the
Current State. The original pending state is initialized to an empty state. The initialCurrent State always specifies that no encryption, compression, or MAC will be used [30].
3.3.3 Compression
The TLS [30] protocol includes the compression structure which could accommodate 256 compression methods. The RFC 3749 [35] provides the updated definition for this structure. The values for the compression methods are divided into three categories. These categories are "the IETF Standards Track protocols" category, "the non-Standards Track methods" category and the "private use" category. In addition, [35] gives the identifier for the DEFLATE compression method.
The TLS [30] and predecessors of this protocol should support identifier 0 for no com- pression (compressionmethod.null) and identifier 1 for deflate compression method. The compressionmethod.null is very important since all the applications that uses SSL protocol to secure their communication are not expected to be able to support compression. The DEFLATE compression method and encoding format is described in the RFC 1951 [36].
3.3.4 MAC calculation
The SSL record consist of the MAC data to preserve the integrity of the record payload. The calculation of the MAC consist of the following fields.
The sequence number The sequence number is the number obtained from sequential counter that is maintained separately for read and write state at each side of the communica-
0 7 8 15 16 23 24 31
Record Type SSL version (major) SSL version (minor) Fragment Length Fragment Length
(Contd.)
Handshake / Change Cipher Spec / Alert / Application Data
hhhhhh hhhhhh hhhhhh hhhhhh hhhhhh hhhhhh hhhhhh h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h h Figure 3.4: SSL Record
tion. This counter is initialized to zero once change cipher spec message is received or sent. The maximum value of this counter is 264−1. Once this maximum value is reached, this counter is again re-initialized back to zero. This counter is incremented each time the SSL record is sent or received.
The record type This is the type of the record. This is the same value as mentioned in the first byte of the record header. This field can include record types such as change cipher spec, alert, handshake or application data.
The SSL version The version number of the SSL protocol that is being used in the SSL communication.
The record data length The length of the plaintext data if no compression is used or the length of the compressed data if compression is negotiated to be not null.
The record data This is the record payload itself.
3.4
SSL Features
3.4.1 Session resumption
The SSL protocol has a feature calledSession Resumption. This features is added because the client (user) is likely to connect to the same server (web site) several times (within a short duration). Therefore, it is reasonable to bypass the heavy cryptographic operations for the same client to reduce the cryptographic overhead on the server. The session resumption makes use of a technique called session caching. The SSL consist of a number of expensive operations such as RSA private key operations. Modern web servers makes use of hardware accelerators to offload the heavy cryptographic operations reducing the significant overhead on the core part of the servers. However, it has been proved that the session caching is still effective in the presence of hardware accelerators [37]. This is because the session caching helps to avoid extra network traffic and requires some other lesser expensive operations to be performed. The operations such as digest calculation, master secret computation account for moderate overhead on the SSL protocols. In spite of these small overheads, session cache is assured to help web server performance [38]. The cryptographic parameters of the
3.4 SSL Features 25
SSL connection such as cipher, message digest algorithm, pre-master secret and compression method choice are stored in SSL session cache.
Therefore, session resumption that utilizes session caching is a feature designed as an
optimization featurein the SSL protocols. The change in the normal SSL handshake protocol when Session Resumption is in use can be observed from Figure 3.5. [37] described practi- cal experiments that evaluated the performance of different units, processes and operations belonging to the SSL protocol. This experiment demonstrated that the session resumption improves the server’s throughput by the factor of 2.2 to 2.7. However, reducing protocol messages (Network overhead) in the session has negligible impact on the performance (1 to 3%)
Figure 3.5: Session Resumption (Abbreviated SSL Handshake Protocol)
Process of session resumption
Whenever client includes theSession ID from previous session in theclient hellomessage, it indicates the client’s willingness to resume the session identified by that particular session ID. This session ID, if found by the server in its session cache and if the server is willing to resume the session indicated by that session ID, the server directly proceeds to sending the
change cipher specand thefinished message.
3.4.2 SSL renegotiation
SSL renegotiation is the process where either the client of the server can initiate a new handshake during and within the existing SSL connection. Unlike the session resumption, the SSL renegotiation is a full handshake process. Hence, all the cryptographic operations are performed during the SSL renegotiation. The SSL renegotiation is further explained in Chapter 4.
3.4.3 SSL resumption versus SSL renegotiation
The SSL resumption is designed as an optimization feature since during the session resump- tion, only new client random and server random are exchanged and these are used to renew the key material. The cipher suite negotiated in the session that is being resumed is main- tained in the resumed session. The session resumption process or abbreviated handshake process bypasses all the heavy public key operations that server has to do otherwise. In addition, authentication process is not performed in the resumed session. A server cannot initiate to resume any session with the client. The client is the one who can resume the session. The server can always rejects a session resumption request from the client.
The SSL renegotiation can be carried out for several reasons such as to change the cipher suite, to authenticate each other (client and server), generate a completely new set of key material etc. In the SSL renegotiation, all compulsory steps in normal handshake are carried out. This means, heavy cryptographic operations are also performed. The SSL renegotiation can be initiated by either communicating party. The SSL renegotiation process is carried out in the current session state. This means, the renegotiation messages are exchanged in encrypted mode unless the parent (immediately previous) negotiated session used the NULL cipher.