SSL /TLS Handshake Optimization: Speeding Up Encrypted Communication

An interesting aspect of the 21st century is how much we depend on the internet and other technologies and devices for many activities that involve us passing across personal data and private information. Daily, information is transmitted over the Internet, and it passes through various devices and servers; hence, the need to secure communication and protect data.

In securing the numerous exchange that entail our personal and confidential information, communication between two or more parties is carried out using a tool called encryption. This security tool helps to protect sensitive data and secure transmission between applications and servers.

In this article, we’ll be discussing the SSL/TLS security protocol, which operates as part of an encryption process that determines secure communication over a computer network or data exchange between a client and server.

Let’s dive right in!

Encryption involves encoding or concealing data to make it inaccessible to unauthorized users. Essentially, it protects users from security risks when performing activities on the internet, such as financial transactions, private messaging, etc.

There are two main methods of encrypting data namely; symmetric and asymmetric encryption.

Symmetric Encryption: This involves using a single key to encrypt and decrypt data. For example, in password-protected zip files - anyone who wants access to the file must have the password.

Asymmetric Encryption: This involves using public and private key pairs to encrypt and decrypt data. For example, your email address - which you can share with people and your email password- that’s for your knowledge only.

Encryption is like a lock with a secret code, and only the person with the right key can unlock the original message. So why would you need a secret code? Reasons would include;

• Mitigating data breaches
• Data Confidentiality
• Secure communication, and
• Regulatory compliance

Encryption is like a secret language, and it is crucial, especially because it assists in keeping your data safe from prying eyes.

SSL (Security Socket Layer) and its upgraded version, TLS (Transport Layer Security), are protocols that make sure the data transmitted between computers is secure using encryption. Think of SSL/TSL as security guards for your information during online conversations. SSL was first created in 1995, but it had some issues with security. So, it got an upgrade and became TLS, which is the safer and more modern version. In other words, SSL is referring to the TLS security protocol.

The TSL performs tasks such as;

• Authentication
• Data Integrity and
• Data Encryption

Websites use HTTPS for securing and protecting data. HTTPS means - Hypertext Transfer Protocol Secure - and its primary function is to make sure the communication between you and the website/application is secure and private.

This also means that HTTPS utilizes SSL/TLS encryption, which aims to add an extra layer of protection to your online experience.

The TLS session is a conversation between two parties, like your computer and a website, which consists of the handshake and encryption phases.

However, before we dive into the TLS handshake, let’s get to the basics and understand how TLS works.

During a session—a conversation between the client and server or two entities—the devices exchange identity information; it’s like an introduction, and this exchange secures the conversation, ensuring that both sides are legitimate.

The handshake phase is for authentication because the client has to trust that it’s communicating with a legitimate server. The server provides a TLS certificate to the client as a way to build trust. They also use a public key protocol for authentication during the handshake; a shared secret session key is established for encrypting all ongoing conversations. This secret session key is used to decrypt and encrypt messages between entities.

For instance, in a client-server interaction, messages delivered from the client to the server are encrypted. The server receives the message and checks if any modifications have been made to it during transit; if there are none, it proceeds to decrypt it. The symmetric session key, which is like a special password that was shared during the handshake, is used by the client to encrypt messages and by the server to decrypt messages. Overall, TLS authenticates connections before encrypting data transmitted over a network.

The beginning process of secure communication between the client (e.g., browser) and server is what is referred to as an SSL/TLS handshake. During this process, the client and server exchange and calculate or negotiate certain values or parameters, e.g. encryption parameters, cryptographic keys, etc.

Overview of TLS Handshake Process

Depending on the variations in SSL/TLS handshakes, the process might differ. Here’s the basic process of the TLS handshake:

The Client Hello:

The first message of the TLS handshake is the Client Hello, inside the client hello there are 5 fields, namely:

• Version: The highest version of the TLS/SSL client supports.

• Random Number: Usually 32 bytes/256 bits (consider the random number as a secret key exchanged between the client and server to secure data during online communication).

• Session ID: A session ID is an 8-byte unique identifier associated with a particular TLS session. When the client sends a session ID, it prompts the server to generate a session ID as well to use as a reference to this particular TLS session.

• Cipher Suites: The client sends a list of supported ciphers in order of preference, and the server will pick from the list it supports. The cipher suite is a mixture of cryptographic algorithms that define various methods to secure a communication channel. It consists of components, which include encryption algorithms, authentication codes, etc.

• Extensions: Optional additional features added during the SSL/TSL handshake

The Server Hello:

After receiving the client’s hello, the server responds with a server hello, which also contains five fields similar to those of the client.

• Version: There are multiple versions of the TLS Protocol, and the version number indicates the highest version of TLS/SSL the client supports or has chosen for the particular session.

