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

and that is the entire TLS

handshake

and

everything

that

happens

during that

handshake

to calculate the keys to protect the application data. Youtube. I'm doing. I'm giving away the main attraction of Keystone, the crux of my hands-on TLS course in this lesson. It is the culmination of each previous lesson and is what the entire course has been gradually building you towards. Now there is a reason why I am doing this and that reason will become clear to you by the end of this video. In the meantime, prepare for the most. complete and most comprehensive explanation of the TL handshake done in true hands-on foreign networking style, we finally get to the lesson this entire course has been building towards.

In this lesson, we will discuss the actual TLS handshake, this handshake is what builds the actual tunnel that will protect the bulk transfer of data between the client and the server. Now I want to warn you that this is going to be a pretty complicated lesson throughout this course. I was especially careful to break down each idea and concept into small, bite-sized chunks, but breaking up the handshake into several different lessons could detract from understanding how it all fits together, so I chose to do the entire TLS handshake in a longer lesson. I would recommend being gentle and alert before you start and leave This will be the first lesson you see of the day rather than something you see at the end of a series of other lessons, so grab that cup of coffee, do some stretches and let's get started.

Let's illustrate the TL handshake. On a record-by-record basis, remember that records do not necessarily map to packets, meaning that sometimes multiple records will fit within a single package, and sometimes multiple packages will be used to send a single record. We'll show you the handshake in its most basic form. 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 will all show you how those variations are different from the handshake that we will discuss in this lesson, so make sure you fully understand

everything

we discuss in this video.

That being said, now it's time to show you the full TLS handshake that will occur between this client and the server. Throughout this handshake, the client and the server are going to exchange and calculate certain values, we will show you the information that each party has in these two boxes to start with, the server already has some data, that is, the server has its own certificate, the server has its own public key and the server has its own private key matching this as our starting point. Now we can show you everything that

happens

in the TL handshake.

Please note that everything we are going to show you happens every time you

visit

an

https

website

or connect to an SSL. VPN, the first message of the TL handshake is the client greeting within the client greeting, there are five different fields. This version number will include the highest version of SSL that the client supports, meaning that if the client supports TLS version 1.3, it will send this. field the hexadecimal code 0304 to indicate that it is compatible with TLS version 1.3 this random number is 32 bytes generated by the client the first four bytes will include the timestamp until the second what this does is it makes two different client greetings impossible sent more than a second apart from each other to have duplicate random numbers, then we have the session ID.

The session ID is an 8-byte value used to identify this specific session. Let's explore the inner workings of the session ID. When we discuss session resumption later in this module for now, for this simple version of the handshake, the client will send a session ID composed only of zeros or sometimes the client will not include an actual session ID, this will ask the server to randomly generate a session ID to use as a reference for this particular TLS session, which brings us to The Cypher Suites which we discussed in the last module, how cipher seats work, the client will send a list of ciphers that the client supports in the order it prefers and the server will select from this list and finally, if additional extensions are to be included in this particular session, it will be done on the client.

Hello, for this version of the handshake we will proceed with an empty extensions field indicating that no additional extensions are being added. requested, but in later lessons in this module we will show you various handshake extensions and how they will affect this main handshake that we are illustrating in this lesson, so those are the five fields in the client greeting

when

receiving the client's greeting. client, server. then it will respond with the server greeting and the server greeting has the exact same five fields. The version number in the server greeting will indicate the highest version of a cell that the server supports.

This random number is also 32 bytes with the timestamp facing down. for the second encoded in the first four bytes, the session ID sent from the server will be a randomly generated value that will be used to identify subsequent session keys. This value is purely arbitrary, it will simply be used as a label to reference this particular session, the server will then select a cipher from the list that the client suggested and return it to the client in the server's ciphers field. Hello and finally if there is any extension that will be included in this particular TLS. handshake this is where the server would provide the necessary information to the client and again in this particular illustration we are 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 server now have additional information , they both know the highest version of a TLS that is mutually compatible, that is, if the client sends TLS version 1.3 in its version field and the server sends TLS version 1.2 in its version field, that tells you both the client and the server that the highest version of a mutually supported cell is TLS 1.2 and both the client and the server will continue the negotiation using the TL 1.2 handshake.

