TLS Handshake - EVERYTHING that happens when you visit an HTTPS website

TLS Handshake Overview

In this section, the instructor introduces the TLS handshake process and its significance in securing data transfer between clients and servers.

The Significance of TLS Handshake

• The TLS handshake is crucial for calculating keys to protect application data.

Detailed Explanation of TLS Handshake

• The lesson serves as the culmination of the course, focusing on dissecting the actual TLS handshake.

• The TLS handshake establishes a secure tunnel for bulk data transfer between client and server.

• Emphasis is placed on understanding the entire TLS handshake in one comprehensive lesson rather than breaking it into smaller parts.

Client Hello Message

This part delves into the details of the Client Hello message exchanged during the TLS handshake.

Components of Client Hello Message

• The Client Hello includes five fields: version number, random number, session ID, cipher suites, and extensions.

• The version number indicates the highest SSL version supported by the client.

• A random number generated by the client ensures uniqueness to prevent duplicate random numbers in subsequent handshakes.

• Session ID serves as a unique identifier for a specific session; all zeros may be sent if no specific ID exists.

• Cipher suites are sent in order of preference by the client for selection by the server.

• Extensions field may include additional information but remains empty in this basic illustration.

TLS Handshake Process Overview

In this section, the transcript delves into the TLS handshake process, detailing how both the client and server exchange information to establish a secure connection.

Client-Server Information Exchange

• The client and server engage in a TLS 1.2 handshake where they exchange random numbers generated by each party. Both sides are aware of these random numbers.

• Both the client and server are privy to essential information including session ID for future reference and the mutually agreed Cipher Suite for data protection during the TLS session.

• Following this exchange, the server sends a certificate record containing its full certificate chain to the client. The client validates this certificate's legitimacy using CA's public key.

• Upon receiving and validating the certificate chain, the client obtains two new pieces of information: the certificate itself and the server's public key contained within it.

Key Exchange and Validation

• Subsequently, the server sends an empty record called "server hello done," indicating no further content transmission at that moment. This marks a standard TLS handshake without additional variants.

• The client then verifies if the received certificate is legitimate by checking its signature with CA's public key. It also confirms if the server owns that certificate by verifying with its private key through a client key exchange record.

• The client key exchange record serves dual purposes: establishing mutual keying material using a pre-master secret as a seed value and confirming that the server is indeed in possession of its certificate.

Pre-Master Secret Encryption

• The pre-master secret, crucial for generating session keys, is created by the client with specific characteristics including TLS version details. It is encrypted with the server's public key before transmission over wire for security.

• Only parties possessing matching private keys can decrypt this pre-master secret; hence, only servers can extract it post-transmission. This shared pre-master secret forms the basis for deriving all session keys in that particular TLS session.

TLS Session Key Generation

In this section, the process of generating session keys in TLS is discussed, highlighting the creation of symmetric encryption and HMAC keys to protect data exchanged between the client and server.

TLS Session Key Generation Process

• The combination of values from the client hello and server hello establishes four values used to generate session keys. These include two sets of symmetric encryption keys and HMAC keys for both directions. This ensures data protection during transmission.

• TLS creates two separate tunnels for data transfer: one to secure client-to-server communication and another for server-to-client communication using distinct symmetric keys. This prevents decryption of one direction's data from compromising the other.

• Even if identical data sets are sent back and forth between client and server, encryption with different keys makes them appear different on the wire. Brute-forcing one set of keys only decrypts half of the conversation due to unique key usage in each direction.

• The generation of additional secrets, including IVs when needed, is calculated through a pseudo-random function (PRF). PRF combines initial values to produce necessary bits for session secrets, ensuring only parties with specific values can generate identical key sets.

• For various encryption protocols requiring different key lengths (e.g., 128-bit or 256-bit), PRF generates all essential keys and IVs by combining values iteratively within itself, allowing customization based on protocol requirements.

Validation in TLS Handshake

This segment delves into how validation occurs during the TLS handshake process after generating session keys, emphasizing mutual confirmation between client and server regarding possessing correct encryption keys.

Validation Steps in TLS Handshake

• Following the Client Key Exchange phase, both parties possess identical session keys but lack confirmation about each other's possession of correct keys. This uncertainty prompts further validation steps in the handshake process.

• To validate possession of correct session keys, the client initiates by sending a Change Cipher Spec record indicating readiness to switch securely based on calculated session keys from previous steps without any confirmation yet from the server about its own set of correct keys.

New Section

In this section, the process of combining information to create encrypted verification data in a TLS handshake is discussed.

Creation of Encrypted Verification Data

• The client session keys, master Secret, and string "client finished" are combined in a PRF to generate verification data. This data is then encrypted with the client session keys.

• The server, having received the same handshake record as the client, can also create identical verification data using its copy of the client session keys and knowledge of "client finished" and the master Secret.

• Verifying that both parties have the correct session keys involves comparing calculated verification data. If they match, it confirms that no tampering occurred during the handshake.

Server's Verification Process

• The server sends an encrypted verification message to prove possession of correct session keys to the client.

• Similar to the client's process, the server calculates a handshake hash from all seen handshake records and combines it with other values like "server finished" and master Secret to create verification data.

Mutual Confirmation of Correct Session Keys

• By exchanging these encrypted verifications, both client and server confirm possession of correct session keys.

TLS Handshake Conclusion

This part concludes how both parties establish and confirm possession of correct session keys through mutual verifications.

Successful Key Calculation

• Both client and server have now calculated and verified each other's possession of correct session keys.

Commencement of Data Exchange

• With confirmed session key possession, both parties can securely exchange bulk data under protection from these negotiated keys.

TLS 1.3 Overview

The speaker discusses the significance of TLS 1.3 in internet security and its widespread adoption beyond web browsing.

TLS 1.3 Features

• TLS 1.3 is a significant advancement in internet security compared to previous versions.

• It is gradually gaining popularity on the internet.

• TLS 1.3 will be extensively used not only for web browsing but also in protocols like Quick, a new layer 4 protocol.

TLS 1.3 Handshake Comparison

The speaker explains that all details seen in the TLS 1.2 handshake will be revisited with the TLS 1.3 handshake, offering a practical course discount until completion.

Handshake Comparison

• Detailed illustrations and aspects of the TLS 1.2 handshake will be demonstrated again for TLS 1.3.

• A practical TLS course discount is available until the completion of the TLS 1.3 module.

• Purchasing the course grants immediate access to existing content and upcoming TLS 1.3 materials.