Record Protocol in SSL and TLS

Sarath Pillai's picture
ssl record layer

SSL Protocols

SSL protocol, which was initially developed by Netscape, is the base for secure communication in the internet today. SSL Being a big topic to cover in a single article/blog post, we have tried to segregate different topics to be understood in SSL.

In this post, we will try to understand the Record Protocol in SSL, out of the four main layers in SSL, which are mentioned below.


  1. SSL Handshake Protocol
  2. SSL Record Layer Protocol
  3. SSL Change Cipher Spec
  4. SSL alert Protocol


SSL Record Protocol

Different Layers in SSL, has got different responsibilities to full fill. SSL Record Layer protocol has got the below functions to fulfill.

  • Breaking Down the Data from Application layers, with fixed length.

  • Compress the Data

  • Add Message Authentication Code, Which is calculated with the help of Integrity Key.

  • Encrypt the packets(which was broked down with fixed length).

  • Add SSL header's in the packets with fixed length. Which consists the following headers, which combinely form a 5byte header.

Record Protocol Header contents in SSL

  1. 1 Byte Protocol Definition
  2. 2 Byte Protocol version
  3. 2 Byte Length

You can say that SSL Record Layer Protocol comes just above, the TCP or Transport Layer in TCP/IP protocol Stack, Which is evident from the below picture.

Record Layer in SSL is the layer, which provides the facilities like confidentiality through encryption and integrity check using MAC.

noteThe object created by the record layer, by fragmenting the data from application layer, and adding appropriate headers, is called as a record.


MAC information is very much necessary in this layer, as it checks the integrity of the record. This is nothing but, a hash value calculated with the help of the following things.

MAC value is the Hash value calculated from [sequence number, padding, primary data, secret key].

So now our record will consist of the following things.

  1. Data Fragment
  2. Some Padding
  3. MAC value


From where will the client get that secret key used in the hash function?

SSL connections are always initiated by the client to the server. So most of the times, server has to select one cryptographic algorithm from the client supported list(Which is given by the client).

Most of the negotiation part in SSL is carried out by the client.

After the initial verification of the server(With the help of a certificate, provided by a Certificate Authority ), by the client, the client sends a "Client Key Exchange Message". This message (Client Key Exchange Message) is encrypted with the public key, provided by the server(So that only server can unlock it).

noteClient Key Exchange Message  is a message sent by the client to the server, containing the "Premaster Secret", which is a random number of 46 bytes.


note"Premaster Secret", is used to create symmetric encryption keys(which are used to encrypt data), and secret key for MAC hash function(For message integrity check on both the server and client side).


noteSSL makes use of both Symmetric and Asymmetric Encryption. Asymmetric Encryption is only used for sending "Client Key Exchange Message" (Which we discussed above). Because, client key Exchange message, is the Supper Secret in SSL(Because the symmetric key for data encryption and secret key for MAC,both are derived from "Client Key Exchange Message").

Although a MAC value for integrity check is now placed on our record, our data is still unencrypted. So now the whole data along with the MAC is encrypted with a symmetric Key(which was also shared to the server using "Client Key Exchange Message")


Now this whole encrypted data along with the following header's form a complete record, ready for transmission over TCP.


  1. 1 Byte Protocol Definition
  2. 2 Byte Protocol version
  3. 2 Byte Length


On receiving a record, which is completely(the fragmented data package, at record layer with all its headers), the the other node can calculate the MAC hash value(because, the secret key for MAC was shared, by the client with "Client Key Exchange Method" ),  and then compare it with the MAC attached on the header. Also the server can decrypt the data with the symmetric key ( which was also shared with "Client Key Exchange Method" ).

Rate this article: 
Average: 4.3 (168 votes)


awesome explanations, thanks.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.