SSH | SSH Protocol Stack | SSH Protocols | Why SSH? | Secure Shell (SSH)

 

SSH

SSH stands for “Secure Shell”.

What is SSH?

Secure Shell (SSH) is a protocol for secure network communications designed to be relatively simple and inexpensive to implement.

Purpose of SSH

SSH provides a secure remote logon facility to replace TELNET and other remote logon schemes that provided no security. SSH also provides a client/server capability and can be used for such network functions as file transfer and e-mail.

SSH Protocol Stack

Figure: SSH Protocol Stack

SSH is organized as three protocols that typically run-on top of TCP: SSH User Authentication Protocol, SSH Connection Protocol, SSH Transport Layer Protocol.

SSH Transport Layer Protocol: It is responsible for server authentication, Confidentiality and integrity, compression.

SSH User Authentication Protocol: It is responsible for authenticates client (user) to the server.

SSH Connection Protocol: It is responsible for multiplexes the encrypted tunnel into several logical channel.

 

SSH Transport Layer Protocol

SSH transport layer protocol focus on main 3 functions: Host Keys, Packet Exchange and Key Generation.

Host Keys  (Watch video to understand using animation)

Server authentication occurs at the transport layer, based on the server possessing a public/private key pair. A server may have multiple host keys using multiple different asymmetric encryption algorithms. Multiple hosts may share the same host key. In any case, the server host key is used during key exchange to authenticate the identity of the host. (Below Figure)

For this to be possible, the client must have apriori knowledge of the server’s public host key. Two alternative trust models that can be used:

The client has a local database (as per above figure) that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain.

The host name-to-key association is certified by a trusted certification authority (CA) (as per above figure). The client only knows the CA root key and can verify the validity of all host keys certified by accepted CAs. These alternative eases the maintenance problem, since ideally, only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible.

Packet Exchange

SSH Packet Format

Figure: SSH Packet Format

Packet length: Length of the packet in bytes, not including the packet length and MAC fields.

Padding length: Length of the random padding field.

Payload: Useful contents of the packet. Prior to algorithm negotiation, this field is uncompressed. If compression is negotiated, then in subsequent packets, this field is compressed.

Random padding: Once an encryption algorithm has been negotiated, this field is added. It contains random bytes of padding so that that total length of the packet (excluding the MAC field) is a multiple of the cipher block size, or 8 bytes for a stream cipher.

Message authentication code (MAC): If message authentication has been negotiated, this field contains the MAC value. The MAC value is computed over the entire packet plus a sequence number, excluding the MAC field. The sequence number is an implicit 32-bit packet sequence that is initialized to zero for the first packet and incremented for every packet. The sequence number is not included in the packet sent over the TCP connection.

 

SSH Packet Exchange Scenario

 Figure: SSH Packet Exchange Scenario

Establish TCP Connection: Above figure illustrates the sequence of events in the SSH Transport Layer Protocol. First, the client establishes a TCP connection to the server. This is done via the TCP protocol and is not part of the Transport Layer Protocol. Once the connection is established, the client and server exchange data, referred to as packets, in the data field of a TCP segment.

Identification of String Exchange: The first step, the identification string exchange, begins with the client sending a packet with an identification string of the form: SSH-protoversion-softwareversion SP comments CR LF. where SP, CR, and LF are space character, carriage return, and line feed, respectively. An example of a valid string is SSH-2.0-billsSSH_3.6.3q3<CR><LF>. The server responds with its own identification string. These strings are used in the Diffie-Hellman key exchange.

Algorithm Negotiation: Next comes algorithm negotiation. Each side sends an SSH_MSG_KEXINIT containing lists of supported algorithms in the order of preference to the sender. There is one list for each type of cryptographic algorithm. The algorithms include key exchange, encryption, MAC algorithm, and compression algorithm. Table shows the allowable options for encryption, MAC, and compression. For each category, the algorithm chosen is the first algorithm on the client’s list that is also supported by the server.

Figure: SSH Transport Layer Cryptographic Algorithms

