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

Summary

Highlights

• The TLS handshake is the backbone of HTTPS and SSL VPNs, occurring every time you connect securely. 🔄
• Client hello and server hello are the initial messages in this handshake, setting the stage for secure communication. 👋
• The pre-master secret, encrypted with the server's public key, becomes the session's foundational security key. 🔗
• Session keys are generated for encrypting data in each direction, enhancing security. 🔐
• Verifying session keys ensures both the client and server can securely exchange data. ✅

Key Takeaways

• The TLS handshake is a vital process for securing HTTPS websites and VPNs, involving client and server exchanges. 🔒
• RSA key exchange is a common method used in TLS handshakes for secure communication. 🔑
• Understanding the basic TLS handshake prepares you for learning about its variations, including TLS 1.3. 📚
• The video is part of a comprehensive course aimed at making you proficient in TLS operations. 🎓
• The creator offers a course discount until the TLS 1.3 module is completed. 💰

Overview

Chapters

• 00:00 - 00:30: Introduction and Overview The chapter provides a comprehensive overview of the TLS handshake, detailing the processes involved in key calculation to secure application data. The author emphasizes the significance of this lesson in understanding the core aspects of TLS, presenting it as the pinnacle of their practical TLS course. It is suggested that there's a purpose behind divulging this pivotal lesson, hinting at a broader objective that will be revealed later.
• 00:30 - 01:00: Course Context and Lesson Outline The chapter introduces the main focus of the course: an in-depth explanation of the TLS handshake. It highlights the importance and the pivotal role of the TLS handshake in establishing a secure tunnel essential for protecting bulk data transmission. The lesson promises a comprehensive and practical approach to understanding this crucial networking process.
• 01:00 - 02:00: Importance of the Lesson and Preparation The chapter emphasizes the importance of understanding the data transfer process between client and server. It warns that the lesson will be comprehensive and requires attention. Instead of dividing the TLS handshake into multiple lessons, it presents the entire process in one session for better coherence. Thus, it advises learners to be fully attentive.
• 02:00 - 03:00: TLS Handshake Basics The chapter begins with advice to start the lesson fresh with a cup of coffee and some stretches, emphasizing the importance of being attentive and ready. It aims to educate listeners about TLS handshake processes on a record-by-record basis. The chapter highlights that records do not always match one-to-one with packets — sometimes multiple records may be contained within one packet or a single record may require multiple packets for transmission.
• 03:00 - 04:00: Handshake Message Structure The chapter introduces the concept of a TLS handshake, focusing on the most basic form of handshake using an RSA key exchange. It emphasizes understanding this basic handshake as a foundation before exploring different variations in subsequent lessons. The chapter aims to prepare the reader for more advanced topics by ensuring a thorough comprehension of the basic TLS handshake structure as discussed in this lesson.
• 04:00 - 05:00: Client and Server Exchange Details In this chapter, the focus is on the client and server handshake process where both parties exchange and calculate necessary information. The server begins with its own certificate, public key, and a matching private key, setting the foundation for the exchange.
• 05:00 - 06:00: Client Hello Message Details The chapter titled 'Client Hello Message Details' explains the first message in the TLS handshake process. This process occurs every time a user visits an HTTPS website or connects to an SSL VPN. The 'Client Hello' message plays a crucial role as it contains five different fields. One of these fields is the version number, which indicates the highest version of SSL that the client supports. For instance, if the client supports TLS version 1.3, it will include this information in the message.
• 06:00 - 07:00: Server Hello Message Details The chapter 'Server Hello Message Details' discusses the components of a Server Hello message in TLS version 1.3. It mentions that the version is indicated by the hex code 0304, and explains the role of a 32-byte random number generated by the client. This random number includes a timestamp in its first four bytes to prevent duplicate random numbers from different client hellos that are sent more than a second apart.
• 07:00 - 08:00: Exchange of Random Numbers and Cipher Suite In the chapter titled 'Exchange of Random Numbers and Cipher Suite,' the concept of a session ID is introduced. It explains that the session ID is an 8-byte value used to uniquely identify a specific session. The discussion notes that in some situations, the client may send a session ID of all zeros or omit it altogether, prompting the server to generate a new session ID. Although more details on the inner workings of the session ID will be provided later in the module when discussing session resumption, this chapter provides a basic understanding of its role during the TLS handshake process.
• 08:00 - 09:00: Certificate and Server Hello Done In this chapter titled 'Certificate and Server Hello Done', the process of cipher suites in network sessions is discussed. The client sends a preferred list of cipher suites to the server, which then selects one from the list. Any additional extensions for a session are specified in the client hello message, and here, an empty extensions field indicates no additional extensions.
• 09:00 - 10:00: Validation of Certificate and Client Key Exchange In this chapter, we discuss the 'Validation of Certificate and Client Key Exchange' focusing on the client and server 'hello' messages in the handshake process. Initially, the lesson explains the client hello message, which comprises five fields. As the lesson progresses, it teases the introduction of various handshake extensions that will be explored in subsequent lessons. Upon the client hello message's reception, the server responds with a server hello message mirroring the five fields of the client hello, starting with the version number. The emphasis is on understanding these components before diving into the influence of handshake extensions.
• 10:00 - 11:00: Pre-Master Secret and Session Key Generation Chapter "Pre-Master Secret and Session Key Generation" covers the essential components central to the SSL/TLS handshake protocol. It details how servers convey the highest version of SSL/TLS they support by sending a 32-byte random number which includes a timestamp encoded in its first four bytes. Alongside, it describes the server-generated Session ID, a unique arbitrary value, which serves to distinguish the particular session that follows. This Session ID essentially acts as a label for referencing specific session keys. Additionally, the server's role in selecting a suitable Cipher for the session is highlighted, emphasizing the procedures that underpin secure session key generation.
• 11:00 - 12:00: Master Secret Derivation This chapter focuses on the process of Master Secret Derivation within the context of a TLS handshake. It explains that during the handshake, the server echoes back the suggested cipher in the server hello message to the client. It also discusses how the server provides necessary information regarding any extensions that will be included in the handshake. However, in this illustrated example, all additional extensions present at the end of both the client hello and server hello messages are excluded. The chapter underscores the interaction between the client and server in establishing a secure communication channel.
• 12:00 - 13:00: Session Key and Secure Channels The chapter discusses the negotiation process between a client and server to establish a secure communication channel using the Transport Layer Security (TLS) protocol. It highlights how both parties determine the highest version of TLS they mutually support, ensuring both the client and server can securely communicate with the agreed-upon protocol version. This process is crucial for setting up a secure channel, with an example given where a client proposes TLS 1.3, but the server responds with TLS 1.2, leading to the mutual decision to proceed with TLS 1.2.
• 13:00 - 14:00: PRF and Key Length Considerations The chapter 'PRF and Key Length Considerations' explains the importance of both the client and server knowing certain random numbers during a secure communication session. It details how the client knows the random number it generated, as well as the one it received from the server, while similarly, the server knows its own generated random number and the one received from the client. This mutual knowledge of random numbers, along with both parties knowing the session ID, is crucial in ensuring the security of the communication.
• 14:00 - 15:00: Verification Data and Encrypted Verification In this chapter, the focus is on the mutual agreement between a client and a server regarding the Cipher Suite to be used for encrypting bulk data transfer in a TLS session. This chapter highlights the importance of both parties having a clear understanding of the agreed-upon encryption methods for secure communication. The chapter encourages a pause to ensure comprehension of how both the client and server gather and agree upon the necessary verification data for a secure session.
• 15:00 - 16:00: Server Verification Process The chapter details the TLS handshake process, specifically focusing on the server verification step. It explains how the server sends a certificate record to the client, which includes the entire certificate chain. If the server has three certificates plus its end entity certificate, all four will be sent in this message, rather than separate records. The chapter ends with the client, after receiving this data, moving on to the next steps in the verification process.
• 16:00 - 17:00: Completion of TLS Handshake The chapter discusses the conclusion of the TLS handshake process. It mentions the transfer of a certificate and public key from the server, and the sending of a 'Server Hello Done' message. This message is typically empty and signifies that the server currently has no more data to send. Additionally, the chapter acknowledges the existence of handshake variations where additional content may be exchanged between the certificate and 'Server Hello Done' message.
• 17:00 - 18:00: Review and Replay Recommendation The chapter titled 'Review and Replay Recommendation' discusses the process that occurs after a certificate is received. It mentions that after the certificate is sent, indicating that certain variants won't be covered yet but will be looked at in future lessons, the client must ask two crucial questions regarding the certificate's legitimacy. The process of verifying the signature in the certificate using the CA’s public key is mentioned but not fully detailed, and the discussion seems set to be continued in future lessons.
• 18:00 - 19:00: Lab and Practical Application The chapter titled 'Lab and Practical Application' discusses the process of validating a server's certificate during a secure communication session. It explains that the client needs to verify if the server is the true owner of the certificate by checking if it possesses the matching private key. This verification is facilitated with the client key exchange record, which serves two primary purposes: establishing mutual keying and ensuring a secure data exchange.
• 19:00 - 20:00: Overview of Variations and Future Content The chapter 'Overview of Variations and Future Content' focuses on the role of a 'pre-master secret' in the context of client-server communications, particularly in cryptographic exchanges. It explains how the pre-master secret serves two primary purposes: first, as a seed value that both the client and server use to generate session keys, and second, as a means to prove the server's authenticity to the client. The pre-master secret is highlighted as a crucial value sent in encrypted form to ensure secure communication. The chapter might also explore variations of this process and potentially future developments in this field.
• 20:00 - 21:00: Invitation to Practical TLS Course The chapter 'Invitation to Practical TLS Course' begins with an explanation of how the pre-master secret in TLS (Transport Layer Security) works. It details that the client generates a 48-byte pre-master secret, which is largely random but includes the TLS version in the first two bytes. This pre-master secret is then encrypted using the server's public key, which the client obtained from the server's certificate during the handshake.

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