Also, both the client and the server will know both random numbers, the client knows the random number that it generated and sent to the server and it knows the random number that it received from the server in the same way that the server knows the client number that was sent by the client and the server know their own random number which they generated randomly, so both the client and the server know both the random numbers, they also know the session ID which will be used to refer to this particular session in the future and, finally, you both know the mutually agreed upon Cipher Suite that will be used to protect the bulk data transfer in this TLS session.

We'll take a quick pulse check right here, go ahead and pause very quickly for a moment and make sure you understand how the client and the server have obtained the mutual information that we just discussed, if you're okay with that, we can now continue, the next record in the TL handshake is the certificate record sent by the server and as you can infer, inside the certificate record is the complete certificate chain of the server so that it is clear if the server had three certificates and the final entity certificate that will be sent. the four in this message will not send four different certificate records after receiving the certificate and the certificate chain from the server, the client will now get two new pieces of information, namely the certificate and of course the public key that was contained in it. in that certificate the next record that will be sent will be from the server and is called server hello done this is an empty record that simply indicates that the server has nothing else to send at this time there are other variants of the handshake in which the server will send more content between the certificate and the hello done server, but the fact that the hello done server is sent right after the certificate is an indication that we are not doing those other variants;

We will see some of them. Other variants in the next lessons of this module now remember that after receiving the certificate from the server, the client must ask itself two questions first: whether the certificate is legitimate and will be validated by verifying the signature on the certificate using the public CA. key and at this point the client has everything he needs to validate that signature. The second question the client is going to ask is whether the server is the true owner of the certificate to be validated by verifying that the server has the matching private certificate.

The key to be made using the next record that the client sends, that record is known as the client key exchange record and there are two main purposes for the client key exchange record: first, to establish mutual key material, that is That is, an initial value that both the client and server will then use to generate session keys. The second purpose of the client key exchange is to prove that the server is actually the true owner of this certificate. Both objectives will be achieved using a special value known as The Pre-Master Secret. now notice that this value is illustrated with this red dotted line around it which is an indication that that particular value is being sent encrypted.

Let me show you how this value works. The client will generate the pre-master secret. The pre-master secret is 48 bytes. and is mostly randomly generated, except that the first two bytes will include the version of TL being negotiated in this handshake, the pre-master secret will be encrypted with the server's public key that the client has since that he acquired.

when

the server sent its certificate, the encrypted version of the pre-master secret is what will be sent over The Wire, which means that the only person who can extract the actual pre-master secret from the encrypted version that was sent over the wire is whoever has the matching private key that our server has, meaning the server can 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 initial value from which all additional session keys will be calculated for this session. What we just described is how RSA sets that initial value. There are other key exchange protocols that set the initial value a little differently and we will show you those in future lessons in this module, but for now we are going to continue with the very basic handshake that includes the RSA key exchange protocol . That being said, I want to show you what actually happens with that pre-master secret value that will be used as the pre-master secret value. the initial value to generate session keys for this particular TLS session, let me show you how it is done first, the pre-master secret will be used to derive the master secret which will be done by taking that pre-master secret and combining it. with some other values, those other values ​​are the client random number and the server random number that were set in the client greeting and the server greeting and the literal string Master secret is actually written in the RFC that way those four values ​​will be combined to create the master secret now notice that both parties have the values ​​necessary to calculate this master secret both parties have the pre-master secret both parties know the chain Master secret is public knowledge it is in the rfcs and then both parties they have the random client and the random server which means that both the client and the server can gather the master secret which will then be used to generate session keys and it can be done by combining the master secret with some other values ​​that those values ​​go to use. to be the literal string key expansion and then once again the random client and random server which were set to the client greeting and server greeting, the combination of these four values ​​would lead to the generation of the keys session and at least four session keys will be created. 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 chain key expansion and both parties have client and server random numbers, which means that both parties have the same identical session keys.

