SSL/TLS - Unlocking The Secrets Of Secure Communication

Table of Contents show

Introduction

In today’s digital age, securing sensitive information and protecting against cyber attacks is of the utmost importance. One of the key ways to achieve this is through the use of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols. These security protocols provide a secure communication channel between the client and server, ensuring that sensitive information is protected from prying eyes.

In this blog post, we’ll take a closer look at the SSL/TLS communication process, highlighting the key steps involved and the role of encryption in securing sensitive data. Whether you’re a network administrator, developer, or just someone looking to better understand how online security works, this guide will provide valuable insights into the inner workings of SSL/TLS communication.

TLS was not originally designed to work with SCTP, but in recent years, some efforts have been made to implement TLS over SCTP. The IETF proposed a work item for Transport Layer Security (TLS) over Stream Control Transmission Protocol (SCTP) in order to provide end-to-end security for SCTP-based applications. However, this work is still ongoing and is not yet widely adopted.

Before diving into the specifics of the SSL/TLS communication process, it’s important to understand the basic concepts behind these protocols.

SSL and TLS are both cryptographic protocols that provide secure communication over networks, such as the internet. They work by using a combination of public key encryption and symmetric key encryption to authenticate the parties involved in the communication and to encrypt the data that is exchanged. Public key encryption uses a pair of keys, one for encryption and one for decryption, while symmetric key encryption uses the same key for both encryption and decryption. Together, these encryption methods provide a secure communication channel that can protect against eavesdropping, tampering, and other types of cyber attacks.

Steps of Communication secured by SSL/TLS

SSL/TLS is cryptographic protocol that provide secure communication over networks. It work by using a combination of public key encryption and symmetric key encryption to authenticate the parties involved in the communication and to encrypt the data that is exchanged. — TLS Communications Steps

The following is an overview of the steps involved in an SSL/TLS communication:

1. TCP Handshake

The TCP (Transmission Control Protocol) Handshake is a series of steps that a client and server go through to establish a secure connection before transmitting data. The process is also known as the “Three-way Handshake” because it involves three separate steps. We can say that normally 3 packets are exchanged between client & server.

The TCP Handshake is used to establish a basic, unsecured connection between the client and server before the SSL/TLS Handshake begins. The SSL/TLS Handshake builds on top of the TCP Handshake by establishing a secure, encrypted connection between the client and server.

1.1. SYN Packet

The SYN (Synchronize) packet is the first step in establishing a connection between a client and a server. The SYN packet is sent by the client to the server and contains several fields, including:

Sequence Number: This is the initial sequence number (ISN) that the client will use for the connection.
Maximum Segment Size (MSS): This is the maximum amount of data that the client is willing to accept in a single packet.
Window Size: This is the amount of data that the client is willing to receive from the server.

The SYN packet is also used for flow control, the client sets the window size to let the server know the amount of data it can send at one time, so the server can adjust its sending rate accordingly.

When the server receives the SYN packet, it will respond with a SYN-ACK (Synchronize-Acknowledge) packet, which contains its own ISN and an acknowledgement of the client’s ISN.

In summary, the SYN packet is used to initiate the TCP Handshake and to exchange information between the client and server necessary to establish a secure connection such as the initial sequence number, maximum segment size and window size.

1.2. SYN-ACK Packet

The SYN-ACK (Synchronize-Acknowledge) packet is the second step in establishing a connection between a client and a server. It is sent by the server in response to a SYN (Synchronize) packet that was sent by the client.

The SYN-ACK packet contains several fields, including:

Acknowledgement Number: This is the number that the server is using to acknowledge the client’s initial sequence number (ISN) that was sent in the SYN packet.
Sequence Number: This is the initial sequence number (ISN) that the server will use for the connection.
Maximum Segment Size (MSS): This is the maximum amount of data that the server is willing to accept in a single packet.
Window Size: This is the amount of data that the server is willing to receive from the client.

The SYN-ACK packet is also used for flow control, the server sets the window size to let the client know the amount of data it can send at one time, so the client can adjust its sending rate accordingly.

When the client receives the SYN-ACK packet, it will send an ACK (acknowledge) packet back to the server, completing the three-way handshake and establishing a connection between the client and server.

In summary, the SYN-ACK packet is used to acknowledge the client’s initial sequence number and to exchange information necessary to establish a secure connection such as the initial sequence number, maximum segment size and window size.

