TLS 1.3 Handshake - many CHANGES from prior versions!

in this lesson we're going to look at some changes that TLS 0.3 introduces as they relate to the TLs handshake there are four significant changes that we're going to discuss and just like in the last lesson I'm going to give you context for each of them so with that in mind I want to start by showing you the TLs 0.2 and prior handshake so here is the TLs 1.2 and prior handshake back in module 6 of the Practical TLS course we uncovered all the details about this handshake we explain what each of these messages were and the contents that they included any of this is unfamiliar to you I'd recommend going back to module 6 and reviewing this lesson with that in mind what I want to focus on in this lesson is how many round trips this handshakes actually takes first the client sends its client hello then the server sends these three messages and this concludes the first round trip then the client sends these three messages and then the server responds with these messages which concludes the second round trip it said that the TLs 1.2 handshake requires two round trips to complete this is referred to as a two round trip time handshake also abbreviated as 2 rtt with that in mind let me show you the TLs 1.3 handshake so you can see how it compares so first again here on the left we're going to have the TLs 0.2 handshake notice four messages and the handshake completes in this illustration anything that shows up below the purple line and in the gray glowy is meant to indicate that that record is encrypted so with that in mind let's show you the first message of the TLs 0.3 handshake you'll notice it starts off very similar to the TLs 1.2 handshake with a client hello and from there pretty much everything else is different the server is then going to send a server hello followed by four encrypted records following that the server is actually eligible to start sending encrypted application data right away you're not going to see this very often because typically we use TLS for https communication and the client still hasn't made a request for a particular web page so it's not like at this point that the server knows what web page is being requested but the option does exist that the server can start sending encrypted application data right here in any case the client would then send the client finished record and again this is also set encrypted notice it's below the purple line and finally the client can start sending application data at this point in total the TLs 0.3 handshake only requires a single round trip notice application data can be sent after this first round trip completes now also notice that most of the TLs 1.3 handshake is encrypted we'll talk more about this in a moment for now I want to continue talking about the round trips if you're anything like me when you first saw this you saw four messages for a 200.2 or two round trips and three messages for one round trip and you thought wait a minute that doesn't really add up well it makes more sense if you look at the handshake within the context of everything else that happens when you're loading a web page so let's go ahead and do that here you have a typical series of events which occurs for you to load a webpage first thing that happens is a DNS request where you resolve a domain name to an IP address then you initiate a TCP three-way handshake to that web server to start a TCP session so this would be your sin your sin act and then your ack once you've done that you can start your TLS session and notice here we have four messages and it's a TLS 1.2 handshake and finally after that you can make your first request asking for a particular web page from which the server will then provide that webpage in web performance testing this is referred to as the time to First byte and as you can see in this illustration for a TLS 1.2 handshake it requires at least five round trips before you get that first byte of actual data now this is actually pretty important so I want to actually count out each of the round trips so you fully understand what I'm talking about first round trip happens with this DNS exchange where the DNS request and the DNS response is made the second round trip happens right here in the first part of the TCP handshake now for this third request both of these items are going to be sent by the client which means there really isn't any delay that happens in between them they're literally sent nanoseconds apart so the third round trip is right here it includes the rest of the TCP three-way handshake and the first part of the TLs 1.2 handshake finally the fourth round trip is right here and then the fifth round trip is right here and this is where we get five round trips for a typical web browsing session when using TLS 1.2 so now let me show you what it looks like if we are using TLS 1.3 so again TLS 1.3 is three messages and from there you would then ask for your HTTP webpage and if we count out all the round trips we would get the first right here for DNS the second right here for the first part of TCP the third right here for the last part of TCP and the first part of the TLs 1.3 handshake and finally again since both of these are sent by the client there is no delay in between they're literally sent nanoseconds apart and so the final fourth round trip happens right here this is where they get that the time to First Bite in TLS 1.3 is going to be 4. and this is how they can count that the TLs 1.2 handshake only requires a single round trip notice it dropped the time to first fight from five round trips in TLS 1.2 in prior to four so as you can see almost immediately after deciding to use 200.3 you just experienced a 20 increase in the speed or decrease in the time to first bike which is a great win for web performance testing so that takes care of talking about TLS 1.3 and the one round trip handshake and again the main difference is that TLS 1.2 in Prior require two round trips before a handshake could complete and TLS 1.3 can do it in one but can we do any better well yes we can TLS 4.3 also allows a way to do a handshake that only requires zero route trips and the way that works is the client can actually send encrypted application data with the client low in the first message to a TLS web server this reduces how much time before the first byte is sent to immediately hence zero route trips now doing this is called sending early data and that's meant in the context of sending data earlier than you would send your normal application data and I do need to point out that sending early data does have some security implications we're going to cover this in more details in the dedicated lesson on this early data zero round trip handshake for now just know that this is a feature and that all TLS 1.3 handshakes reduce the round trip time required from two to one which now brings us to the second major idea that I want to talk about in the TLs 1.3 handshake this is actually something we pointed out a moment ago notice that most of the TLs 1.3 handshake is actually sent encrypted in fact the only things that are not encrypted is the client hello and the sir hello every other record in the TL 2.3 is sent encrypted on The Wire this paves the way for cool new features like esni and ech which stands for encrypted Sni or server name indication an encrypted client hello both of these are only possible in a TLS 3.3 handshake so let's talk about it recall that Sni was when a client includes a server name extension in the client low and inside that extension the client is providing the domain name that the client is requesting this allows a server that is hosting multiple websites each with their own certificate to know which certificate should be sent back to the client now Sni is something that existed in TLS 1.2 so so far nothing is new what's new was the idea of doing this encrypted imagine if we could send that Sni header encrypted within the client low this would create a situation where if you're studying the packets on the wire you don't know what website is being requested it's a win for privacy and private browsing now why didn't we think about this in TLS 1.2 well recall that in TLS 1.2 the certificate was sent in clear text which meant even if we did encrypt the Sni header someone could just look at the server certificate as it comes back across the wire to see what website the client is browsing to so the whole concept of doing encrypted Sni really only makes sense in a world where we're also encrypting the certificate which TLS 1.3 does this is one of the new features that could be added to tls13 in the future moreover if we're encrypting something within the client hello why not go one step further and simply encrypt the entire client hello that's the idea behind ech or encrypted client below we could get to a world where the entire TLS handshake is sent encrypted which means anybody eavesdropping on the wire has no idea what is actually being exchanged within the handshake and what is being requested and what extensions and anything like that that would be a huge win for privacy the issue however is that these things are not quite so easy to implement you sort of run into a chicken or the egg bro in order to encrypt something you need session keys and in order to get session Keys you need to do a TLS handshake so you run into this problem with how do we have session keys at the beginning before we actually do a TL of tangent now some creative ideas have been thrown out something like maybe we can hide some asymmetric keys in DNS such that we can use DNS to initiate key exchange and use those to encrypt the client low or the Sni header but nothing has been formalized as a standard neither of these have actually made it into TLS 1.3 the main idea of bringing them up in this lesson is simply to tell you they are only features that are possible in a TLS 1.3 handshake likely they'll figure out some way of implementing these in the future but at the moment I just wanted to introduce to you to the idea not necessarily tell you how they work since at this point that hasn't actually been decided one way or another this is the second item that I want to discuss insofar as changes the TLs point three related to the handshake which now brings us to the third which is somewhat related the third idea that I want to discuss with the TLs 1.3 handshake has to do with mutual Authentication recall that in TLS typically only the server is authenticated which means only the server is sending a certificate but there is a way to do a TLS handshake such that both the client and the server are both sending a certificate that's what's called Mutual Authentication this existed in TLS 1.2 and it also exists in TL 0.3 in order to do Mutual authentication in TLS 1.3 the server is also going to send a Certificate request record along with the server hello and that's going to prompt the client to send their certificate along with a certificate verify record in their next message the difference with TLS 1.3 is notice the client certificate is always sent encrypted this didn't exist in TLS 1.2 in TLS 1.2 the client certificate was sent clear text in a mutual authentication handshake now you might be thinking to yourself wait a minute a certificate is meant to be public domain it's meant to be something you can share freely which means it's fine to send in clear text and that's mostly true but compare that to a server certificate remember that a server certificate belongs to a website that is meant to be accessed by the entire world whereas a client certificate typically identifies a individual user or potentially an individual device which means a client certificate is typically going to include information that is somewhat more sensitive things like a person's name or a device ID or an email address or a username things that you might not want seen if you can spare it therefore when they created TLS 4.3 one of the main goals they had was to ensure that anytime you're doing Mutual authentication the client certificate is always encrypted they in fact went a step further than that encrypted both Decline and server certificate but one way or another I did want to specifically call out that when doing Mutual authentication another win of TLS 0.3 that the client certificate is also encrypted that takes care of the third major item that I want to discuss in this lesson the fourth major idea that I want to discuss in this lesson as it relates to the TLs handshake is that TLS 1.3 is going to generate many more session Keys than TLS 1.2 and prior recall that TL 2.2 in Prior is going to create four session keys this is the slide that I used to show you that back in module 6. so if any of this is unfamiliar I'd recommend reviewing that lesson these values were combined to create the master secret and the master secret was combined with these values to create these four session keys now if you want to count these IVs these initialization vectors as other session Keys that's totally fine you can take this to mean that teals when we two and prior creates six session Keys you'll see why in a moment whether it's four or six it won't really matter either way we have TLS 1.2 here are the four main session keys that are created a client encryption key a client hmac key which is used to secure everything being sent from the client to the server and then a server encryption and server hmac key which is used to secure everything sent from the server back to the client in TLS 1.3 however 11 total session keys are created or more depending upon how you count them plus 0.3 creates a new set of session keys for each potential use of that key meaning you'll have some set of keys that are going to be used to encrypt portions of the handshake a different set of keys that are going to be used to encrypt application data yet another set of keys in case we're doing early data and a zero round trip handshake and yet another set of keys simply to save in case we're going to do session resumption at some point in the future notice with TL 7.3 every place in the handshake where you might need a set of keys a new key is generated specifically for that use that's different from TLS 1.2 and prior which only creates these four keys or six and simply uses those throughout the handshake moreover with the TLs 0.3 session Keys better cryptographic separation exists between every set of key which means if something were to happen to compromise that key it in no way is going to change or restrict or reduce the security of this key same thing with this key and this key the keys are created in such a way with perfect cryptographic separation remember how a moment ago I told you however you count the keys in TL's point two whether it's four or six it doesn't really matter that's because tios.2 doesn't actually create four or six Keys TLS 1.2 and prior creates one super long key and then breaks that up into four or six different sub Keys meaning one long string of ones and zeros are the result of the TLs 1.2 key generation and that long key is then broken up into the four or six types of keys that you need but each of these each of these four different values are all pulled from the same Long Key so in a way you could interpret the tls2 handshake to only create one super Long Key that's different with tlc3 where the handshake and the key generation sequence has been formalized and streamlined to create many different keys with perfect cryptographic separation now that key generation process in TLS 0.3 is referred to as the E schedule and we'll have dedicated lessons exploring that in more details later in the course for now just understand that one of the differences that TL 2.3 brings about is that it's going to generate many more session Keys than TLS 1.2 and prior so that takes care of talking through the four significant differences with TLS 1.3 as they relate to the TLs handshake the main takeaways from this lesson are understanding the four items we discussed and how each of them contribute to either improving the Simplicity or security or both of TLS 1.3 in the next lesson we're going to continue talking about the differences with TLS and 0.3 focusing on the differences related to session renegotiation but that's it for this lesson I hope you enjoyed this video thank you for watching and we'll see you in the next one hey YouTube If you enjoyed that lesson then you'll also enjoy the full course that it came from practical TLS it's a deep dive into SSL and TLS taught methodically and intentionally full of easy illustrations and in the simplest way possible you'll get to learn cryptography certificates private Keys the handshake open a cell and everything you need to become an SL expert to learn more check out pracnet.net TLS and if you need more convincing that this is the best TLS training course then check out the other free lesson previews on YouTube thank you and have a great day [Music] thank you [Music]

Channel: Practical Networking

Views: 14,009

Keywords: tls 1.3, tls protocol, tls handshake, tls 1.3 handshake explained, tls 1.3 vs 1.2, tls 1.3 key exchange, tls 1.3 handshake wireshark, tls 1.3 handshake, tls 1.3 deep dive, tls 1.3 wireshark, tls 1.3 encryption, tls 1.3 decryption, transport layer security, 1.3 handshake, tls1.3, tls handshake 1.3, 0rtt, 1rtt, 2rtt, encrypted client hello, ech, encrypted sni, esni, encrypted server name indication, mtls, mutual authentication, ssl, ssl deep dive, tls deep dive

Id: JA0vaIb4158

Length: 17min 38sec (1058 seconds)

Published: Thu Jun 15 2023