Understanding TLS : An encryption based security protocol (Part 2)

Arunkumar PP
15 min readOct 13, 2023

--

This is my 2nd article from Understanding TLS series.
Part 1 : Understanding TLS : An encryption based security protocol (Part 1)

In the previous article, we had peer view into the TLS security layer and its key functionalities. Also, the process behind a usual web request between a client (such as browser) and Web server. Here let’s understand the Cryptographic properties and implementations of TLS protocol for ensuring a secure and encrypted communication between the entities connected over the network.

Cryptographic properties used in TLS.

Cryptography is a technique of securing information and communications through the uses of codes and mathematical rules so that only person for whom the information is intended can understand it and process it. Let’s understand some of the well-known cryptography properties that underpin TLS, ensuring the confidentiality, integrity, and authenticity of data in transit.

1. Encryption Algorithm

An encryption algorithm is a method used to transform data into a cipher text. The algorithm will use the Encryption key to alter data in a predictable way, so that encrypted data will appear random, and turned back to its normal plain text using the decryption key.

By scrambling data into a cipher text, the confidentiality of the data is ensured, only an authorized person can read the plain text, by decrypting using the actual key of Decryption.

In TLS, the confidentiality of the data in transit is ensured by the implementation of two different Encryption properties.

  • Symmetric Encryption
  • Asymmetric Encryption

Symmetric Encryption: Symmetric encryption is an encryption methodology which uses a single shared key for both encryption and decryption.

As seen in above picture, the encryption and decryption of the data is achieved using same secret key, which enables the simplest kind of encryption process.
In symmetric key encryption both parties that exchange data must have the shared key. If that shared key is exposed, an attacker would be able to decrypt all the communications encrypted using that key. That is why the shared key must be distributed between the parties using an already established, secure, encrypted communication channel. Another disadvantage of symmetric encryption is that you cannot authenticate the sender of a message, which compromises authenticity.

Symmetric encryption Algorithms: RC4, AES, DES, 3DES, and QUAD (AES- Advance Encryption Standard is the widely used symmetric encryption algorithm, also found in TLS encryptions)

Pros of Symmetric encryption:

  • Fast and low resource usage: Since it’s using a single key for encryption and decryption, it’s faster to execute.
  • Simple Operation: Users have only one key for encryption and decryption so it’s easy to execute and manage.
  • Identity verification: It uses password authentication as a security purpose to prove the receiver’s identity.

Cons of Symmetric encryption:

  • Same key used for encryption/decryption.
  • Different key for different parties — difficult key management/distribution

Asymmetric Encryption: Asymmetric key encryption also known as public key encryption uses key pairs: a public key and a private key, for encryption and decryption of data. This means that content encrypted using one key from the key pair can only be decrypted using the other. The public key, as the name implies, can be shared with anyone. The private key must be known only to the owner.

Asymmetric Encryption has also been used to authenticate the sender by signing the data been sent.

Asymmetric Encryption algorithms: RSA, Diffie-Hellman, ECC algorithm.

Pros of Asymmetric encryption:

  • Asymmetric Encryption has two keys, one public and one private, so there’s no problem with distributing keys.
  • Add on Security, Integrity, and Authenticity.

Cons of Asymmetric encryption:

  • Hard to understand and execute: Asymmetric Encryption is not that easy to implement and manage due to its large key sizes.
  • Performance: Asymmetric Encryption is slower in performance compared to Symmetric Encryption

2. Hashing

Hashing is a fundamental process in cryptography that involves in taking an input (data or message) and applying a mathematical algorithm called a hash function to obtain a fixed-size string of characters or numbers known as hash value or hash code.

Main characteristics of hash functions are:

  • A given known input must always produce one known output.
  • Hashing is a one-way computational activity i.e. Once hashing has been done, it should be impossible to go from the output to the input.
  • Different multiple inputs should give a different output.
  • Modifying an input should mean a change in the hash.

Since Hashing function is an irreversible activity and produces the unique results or hash value for each input, the integrity of the received data or message can be verified with the help of hash functions.

Use cases of Hash function in TLS

Data integrity: A data in transit is always prone to have a risk of being corrupted or altered due to network issues or malicious activities. TLS uses hashes to verify the integrity of these data.

