How does SSL/TLS work - part three

The previous post in this series about SSL/TLS described the handshake - the process that establishes an SSL/TLS session between client and server. The session includes agreed-upon encryption keys. Now, let's drill down to how the data sent across the wire is packaged - the record protocol and the alert protocol.

Record protocol

The record protocol is responsible for compression, encryption and verification of the data. All data to be transmitted is split into records. Each record consists of a header byte, followed by the protocol version, the length of the data to be sent (known as the payload), and the payload itself. Firstly, the data is compressed if compression has been agreed upon. Then a MAC is computed and appended to the data. The MAC allows the receiver to verify that the record has not been tampered with. Its calculation includes a sequence number which sender and receiver both keep track of. Finally, the data and the appended MAC are encrypted using the session's encryption keys, and the result is the payload for the record. At the receiving end, the record is decrypted, and the MAC is calculated to verify that the record's data has not been tampered with. If compression was used, it is decompressed.

Alerts

If errors occur, SSL/TLS defines an alert protocol so that error messages can be passed between client and server. There are two levels - warning and fatal. If a fatal error occurs, after sending the alert the connection is closed. If the alert is a warning, it is up to the party receiving the alert as to whether the session should be continued. One important alert is close notify - it is sent when either party decides to close the session. Normal termination of a session requires close notify to be sent. It is worth noting that some SSL/TLS implementations do not send this message - they simply terminate the connection.

Versions

SSL/TLS internal version numbers do not correspond as might be expected to what is publicly referred to as the version number. For example, 3.1 corresponds to TLS 1.0. The main versions currently in use are shown in the table below.

These are useful to be familiar with, as the internal version numbers are often preferred. The final post on SSL/TLS will examine some of the more recent vulnerabilities that have been discovered, and how they have been dealt with.