• Random Number: Usually 32 bytes/256 bits the random values created between the client and server are used to deduce encryption keys for securing the communication session.

• Session ID: 8 bytes, 32 bits; think of the session ID as a reference. The server generates values to uniquely identify the occurring session keys.

• Cipher Suites: The server examines and selects a cipher from the list presented by the client and echoes it back to the client, confirming the selected cipher suite.

• Extensions: If there are any extensions to be included in a particular TLS handshake, this is where the server would provide the necessary information back to the client.

After the client and server say hello, the client and server share and agree on pieces of information:

• TLS version

• The client and server know both the random numbers generated and received

• The client and server know the session ID to reference the TLS session in the future.

• The agreed-upon cipher suite to protect bulk data transfer in the TLS session.

Certificate Record:

The next message in the TLS handshake is the certificate record sent by the server to the client. This certificate record is the server’s entire certificate chain; it is like a bundle that contains the end entity certificate and some additional certificates in-between, called intermediate certificates.

If the server has three certificates and also its end-entity certificate, it doesn't send each of them separately. Instead, it bundles all four certificates together in one message. After the certificate and certificate chain is received from the server, the client will obtain new information, namely the certificate and public key that were contained in that certificate.

Server Hello Done:

This is the next message that’ll be sent from the server. This message shows that the server has nothing more to send.

Note: After receiving the certificate from the server, the client checks to know if the certificate is legitimate by verifying the digital signature in the certificate using the CA’s (Certificate Authority) public key. The client also checks to know if the server is the legitimate owner of the certificate by verifying that the server has the matching key. This process is carried out by the next record, called the client key exchange record.

Client Key Exchange:

The record establishes mutual keying material (secret cryptographic information), which is a seed value that the client and server will use to generate session keys. Additionally, it verifies and double-checks that the server is indeed the legitimate owner of the certificate, making sure everything is on the up and up in their virtual handshake.

These checks would be done using a value known as a pre-master secret, which is sent encrypted. The client randomly generates the 48 bytes of the pre-master secret. The first two bytes include the TLS version negotiated between the client and server during this handshake. The pre-master secret is encrypted with the server's public key, which the client acquired when the server sent its certificate.

The version of the pre-master secret the client sends is encrypted and can only be extracted by whoever has the matching private key that the server has, allowing the server to extract the original pre-master key. After this exchange, both parties have the pre-master secret, which is the seed value from which all session keys will be calculated.

In this case, RSA (Rivest-Shamar-Adleman, a type of asymmetric encryption) ascertains the seed value. Bear in mind that there are other key exchange protocols used in secure communications.

Change Cipher Spec Record (Client): This is not considered a handshake but a phase that indicates the client has all it needs to communicate securely.

Finished Record (Client): This handshake shows the server that the client has the correct session keys. This is carried out by using a value called encrypted verification.

Note: During this finished record stage, the server knows that the client has the correct keys, but the client doesn’t know the server has the correct keys.

Change Cipher Spec Record (Server): To make sure they're on the same page, the server sends a change cipher spec record. It's just a quick double-check to ensure they're speaking the same secret language.

Finished Record (Server): Just like the client that sends the change cipher spec record, and finished record, the server is going to do the same with its own encrypted verification data.

After these stages, the client and server have confirmed that they have the correct session keys, bringing the TLS handshake to an end and allowing them to share bulk data that’s being protected with the negotiated session keys.

TLS contributes to the speed of encrypted communication by:

TLS Session Resumption: This allows clients and servers that have communicated previously to use an abbreviated handshake. The feature allows the client and server to use the same encryption key for multiple sessions without the need to establish a new secure connection every time, improving performance significantly.

Symmetric Secret Key/Symmetric Algorithm: Symmetric (single shared secret key) encryption is much faster than asymmetric encryption (public-private key pairs) because it uses the same key for encryption and decryption and doesn't have to perform a lot of mathematical calculations when converting plaintext data into ciphertext. The asymmetric encryption is slower and is used during the handshake stage to exchange the secret session key.

OCSP Stapling: The Online Certificate Status Protocol is responsible for checking certificate revocation, mitigating risk, regulatory compliance, etc. OCSP stapling fetches the current status of its certificate from CA (certificate authority) and delivers it to the client during the TLS handshake. It eliminates the need for the client to make a separate request to the OSCP server. This process ensures that clients can establish a faster connection.

Configuring websites with the latest version of TLS (Transport Layer Security), a more secure version of SSL, prevents unauthorized access to sensitive information. Without TLS, private messages, credit card details, etc. would be easily intercepted by attackers over the internet. A TLS handshake is simply how the client and server communicate securely.