Message Digest: Hash functions are used to create fixed-size unique “message digest” or “hash values” from the data being transmitted. A good cryptographic hash functions has several properties, including being collision resistant and pre-image resistant.

Data Verification: In TLS, the sender computes the hash of the data being sent and includes it in a “hash-based message authentication” (HMAC) along with a secret key. The recipient can independently compute the received data and use the same key to verify the HMAC. If the hashes match, it provides strong evidence that the data is not been tampered during its transit.

Digital Signatures: When a server sends its digital certificate, which include its public key, the client can use a hash of the certificate to verify the authenticity. The hash is signed by a trusted certificate authority (CA), ensuring that the certificate is not forged or tampered.

3. Key Exchange

Key Exchange is one of the cryptographic methods used for secure communication. It refers to the process of securely sharing cryptographic keys between two different parties to enable them to communicate privately and securely.

In TLS, Key exchange is a critical component, which is used for secure internet communications. It’s the process by which a client and a server agree on a shared secret key that will be used for encrypting and decrypting data during their communication sessions.

RSA and Diffie-Hellman-Merkle are the top key exchange algorithms used in TLS.

4. MAC (Message Authentication Code):

The Message authentication code is a method used to ensure the integrity and authenticity of a message or piece of data. It’s a short piece of information (often a fixed length of string) generated from the original message and a secret key.

How a Message Authentication Code is used for integrity check?

Step1. Key Setup: Both the sender and receiver share a secret key that must be kept confidential. This key is used exclusively for generating and verifying MACs.

Step2. Message Creation: The sender takes the original message or data that they want to send and combines with the secret key. The specific method for this combination depends on the chosen MAC algorithm.

Step3. MAC Generation: The sender applies a MAC algorithm, which is often a combination of cryptographic hash function and encryption operations, to the message and the secret key. This process results with creation of a fixed-length MAC value.

Step4. Message Transmission: Once the MAC value is generated MAC is either attached with the message or sent separately to the recipient. The sender transmits both MAC and message to the recipient over an insecure communication channel.

Step5. Message Receiving: The Recipient receives the message and the MAC.

Step6. MAC Creation (Recipient side): Since recipient also know the secret key (shared with sender) and can apply the same MAC algorithm to the received message and key to calculate the new MAC value.

Step7. Comparison: The recipient compares the MAC value generated from received message with the MAC value shared by the sender.

Step8. Verification: If two MAC values match, it indicates that the message has not been modified or tampered during transit.

If the MAC values are not identical then the message is confirmed as modified or tampered during its transit.

5. Cipher Suits

Cipher Suits is set of cryptographic algorithms and protocols used to secure a network connection. It defines how encryption and decryption will be performed, as well as how key exchange and authentication will take place during TLS handshake.

Let’s understand Cipher suits components using the above image:

  • Key Exchange Algorithm: This defines the method used for the client and server to securely exchange cryptographic keys.
    ECDHE (Elliptic Curve Diffie-Hellman): Similar to Diffie-Hellman (Facilitates secure key exchange through mathematical operations) but uses elliptic curve cryptography for efficiency.
  • Authentication Algorithm: This specifies how client and server authenticate each other’s identities.
    RSA: The server certificate includes its public key, and the client verifies it with a CA’s public key.
  • Bulk Encryption Algorithm: This determines how data is encrypted and decrypted after the handshake.
    AES_128_GCM: GCM (Galois Counter Mode) uses a block cipher with block size 128 bits (commonly AES-128) operated in counter mode for encryption, and uses arithmetic in the Galois field GF(2128) to compute the authentication tag.
  • Message Authentication: MAC algorithm ensures the integrity of data during transmission.
    SHA256: Secure Hash Algorithm-256 is widely used cryptographic algorithm that produces a fixed-length, 256-bit (32-byte) hash value.

TLS Handshake

From previous article we have seen how a web request process occurs between a client(browser) and server in which we had used plain HTTP protocol for communication with no security layer in between. Once the TCP connection was established between the client and server, the data transfer was occurring in clear text, making it a clean visible data transmit for an eavesdropper.