Now you may be wondering why two sets of keys. Well, that's a great question. What TLS is actually doing is creating two separate tunnels, one to protect all of them. data sent from the client to the server and another to protect all the data sent from the server to the client. In both cases, these are symmetric keys, meaning that everything the client sends will be encrypted and protected with these keys and the server will use its copy. of the same keys to decipher thatcontent and in the other direction, everything 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 its server send duplicate sets of data exactly identical to each other, as they will be encrypted with different keys and will look different on The Wire. Also, if someone did all the hard work to brute force a set of keys in the best thing is that they will only capture and decrypt half of the conversation, that is, the conversation in only one direction because the conversation in the other direction uses a completely new set of keys, this is how TLS and SSL will generate the session keys to protect.

The actual bulk data transfer, the main idea is that TLS is essentially building two different tunnels, one tunnel to protect the data transfer in each direction. Now I will also mention here that if additional secrets are required, this same calculation is what will be done. Previously we discussed encryption protocols in the Cipher Suite module we mentioned that certain encryption protocols require what is known as an IV or a vector. initialization. Well, this is the step that will actually calculate the IVs needed, of course, now you may be wondering how. Will this calculation generate all the necessary keys and IVs we need for this session?

Consider that sometimes we are using a 128-bit encryption protocol that only needs 128 bits for each of the encryption keys and other times we are using 256-bit encryption keys, in which case we will need two sets of 256-bit symmetric keys. each. The way it works is that these values ​​are combined into what is known as a prf or a pseudo-random function. It's somewhat like a hash algorithm, but creates a digest of any length you want internally. A prf includes a hash algorithm that feeds back on itself, meaning you can run the prf for as long as you want to generate as many required bits as possible. you need all the secrets for this session, but like a hash algorithm, the only way to get an identical bitstream is to have identical initial values, which means that only whoever has these four values ​​can generate this exact set of keys that were generated in this session.

That sums 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 logs and now is another good time to take a quick pulse check, go ahead and pause here for a moment. and make sure you understand how the client and server have arrived at this most recent set of values ​​and, in particular, how they calculated the session keys that will be used to actually protect the big 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's key exchange and then computed The server confirms that the server has the correct keys in the same way that the server simply received the key exchange from the client and performed these calculations, but has not yet received anything from the client to prove that the client had the correct keys.

The purpose of the rest. of the records in the handshake is to validate that each party has the correct set of keys and that will start with the client sending the encryption specification record change. This log is an indication that the client has everything it needs to talk securely, meaning it was able to calculate the session keys, you can read this log when the client says it is ready to switch to the encryption it has. specified on the client and server. Hello, now notice that this record is in black and it is there to indicate that it is not a handshake record remember that the encryption specification change is another record completely after the encryption specification change the client will send the record finished the finished record is a handshake record and will be used to prove to the server that the client has the right session keys will be made using a special value known as encrypted verification, let me show you how it is constructed, the client will calculate a hash of all the handshake records that have been seen so far, so if we lower our handshake at this point in the negotiation five handshake records have been sent so far the client hello the server hello the certificate the server hi done and the client key exchange so all the content of those five 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 will be combined with some other values ​​to create what I'm going to call verification data, those other values ​​are the finished client literal string and the master secret, they will all be combined into a prf to create the verification data and finally the data verification will be encrypted with the client's session keys, that is what will create this encrypted verification that was sent on The Wire, in theory the server saw the same handshake record until now, so the server can also create exactly the same handshake cache.