SSH Key Exchange: The next step is key exchange. The specification allows for alternative methods of key exchange, but at present, only two versions of Diffie-Hellman key exchange are specified. The following steps are involved in the exchange. In this, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the order of the subgroup; V_S is S’s identification string; V_C is C’s identification string; K_S is S’s public host key; I_C is C’s SSH_MSG_KEXINIT message and I_S is S’s SSH_MSG_KEXINIT message that have been exchanged before this part begins. The values of p, g, and q are known to both client and server as a result of the algorithm selection negotiation. The hash function hash() is also decided during algorithm negotiation.

Client-Side Secret Key Calculation: Random value x is selected by client. Then client calculates e = g^x mod p (share value “e” with server).

Client calculates secret key K = f ^x mod p.

Server-Side Secret Key Calculation: Random value y is selected by server. Then server calculates f = g^y mod p (share value “f” with client).

Server calculates secret key K = e ^y mod p.

H = hash (V_C ||V_S || I_C || I_S ||K_S || e ||  f || K)

Sign  = (K_S || f || s)

End of Key Exchange: The end of key exchange is signaled by the exchange of SSH_MSG_NEWKEYS packets. At this point, both sides may start using the keys generated from K.

Service Request: The final step is service request. The client sends an SSH_MSG_SERVICE_REQUEST packet to request either the User Authentication or the Connection Protocol. Subsequent to this, all data is exchanged as the payload of an SSH Transport Layer packet, protected by encryption and MAC.

Key Generation

The keys used for encryption and MAC (and any needed IVs) are generated from the shared secret key K, the hash value from the key exchange H, and the session identifier, which is equal to H unless there has been a subsequent key exchange after the initial key exchange. The values are computed as follows.

