Four Secured Socket Layer (SSL) Protocols

Without demonstrating how SSL completes its tasks, we have only talked about the concept of SSL in the previous section. <Please add the link to the previous file of SSL and SSL Architecture> According to the diagram below, SSL defines four protocols over two layers:

The transport mechanism is the Record Protocol. Along with the information from the application layer, it also contains messages from three more protocols. The payload of the transport layer, which is often TCP, is a message from the Record Protocol. The Record Protocol's security parameters are provided via the Handshake Protocol. It creates a cypher set, offers keys, and specifies security parameters. Additionally, if necessary, it authenticates both the client and the server. The ChangeCipherSpec Protocol is used to announce when cryptographic secrets are ready. Anomalies are reported via the Alert Protocol. In this part, we'll briefly go through all four protocols.

Handshake Protocol

The Handshake Protocol employs messages to exchange data for constructing the cryptographic secrets as well as to negotiate the cypher suite, and authenticate the server to the client and the client to the server as necessary. The four phases of the handshake are depicted in the following figure.

First Phase - Establishing Security Capabilities

The client and server disclose their security capabilities in Phase I and pick the ones that work best for them both. A session ID is created during this stage, and the cypher suite is decided upon. The parties select a specific compression technique. In order to create a master secret, as we have seen before, two random integers are finally chosen, one by the client and one by the server. Following Phase I, both the client and the server are aware of the SSL version, the cryptographic techniques, the compression technique, and the two random integers used to generate the key.

Second Phase - Server Authentication and Key Exchange

Authentication for the server takes place in Phase II, if necessary. In addition to requesting certificates from the client, the server has the option of sending its certificate and public key. When Phase II is complete, the client and server have been authenticated, and if necessary, the client has access to the server's public key.

Third Phase - Client Authentication and Key Exchange

Phase III is used to verify the client's identity. After Phase III, the client and server can verify each other and share the pre-master secret.

Fourth Phase - Finalizing and Finishing

In Phase IV, the client and server exchange messages to finalize the Handshake Protocol and alter the cypher parameters.

ChangeCipherSpec Protocol

As we've seen, the Handshake Protocol allows for the gradual formation of cryptographic secrets as well as the negotiation of the cypher suite. When are these parameters or secrets available for usage by the two parties, then? SSL requires that these parameters or secrets cannot be used by the parties until they have exchanged or received a specific message, the ChangeCipherSpec message, which is done so during the Handshake Protocol and is specified in the ChangeCipherSpec Protocol. The reason is that the problem goes beyond simple message sending and receiving. Two states, not one, are required for the sender and the receiver. The parameters and secrets are tracked by one state, the pending state. The active state, which is the other state, contains the parameters and secrets that the Record Protocol uses to sign, validate, or encrypt and decode messages. Additionally, read (inbound) and write (outbound) data are stored in each state separately.

Alert Protocol

SSL reports problems and strange conditions using the Alert Protocol. It just makes use of one message to describe the issue and its severity (warning or fatal).

Record Protocol

Messages from the top layer are transmitted through the Record Protocol (Handshake Protocol, ChangeCipherSpec Protocol, Alert Protocol, or application layer). The message is split into pieces and, if desired, compressed; the compressed message is then added to by adding a MAC with the agreed-upon hashing algorithm. Utilizing the agreed-upon encryption procedure, the compressed fragment and MAC are both encrypted. The encrypted communication is then supplemented with the SSL header. This process at the sender is shown in the given Figure. The recipient reverses the process.