17: Visualizing and Decrypting TLS 1.3 | Learn Wireshark @ SF22US

uh this is visualizing tls encryption uh one of the reasons that i did this uh session uh is because um when uh when uh uh i started off i actually have a structural engineering degree so i went to school to learn how to keep buildings standing up and uh but that was at a time in the mid 90s when i graduated when computers were making their way into business uh i was always a techie from the time i was a little kid and uh always just playing around with the computers in fact even in college we didn't really have computer labs for the structural engineers that was really designated for only uh computer engineering electrical engineering students but i still was on their vacs playing around on the internet or what the internet was at the time and um so it was always fascinating to me and uh as i moved into it what i realized was was most the documentation that was out there for learning about protocols and how the stuff worked was really designed for and written by engineers who had advanced degrees so oftentimes when you read documentation from somebody written some of their rights with a master's degree they're using a language that is oftentimes beyond what a non-or slightly less non-technical person can handle so um as i move through my career i struggled with all the documentation and just had to hack away at it stuff until i learned it uh in the last couple years i really wanted to learn more about tls and how encryption works and if you go online and you try to learn about it uh just by using google searches what you'll find typically is one of two possibilities you're either going to get the master's degree thesis of how it works with all the challenging language or you're going to get somebody who doesn't know anything about encryption who's going to tell you that the uh the private key encrypts the data and the public key decrypts it or vice versa which isn't entirely untrue but it's not how tls and and website encryption work so my goal was to make this more accessible and so that everybody can walk away from this with some idea of how the encryption is working so that we understand uh what exactly uh is happening with tls we can learn how to decrypt it understand the handshake and and whatnot and have a much much better opportunity of really knowing what's happening here without having to understand uh enormous words or challenging math so visualizing tls encryption here before we get into the session topics a little bit more about me right now i've in the past 20 years i've worked as both an i.t engineer network engineer and also a technical trainer so i've worked at a few two-year colleges teaching students how networking works getting them jobs literally pulling them out of the gutter sometimes and and getting them some really great jobs it's been a really rewarding experience the last five years of my life i've spent creating videos training videos for ccna netplus and wireshark and some other stuff for pluralsight and pluralsight if you don't know they are an ite training company mainly for developers but we have a massive it operations library as well uh if anybody's interested in checking it out i have i can offer you a 30-day trial of that service there's no no need to put any credit cards in or anything like that no obligations if you're not interested no big deal uh just uh shoot me an email or talk to me after the session so the topics for this session then we're gonna look at uh ssl versus tls uh if you look on line two there's all kinds of crazy stories about the differences between these two so we'll talk about the history of tls and ssl uh we'll look at uh what encrypting data is like i think generally most of us have a understanding of this we're gonna look at encrypting data and what's needed for this to happen we'll look at a diffie-hellman key exchange uh and we'll see how that is actually a super accessible um way to understand the key exchange process we'll look at some data encryption protocols that we use and then we will do some decrypting of tls right in wireshark i posted this link in the chat for the in the discord chat for this room uh this has all of the this is all the info we you would need for this uh it has the link there of course uh my twitter and email address uh my work at pluralsight here i have a couple links that um that are extremely useful in understanding tls [Music] michael driscoll made these these links and it's an illustrated tls uh 1.2 and 1.3 and he goes through the entire process of how the this works goes down right down to the to the bits and tells you every little detail about it so you can really drill down in this and and spend a lot of time on on this i think i've spent quite a few hours working through this um over the years and then the captures for the presentation are also in that one note i'll try to get the slides up there i'm not sure that i have permission to post the slides yet or not i have to ask pluralsight because it uses a lot of their assets all right so web browser encryption uh what's going on here so when we talk about web browser encryption and we want to encrypt the data that we're sending back and forth between the client and the server we really have two components to this one component is that we need to negotiate the encrypted session right so we need some protocol to negotiate between the client and the server to figure out what protocols we're going to use and how we're going to set up that encryption the second component is is the encryption protocols themselves right so to negotiate the encrypted session we can use ssl or tls to encrypt our data we need uh two of these six protocols so we can use rsa diffie-hellman elliptical curve diffie-hellman triple des aes and cha-cha 20. we're going to talk about all of this as we move through the presentation so history here history lesson so 1994 netscape navigator came out this is a this is part of uh this is the commercial end of a project that came out of university of illinois champaign urbana uh in 94 right when http came out and this was the first web browser available commercially it cost money to buy it so you had to pay netscape money to download this maybe not as an end user but definitely as a business user you had to pay money for this application just like you would any other application at the time whether it be word perfect or quattro pro i think word and excel were around then just not as popular so you had to pay for this and get a license to use it and as netscape quickly found out businesses really wanted to take advantage of this technology and but in order to do that they needed some type of encryption so netscape engineers came up with ssl version 2 which was very very quickly determined to be easily crackable so you could you could go get through the protocol and decrypt the data so just a year later they came out with ssl version three and it wasn't that long ago that probably a matter of three four years ago where companies were actually still using ssl version three which was a bad idea but uh it's been around for a long time all right so uh with with netscape navigator coming out what also came out in 1995 that was significant in the world of i.t well well what operating system in 1994 would you install netscape navigator on in 94 though windows 3.1 anybody use windows 3.1 right so windows 3.1 thank you um you'd install this on windows 3.1 well 95 windows 95 came out of course in 1995 and uh what came bundled with windows 95 internet explorer and you didn't have to pay for internet explorer it came right along with the operating system so uh it was microsoft's goal to get rid of netscape navigator by uh giving away internet explorer for free uh and this was the start of the browser wars of course and does anybody know this this movie yeah uh yeah war games yes uh shall we play a game uh and uh so 95 started the browser wars microsoft really wanted to put netscape out of business and they pretty much succeeded which brings us to the name so microsoft internet explorer came with encryption in ssl version three but by 1999 the the browser wars were were pretty much over by then microsoft had most of the share of the market and uh they wanted to make an rfc specifically for web encryption microsoft did not want ssl as the name because that was netscape's name for it so microsoft pushed and with the rfc they changed the name to tls so tls 1.0 and ssl version 3.0 are about the same protocol there's very slight differences between the two so what's the difference between ssl and tls literally nothing it's the same protocol with a new name um as time has passed now we are up to versions tls 1.2 and 1.3 most of the transactions you see on the internet today are going to be tls 1.3 we should hope that they're 1.3 it's a super efficient version of the encryption compared to 1.2 and we're going to see that later on when i go through the packet capture we'll see the the difference in how much more efficient tls 1.3 is during the handshake process than 1.2 plus we can encrypt the data lots faster with tls 1.3 so let's talk about data encryption basics here so we want to send a message from the client from an https client to an https server so what we need to do is we need to take that message we're going to run it through some encryption algorithm typically a symmetric key algorithm where both this client and the server are going to use the same key and the same algorithm to encrypt it so we run it through an algorithm along with a secret key that we create or that is created it encrypts the message we can then send that message across the wire across the public internet to our server server can then reverse the process by taking the same algorithm same key and decrypting the message and now we're left with the original message on the server that the client sent before it was decrypted the challenge here is that we need a key that's exactly the same on both sides so the client and the server need the identical key to do this but we cannot send that key across the public internet or users on the internet will be able to grab the key and decrypt the traffic making our encryption useless so we need some kind of protocol then to exchange the key we just can't send the key across the wire and that's where a key exchange protocol comes in so before we can do data encryption we have to negotiate a key between the client and the server so one of the ways we can do that is with a protocol called diffie-hellman so diffie-hellman and there's one other gentleman that i don't remember his name diffie-hellman actually came up with the same idea that somebody else had come up with several years earlier uh diffie-hellman uh got credit for it even though somebody else actually had uh had developed most of this technology but this is pretty cool mathematics this isn't an i.t thing this is just mathematics and cryptography so here's how it works when we're doing uh tls encryption uh one of the parts of the process is that we send a certificate from the server to the client a certificate serves multiple purposes and in the case of a diffie-hellman key exchange there are two prime numbers inside of the certificate that are useful that become our public key and that's the value p and g so here i've just chosen two small values for png 149 and 17 just to make this process easy and accessible in reality these prime numbers are much much larger so we send the certificate across the client the client will look at the certificate pull out the p and g value that is the public key everybody can know about those values client is then going to choose a private key i picked eight client key the client private key is going to be much much larger than this but again we're keeping the math simple and then what we do is we do some mathematics right so we take our g value we raise it to the power of our private key and then mod p yesterday gerald talked about the modulo mod here is modulus modulo it's it's just calculating the remainder so if you don't remember this from uh grade school well i'll remind you here so we have 95 divided by eight right so we we do the math here 8 goes into 9 one time that leaves a remainder of 15 8 goes into 15 one time again and we can keep doing this calculation to calculate our decimal points here but really we're not after that what we're after is the remainder and uh that seven sore modulus is seven so in in this modulus math all we're doing is just calculating the remainder of some um of this this formula here so g to the uh g to the power of a that's 17 to the power of 8 mod 149 equals 5. and i'm calling this our encrypted key this is a key information that we share publicly then with the server so we do that calculation and then we send that information to the server server does the same thing server picks its own private key i picked six here it's going to run the same formula g to the power of the private key mod p in this case we get 16. so the server then sends 16 back to the client now what we do is we run the same formula again this time though we take our encrypted key that we've exchanged with each other we raise it to the power of our private key mod p and on the client side we get 129. on the server side we get 129. so our key becomes 129. 129 was never shared between the client and the server the only way to get 129 is to have a private key of eight on the client side and a private key of six on the server side so if you can guess those numbers out on the public internet you can figure out the key but in theory these private keys and in theory these private keys should be large enough in order that you can't guess it however there are issues with uh the way diffie-hellman is implemented that make it somewhat i don't wanna say somewhat easy but make it possible to actually figure out the key uh without knowing the private keys so with that we don't actually use jiffy hellman anymore not this version of it but this version of it in my opinion is a really great way to understand actually how kind of elegantly simple this process is to exchange a key between two parties without having anybody else be able to figure out what it is so for our key exchange then we have different options remember in the beginning i said we have these six protocols and we have to use two of them to make it work well for the key exchange portion of this in tls 1.2 we have three different options we can choose from for our key exchange rsa is one of them rsa rivers shamir edelman they came up with a similar process for that diffie-hellman did back in the late 60s early 70s and uh the process allows for the same key exchange process we don't use it anymore and we don't use it not because the protocol itself is bad but the way it's implemented makes it potent has makes it have a potential to be uh compromised so we don't use rsa to do our key exchange anymore i've already said we don't use jiffy hellmann for the same reason the way that it's implemented in computers makes it somewhat vulnerable to compromise so we don't use jiffy helmet anymore either dippy helmet in and of itself is completely fine it's just the way that it's implemented which leaves us with this new one elliptical curved iffy helmet i'll give you a rundown of how that works shortly in tls 1.3 we don't get to pick you get to use elliptical curved iffy helmet that's it and this will make sense in a little bit so let's talk about elliptical curved iffy helmet so one of the values that we needed in the key exchange process with straight up nippy helmet or rsa is we needed the certificate so we needed that certificate that had our public key in it that we could send from the server to the client and we could not calculate any keys until we got that certificate with elliptical curve we don't need the keys in the certificate at all we can just start the process as a matter of fact the client can start this process so here's how this works the the elliptical curve um i drew uh this is my my drawing of elliptical curve that we're using here uh theoretically it should be something similar to the 1 x25519 curve but it's likely way off anyway there are different predefined curve types that the client and the server can choose from most implementations today on the server side and the client side are going to pick x25519 but there are different curve types here it's just a different slightly different formula to calculate this curve on the graph so when we're doing a tls 1.3 elliptical curve diffie-hellman what's going to happen is the client is going to pick a curve type so in most cases like i said it's going to pick the x25519 the client is also going to choose a private key it's going to pick a large random number private key and what'll happen is through the private key we're going to pick a point on the curve and we're going to do a bunch of iterative math to pick several points on this curve and use those points to come up with a public key so really we're using the curve and some math to calculate a public key one of the links that i have on the on the onenote page is actually for michael driscoll's animated version of how this happens so if you want to really dive deeper into the math of what's happening with this curve he does a really great job of showing several animations and walks you through all the calculations of this i'm i'm just keeping it very simple here so and and i literally made these numbers up these aren't this isn't this is not a real calculation here these are truly made up numbers so what happens then is the client in its very first message the server is going to say here's my public key and this is the curve type i picked if you can use that great if you can't use it the server will reply back with the curve type it can use with a public key but if the server can use the 25519 curve what it'll do is it's going to do the same exact calculation right so it's going to take the curve type plus its private key it's going to come up with its own public key and send that over to the client and now this information looks real similar to what we saw with the straight up diffie-hellman right we have a private key and some public key exchange now we can run the calculation in reverse and we can actually come up with the identical key on both sides so now the client and the server have an identical key that they've calculated on both sides they use that key to derive some application keys and these application keys are the same on both the client and the server and we can actually use those keys to encrypt our data then so that key exchange process is like the critical component to doing a proper tls encryption for web browsers [Music] so once we have the key exchanged now we can use a symmetric key uh encryption protocol so here we have three different ciphers we can use we can use triple des we can use aes or we can use cha cha 20. well triple des is the oldest one that came out of the 70s or 80s it used to just be des encryption and des encryption was somewhat weak i think it had 56 bits in its key so we fixed that by just running it through the algorithm three times to create a 168-bit key and uh triple des actually uh can be used but aes the advanced encryption standard uh was part of a competition that came to find the next generation protocol for uh triple des so aes is the one of the preferred encryption protocols we use for this uh another one is cha cha 20 which came out a few years after aes and both of these are proper secure ways to encrypt data with a key with a symmetric key so in tls we're going to use either aes or cha cha 20 most encryption that you see on the internet's using aes so we have key exchange we have data encryption second to last component of tls encryption here is handshake integrity uh why do we need handshake integrity anybody have an idea yeah man in the middle attack in case in case somebody's listening to our tls conversation we use handshake integrity protocols to make sure that we have some way of checking to see if somebody tampered with the data while it was not either on the client device or the server device so uh what we use for that is we use a hash algorithm either sha-256 or sha-384 and the way that works is we take a we take every single we take a piece of every single component in the handshake and we run it through the secure hash algorithm and it comes up with a number and we put that number in one of our handshake messages we send that message to the client or to the server and then we can do a reverse calculation and find out if those numbers match right so uh the client has all the pieces of the handshake the server has all the pieces of the handshake both the client and the server can run the same exact calculation compare it to the number that's inside of one of the handshake messages if the numbers match great it appears that no one tampered with the message if the numbers don't match it means that either somebody tampered with the message or maybe there's something wrong on the network and bits are getting flipped but generally speaking handshake integrity involves just making sure that the handshake has not been tampered with the last piece of this puzzle is server authenticity now in tls 1.3 i said we don't use the certificate for any encryption so the certificate is only used for server authenticity right so when we talk about certificates the way certificates work is this is wildly basic we have some type of certificate authority you can set up your own certificate authority at home on linux using something like openssh but a certificate authority is typically an agency on the internet that issues valid certificates to servers so that we can validate that that server is who it says it is and the way that's done is uh the root certificate is created at the certificate authority the certificate authority then we'll work with operating system vendors uh and browsers to make sure that that a copy of that root certificate is installed on every single computer that way when uh that way we can validate the certificate so certificate authority then will use the root certificate plus a key to generate an intermediate certificate and then that intermediate certificate will be combined with a key to generate server certificates so the server certificate is chained to the intermediate certificate which is chained to the root certificate the server certificate then gets installed on an https server and one of the components of the handshake and tls is to send the certificate to the client what will happen then is the client will compare that mathematically with the root certificate that's stored on the root certificate store on the workstation if there's a mathematic if the mathematics say yep the certificate came from this root certificate great the server is who it says it is if it's not and there's no match there you're going to get a certificate error on your workstation and it's going to say hey are you sure you want to do this certificate errors can happen in many ways if you build your own web server at home on linux and you just use a default search on there you're definitely definitely going to get a certificate error unless you install the root certificate on your client which which is done often i don't want to go too deep into this because this could be a whole class in and of itself so when we talk about certificates what's in there we can use a server certificate to do rsa encryption but we don't do that anymore we can use uh the certificate p and g values to do diffie-hellman but we don't do that anymore either so what's left we use the certificate for verification information for the certificate chain to make sure our cert is signed and is appropriate so there we go tls encryption four steps key exchange data encryption handshake integrity and then server authenticity so let's go take a look at some captures here so in order to understand what's happening with the handshake we need to be able to decrypt the data in wireshark so oftentimes the decryption of the data in wireshark is not so much to get the data out it's more to understand what's happening and troubleshoot the handshake and other components of uh of that conversation so i'm going to show you how to get the key the encryption key for these both in mac and in windows i forgot that my m1 mac doesn't support standard windows so i can show i don't have wiresharks that have been running correctly on it yet but i can show you how to how to export the keys on it so we'll start with mac here and uh it's actually a pretty simple process let's get wireshark running and uh what i do is we go to a command to get our keys uh we need to issue the command export ssl key log there's too many ls's ssl key log file equals and then we give it a directory so i'm going to put it in here and then a file name i'm just going to call this key key log.key bad assignment there we go and then we do open dash a firefox and start a capture now and uh let's just go to wireshark.org stop the capture so let's find some tls messages here let's do this wow tcp stream so here is our tls 1.3 handshake let's see if we can make that a little bigger cincinnati act for tcp and then we have our client hello and our client hello if we take a look at what's happening here we see key share the key share information it's saying group x25519 and then there's the key that i calculated so that's the public key that we're sending from the client to the server so this is not encrypted data yet this is all uh unencrypted the server replies back and it does the same thing it says yep keyshare x.255 here's the key that's the server sent back to the client now uh everything after this is encrypted so we can't see this information anymore so this is where we go in and uh enter in our key that we captured so what i do is i right click on transport layer security go to protocol preferences open tls preferences and then down here it says premaster secret log file name just browse to documents ssl key log you grab that and now that same packet that i just had selected here now it says encrypted inspect extensions certificate we didn't see that certificate before so here this was encrypted so the certificate and tls 1.3 is actually encrypted now so here's the the exchange of the certificate uh it has uh uh um well at any rate we have the the certificate information here once this is done uh the the client and the server finish up here with this change cypher spec finished and now everything after that is our data and you can actually see the website coming through now http 2. uh we can't actually decrypt this and or we can't actually see what's happening here in wireshark just because uh http 2 uses a stream instead of clear text information but here's the website being transferred then and with the decryption we can actually see all this information uh real time does that make sense uh in windows to get that key log file this is windows 11 and to do this we go to control panel and then system and then about of course it's much easier in windows right advanced system settings environment variables and then in environment variables i realize this is probably tiny for you guys to see in the back but in environment variables here we're going to create a new environment variable under user variables the variable name is ssl key log file well sorry ssl key log file and then we pick a place to put it browse browse directory here we'll just put it on documents and then we'll put it in ssl key log uh what's the question again when you open the web browser so if so on mac or linux when you issue this command export ssl key log file and then you use the same terminal to open up firefox what will happen is firefox will write the key right to the folder right to this file so this these two steps is what's actually writing the writing that key log file to the to that directory that we can use and i can actually show that happening in just a second in windows uh key log uh we just specify the file name in the same way we give it a name in in the directory that we choose hit ok and now when we open up a web browser it's going to write to that file as well if we look here so key this this is the file that i generated on my mac right now the file i called was key i called the file key dot log for windows so if i open up firefox go to wireshark.org what did i do wrong that looks right so once i opened up once i reopened up wireshark after or reopened up firefox after i created the entry now we have this new file in here called key.log so in this cube.log file you can see there's a bunch of hex values in there these are all of our keys for this yes uh this is for either this is for any of anything ssl version ssl version 3 all the way through tls 1.3 it'll work the same to prevent this from happening um yeah no it uh the the pfs so the question was for for those on zoom was um uh that in tls 1.3 there's perfect forward secrecy that is done with the elliptical curve protocol but you can still capture the keys on the local device and use them to decrypt the traffic but the difference is is that in some of the other protocols like diffie-hellman and rsa you can actually predict you can predict i'm i'm talking a little bit out of out of my space here but i believe in rsa the you can when you encrypt the data with a key you get similar output and or you get the same output so you can use that to uh get around that and that's where perfect forward secrecy fails something special happens in in elliptical curve to make this this happen and like i said that's a bit beyond my my scope for this so okay yep yep yeah and it's not just a folder you need to specify a file name so you need to you need to specify the folder and you need to give it a file name i called mine key.log it doesn't matter what the file name is it can be literally anything you want it to be and yeah so here on we'll go back to the mac just because uh uh chrome and firefox will work like this safari i don't believe works and i'm not certain about edge i think if i remember correctly i think edge does work the current versions of edge do work and they'll export the key file for you safari i don't believe does so if i delete this file and let's uh how long does this go janice 11 30 okay so i'm going to delete both the key log files here let's close firefox and i'm going to reopen it you can see that immediately when i launch firefox it regenerates that key log file and it's going to think it's a keynote presentation of course but yeah once once you uh once you launch firefox through that window it's going to immediately generate this on windows it's the same way if you delete the file and then you reopen firefox it'll immediately generate that file again so all right let's take a look at some captures right unless you have other questions okay so i have a couple captures in here we can look at so let's start with let's look at a tls 1.2 [Music] capture first so here is tls 1.2 um and tls one two it's a little bit different here so with tls one two what we're doing is the the client hello is going to send a message to the server and in that message it's going to tell the server all of the cipher suites that it supports and these include uh here it says elliptical curve diffie-hellman with aes 128 and sha-256 so those are our three protocols that we're using for uh negotiating this encryption right our key exchange our symmetric key encryption and then sha-256 is for handshake integrity uh and down here you see we have some with rsa in here and there's a reason a lot of times we used rsa in this or we supported rsa here and that's for troubleshooting so if you were working as a administrator and you're trying to troubleshoot things you could actually force rsa to be the key exchange which uses a certificate and you can do some trickery with the certificate to do decryption here but generally speaking you'll see that all the other ones are elliptical curve and it's just choosing a different uh different encryption protocol aes here here's cha cha 20 aes 256 or a different handshake integrity protocol so the client sends that hello message it says hey i support all these versions the server comes back and it picks one of them and it says right here the cipher suite that it chose is elliptical curve giffy hellman uh using rsa here the rsa this is for uh uh integrity right it's just checking the integrity of this aes 128 gcm is checking integrity of that and then sha-256 for handshake integrity so it's choosing one of the protocols in the client's suite the server then sends the certificate over to the client the client then sends its key that it shows through that calculation with the elliptical curve it sends the key back to the server the server does the same thing back and at this point now now the message is encrypted we can decrypt this message [Music] by putting in our key right click on tls properties protocol preferences open tls preferences and then i go grab that key it's this one right now that's the death we got the wrong key i do oh this is it there we go so yeah now it says now instead of saying change cipher spect encrypted data now it says finished and then our very next message here get http 1.1 you can see our http data here this is not using http 2 this is a little bit older and you can see pluralsight.com in here and you can see other information and we can actually see some of the website getting downloaded here through http1 so that's tls 1.2 we can see that the handshake goes uh clienthello server hello server sends a certificate client sends a key server sends the key and then it's finished let's take a look at tls 1.3 again yes uh at the end of a tls connection at the end of the tls connection here um we're just sending a message here that just said uh no i wasn't planning on covering it but in tls12 we're just sending a message that says we're closing and then spin well reset in this case but finnac reset right all the same right what is that what's happening right yep yeah let's take a look let's take a look at what happens in tls 1.3 with that too i don't know yeah i don't know the answer to that yeah the question was for those on zoom uh is it always the is the alert message always this uh uh closed notify message and yeah i do not know the answer to that all right so here's a tls one three put the key in there okay so this is this is uh this is actually a good one to take a look at where uh this is my bad certificate so let's take a look at what's happening on the good side first well first let's do this so this is me connecting to my home firewall and my home firewall is https however the circuit certificate is unsigned so when we do this we get the client hello we get the server hello and the server hello then uh should be sending the certificate but then we get an alert here it says level fatal description bad certificate what's happening on my web browser at this time you're getting a warning yeah it's saying hey this is a bad certificate you shouldn't be doing this and then you have to go in and say yep this is fine i'll keep going and after that it's going to start a new tls session and here we get our client hello right the clientello just like we saw earlier it's immediately sending it does it does show a list of ciphers that we can use here but you notice something different about these ciphers especially the top two here what protocols missing in these top two top three yeah the ecdh right down here we have elliptical curve diffie hellman and then on top these three don't have that included well what the what this client is saying is saying well one i'm going to try tls 1.3 and i'm going to send you all the information for tls13 and if for some reason server you don't support that i still support tls 1.2 and i know that because i'm telling you some of the cipher suites i send have elliptical curve in them so we can actually revert back to tls 1.2 if needed but we're also sending our key exchange right so right here is our key exchange information coming in the clientele so the client hello is saying we're going to try tls13 here's the curve i'm using here is the uh the key let's try it the server comes back and it says yeah i support tls13 it says um well it says tls12 here but this is only used because tls-13 is so strange in order to get these messages through corporate data loss prevention devices uh we had to trick those devices into thinking it was tls one two uh do you guys know about data loss prevention devices it's a way of uh it's it's an appliance you install at the edge of your network and all the devices inside of your network when they send traffic that traffic is decrypted at that device the traffic is inspected against a database of known information that shouldn't be leaked and it'll flag anybody who's trying to send out information over the public internet that shouldn't be sent out so it's intended to protect uh intellectual property or medical records or credit card data all this type of thing so we're actually decrypting the data as it leaves the network and then re-encrypting it when it goes out to the web just to inspect it in the middle and in order to get that device to work it needs to be tricked into version 1.2 which is why we're doing this so but it's actually using tls13 and we know that it's using tls13 because the cipher suite we picked here doesn't have a key exchange protocol listed which means we're using elliptical curve and then we come back and uh we we uh send a final message from the server to the from the client to the server saying yep we're all good we've got the uh certificates we've got all the encryption set we're good to go and then after that we're downloading the website and other data last one i want to take a look at here is something that chris is going to talk about tomorrow but we're just going to do a little teaser of it and that's quick have you guys heard of quick quic quick is uh google's new implementation of tcp so here is uh me going to youtube to look at one of chris's videos uh what's special about this what uh when we use a tls um what uh layer four protocol do we use typically tcp uh what are we using here not tcp we're using udp there's no three-way handshake right so quick is supposed to be wildly efficient right so udp has almost no information in it right it's it's just a source and destination port and a couple little options but then quick is running on top of that so quick is actually doing all the negotiation for tls here and we can see that better if i decrypt this still have to go to tls peter actually just changed this in here not long ago from ssl to tls we got updated information it was a very very short time ago that this used to all be ssl in here yeah but all the display yeah everything is tls now no longer ssl and uh did i grab the wrong key yes although maybe not this moment it says that's the key for some reason it's not uh it's not letting me do it here i don't know here it is we're uh is it encrypted inspections well this may be a failed failed piece of this uh reassembled in frame nine well that's what quick is basically it's udp is the is the protocol used to carry quick and then built into quick we're using tls one three so the idea with quick is that uh it's a lot faster to get from um there's there's two big advantages of it one is that uh we're go we're ignoring the three-way handshake and we're going right to quick's handshake which is much shorter and in the quick handshake we are doing the encryption we're establishing the encryption right away and then the second thing quick is allowing us to do is have is download lots of different streams of traffic all at once so http 2 kind of does this over tcp but quick is supposed to make it even faster and more efficient so we're giving up on tcp a little bit but i think tcp has a long way to go before we we end that one and i highly recommend going to chris's presentation tomorrow on quick that's i i believe that's part of quick yeah i believe http 3 is used as a as part of quick yeah any other questions yeah go for it okay gotcha how do you how okay so so okay yep so there's there's a way wow so what for the zoom for the zoom followers what uh what we're talking about is there's a uh uh command line interface program what's it called again edicap and you can actually inject the key into the capture file itself so you don't have to keep changing it like i've been doing and then yeah then you can dump the log file yeah all right great thanks and and yeah slightly beyond the scope of this uh for for today but yes that's that's outstanding information thank you anything else uh please fill out the survey and uh if you are interested in uh a trial for pluralsight come come let me let me know and i'll help you out thanks everybody

Channel: SharkFest Wireshark Developer and User Conference

Views: 8,216

Keywords: SharkFest, Wireshark, TLS

Id: Cq6yj9se9M4

Length: 60min 59sec (3659 seconds)

Published: Fri Feb 17 2023