1.3. ACK Packet

The ACK (Acknowledgment) packet is the third and final step in establishing a connection between a client and a server. The ACK packet is sent by the client to the server after the client receives a SYN-ACK packet from the server.

The ACK packet contains several fields, including:

Acknowledgment Number: This field contains the next sequence number that the sender of the ACK packet expects to receive. It is used to acknowledge the receipt of data from the other end of the connection.
Control Flags: This field contains control flags such as the ACK flag, which indicates that the packet is an ACK packet.
Window Size: This field contains the amount of data that the sender of the ACK packet is willing to receive. It is used for flow control between the client and server.
Checksum: This field contains a checksum of the packet’s header and data, used to ensure the packet’s integrity during transmission.

It’s important to note that the ACK packet does not contain any payload data and it is a much smaller packet than the SYN and SYN-ACK which contains many fields and the initial sequence number

The ACK packet is also used for flow control, it tells the server that the client has received all the data sent so far, so the server can adjust its sending rate accordingly.

When the server receives the ACK packet, it will consider the connection established and the client and server can begin sending data over the secure connection.

In summary, the ACK packet is used to confirm the client’s receipt of the server’s initial sequence number and to complete the three-way handshake, establishing a connection between the client and server. The packet is also used for flow control by signaling the sender that the receiver has received all the data sent so far.

Once the three-way handshake is complete, the client and server can begin sending data over the secure connection. If either the client or server wants to close the connection, they will use a similar process known as the “four-way handshake” to gracefully close the connection.

2. TLS Handshake

The TLS Handshake is the process by which a client and a server establish a secure, encrypted connection using the TLS protocol. It is a series of steps that both parties go through to establish the parameters of the secure connection, including the version of TLS to be used, the cryptographic algorithms that will be used for encryption and decryption, and the exchange of keys used to establish the secure connection.

The TLS Handshake is an essential part of the TLS protocol, as it ensures that the client is communicating with the intended server, and that the connection is secure. The TLS Handshake begins after the TCP Handshake and it is considered to be more secure than SSL and it’s currently being replaced by its successor, TLS 1.3 and above. We will discuss TLS1.3 in another post in very near future.

The TLS Handshake can be broken down into the following sub-steps:

2.1. “Client Hello” message

The “Client Hello” message is the first message sent by the client during the Transport Layer Security (TLS) Handshake process. It is sent by the client to initiate the TLS Handshake and initiate the establishment of a secure, encrypted connection with the server.

The “Client Hello” message contains several fields that provide information about the client and the parameters of the proposed secure connection. These fields include:

Protocol version: The version of TLS that the client supports. The client will typically send the highest version of TLS it supports, and then in response the server will respond with the highest version it supports that is also supported by the client.
Random number: A 32-byte random number, which is used to generate the session keys for encryption and integrity.
Session ID: An optional field that can be used to indicate that the client is attempting to resume a previously established session.
Cipher suites: A list of the cryptographic algorithms and key exchange methods that the client supports. The server will select a cipher suite from this list that it also supports, and this will be used to establish the secure connection.
Compression methods: A list of the compression methods that the client supports.
Extension: An optional field that can be used to indicate support for additional features such as server name indication (SNI), certificate status request, or to negotiate specific versions of the protocol.

The “Client Hello” message is the first message sent by the client in the TLS Handshake process. It contains information about the client and the parameters of the proposed secure connection. The server uses this information to determine the parameters of the secure connection and to select the appropriate cryptographic algorithms and key exchange methods to establish the secure connection.

2.2. “Server Hello” message

The “Server Hello” message is the second message sent during the Transport Layer Security (TLS) Handshake process. It is sent by the server in response to the “Client Hello” message and is used to confirm the parameters of the secure connection with the client.

The “Server Hello” message contains several fields that provide information about the server and the parameters of the proposed secure connection. These fields include:

Protocol version: The version of TLS that the server has selected to use for the secure connection. It must be the same or lower than the version that the client requested in the “Client Hello” message.
Random: A 32-byte random number, which is used to generate the session keys for encryption and integrity.
Session ID: An optional field that can be used to indicate that the server is resuming a previously established session.
Cipher suite: The cipher suite that the server has selected from the list of cipher suites provided by the client in the “Client Hello” message.
Compression method: The compression method that the server has selected from the list of compression methods provided by the client in the “Client Hello” message.
Extension: An optional field that can be used to indicate support for additional features such as signing algorithm for the server or to negotiate specific versions of the protocol.

