TLS 1.3 Handshake

[Music] hey everybody john wagon here with dev central and we're coming to you with another light board lesson video today we're going to talk about the TLS handshake and we've actually done some other TLS handshake videos but the new version the new protocol TLS 1.3 was just released and the handshake actually changed quite a bit with this new version of TLS so specifically today we're going to talk about the TLS 1.3 handshake if you'll if you remember back to the old version or older versions of the TLS handshake you have to have a client on one end who is trying to establish secure communications with the server over here and the thing that starts off the whole handshake and this is still true in TLS 1.3 is the client sends a hello message to the server and I'm just going to put a little arrow over there and previously the client hello was sent and you would have some supporting cipher suites and a few other little details maybe some extensions that kind of thing and then the server would say okay hey I know what a cipher suites are wanting to or that you can support but the server always gets to choose the cipher suite and then that would send a server hello and it would send its certificate and then there was be some key exchange information going on there there was this changed cypher spec message that would go back and forth and then finally it would come down to a finished message on the client side a finished message on the server side and then the application data that is encrypted would be able to kind of flow after that so the the bottom line is with like TLS 1.1 or TLS 1.2 there were all those different steps involved in the handshake before you finally got to encrypted application data in TLS 1.3 the entire idea is let's make this as short as we possibly can and get to that application data as quickly as we possibly can and we do that in order to save time because people that are out there on the internet when they click you know go to this their favorite website then they want to be on the website you know and if they've gotta wait for all this exchange to happen and this handshake to happen before they can you know get to their data get the page to load then they're not happy we we don't want unhappy internet customers right so we want to shorten this handshake all right so what happens with TLS 1.3 the client sends a hello message and then I'm gonna say supported supported ciphers supported ciphers that the client supports which is not a new thing it did that in the past and then I'm also going to say key agreements as is one term that they've put in now so supported ciphers and key agreements that it sends over to the server and then here's the cool thing that it does kind of preemptively if you will and that is a key share key share and one thing that I mentioned quickly is in TLS 1.3 perfect forward secrecy is mandated so you have to use perfect forward you know capable cipher suites and with that you have this key exchange mechanism that goes back and forth just to give you a example back in the older versions of TLS you can use RSA for key exchange but that does not support perfect forward secrecy so you cannot use RSA for key exchange stuff so with that basically what the client is going to say is hello these difference ciphers is that it supports and then it's going to go ahead and calculate a key share and essentially what it's doing is it's it's is it saying hey server I think I know what cipher suites that you're going to choose based on my list of supported cipher suites and I'm gonna say I'm gonna say more more than one over here on the key share and what it can do is it can say hey what I can do is actually calculate preemptively calculate what would be the shared key or for the key exchange purposes of this handshake I'm going to go ahead and preemptively calculate multiple versions of a key share based on all the different ciphers that I saw and I'm gonna send those over preemptively again with the hello message to the server the idea is that if the server is to was to pick any of these ciphers that I supported it would already have the key share that it needs in order to generate the symmetric key that you're trying to get down to ultimately anyway alright so the it's going to preemptively calculate the key share it's going to send all that stuff over to the server so now the server has all this information so the server is gonna say hello back all right and it's gonna say the chosen cipher suite because it still gets to make the choice chosen cipher suite so hello chosen cipher suite and then it's going to have and it's going to generate a key share as well and that's used again in the key exchange algorithms that are that are you know used between client-server so as long as it chooses a cipher suite based on one of the ones that the client sent over then this key share that this client sent is going to be able to be used by the server with its own key share to generate the symmetric key that's needed for the encryption if and as long as that happens then it's good to go so it's gonna send all of this stuff back over to the client and now the client would then have the key share from the server and it can also generate the symmetric key and so at that point both of them have the symmetric key that they need and there's only been really one round trip and this whole thing once the server does all this stuff then it can also send a signed certificate signed cert and it uses the server certificate for authentication to make sure that the client knows that hey this is the actual server that you're looking for and I'm going to put a little lock next to that thing because because it has the key share from the client and of course it's generated its own key share and then and then that's all it needs in order to have the symmetric key then it can go ahead and encrypt this with the symmetric encryption key and then it's going to send its finished message finished message and that is also encrypted so all of this stuff gets sent back to the client all right then the client has all this stuff and as soon as the client gets the key share from the server along with its own key share it can do all the crazy cool mathematics to generate the symmetric key and because it has the encrypted signed certificate and the finished message from the server it can then decrypt that with the sign or with the symmetric key and so then it's got everything it needs and so now it's ready to go ahead and say finished over here on its side and then it can go ahead and send its first HTTP GET message or whatever it needs and send it back over so with one you know with one trip from client to server with all this information and then another trip from server back here then you're ready to go ahead and start sending HTTP data and of course over here you know this is the HTTP answer you know from from whatever the server how are the server needs to answer that get requests of course all right so that is the very abbreviated version of the handshake now that we're in TLS 1.3 a couple of quick notes that I would make like I said preemptively what the client does is it generates the key share before it sends it to the server well what if the server does not choose one of the supported ciphers at the clients sent if that happens then the server sends what's called a hello retry request back to the client and it sends its key share calculated key share back to the client as well basically saying hey client let's try this again why don't you send me a cipher that I actually support and oh by the way here's the key share that I'm going to use based on the decipher that I've chosen so a hello retry request and if there are absolutely no common cipher parameters or cipher suites that they can ever agree on then the server based on the new protocol the server must abort the connection and then send a send an alert message back to the client saying hey this connection has been aborted and basically it's because we can't we cannot find common ground on our on our supported ciphers all right so this is a this is a it's a very good step in terms of you know efficiency and speed with respect to the TLS handshake in version 1.3 so it's good to know how how this thing happens and how it's different from the previous version so thanks for watching this light board lesson video with us today hey if you like this then you can click right here on the DC ball and subscribe to our YouTube channel and we will see you guys out there in the community you

Channel: F5 DevCentral

Views: 23,409

Rating: 4.8486056 out of 5

Keywords: f5, devcentral, tls, tls 1.3, encryption, ssl, handshake, protocol, network, computer

Id: yPdJVvSyMqk

Length: 9min 20sec (560 seconds)

Published: Mon Jun 04 2018