• 00:00 - 00:30 and that is the entire TLS handshake and everything that occurs throughout that handshake in order to calculate the keys to protect application data all right YouTube I'm doing it I'm giving away the Keystone Main Attraction the Crux of my practical TLS course this lesson is the culmination of every lesson prior and is what the entire course has been gradually building you towards now there's a reason I'm doing this and that reason will become clear
• 00:30 - 01:00 to you at the end of this video in the meantime get ready for the most complete and most thorough explanation of the TLs handshake done in the true practical networking Style foreign [Music] we finally made it to the lesson that this whole course has been building towards in this lesson we'll be picking apart the actual TLS handshake this handshake is what will build the actual tunnel which will protect bulk
• 01:00 - 01:30 data transfer between the client and the server now I want to give you a fair warning that this is going to be a rather involved lesson throughout this course I took particular care to break up every idea and concept into small bite-sized chunks but breaking up the handshake into multiple different lessons might detract from understanding how it all fits together so instead I chose to do the entire TLS handshake in one longer lesson I'd recommend being nice and alert
• 01:30 - 02:00 before you start and let this be the first lesson you watch of the day instead of something you watch at the end of a series of other lessons so grab yourself that cup of coffee do a few stretches and let's get to it we're going to illustrate the TLs handshake on a record by record basis recall that records don't necessarily correlate to packets meaning sometimes multiple records will fit inside a single packet and sometimes multiple packets will be used to send a single record
• 02:00 - 02:30 we're going to show you the handshake in its most basic form meaning a TLS handshake using an RSA key exchange the lessons that follow in this module will show you different variations of this basic handshake but we're all going to show you how those variations are different to the handshake we're going to discuss in this lesson so make sure you very thoroughly understand everything we discuss in this video that being said it is now time to show you the entire TLS handshake that'll
• 02:30 - 03:00 occur between this client and the server throughout this handshake the client and the server are going to exchange and calculate certain values we're going to show you the pieces of information that each party has in these two boxes to begin the server already has a few pieces of information namely the server has its own certificate the server has its own public key and the server has its own matching private key with this as our starting point we can
• 03:00 - 03:30 now show you everything that occurs in the TLs handshake keep in mind everything we're about to show you occurs every time you visit an https website or connect to an SSL VPN the first message of the TLs handshake is the client hello inside the client hello are five different fields this version number is going to include the highest version of SSL that the client supports meaning if the client supports TLS version 1.3 it's going to send in this
• 03:30 - 04:00 field the hex code 0304 to indicate that it supports TLS version 1.3 this random number is 32 bytes generated by the client the first four bytes of that is going to include the time stamp down to the second what this does is it makes it impossible for two different client hellos sent more than a second apart from each other to have duplicate random numbers
• 04:00 - 04:30 then we have the session ID the session ID is an 8 byte value used to identify this specific session we're going to explore the inner workings of the session ID when we discuss session resumption later in this module for now though for this simple version of the handshake the client will send a session ID of all zeros or sometimes the client won't include an actual session ID this will prompt the server to randomly generate a session ID to use as a reference for this particular TLS
• 04:30 - 05:00 session which brings us to The Cypher Suites we discussed in the last module how the cipher seats work the client will send a list of ciphers that the client supports in the order that the client prefers and the server will pick from this list and finally if any additional extensions are going to be included in this particular session it would be done in the client hello for this version of the handshake we will proceed with an empty extensions field indicating no additional
• 05:00 - 05:30 extensions are being requested but in later lessons in this module we'll be showing you various handshake extensions and how they will affect this core handshake that we're illustrating in this lesson so those are the five fields in the client hello upon receiving the client hello the server will then respond with the server hello and the server hello happens to have the exact same five fields the version number in the server hello
• 05:30 - 06:00 will indicate the highest version of a cell that the server supports this random number is also 32 bytes with the time stamp down to the second encoded in the first four bytes the session ID sent from the server is going to be a randomly generated value that'll be used to identify the ensuing session keys this value is purely arbitrary it's simply going to be used as a label to reference this particular session the server will then select a Cipher
• 06:00 - 06:30 from the list that the client suggested and Echo it back to the client in the ciphers field of the server hello and finally if there are any extensions that are going to be included in this particular TLS handshake this is where the server would provide the necessary information back to the client and again in this particular illustration we're going to exclude all the additional extensions that exist at the end of the client hello and the server Hello both the client and the
• 06:30 - 07:00 server now have additional pieces of information both know the highest version of a TLS that is mutually supported meaning if the client send TLS version 1.3 in its version field and the server sent TLS version 1.2 in its version field that tells both the client and the server that the highest mutually supported version of a cell is TLS 1.2 and both the client and the server will continue the negotiation using the TLs 1.2 handshake
• 07:00 - 07:30 moreover both the client and the server are going to know both random numbers the client knows the random number it generated and sent to the server and it knows the random number that it received from the server in the same way the server knows the client number that was sent by the client and the server knows its own random number that it randomly generated so both the client the server know both random numbers they also both know the session ID that
• 07:30 - 08:00 will be used to reference this particular session in the future and finally they both know the mutually agreed Cipher Suite that'll be used to protect the bulk data transfer in this TLS session now we'll take a quick pulse check right here go ahead and pause real quick for a moment and make sure you understand how the client and the server have attained the mutual pieces of information that we've just discussed if you feel good about that we can now continue
• 08:00 - 08:30 next record in the TLs handshake is the certificate record sent by the server and as you can infer inside the certificate record is the server's full certificate chain to be clear if the server had three certificates and its end entity certificate it's going to be sending all four of them in this message it's not going to send four different certificate records after receiving the certificate and certificate chain from the server the client is now going to attain two new
• 08:30 - 09:00 pieces of information namely the certificate and of course the public key which was contained in that certificate the next record that will be sent will be from the server and is called the server hello done this is an empty record which simply indicates that the server has nothing more to send at this time there are other variants to the handshake in which the server is going to send more content in between the certificate and server hello done but the fact that the server hello done
• 09:00 - 09:30 is sent right after the certificate is an indication that we are not doing those other variants we'll be looking at some of those other variants in the next few lessons of this module now recall that after receiving the certificate from the server the client needs to ask itself two questions first is is the certificate legitimate that'll be validated by verifying the signature in the certificate using the ca's public key and at this point the client has
• 09:30 - 10:00 everything it needs to validate that signature the second question that the client is going to ask is is the server the true owner of the certificate that is going to be validated by verifying that the server has the matching private key which will be done using the next record that the client sends that record is known as the client key exchange record and there are two primary purposes for the client key exchange record first is to establish Mutual keying
• 10:00 - 10:30 material meaning a seed value which both the client the server will then use to generate session keys second purpose of the client key exchange is to prove that the server is indeed the true owner of this certificate both of these goals are going to be done using a special value known as The pre-master Secret now notice this value is Illustrated with this red dotted line around it that's an indication that that particular value is sent encrypted
• 10:30 - 11:00 let me show you how this value works the client is going to generate the pre-master secret the pre-master secret is 48 bytes and is for the most part randomly generated except the first two bytes are going to include the TLs version that is being negotiated in this handshake the pre-master secret is then going to be encrypted with the server's public key which the client has because it acquired it when the server sent its certificate
• 11:00 - 11:30 the encrypted version of The pre-master Secret is what's going to be sent on The Wire which means the only person that can extract the actual pre-master secret from the encrypted version that was sent on the wire is whomever has the matching private key which our server does which means the server is able to take this and extract the original pre-master Secret now both parties have the identical pre-master Secret this pre-master secret will be the seed
• 11:30 - 12:00 value from which all additional session keys for this session will be calculated now what we've just described is how RSA establishes that seed value there are other key exchange protocols that establish the seed value a little differently and we'll show those to you in future lessons in this module but for now we're going to continue with the very basic handshake which includes the RSA key exchange protocol with that said I want to show you what actually happens to that pre-master
• 12:00 - 12:30 secret value that pre-master secret value will be used as the seed value to generate session keys for this particular TLS session let me show you how that's done first the pre-master secret is going to be used to derive the master Secret that's going to be done by taking that pre-master secret and combining it with a few other values those other values are the client random number and the server random number which were established in the client hello and the server hello and the
• 12:30 - 13:00 literal string Master secret it's actually written into the RFC that way those four values will be combined to create the master Secret now notice that both parties have the necessary values to calculate this master Secret both parties have the pre-master secret both parties know the string Master secret it's public knowledge it's in the rfcs and then both parties have the client random and the server random which means both the client and the server are able to put together the
• 13:00 - 13:30 master Secret that Master secret is then going to be used to generate session keys and it can be done by combining the master secret with a few other values those values are going to be the literal string key expansion and then once again the client random and server random that were established in the client hello and the server hello combining these four values would lead to the generation of the session keys and at minimum four session keys will be created
• 13:30 - 14:00 a symmetric encryption key and an hmac key to protect what is sent from the client and a symmetric encryption key and an hmac key to protect what is sent from the server and again both parties had the master secret both parties know the string key expansion and both parties have the client and server random numbers which means both parties have the same identical session keys now you might be asking yourself why two
• 14:00 - 14:30 sets of keys well that's a great question what TLS is actually doing is it's creating two separate tunnels one to protect all the data sent from the client to the server and another to protect all the data sent from the server back to the client in both cases these are symmetric keys meaning whatever the client sends will be encrypted and protected with these keys and the server will use its copy of the same keys to decrypt that content
• 14:30 - 15:00 and in the other direction whatever the server sends will be protected by those keys and the client will use those same identical keys to decrypt and read that content the benefit of all this is even if the client and their server send the exact identical duplicate data sets to each other since they're going to be encrypted with different Keys they're going to look different on The Wire moreover if someone were to do all the hard work to brute force one set of keys
• 15:00 - 15:30 at best they're only going to capture and decrypt half of the conversation meaning the conversation in Only One Direction because the conversation in the other direction is using an entirely new set of keys so that is how TLS and SSL will generate the session keys to protect the actual bulk data transfer the main thought there is that TLS is essentially building two different tunnels one tunnel to protect the data transfer in each Direction now I'll also mention here that if any
• 15:30 - 16:00 additional secrets are required this same calculation is what's going to generate them earlier we discussed encryption protocols in the cipher Suite module we mentioned that certain encryption protocols require what's known as an IV or an initialization vector well this is the step that's actually going to calculate any necessary IVs of course you might be asking yourself now how is this one calculation going to generate all the necessary keys and IVs
• 16:00 - 16:30 that we need for this session consider sometimes we're using a 128-bit encryption protocol which only needs 128 bits for each of the encryption keys and other times we're using 256-bit encryption keys in which case we're going to need two sets of symmetric keys that are each 256 bits well the way it works is that these values are combined in what's known as a prf or a pseudo-random function a pseudo random function is sort of like a hashing algorithm but it creates a
• 16:30 - 17:00 digest of any length you want internally a prf includes a hashing algorithm that feeds back in on itself which means you can run the prf for as long as you want to generate as many necessary bits as you need for all the secrets for this session but just like a hashing algorithm the only way to get an identical bit stream is to have identical starting values meaning only Whoever has these four values can generate this exact set of
• 17:00 - 17:30 keys that was generated in this session that wraps up all the events that occur as a result of sending the client key exchange so far in the handshake we've discussed these five records and now is another good time to take a quick pulse check go ahead and pause right here for a moment and make sure you understand how the client and the server have attained this most recent set of values and in particular how they calculated the session Keys which will
• 17:30 - 18:00 be used to actually protect bulk data if you feel good about that then we can continue at this point in the handshake both the client and the server have identical session keys however at this point neither of them know that the other has the correct keys the client simply sent the client key exchange and then calculated the necessary keys but hasn't received anything from the server confirming that
• 18:00 - 18:30 the server has the correct keys in the same way the server simply received the client key exchange and went through these calculations but still hasn't received anything from the client to prove that the client had the right keys the purpose of the rest of the records in the handshake is to validate that each party has the right set of keys and that's going to start with the client sending the change Cipher spec record This Record is an indication that the
• 18:30 - 19:00 client has everything it needs to speak securely meaning it was able to calculate the session keys you can read this record as the client saying it is ready to change to the cipher that they have specified in the client and server hello now notice that this record is in Black that's there to indicate that this is not a handshake record remember that the change Cipher spec is another record entirely following the change Cipher spec the client is going to send the finished
• 19:00 - 19:30 record the finished record is a handshake record and is going to be used to prove to the server that the client has the right session keys that's going to be done using a special value known as the encrypted verification let me show you how that is constructed the client is going to calculate a hash of all the handshake records that have been seen so far so if we pull back down our handshake at this point in the negotiation there have
• 19:30 - 20:00 been five handshake records that have been sent so far the client hello the server hello the certificate the server hello done and the client key exchange so all the content of all five of those handshake records will be hashed together and that's going to create what I'm going to call a handshake hash then that handshake hash is going to be combined with a few other values to create what I'm going to call verification data those other values are the literal string client finished and the master
• 20:00 - 20:30 Secret those will all be combined in a prf to create the verification data and finally the verification data will then be encrypted with the client session keys that's what's going to create this encrypted verification which was sent on The Wire in theory the server saw the exact same handshake record so far so the server is also able to put together this exact same handshake cache
• 20:30 - 21:00 the server also knows the string client finished again it's built into the RFC so that's public knowledge and the server has the master Secret which means the server is able to put together the same verification data the server will then take what was sent on The Wire decrypt it with its copy of the client session keys and if the result of that is identical to the verification data that the server put together this tells the server that the client definitely has the same session keys
• 21:00 - 21:30 moreover calculating the handshake hash from What was seen or sent by the client or the server also proves that the client and the server saw the same handshake records if someone had tampered with the client hello after the client had sent it and before the server had received it this verification data on either side of the wire would not match so using the handshake hash in this way proves that no one messed with the
• 21:30 - 22:00 content that was sent to negotiate this particular session so that is how the client will prove to the server that the client has the correct session keys so at this point the server knows the client has the correct session keys but the client still doesn't know that the server has the correct session keys so this same process will now be done but from the other direction the server is going to send a change Cipher spec record and then the server is going to
• 22:00 - 22:30 send its finished message which is going to include its own encrypted verification data just like before the change Cipher spec record is not a handshake record it's simply a record that is there to indicate that the server has everything it needs to start speaking securely and the finished message will be there to prove to the client that the server has the correct session keys this encrypted verification is put
• 22:30 - 23:00 together in a similar way as to the one that the client sent but for the sake of thoroughness I'm going to show it to you just like when the client did it the server is going to calculate a hash of all the handshake records that have been seen so far if we bring back down our TLS handshake and count out all the handshake records that have been sent we have the client hello the server hello the certificate the server hello done the client key exchange and the client finished all the content of those handshake
• 23:00 - 23:30 records will be combined in a hashing algorithm and the result of that will be a handshake hash and once again as long as both the client and the server saw or sent the same records both the client and the server will be able to put together the identical handshake hash that handshake hash is then combined with other values to create the verification data those other values are the literal string server finished and the master Secret which both the server and the client
• 23:30 - 24:00 have which means both the client and the server are able to put together at The Identical verification data that verification data is then going to be encrypted by the server using the server encryption keys and then sent on The Wire the client will then take what was sent by the server decrypt it with its copies of the server session keys and verify that it matches what the client calculated as the verification data that will prove to the client that the
• 24:00 - 24:30 server has the exact same set of keys that the client expected so at the end of the server finished message the client has the necessary proof that the server has the right session keys which means at this point in the handshake both the client and the server have calculated the correct session keys and have proven to each other that they have the correct session Keys which means there's nothing further to do and
• 24:30 - 25:00 the handshake and they can now start sharing bulk data with each other protecting that data with the session keys that they have negotiated and that is the entire TLS handshake and everything that occurs throughout that handshake in order to calculate the keys to protect application data if you've made it this far then you should give yourself a round of applause because we just covered a lot of information I would highly recommend watching this
• 25:00 - 25:30 video again to make sure it all sinks in remember this TLS handshake that we just discussed occurs every single time you browse to an https website or every time you connect to an SSL VPN in the remaining lessons of this module we're going to look at variations to the handshake we just discussed these variations are going to include different key exchange protocols different features or different extensions but understanding the core handshake that we just Illustrated is crucial
• 25:30 - 26:00 because when we show you the variations we're only going to show you how they are different so again I would highly recommend giving this video a watch one more time to make sure it all syncs in before you start watching the other lessons in this module moreover before you get to the other lessons there's also a lab that you're going to have to complete which goes with this particular lesson in your next Lab you're going to be inspecting a TLS handshake in Wireshark you'll get to see
• 26:00 - 26:30 and pick apart each of the records we discussed in a real live capture of a TLS session there will also be some questions for you to answer to help guide your exploration of the TLs handshake so you have that to look forward to I hope you enjoyed that lesson it's the culmination of what every lesson prior in the course was building towards if as you're going through that there was any part of it that left you asking other questions I guarantee you that there's probably another lesson earlier in the course that spoke to your question exactly what you just saw was the
• 26:30 - 27:00 handshake or TLS versions 1.2 and prior TLS 1.3 came out a few years ago and is slowly building traction on the internet TLS 1.3 is a major departure to how we did Internet Security before plus it's going to be used everywhere not only with just browsing the web but also in quick the new layer 4 Protocol so wherever you work in the internet ecosystem you will definitely come across TLS 1.3 all the illustrations and all the details we just saw in the TLs 1.2
• 27:00 - 27:30 handshake I'm going to do again with the TLs 1.3 hand check and to motivate myself to finish I'm going to Discount a practical TLS course to the lowest price I've ever offered until I finish the TLs 1.3 module purchasing the course now will give you instant access to everything already published and all the TLs 3.3 content that I'm currently creating as we speak so if there's any part of you or your job responsibilities that require in-depth knowledge of TLS this is an absolute must buy course for you
• 27:30 - 28:00 but don't wait too long because as soon as I finish the TLs 1.3 content the course is going back to its full price I hope you got a lot out of this video I look forward to seeing you in the Practical TLS course [Music]