I’ve already discussed SSL in my previous article. Here I’ll be explaining SSLv3. It was developed by Netscape.

General SSL Architecture

It was designed to secure end-to-end services on the internet. I’ll show that SSL isn’t a single handed protocol. It’s a layer of more than one protocol such as:

  1. SSL record protocol
  2. SSL handshake protocol
  3. SSL change cipher spec protocol
  4. SSL alert protocol

The SSL record protocol provides basic security to other higher level protocols, specially HTTP, which is responsible for server client interaction on the web. The other three protocols are responsible for managing for the whole SSL exchange. There are two basic concepts in SSL. They are:

  1. SSL connection : In SSL, mechanism connections are a P2P (Peer-to-peer) relationship.
  2. SSL session : Its client-server association. Most likely created by the SSL handshake protocol.

SSL Record Protocol

It provides two main services for SSL:

  1. Integrity : Handshake protocol, which produces a shared secret key, used to form the MAC (Message Authentication Code).
  2. Confidentiality : Handshake protocol produces a shared secret key to encrypt the SSL payload.

The chart below describes the operation of the protocol.

The record protocol takes application data and fragments data into blocks. Then it compresses and adds a MAC to encrypt the data. Finally header information added and transmitted to the TCP segment. Fragmentation application data is fragmented into blocks of 214 bytes or less. Then the compression it applies has to be lossless. It shouldn’t increase the content length more than 1024 bytes. Compression is optional. SSLv3 doesn’t use any compression mechanism. After that, the MAC is computed in which a shared secret key is used. The SSLv3 MAC algorithm is based on HMAC, which you may find in RFC 2104. The latest version of HMAC uses XOR. Then, it’s time for encryption. It may increase the content length more than 1024, but the total length of it should not exceed 214+2048.

Want to learn more?? The InfoSec Institute CISSP Training course trains and prepares you to pass the premier security certification, the CISSP. Professionals that hold the CISSP have demonstrated that they have deep knowledge of all 10 Common Body of Knowledge Domains, and have the necessary skills to provide leadership in the creation and operational duties of enterprise wide information security programs.

InfoSec Institute's proprietary CISSP certification courseware materials are always up to date and synchronized with the latest ISC2 exam objectives. Our industry leading course curriculum combined with our award-winning CISSP training provided by expert instructors delivers the platform you need in order to pass the CISSP exam with flying colors. You will leave the InfoSec Institute CISSP Boot Camp with the knowledge and domain expertise to successfully pass the CISSP exam the first time you take it. Some benefits of the CISSP Boot Camp are:

  • Dual Certification - CISSP and ISSEP/ISSMP/ISSAP
  • We have cultivated a strong reputation for getting at the secrets of the CISSP certification exam
  • Our materials are always updated with the latest information on the exam objectives: This is NOT a Common Body of Knowledge review-it is intense, successful preparation for CISSP certification.
  • We focus on preparing you for the CISSP certification exam through drill sessions, review of the entire Common Body of Knowledge, and practical question and answer scenarios, all following a high-energy seminar approach.

The following table shows encryption algorithms and their key sizes.

Algorithm Key Size
RC4-40 40
RC4-128 128
AES 128,256
Fortezza (Used in Smartcard Encryption) 80
IDEA 128
RC2-40 40
3DES 168
DES-40 40
DES 56

The final step of the SSL Record protocol is to add header information to the final encrypted content.

Change Cipher Spec Protocol

Change cipher spec protocol uses the SSL record protocol. It helps the party to avoid a pipeline stall. It’s a TLS protocol. It consists of one single message of one byte. It causes a pending state in order to copy it to the current state. It updates the encrypted text to be used in TLS.

The architecture of SSL record:

SSL Alert Protocol

It’s usually used to send and receive SSL related alerts to end to end identities. These alert messages are also compressed and encrypted. The figure below shows the alert protocol structure.

Each message uses two bytes. The level byte is a value warning and the alert byte conveys the severity of the payload. If the level becomes fatal, SSL will directly initiates a connection. If there are more connections in same session, then they may continue. The alert byte contains code which produces a specific alert. Some alerts are listed below and they can be identified by their name.

  1. bad_certificate
  2. unsupported_certificate
  3. certificate_revoked
  4. illegal_parameter
  5. decompression_failure
  6. bad_record_mac
  7. handshake_failure
  8. no_certificate
  9. certificate_expired

SSL Handshake Protocol

The most important and complicated part of SSL is the SSL handshake protocol. This protocol allows both ends to connect each other, authenticating each other, negotiating encryption and exchanging packets. It contains a series of messages transferred between a server and client.

The SSL handshake has four main phases.

Phase 1. Establishing Connection and Capabilities For Security

It initiates the logical connection between a client and a server. It also generates security capabilities of which a server and a client will both use.

RN are random numbers which are generated by clients. It consists of a 32 bit timestamp and 28 bytes. First, the client sends a client_hello message and waits for the server to reply. The server replies to the client with a server_hello message. Both messages contain the same parameters such as versions, session IDs, cipher suites, compression methods, and initial random numbers. Then, a random field is generated by the server which is different than the client’s. The cipher suite contains a single cipher which is selected by the server. The compression field contains the compression method selected by the server.

Phase 2. Key Exchange & Server Authentication

The server sends a certificate to a client which needs to be authenticated. It contains one or more chains of X.509 certificates. Then, the server_key_exchange message may be sent if it’s required. It’s necessary if you use anonymous Diffie-Hellman, ephemeral Diffie-Hellman, RSA key exchange or Fortezza.

Phase 3. Key Exchange & Client Authentication

After the server sends a certificate to a client, the client should verify whether it’s valid or not. If everything is satisfactory, then the client sends more than one message back to the server. If there is no suitable certificate, The client sends a no_certificate alert to the server. Then the client sends a client_key_exchange_message.

In this phase a client sends a certificate_verify message to the server. This certificate always has signing capability. It signs a hash code based on the previous message. Verification needs to be done by signing a certificate. If anyone misuses it, then they won’t able to send that message.

Phase 4. Finish Phase

The fourth phase creates a secure connection. The client sends a change_cipher_spec message. Then, the client copies the new cipher_spec into the current cipher_spec. Then, the client sends a finish message. Only the finish message verifies that the key authentication and exchanging of the key have been successful.

In a nutshell, the whole SSL process can be illustrated as shown in the figure below.


In this article I tried to simplify and describe SSL, it’s architecture and how the SSL handshake works. I also mentioned the encryption algorithms that are used in SSLv3. In my next article I will present Transport Layer Security.