Initial IV client to server: HASH (K || H || "A“ || session_id)

Initial IV server to client: HASH (K || H || "B“ || session_id)

Encryption key client to server: HASH (K || H || "C" || session_id)

Encryption key server to client: HASH (K || H || "D" || session_id)

Integrity key client to server: HASH (K || H || "E" || session_id)

Integrity key server to client: HASH (K || H || "F" || session_id)

 

SSH User Authentication Protocol

SSH user authentication protocol focus on main 3 functions: Message Types and Formats, Message Exchange and Authentication Methods.

Message Types & Formats

Three types of messages are always used in the User Authentication Protocol. Authentication requests from the client have the format:

byte SSH_MSG_USERAUTH_REQUEST (50)

string user name

string service name

string method name

where user name is the authorization identity the client is claiming, service name is the facility to which the client is requesting access (typically the SSH Connection Protocol), and method name is the authentication method being used in this request. The first byte has decimal value 50, which is interpreted as SSH_MSG_USERAUTH_REQUEST.

If the server either (1) rejects the authentication request or (2) accepts the request but requires one or more additional authentication methods, the server sends a message with the format:

byte SSH_MSG_USERAUTH_FAILURE (51)

name-list authentications that can continue

Boolean partial success

where the name-list is a list of methods that may productively continue the dialog. If the server accepts authentication, it sends a single byte message: SSH_MSG_ USERAUTH_SUCCESS (52).

 

Message Exchange (Watch video to understand using animation)

The message exchange involves the following steps:

Figure: SSH User Authentication Protocol Message Exchange

Step-1: Client Send SSH_MSG_USERAUTH_REQUEST

Step-2: Username is not valid then server send SSH_MSG_USERAUTH_FAILURE

Step-3: Server send list of authentication method.

Step-4: Client selects one of the methods from the list & again send request to server.

Step-5: If more authentication method is required then server send partial success value true.

Step-6: When all required authentication methods succeed, the server sends a SSH_MSG_USERAUTH_SUCCESS message.

 

Authentication Methods (Watch video to understandusing animation)

The server may require one or more of the following authentication methods.

Public key: The details of this method depend on the public-key algorithm chosen. In essence, the client sends a message to the server that contains the client’s public key, with the message signed by the client’s private key. When the server receives this message, it checks whether the supplied key is acceptable for authentication and, if so, it checks whether the signature is correct.

Password: The client sends a message containing a plaintext password, which is protected by encryption by the Transport Layer Protocol.

Host based: Authentication is performed on the client’s host rather than the client itself. Thus, a host that supports multiple clients would provide authentication for all its clients. This method works by having the client send a signature created with the private key of the client host. Thus, rather than directly verifying the user’s identity, the SSH server verifies the identity of the client host—and then believes the host when it says the user has already authenticated on the client side.

 

SSH Connection Protocol

The SSH Connection Protocol runs on top of the SSH Transport Layer Protocol and assumes that a secure authentication connection is in use. That secure authentication connection, referred to as a tunnel, is used by the Connection Protocol to multiplex a number of logical channels. SSH user connection protocol focus on main 3 functions: Channel Mechanism, Channel Types and Port Forwarding.

Channel Mechanism

All types of communication using SSH, such as a terminal session, are supported using separate channels. Either side may open a channel. For each channel, each side associates a unique channel number, which need not be the same on both ends. The life of a channel progresses through three stages: opening a channel, data transfer, and closing a channel.

Figure: SSH Connection Protocol Message Exchange

Open a new Channel: When either side wishes to open a new channel, it allocates a local number for the channel and then sends a message of the form:

byte SSH_MSG_CHANNEL_OPEN

string channel type

uint32 sender channel

uint32 initial window size

uint32 maximum packet size

where uint32 means unsigned 32-bit integer. The channel type identifies the application for this channel, as described subsequently. The sender channel is the local channel number. The initial window size specifies how many bytes of channel data can be sent to the sender of this message without adjusting the window. The maximum packet size specifies the maximum size of an individual data packet that can be sent to the sender. For example, one might want to use smaller packets for interactive connections to get better interactive response on slow links.

If the remote side is able to open the channel, it returns a SSH_MSG_CHANNEL_OPEN_CONFIRMATION message, which includes the sender channel number, the recipient channel number, and window and packet size values for incoming traffic.

Otherwise, the remote side returns a SSH_MSG_CHANNEL_OPEN_FAILURE message with a reason code indicating the reason for failure.

Data Transfer: Once a channel is open, data transfer is performed using a SSH_MSG_CHANNEL_DATA message, which includes the recipient channel number and a block of data. These messages, in both directions, may continue as long as the channel is open.

Close a Channel: When either side wishes to close a channel, it sends a SSH_MSG_CHANNEL_CLOSE message, which includes the recipient channel number.

 

Channel Types

Four channel types are recognized in the SSH Connection Protocol specification.

Session: The remote execution of a program. The program may be a shell, an application such as file transfer or e-mail, a system command, or some built-in subsystem. Once a session channel is opened, subsequent requests are used to start the remote program.

x11: This refers to the X Window System, a computer software system and network protocol that provides a graphical user interface (GUI) for networked computers. X allows applications to run on a network server but to be displayed on a desktop machine.

Forwarded-tcpip: This is remote port forwarding, as explained in the next subsection.

Direct-tcpip: This is local port forwarding, as explained in the next subsection.

 

Port Forwarding (Watch video to understandusing animation)

One of the most useful features of SSH is port forwarding. In essence, port forwarding provides the ability to convert any insecure TCP connection into a secure SSH connection. This is also referred to as SSH tunnelling. We need to know what a port is in this context. A port is an identifier of a user of TCP. So, any application that runs on top of TCP has a port number. Incoming TCP traffic is delivered to the appropriate application on the basis of the port number. An application may employ multiple port numbers.

Figure: Connection via TCP

Above figure illustrates the basic concept behind port forwarding. We have a client application that is identified by port number x and a server application identified by port number y. At some point, the client application invokes the local TCP entity and requests a connection to the remote server on port y. The local TCP entity negotiates a TCP connection with the remote TCP entity, such that the connection links local port x to remote port y.

Figure: Connection via SSH Tunnel

To secure this connection, SSH is configured (above figure) so that the SSH Transport Layer Protocol establishes a TCP connection between the SSH client and server entities, with TCP port numbers a and b, respectively. A secure SSH tunnel is established over this TCP connection. Traffic from the client at port x is redirected to the local SSH entity and travels through the tunnel where the remote SSH entity delivers the data to the server application on port y. Traffic in the other direction is similarly redirected.

SSH supports two types of port forwarding: Local Port Forwarding and Remote Port Forwarding.

Local Port Forwarding: The following example should help clarify local forwarding. Suppose you have an e-mail client on your desktop and use it to get e-mail from your mail server via the Post Office Protocol (POP). The assigned port number for POP3 is port 110. We can secure this traffic in the following way:

Step-1: The SSH client sets up a connection to the remote server.

Step-2: Select an unused local port number, say 9999, and configure SSH to accept traffic from this port destined for port 110 on the server.

Step-3: The SSH client informs the SSH server to create a connection to the destination, in this case mail server port 110.

Step-4: The client takes any bits sent to local port 9999 and sends them to the server inside the encrypted SSH session. The SSH server decrypts the incoming bits and sends the plaintext to port 110.

Step-5: In the other direction, the SSH server takes any bits received on port 110 and sends them inside the SSH session back to the client, who decrypts and sends them to the process connected to port 9999.

Remote Port Forwarding: With remote forwarding, the user’s SSH client acts on the server’s behalf. The client receives traffic with a given destination port number, places the traffic on the correct port and sends it to the destination the user chooses. A typical example of remote forwarding is the following. You wish to access a server at work from your home computer. Because the work server is behind a firewall, it will not accept an SSH request from your home computer. However, from work you can set up an SSH tunnel using remote forwarding. This involves the following steps.

Step-1: From the work computer, set up an SSH connection to your home computer. The firewall will allow this, because it is a protected outgoing connection.

Step-2: Configure the SSH server to listen on a local port, say 22, and to deliver data across the SSH connection addressed to remote port, say 2222.

Step-3: You can now go to your home computer, and configure SSH to accept traffic on port 2222.

Step-4: You now have an SSH tunnel that can be used for remote logon to the work server.

To learn more about Socket Programming Functions, Click here

Watch more videos click here.

HTTPS | What is HTTPS | HTTPS Connection | Working of HTTPS | HTTP vs HTTPS | Purpose of HTTPS

HTTPS

HTTPS stands for “Hyper Text Transfer Protocol Secure”.

What is HTTPS?

HTTPS is a protocol, which is used for communication between web browser and web server. HTTPS is secure version of HTTP.

Purpose of HTTPS

HTTPS provides the confidentiality and integrity of data between the user's computer and the website. HTTPS encrypt URL, username, password and sensitive information of user.

What is the default port number of HTTPS?

443 is default port number of HTTPS.

Is search engine uses HTTP or HTTPS?

Search engine uses HTTPS.

Working of HTTPS

Figure: How HTTPS works?

In above figure user interact with server and server user secure https, it shows secure connection between client and server. SSL certificate is added at server side. So, http use SSL, it converts into https. Connection is secured, it means all the data in encrypted from during transmission. Hacker or attacker cannot get any information from that connection.

When HTTPS is used, the following elements are encrypted during communication:

URL of the requested document

Contents of the document

Contents of browser forms (filled in by browser user)

Cookies sent from browser to server and from server to browser

Contents of HTTP header

 

HTTPS Connection

HTTPS connection execute in three phases: Connection Initiation, Data Transfer, Connection Closure.

Figure: HTTPS Connection Phases

Connection Initiation

HTTPS uses TLS handshake protocol to establish a connection between client and server.

Client Hello to server: Client sends hello request to server to start connection initiation.

Digital Certificate shared by server: Server shares its digital certificate with client for the purpose to share a public key of server.

Secret Key share with server: Client generates secret key and share with server. This secret key is encrypted using server’s public key. It is decrypt using only server’s private key.

End handshaking: When connection is established TLS handshake end.

We need to be clear that there are three levels of awareness of a connection in HTTPS: At the HTTP level, At the level of TLS, At the level of TCP.

At the HTTP level, an HTTP client requests a connection to an HTTP server by sending a connection request to the next lowest layer. Typically, the next lowest layer is TCP, but it also may be TLS/SSL. At the level of TLS, a session is established between a TLS client and a TLS server. This session can support one or more connections at any time. As we have seen, a TLS request to establish a connection begins with the establishment of a TCP connection between the TCP entity on the client side and the TCP entity on the server side.

 

Data Transfer

Data Transfer should be done by HTTP Request with TLS application data. All HTTP data is to be sent as TLS application data. Normal HTTP behaviour, including retained connections, should be followed.

 

Connection Closure

Connection closure should be done by three levels: HTTP Level, TLS Level, TCP Level.

An HTTP client or server can indicate the closing of a connection by including the following line in an HTTP record: Connection: close. This indicates that the connection will be closed after this record is delivered. The closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity on the remote side, which will involve closing the underlying TCP connection. At the TLS level, the proper way to close a connection is for each side to use the TLS alert protocol to send a close_notify alert. TLS implementations must initiate an exchange of closure alerts before closing a connection.

A TLS implementation may, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an “incomplete close”. Note that an implementation that does this may choose to reuse the session. This should only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the message data that it cares about. HTTP clients also must be able to cope with a situation in which the underlying TCP connection is terminated without a prior close_notify alert and without a Connection: close indicator. Such a situation could be due to a programming error on the server or a communication error that causes the TCP connection to drop. However, the unannounced TCP closure could be evidence of some sort of attack. So the HTTPS client should issue some sort of security warning when this occurs.

 

Difference between HTTP and HTTPS (HTTP vs HTTPS)

To learn more about Socket Programming Functions, Click here

Watch more videos click here.

What is SSL? | What is SSL Ceritificate? | SSL Architecture and Protocols | Secure Socket Layer | SSL Protocol Stack | Purpose of SSL

 

SSL Architecture & Protocol

SSL is developed by Netscape Communication. SSL stands for “Secure Socket Layer”.

SSL stands for Secure Socket Layer.

What is SSL?

SSL is a protocol for establishing secure links between networked computers.

Purpose of SSL

SSL provides confidentiality, authentication and data integrity in internet communication. SSL is the predecessor to the modern TLS encryption used today.

Figure: Connection using HTTP

In above figure user interact with server but server uses only normal http, it shows unsecured connection between server and client. Hacker or attacker can capture the message from unsecured connection. Username and password are also sent in plain text form. It means hacker or attacker get user’s sensitive information.

Figure: Connection using HTTPS (use of SSL Certificate)

In above figure user interact with server and server user secure https, it shows secure connection between client and server. SSL certificate is added at server side. So, http use SSL, it converts into https. Connection is secured, it means all the data in encrypted from during transmission. Hacker or attacker cannot get any information from that connection.

 

What is an SSL Certificate?

An SSL certificate is a bit of code on your web server that provides security for online communications. When a web browser contacts your secured website, the SSL certificate enables an encrypted connection. It's kind of like sealing a letter in an envelope before sending it through the mail. Websites need SSL certificates to keep user data secure, verify ownership of the website, prevent attackers from creating a fake version of the site, and convey trust to users.

 

SSL Architecture (Watchvideo to understand with animation)

The current version of SSL is 3.0. SSL is works in between application layer and transport layer the reason SSL is also called TLS (Transport Layer Security).

Figure: SSL Protocol Stack

SSL encrypt the data received from application layer of client machine and add its own header (SSL header) into the encrypted data and send encrypted data to the server side. SSL is not a single protocol to perform security tasks there are two layers of sub-protocols which supports SSL there are the SSL handshake protocol, SSL change cipher specification, SSL alert protocol and the SSL record protocol shown in architecture.

SSL Handshake Protocol: Connection establishment.

SSL Change Spec Protocol: Use of required cipher techniques for data encryption.

SSL Alert Protocol: Alert (warning, error if any) generation.

SSL Record Protocol: Encrypted data transmission and encapsulation of the data sent by the higher layer protocols. Two important SSL concepts are the SSL Connection and the SSL Session.

SSL Connection: It is a transport that provides a suitable type of service. Each connection is associated with one SSL session.

SSL Session: It is a set of cryptographic security parameters which can be shared among multiple SSL connections. An SSL session is an association between a client and a server.

 

SSL Protocols (Watchvideo to understand with animation)

SSL Handshake Protocol

Figure: SSL Handshake Protocol Action

Phase 1: Establishing security capabilities

Client Hello:

The highest SSL version number which the client can support.

A session ID that defines the session.

There is a cipher suite parameter that contains the entire cryptographic algorithm which supports client’s system.

A list of compression methods that can be supported by client system.

Server Hello:

The highest SSL version number which the server can support.

A session ID that defines the session.

A cipher suite contains the list of all cryptographic algorithms that is sent by the client which the server will select the algorithm.

A list of compression method sent by the client from which the server will select the method.

Phase 2: Server Authentication and Key Exchange

Certificate: The server sends a certificate message to authentication itself to the client. If the key exchange algorithm is Diffie-Hellman than no need of authentication.

Server key exchange: This is optional. It is used only if the server doesn’t sends its digital certificate to client.

Certificate Request: The server can request for the digital certificate of client. The client’s authentication is optional.

Server Hello done: The server message hello done is the last message in phase 2, this indicates to the client that the client can now verify all the certificates received by the server. After this hello message done, the server waits for the client-side response in phase 3.

Phase 3: Client Authentication and Key Exchange

Client Certificate: It is optional, it is only required if the server had requested for the client’s digital certificate. If client doesn’t have certificate, it can be sending no certificate message. Then it is up to server’s decision whether to continue with the session or to abort the session.

Client key exchange: The client sends a client key exchange, the contents in this message are based on key exchange algorithms between both the parties.

Certificate Verify: It is necessary only if the server had asked for client authentication. The client has already sent its certificate to the server. Bit additionally if server wants then the client has to prove that it is authorized holder of the private key. The sever can verify the message with its public key already sent to ensure that the certificate belongs to client.

Phase 4: Finish

Change cipher spec: It is a client-side messages telling about the current status of cipher protocols and parameters which has been made active from pending state.

Finished: This message announces the finish of the handshaking protocol from client side.

Change cipher spec: This message is sent by server to show that it has made all the pending state of cipher protocols and parameters to active state.

Finished: This message announces the finish of the handshaking protocol from server and finally handshaking is totally completed.

 

SSL Change Cipher Spec Protocol

Figure: SSL Change Cipher Spec Protocol Format

SSL Change Cipher Spec Protocol is upper layer protocol. It is the simplest protocol. This protocol consists of only single byte with value “1”, as shown in figure. It consists of single message only. It copies pending state to current state, which updates the cipher suite to be used to this connection.

 

SSL Alert Protocol

 Figure Shows Alert Protocol Format

Figure: SSL Alert Protocol Format

SSL uses the Alert protocol for reporting error that is detected by client or server, the party which detects error sends an alert message to other party. If error is serious than both parties terminate the session.

Table shows the types of alert messages. SSL alert protocol is the last protocol of SSL used transmit alerts, if any via SSL record protocol to the client or server.

The SSL alert protocol format is shown in figure. Alert protocol uses two bytes to generate alert. First 1 byte indicates two values either 1 or 2. “1” value indicate warning and “2” indicate a fatal error.

Whereas second 1 byte indicates predefined error code either the server or client detects any error it sends an alert containing the error.

SSL Record Protocol

After completion of successful SSL handshaking the keen role of SSL record protocol starts now. SSL record protocol is second sub-protocol of SSL also called lower-level protocol. As defined earlier the SSL record protocol is responsible for encrypted data transmission and encapsulation of the data sent by the higher layer protocols also to provide basic security services to higher layer protocols. SSL records protocol provides different service like data authentication; data confidentiality through encryption algorithm and data integrity through message authentication to SSL enabled connections.

The record protocol provides two services in SSL connection:

Confidentiality: This can be achieved by using secret key, which is already defined by handshake protocol.

Integrity: The handshake protocol defines a shared secret key that is used to assure the message integrity.

Following are the operation performed in Record protocol after connection is established and authentication is done of both client and server.

Figure: SSL Reccord Protocol Operation

Fragmentation: The original message that is to be sent it broken into blocks. The size of each block is less than or equal to 214 bytes.

Compression: The fragmented blocks are compressed which is optional. It should be noted that the compression process must not result into loss of original data.

Addition of MAC: A short piece of information used to authenticate a message for integrity and assurance of message.

Encryption: The overall steps including message is encrypted using symmetric key but the encryption should not increase the overall block size.

Append Header: After all the above operation, header is added in the encrypted block which contains following fields.

Content type: It specifies which protocol is used for processing.

Major version: It specifies the major version of SSL used, for example if SSL version 3.1 is in use than this field contains 3.

Minor version: It specifies minor version of SSL used, for example version 3.0 is in use than field contains 0.

Compressed length: It specifies the length in bytes of the original plain text block.

Figure shows SSL record protocol header format.

Figure: SSL Record Format

To learn more about Socket Programming Functions, Click here

Watch more videos click here.