Explaining TLS 1.3

[Music] hey everybody John wagged on here with dev central and we are bringing you another light board lesson video today we're gonna talk about TLS 1.3 this is the protocol that's used between client and server in encrypted communication on the Internet today so before we get into the specifics of TLS 1.3 I wanted to highlight a report that was just released by our awesome f5 labs security research team they do all kinds of great security research threat analysis that kind of stuff and they wrote this report it's called the 2017 TLS telemetry report and it goes on it goes over a ton of different security related stuff but it's of course centered around TLS and and it gives you statistics on things like you know what versions of tls/ssl are out there in the wild today I'll give you a little a little teaser from the report and I'll link to it by the way but did you know that like 11 percent of hosts out there in the Internet today still use SSL version 3.0 which in today's day and age this is 2018 that is like ancient history that is crazy outdated insecure stuff in fact it's even prohibited by the IETF as to cell 3.0 but 11 percent of you people out there still using it things like TLS 1.2 which is the latest before TLS 1.3 of course 89% of hosts use TLS 1.2 81% of communications across the internet today are encrypted with HTTPS with SSL TLS with something all right so it's it's things like that it's a fascinating report it shows you all kinds of different stuff so get out there and check that out in light of that we wanted to talk about this new version TLS 1.3 TLS 1.2 s going on for a long time and there is a kind of a philosophical debate if you will about whether TLS 1 - is even broken enough to need to be replaced or not but nonetheless the organization the IETF the internet engineering task force who governs all this stuff released or just just recently approved TLS 1.3 all right so again the TLS protocol is a protocol in it and it defines the the way that the client and server on the internet communicate so I'm gonna draw just a very quick representation of the TLS handshake up here and then we'll use that to kind of talk a little bit today so you have you have client over here and then you have server over here and then you have what is considered or what is called the TLS handshake and that is the way that the client and the server exchange encryption keys to be able to ultimately encrypt all their communication and make it secure so the client sends a message to the server this is a hello message and then the server responds with stuff this is a very simplified version but basically the server responds with a hello you know plus a lot of stuff and then ultimately you arrive down here at what we'll call application data and I'm going to put a little lock on that because that stuff once you go through this little key exchange and cipher you know coordination and agreement and all that stuff then ultimately you land down here with encrypted application data between client server okay so one of the critical or the I guess I should say there are a couple of critical things to talk about with respect to TLS 1.3 and I'm gonna break them into two kind of primary categories and these are the things that TLS 1.3 brings to us that maybe TLS 1.2 or even previous versions did not have and the two major categories that I'll that I'll list up here our performance and security so here's performance and then security all right on the performance side as the ietf went through you know hey if we're gonna we're gonna create this new protocol this TLS 1.3 it better be better than the old protocol of course and one of the things that they talked about was this performance issue and we'll go back here quickly to client server whenever the client sends encryption information or key information or cipher and all that kind of stuff over to the server and then the server sends back they've got a chunk through all this stuff and they got a they got to calculate encryption keys and it just it gets kind of clunky and and computationally expensive as it were and so the ITF said hey we need to we need to make sure that that's as fast as we can possibly make it for especially in today's day and age for things like mobile phone experiences I mean every one of us it seems like has a mobile phone and to ask our little you know mobile phone to do all these complex calculations gets a little crazy sometimes so so with that in mind what they wanted to do is have a shorter and I'm just gonna put this up up here shorter handshake all right so what used to be a fairly sophisticated back and forth between the client and the server client hello it offers up cipher suites the server would send back a certificate you know and say this is the cipher suite that I you know agreed to and then each of them have to calculate the keys and then they send these chained Seif respect messages back and forth and then they have to encrypt certain things and then they finally land down here to application data but it was it was a bunch of back-and-forth now there is a much shorter handshake that happens it's basically the client says hey hello server sends some bits and pieces of information the server gets that sends all of the pieces of information it needs to send and then they just start encrypting stuff so it's a much quicker flow through the handshake process alright so shorter handshake the other one that I'll put up here is I'm going to put a zero and then R T T that's a zero round-trip time and that actually goes back to the shorter handshake and this is in a session result chin situation so imagine if a client has already established communications with a server they've already established a session they've already got this session key and it's in minutes encrypted and the communication is encrypted all that stuff let's say for example that client does what it needs to do on that web server and then it's you know the session is now no longer valid then if that client comes back to the server and says hey you know I was shopping on your website or whatever now not shopping for a minute now I'm coming back I want to shop again kind of thing so so now it needs to establish another secure communication with that server the idea behind zero round-trip time is that the client could say hey server do you remember me I was here a little while ago we did this whole shopping experience and I gave you the encryption capability or the cryptic keys aren't stuff why don't we reuse some of that stuff and and let's make this whole you know an encryption handshake thing go much much faster than it would need it would have needed to in previous versions of TLS so basically the client can say server hello I'm gonna send you some little bits of information that you might need to resume the session that we had before and then I'm gonna go ahead and send like my first get request or my first bit of hey let me access your website and and then the server when it gets that it can say oh yeah I remember that guy I remember that client so let me just let me calculate the encryption keys that would need to be calculated and let me respond to the get request and let's just go ahead and start doing this thing so basically there's not even a complete round-trip that needs to happen so the client can send some of its application requests with its initial hello as it were in this session resumption all right the the bottom line on all this is that the the the handshaking between the client and the server is significantly reduced now so what that equates to then if you're a mobile user or if you have a desktop or laptop whatever then when you go to access a web page the webpage is going to respond much quicker than it used to if it did not use TLS 1.3 so theoretically as we move forward and as more and more web servers and more more clients adopt TLS 1.3 then then you will start to see faster response times on web pages which everybody loves that right one interesting thing about the zero round-trip time that I will mention though is it is susceptible to what we call a replay attack and that is if you have a man in the middle or a attacker bad guy that can actually grab some of the client information and hold on to that then as then then that attacker could impersonate the client and say hey server here's another get request or here's another request to your web application then the server theoretically could then respond back to that what would be an attacker replaying that client request and then you know and it could it could serve up the webpage that would have been requests we requested that's you know for some examples that's maybe not such a big deal if you're transferring data or I'm sorry not transferring data if you're transferring money from your bank account or if you're deleting a database entry or your I mean you can you can imagine that could be a problem of course so the ITF actually addresses this in the in the write-up of the RFC 40l s 1.3 and they essentially say that it's up to the server ultimately to be configured properly to deal with this problem so server if you get a replay attack you need to be configured properly in order to handle that properly so if you're a server a web server administrator or you you're a web developer or that kind of thing then design your web applications in such a way that you are not susceptible to replay attacks that's what the ITF would tell you that's what they are going to tell you and have told you in this write-up okay so performance increased with TLS 1.3 from a security perspective there are several things to note I'm gonna put old old ciphers goodness that's not good penmanship ciphers removed all right and so basically anything that they considered they being the ITF considered legacy or ciphers that have been problematic and you know from a historical perspective that have been susceptible to attacks or that kind of thing those have been removed too now of course favor newer cipher sets and cipher strings that are stronger and not susceptible to attacks with that there's this thing called a e a D ciphers and every cipher set now that's approved for TLS one not three is a EA D ciphers stay tuned by the way we're gonna do another light board on a EAB ciphers like what does that even mean what are those things so we'll give you a little teaser there stay tuned we'll do one of those there is also messages are encrypted after the server hello comes back from the server everything after that so I'm going to put I'm gonna put server hello plus encrypted encrypted all right so basically what I'm saying there is everything after the server hello is encrypted in the TLS handshake like I said there's a bunch of stuff here that I did not include key exchange information and some of that kind of stuff that used to not have to be encrypted now it is going to be encrypted if as as you use TLS 1.3 all right there is a there is a version I'll say version negotiation version negotiation and basically what this and actually I'm going to put reverse negotiation removed what you used to be able to do is negotiate what version of TLS or SSL that you wanted to use between client server so you know hey client says hey server here's my cipher suites that I want to offer up I'm saying hello I want to use TLS version 1.2 or 1.1 or whatever it is and so you would have this this method of negotiating what version of TLS that you would want to use what this opened up though is a susceptibility to a doubt what we call a downgrade attack if you guys remember the the poodle attack that's basically what this would do it would say hey I am gonna step in me being attacker bag now I'm gonna step in and force the server to downgrade to SSL 3.0 which by the way if you listened earlier eleven percent of you people are still using that based on our TLS telemetry report so for eleven percent of you we don't even have to make you downgrade but nonetheless it's an attack where you would say hey server let's downgrade to a lower or more vulnerable version of SSL and then the server would do that and then that would open up a lot of possibilities then for the attacker to you know attack and hack into your system and just all that kind of stuff all right so with version negotiation removed now then then there is it basically makes that a more secure interaction between client and server so so anyway so that is also out and then the final thing that I put up here it's three big letters PFS perfect forward secrecy is what that is we have a lightboard on that as well this is probably one of the most important things of TLS 1.3 and that is that perfect forward secrecy now is required for this whole handshake thing which basically means that that like the RSA version of key exchange that whole thing is not going to be able to be used anymore one of the significance byproducts of that is whenever you used to use RSA or or obviously a lot of people still do it today but in an RSA implementation you would have a private key on the server and then you have a public key that the server would would serve out of course but that private key would stay static and what that allowed you to do is you could say hey if I've got you know clients coming into my web application and I want to send them to like a data loss prevention you know mechanism or maybe I want to send them to intrusion detection or intrusion prevention you know mechanism to kind of check things out before they ever get to my web application then you could share you could still encrypt that entire thing between client and server but you could share your private key from your server out to those trusted places like an IPS or IDs or whatever and then that that's that service or that you know that feature could take the encrypted client data it could decrypt it with the private key it could check it all out if everything's good it sends it on back to your web application well now with perfect forward secrecy you cannot do that you cannot share the private key out with all these different people because there is a there is a new and unique private key for every single session between client and servers so we at we actually have a lightboard on perfect forward secrecy so we can link to that as well but you need to understand that that that this creates a very interesting problem that we collectively are going to need to just start to figure out and solve so so anyway so that is one of the key elements of TLS 1.3 perfect for word ciphers are required now all right so that's a few things on TLS 1.3 it's it's an exciting thing I mean it's got some really cool new features to it like I said from a performance standpoint from a security standpoint we are making steps forward but it's it's got some things that we need to be aware of like perfect forwards secret ciphers are are going to be required now so all right so whether whether you like it or not honestly this is the way that the world is moving and clients are going to start to adopt TLS 1.3 you know from a browser perspective and web servers are going to start to adopt this as well so this is the way the world is moving let's understand it let's get on board with it and and then some of those issues that we need to work out let's let's get creative and and let's let's pull our heads together and figure those out as well so thanks for hanging out with us today to watch this light board lesson video on TLS 1.3 hey if you like this you can click on the DC ball here and subscribe to our YouTube channel and we will see you guys out there in the community you

Channel: F5 DevCentral

Views: 49,180

Keywords: f5, devcentral, tls, ssl, security, 1.3, handshake, cipher, 0-RTT, PFS

Id: VzWqnT5dErI

Length: 17min 59sec (1079 seconds)

Published: Tue May 08 2018