The “Server Hello” message is the second message sent during the TLS Handshake process. It is sent by the server in response to the “Client Hello” message and is used to confirm the parameters of the secure connection with the client. It contains information about the server and the parameters of the proposed secure connection, including the version of TLS the server has selected to use, a random number, a session ID, the selected cipher suite, the selected compression method and any additional features that the server supports.

2.3. Server sends TLS certificate

In this step the Server sends its TLS certificate. It is one of the important steps of the Transport Layer Security (TLS) Handshake process. After the server sends its “Server Hello” message to the client, it sends its SSL/TLS certificate to the client.

The server’s certificate contains the following fields:

Public key: The server’s public key which will be used by the client to encrypt a message and send it to the server.
Subject: The name of the entity that the certificate represents, typically the fully qualified domain name (FQDN) of the server.
Issuer: The name of the organization or entity that issued the certificate, typically a trusted certificate authority (CA).
Validity period: The date and time that the certificate is valid from and until.
Signature: A digital signature of the certificate issuer, which can be used to verify the authenticity of the certificate

The certificate is sent in a specific format called X.509 and it’s used to authenticate the server’s identity to the client and ensure that the client is communicating with the intended server.

2.4. Client verifies the TLS certificate sent by server:

Once the client receives the server’s certificate, it will verify the certificate by checking if it’s not expired, it’s issued by a trusted certificate authority (CA) and matches the domain name of the server it is trying to connect to. If the certificate is verified, the client will encrypt a message and sends it to the server using the server’s public key from the certificate.

During this step, the client will perform the following checks on the certificate:

Validity: The client checks if the certificate is not expired. If the certificate has expired, the client will reject the connection.
Trust: The client checks if the certificate has been issued by a trusted certificate authority (CA). If the certificate has not been issued by a trusted CA, the client will reject the connection.
Domain match: The client checks if the domain name in the certificate matches the domain name of the server it is trying to connect to. If the domain names do not match, the client will reject the connection.
Signature Validation: The client verifies the digital signature of the certificate issuer, which can be used to verify the authenticity of the certificate.
Extended Validation (EV) certificate: The client may check if the certificate is an EV certificate, which has more stringent requirements on the identity of the certificate holder and the validation process performed by the certificate issuer.

If the certificate passes all of these checks, the client will consider the certificate to be valid, and the connection to be secure.

It’s important to note that if the client cannot verify the certificate, then it will reject the connection and the communication will not continue to the next step i.e. the key exchange.

2.5. Client sends a “Client Key Exchange” message

The “Client Key Exchange” message is a message sent by the client during the Transport Layer Security (TLS) Handshake process. It is sent after the server sends its certificate and the client verifies it.

The “Client Key Exchange” message is used to establish the session keys for encryption and integrity. The message contains the following fields:

Encrypted Pre-Master Secret: The pre-master secret is a random number generated by the client, it is used to generate the master secret. The client encrypts the pre-master secret using the server’s public key from the certificate, this ensure that only the server can decrypt it.
Key exchange algorithms: The key exchange algorithm used to encrypt the pre-master secret.
Public Key: The client may also send a public key in the key exchange message, this is used in the key agreement algorithm.

The server uses its private key to decrypt the pre-master secret, generating the master secret from the pre-master secret. Both parties use this master secret to generate session keys for encryption and integrity.

The “Client Key Exchange” message is an important step in the establishment of a secure connection, as it ensures that the client and the server share a secret key that is used to encrypt and decrypt data exchanged between them.

It’s important to note that various key exchange algorithms are supported by TLS, such as RSA, Diffie-Hellman, and ECDH, and the specific algorithm to be used is negotiated during the handshake process.

2.6. Server generates a master secret

During this step, the server uses its private key to decrypt the pre-master secret, which was sent by the client in the previous step i.e. “Client Key Exchange” message. Once the server has the pre-master secret, it generates a master secret from it.

The master secret is a unique and unpredictable value that is used to generate the session keys for encryption and integrity. These session keys will be used to encrypt and decrypt the data exchanged between the client and the server.