The server also knows that the client's chain ended again. It's built into the RFC, so it's public knowledge and the server has the master secret, which means the server. is able to gather the same verification data, the server will take what was sent on The Wire, decrypt it with its copy of the client's session keys, and if the result is identical to the verification data the server gathered, this tells the server that the client definitely has the same session keys, furthermore computing the handshake hash from what was seen or sent by the client or server also proves that the client and server saw the same handshake records if someone had tampered with the client's handshake after the client had sent it and before the server received it, this verification data on both sides of the wire would not match, so using the handshake hash linking this way demonstrates that no one messed with the content that was sent to negotiate this particular session, so it is how the client will prove to the server that it has the correct session keys so at this point the server knows that the client has the correct session keys but the client does not yet know that the server has the correct session keys, so this same process will now be done, but from the other address the server will send a change encryption specification record and The server will then send its finished message which will include its own encrypted verification data, just as before the change encryption specification record was made. is not a handshake record, it is simply a record that is there to indicate that the server has everything it needs to start talking securely and the finished message will be there to demonstrate to the client that the server has the keys to correct session.

This encrypted verification is done together. in a similar way to what the client sent but to be more exhaustive I am going to show them to you just as 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 go down again our TLS handshake and we count all the handshake records that have been sent, we have the client, hello, the server, the certificate, the server, hello, done the client key exchange and the client finalized all the content of that handshake. The records will be combined in a hashing algorithm and the result will be a handshake hash and again, as long as both the client and the server see or send the same records, both the client and the server will be able to bring the same records together. . handshake hash that handshake hash is then combined with other values ​​to create the verification data; those other values ​​are the finished server literal string and the master secret that both the server and the client have, which means that both the client and the server can build together on the identical verification data, that verification data will be encrypted by the server using the server's encryption keys and then sent to The Wire, the client will take what was sent by the server, decrypt it with its copies of the server's session keys and verify that it matches what the client calculated as the data. verification that will demonstrate to the client that the server has exactly the same set of keys that the client expected, so that at the end of the server's completed message, the client has the necessary proof that the server has the correct session keys, which which means that 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 that there is nothing more to do and the protocol 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 happens during that handshake to calculate the keys to protect the application data if you have.

So far, a round of applause should be given because we just covered a lot of information. I highly recommend watching this video again to make sure it all sinks in. Remember that this TLS handshake we just discussed happens every time you navigate to an

https

or every time you connect to an SSL VPN. In the remaining lessons of this module we will look at variations of the handshake we just discussed. These variations will include different key exchange protocols, different features, or different extensions, but understanding the main handshake we just illustrated is crucial because when we show you the variations, we're only going to show you how they're different, so again I recommend I strongly encourage you to watch this video one more time to make sure everything syncs before you do. start watching the other lessons in this module;

Additionally, before moving on to the other lessons, you will also need to complete a lab that goes with this particular lesson. In your next lab, you will inspect a TLS handshake. In Wireshark you will be able to see and separate each of the logs we discussed into an actual live capture of a TLS session. There will also be some questions you'll need to answer to help guide your exploration of the TL handshake so you have that to look at. I hope you enjoyed that lesson. It is the culmination of what each previous lesson in the course was building.

If as you went along, there was any part that left you asking other questions. I guarantee there's probably another lesson. Earlier in the course answering your question, exactly what you just saw was the handshake or TLS versions 1.2 and the previous TLS 1.3 came out a few years ago and is slowly gaining ground on the Internet. TLS 1.3 is a major change in the way we made the Internet. The security above and in addition will be used everywhere, not only when browsing the web, but also quickly with the new layer 4 protocol, so wherever you work in the Internet ecosystem, you will definitely find TLS 1.3, all illustrations and all the details we just saw. in the TLs 1.2 handshake I am going to do the TLs 1.3 hand check again and to motivate myself to finish I am going to Discount a TLS practical course at the lowest price I have offered until I finish the TLs 1.3 module buying the course now will give you Instant access to everything already published and all the TLs 3.3 content I'm currently creating as we speak, so if there is any part of you or your job responsibilities that requires in-depth knowledge of TLS, this is a definitely a must-buy course. for you, but don't wait too long because as soon as the TLs 1.3 content ends, the course will return to full price.

I hope you got a lot out of this video. I hope to see you at the TLS Practical Course