To communicate over a secure channel, two peers must agree on the cryptographic keys and encryption algorithms for that session. TLS protocol describes the steps to authenticate the peers and set up a secure connection with defined parameters. The entire sequence which involves setting up the session identifier, TLS protocol version, negotiating the cipher suite, certificate authentication of the peers and cryptographic key exchange between peers is called a TLS Handshake.

Simplified illustration of the full TLS handshake process

Let’s understand steps involved in the TLS handshake process, leading to a secure communication between entities.

  1. Client Hello (Client -> Server)

TLS handshake process starts by, sending a Client Hello message from the client (browser) to the server to initiate the session.

The Client hello includes the following information’s:

Client Hello
  • Version: The TLS protocol version number that the client wants to use for communication with the server. This is the highest version understood by the client.
  • Client Random: A 32-bit pseudorandom number that is used to calculate the Master secret (used in the creation of the encryption key).
  • Session Identifier: A unique number used by the client to identify a session.
  • Cipher Suite: The list of cipher suites supported by the client ordered by the client’s preference. The cipher suite consists of a key exchange algorithm, bulk encryption algorithm, MAC algorithm and a pseudorandom function.
List of Cipher suits supported by client

Clients share the supported types of Cipher Suites with the server. Here we can see, the client is letting know the server that it supports these 17 Cipher suites and chose any 1 among them.

  • Compression Method: Contains a list of compression algorithms ordered by the client’s preference.

2. Server Hello (Server -> Client)

After the server receives Client Hello from the client, it replies with a Server hello. Also containing some information’s in return to clients demands.

Server Hello

Server Hello contains following information:

  • Server Version: The highest TLS protocol version supported by the server which is also supported by the client.
  • Server Random: 32-byte pseudorandom number used to generate the Master Secret.
  • Session Identifier: Unique number to identify the session for the corresponding connection with the client. If the client Session ID was not empty, the server searches for previously cached sessions and if a match is found, that session ID is used to resume the session. If the client Session ID was empty, a new session may be created by the server and sent in the server Session ID.
  • Cipher Suits: The server selects the cipher suite among the multiple Cipher suites options sent in Client Hello.
Cipher suite supported by Server
  • Compression Methods: Server selects the compression method among Compression methods sent in Client Hello.

3. Server Certificate (Server -> Client)

The server sends the client a list of X.509 certificate to authenticate itself. The server’s certificate contains its public key. The certificate authentication is either done by the third party (Certificate Authority) that is trusted by the peers, the operating system and the browser which contains the list of well-known Certificate Authorities or by manually importing certificates that the user trusts.

4. Server Key Exchange (Server -> Client)

The message is optional and only sent if the certificate provided by the server is not sufficient for the client to exchange a pre-master secret.

5. Server Hello Done (Server -> Client)

This message indicates that the server is done and waiting the client response.

6. Client Certificate (Client -> Server) -Optional

In rare cases, the server may require the client to be authenticated with a client certificate. If so, the client provides its signed certificate to the server.

7. Client Key Exchange (Client -> Server)

The Client Key Exchange message is sent right after the Server Hello Done is received from the server. If the server requests a Client Certificate, the Client Key Exchange is sent after that. During this stage, the client creates a pre-master key.

Pre-Master Secret
It is a random number generated by the client, the method of creation depends on the cipher suit and then shared with the server.
Before the pre-master key secret is sent to the server, the client encrypts it using the server public key extracted from the certificate provided by the server. So that only the server can decrypt the message using its private key. (Asymmetric encryption)

Master Secret
After the server receives the pre-master secret key, it uses its private data to decrypt it. Now the client and the server computes based on random numbers exchanged earlier (Client Random and Server Random) using pseudorandom function.

A PRF is a function used to generate arbitrary amounts of pseudorandom data.

The master secret key, which is 48 bytes in length, will then be used by both client and server to symmetrically encrypt the data for the rest of the communication.

The client and the server create a set of 3 keys:

  • client_write_MAC_key: Authentication and Integrity check
  • server_write_MAC_key: Authentication and Integrity check
  • client_write_key: Message encryption using symmetric
  • keyserver_write_key: Message encryption using symmetric
  • keyclient_write_IV: Initialization Vector used by some AHEAD ciphers
  • server_write_IV: Initialization Vector used by some AHEAD ciphers