The process of generating the master secret is specified in the key exchange algorithm used in the “Client Key Exchange” message, for example, in the case of RSA key exchange, the server will use its private key to decrypt the pre-master secret, while in the case of Diffie-Hellman key exchange, the server will use its private key to perform a key agreement to generate the master secret.

Once the master secret is generated, it is securely exchanged between the client and the server, and both parties use this master secret to generate session keys for encryption and integrity.

It’s important to note that the master secret is unique for each connection and it’s discarded once the connection is closed.

2.7. “Server Hello Done” message

The “Server Hello Done” message is used to indicate to the client that the server has completed its part of the handshake process and is ready for the client to continue. It is a simple message that typically does not contain any data or fields, it only serves as an indication that the server has finished sending its messages and is ready for the next step of the handshake.

It is typically a simple message that does not contain any data or fields. It is used to indicate to the client that the server has completed its part of the handshake process and is ready for the client to continue. The “Server Hello Done” message is usually represented as a packet in the network, it has the following structure:

Type: The type of the packet which is “Server Hello Done”
Length: the length of the packet
Protocol version: The version of the TLS protocol that is being used
Handshake message: The specific message type is “Server Hello Done”

It’s important to note that this message is optional in some version of the protocol, and its absence doesn’t affect the handshake process.

The “Server Hello Done” message is an important step in the establishment of a secure connection, as it indicates that the server has finished sending its messages, it also indicates that the client can proceed with the next step of the handshake process.

2.8. Client sends a “Change Cipher Spec” message

The client sends a “Change Cipher Spec” message to the server, indicating that it will start using the new session keys for encryption and integrity.

The “Change Cipher Spec” message is represented as a packet in the network, and it has the following structure:

Type: The type of the packet which is “Change Cipher Spec”
Length: the length of the packet
Protocol version: The version of the TLS protocol that is being used
Change Cipher Spec message: This message contains a single byte value of 1, indicating that the sender will start using the new session keys for encryption and integrity.

After the “Change Cipher Spec” message, the client will send a “Finished” message which is the last message from client in the handshake process, it includes a hash of the previous handshake messages and the new session keys, this is used to ensure the integrity of the handshake process.

2.9. Client sends a “Finished” message

The client sends a “Finished” message to the server, including a hash of the previous handshake messages and the new session keys.

2.10. Server sends a “Change Cipher Spec” message

Just like client, the server also sends a “Change Cipher Spec” message to the client, indicating that it will start using the new session keys for encryption and integrity.

2.11. Server sends a “Finished” message

The server sends a “Finished” message to the client, including a hash of the previous handshake messages and the new session keys.

In conclusion, the Transport Layer Security (TLS) Handshake process is a crucial step in the establishment of a secure connection between a client and a server. It involves a series of messages exchanged between the client and the server to authenticate their identities, establish a secure session, and agree on the cryptographic algorithms to be used for encryption and decryption. This process is the foundation of a secure communication channel that ensures the confidentiality and integrity of the data exchanged between the client and the server.

Once the TLS Handshake is completed, the client and server can securely exchange data using the session keys generated during the handshake process.

It’s important to note that in recent versions of TLS, steps were added such as 0-RTT and post-handshake authentication to improve the overall security of the protocol.

3. Data Transmission

The data transmission step of Transport Layer Security (TLS) communication over Transmission Control Protocol (TCP) is the process of securely exchanging data between a client and a server after a secure connection has been established.

Once the client and the server have completed the TLS Handshake process, they have established a secure session, and agreed on the cryptographic algorithms to be used for encryption and decryption. They have also agreed on the session keys that will be used to encrypt and decrypt data.

During the data transmission step, the client and the server use the established session keys to encrypt and decrypt the data exchanged between them. The data is typically divided into smaller chunks called records, and each record is independently encrypted and decrypted.

The process of encrypting and decrypting the data is done using the agreed upon cryptographic algorithms, such as AES or 3DES. The use of symmetric encryption algorithms ensures that the data is secure while in transit and can only be read by the intended receiver.

It’s important to note that the data transmission step occurs over the established TCP connection, and the data is exchanged in the form of packets, which are sent and received over the network using the standard TCP flow control mechanisms.

In summary, the data transmission step is the final step in a TCP-based TLS communication, it ensures that the data exchanged between the client and the server is secure and cannot be read by any unauthorized parties.

SSL/TLS – Unlocking the Secrets of Secure Communication

ByAdmin