YT YouTube2Text

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

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

by Practical Networking · 4,610 words · 752 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

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

About this transcript

This page contains the full transcript of TLS Handshake - EVERYTHING that happens when you visit an HTTPS website by Practical Networking, generated from the public captions YouTube serves with the video. The transcript has 4,610 words across 752 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.