Both Client and Server will use the master secret to generate the sessions keys which will be to encrypt/decrypt data.

8. Client Change Cipher Spec (Client -> Server)

Change Cipher Spec: It defines changes in ciphering strategies. The change cipher spec message, transmitted by both the client and the server, defines the re-negotiated cipher spec and keys that will be used for all the messages exchanged henceforth.

Client notifies the server that all the further messages will be encrypted using the algorithm and keys that were just negotiated.

9. Client Handshake Finished (Client -> Server)

The last message of the handshake process from the client signifies that the handshake is finished indicating that TLS negotiation is completed. This is also the first encrypted message of the secure connection.

10. Server Change Cipher spec (Server -> Client)

Server informs the client that all the further messages will be encrypted using the algorithm and keys that were just negotiated. Server is also ready to switch to an encrypted environment.

11. Server Handshake Finished (Server -> Client)

The last message of the handshake process from the server (sent encrypted) signifies that the handshake is finished.

Application Data Flow

Once the entire TLS Handshake is successfully completed the peers validated, the applications on the peers can begin communicating with each other in the secure way.

SSL/TLS Certificates

SSL/TLS certificate, often referred to as digital certificate, is a digital credential used to authenticate entities on the internet. These entities can be websites, servers, email providers, or individuals. Digital certificates provide a secure way to establish trust between users and online services.

A digital certificate contains identifiable information, such as a user’s name, company, or department and a device’s Internet Protocol (IP) address or serial number. Digital certificates contain a copy of a public key from the certificate holder, which needs to be matched to a corresponding private key to verify it is real. A public key certificate is issued by certificate authorities (CAs), which sign certificates to verify the identity of the requesting device or user.

Certificate Authority (CAs)
A Certificate Authority is a trusted third-party organization or entity that serves as central authority for managing digital certificates and public keys. Primary purpose of CAs is to verify the identity of entities (i.e., websites, servers, individuals) and issue digital certificates that vouch for their authenticity. CAs are integral to creating trust and security in online interactions.

Functions of Certificate Authority.
1. Identity verification.
2. Certificate Issuance.
3. Digital Signature.
4. Certificate Distribution.
5. Certificate Revocation.
6. Certificate Renewal

Types of SSL/TLS Certificates.

· Single-Domain
This type of certificate applies to only one hostname (Fully Qualified Domain Name — FQDN) or subdomain. For example, you may get a certificate for www.example.com or my.example.com. However, mail.example.com will not be included in the scope of this certificate. The certificate will only be valid for one hostname that you specify during registration.

· Wildcard
This type of certificate applies to an entire domain with all its subdomain. For example, if you register *.example.com, the certificate will apply to mail.example.com, secre.example.com, admin.example.com and all other similar subdomains. You can host each subdomain on a different server and use the same wildcard SSL/TLS certificate on multiple servers if the domain is the same.

· Multi-Domain
This type of certificate applies to several different domain names. Each domain name may be a single domain or a wildcard. Usually, when you acquire such a certificate, you can change the domain names at any time. This type of certificate is also often called a Subject Alternative Name (SAN) certificate.

SSL/TLS Certificate Validation

SSL/TLS certificates are also available in different flavours from the point of view of identity validation. The more identity validation, the more trustworthy the certificate is but the more time it takes to acquire it.

· Domain Validation
A domain validation certificate only confirms that the person who applies for a certificate is the owner of the domain name (or at least has access to it). This kind of validation usually takes only a few minutes up to a few hours.

· Organization Validation
The Certification Authority (CA) not only validates domain ownership but also the owner’s identity. This means that an owner might be asked to provide personal information and identification documents that prove their identity. Such validation may take several days.

· Extended Validation
This is the highest level of validation. It includes validation of domain ownership and owner identity, but it also requires the business to provide proof of legal registration.

Conclusion

Here we conclude the second part of Understanding TLS article, where we had a look around with basic understanding on cryptogrpahic properties involved in TLS protocol, The step by step process involved in TLS handshake, also informations on TLS certificates.

In the next part let’s explore even more information over the TLS protocol.

I thank you all who spent there valuable time in going through this article and found useful

Author: Arunkumar P P

Linkedin : Arunkumar P P

--

--