Decrypting TLS, HTTP/2 and QUIC with Wireshark

this video is part of my series with chris showing you how to decrypt protocols such as https as well as quick in a previous video which i've linked here and below chris showed you how to export keys on a mac how to use those keys in wireshark so that you could decrypt encrypted packets in this video we're continuing the discussion looking at protocols such as https how that's different to http version 2 how that's different to quick which is an emerging protocol which you're most likely using right now if you're watching this video on youtube now if you want to see part one of the interview please use the link below otherwise continue watching where chris and i talk about the various protocols in use today so if you on the bottom left where it says hypertext transfer protocol 2 can you just expand that bottom left absolutely you bet actually david that's a that's a great uh question and a good place for your eyes to go because when i first started to decrypt uh tls sessions i saw http 2 and i went oh there's more going on beyond that lock than i thought so it's not just http 1.0 or 1.1 uh now http 2 or even with the next generation of http now we see http 3 as well can you what what is just for everyone's benefit can you explain what's http 2 and you mentioned http http 3 and i saw your file name is called quick what's all that about ooh good question okay so here here it is plain and simple with http 2 or actually let me back up http1 yep hp 1.0 allowed me to establish a connection with you imagine david you you be the server okay yeah i established a connection to you over tcp handshake cincinnati yeah and i immediately then ask you for a file get david.png yeah send you a picture you send me that file yeah you send me the file and i say great thank you done and i shut down the tcp connection well that's not very efficient no http 1.1 allowed it for pipelining so then i say hey david go ahead and send me um the png file go ahead and send me your david david.png you're going to send that over immediately after that i could say now send me bumble png yeah and then you send that one and then i say okay send me chris then you know send me grier send me a send me send me wireshark i could do all of these requests one after the other over a single tcp stream efficient so the session was kept up here correct the tcp session was still up yeah problem we started to run into some issues where tcp became a bottleneck yeah where we we now need a hundred uh images files things to bring over over web but i'm only i'm doing it over an individual tcp channel or even if i started up several tcp connections i could still only use one one request over one tcp connection okay what http 2 does is it allows me to set up streams on top of one tcp connection that's what this is up here you see it says settings and basically i'm going to collapse all this david this is a better packet to show show you this with you see all these streams yeah basically you could think of each one of these streams as an individual tcp connection of its own within the main so it's within the main session yeah yeah it just allows me to multiplex yeah requests over a single tcp stream what that allows me to do is now instead of saying hey david give me that david image and you send it then bumble image now chris image now i can say hey david give me david bumble chris greer wireshark tcp give me everything you have and you can then start to work on those requests all over one tcp connection that's what http 2 is just to keep it simple so when i say get here and i come down here now this is you see in wireshark shows me it helps me out it says here's a stream so this is stream 15. it just gives me give me a stream number and there's a bit more detail in there but we'll leave that simple so the stream id is 15 and that's where we're doing a get all right so that get what i'm going to look for what my eyes are going to do is i'm going to look for when's the next time i see 15 or i can even come here and i can say follow http 2 stream if i want to let's actually do that i got some stuff that came up i'm going to close this out i just want to come back to my packets basically so here's the get for stream 15 and the response came here this was the next packet that had stream 15 in it and this is my 302 found so the server says okay great uh we got some stuff let's go ahead and see what the server came up with if i expand this 302 found now here's the key this is this is what uh basically this is telling us david if we come down it's it's uh quite a bit of hdp information going on here that we're gonna jump over i know this is a lot going on here but uh basically so my response code is found so the status code is 302 which means okay i found you but i'm actually going to redirect you somewhere else your location that we're talking to is youtube.com but this is the key here the the server is coming back and actually suggesting an alternative alternate service if i expand this out down at the bottom what the server's saying is hey this is great that we're talking over tcp using a tls encrypted handshake http 2 however what do you think if we jump over to quick and we use http 3 and this is this is actually quick draft 29 that it's suggesting but the point is the server's saying hey i can talk to you that's wonderful not an issue at all here but do you mind doing it over quick i'm hoping you can explain what quick is for everyone who doesn't know absolutely so quick is it it came from google but what quick is is it basically the newest transport layer protocol for the longest we were only running two protocols as you native we were just running two protocols at the transport layer tcp connection oriented yeah udp connectionless that's it yeah unless you can think of another transport protocol that you know i'm missing out on but those are the those are the top ones yeah the top ones yeah what started yeah it was started to happen um to move most of our data yeah those are those are the kings so what started to happen was basically google was thinking you know we got to speed up the internet and a bottleneck that we have is tcp i mean look we have to do a tcp handshake we have to do a tls handshake so they were thinking you know if i even if i can go back to my packets here and if i come up to the top from the time that i send that sin let me just set that filter one more time from the time that the user sends this in until the user gets its first usable byte of data right basically this 302 found from from the time it begins to the time of 302 found is too long there's too much chatter too much going on we gotta simplify this and make it to where david could send uh basically establish a connection in one round trip and even be able to get data on that first response one round trip okay that's the goal of quick so what quick is after after the server says hey do you want to go to quick basically what happens down a little further in this pcap actually just a few packets later the client opens up a quick connection to the same ip address only check this out here's ip now we're over udp we're going to udp 443 yeah right tcp 443 is the one we've been working with for a while quick is over udp 443 but now what we're doing is we're establishing a secure conversation over udp and that picks up basically my what my browser did is it moved over to quick and uh that's the application that it's using to be able to send data at layer three all right layer four is quick and then http can sit on top of it in fact dave right now the users are probably or the viewers are probably watching this video over quick uh anything you search on google is going to be over quick you check your google mail you go to youtube even facebook is now flipped over to quick so think of it as tcp2 without some of the bottlenecks that tcp creates yeah it's amazing i mean i'm trying to remember when it when it when did the draft come out it's only about is it about a year ago that they they started moving towards us i can't remember when it when it when did it actually get ratified or whatever it is may 2021 so yeah seven months ago five months ago yeah yeah it's not long but they've been working on it since basically google first incepted this it started out as g-quick it started out as a google quick internet connections and uh that was back in 2012. so this standard is nine years in the making so like if you use if you use chrome most people use chrome or firefox if you go to any of the big websites like you mentioned facebook google and some others it's going to be quick so at some point i'll probably have to get you back for a whole deep discussion on this because we're going to see more and more of this or can you give us like a quick tour of quick versus tcp and http absolutely no problem um in fact what i would suggest to the listeners or anyone that's watching this right now fire up wireshark yeah look at this video through the lens of wireshark and what is your transport layer protocol it's probably udp yeah so if you only see udp there and there's just data sitting within udp that's likely quick sitting on top of udp we just missed the initial handshake setup so wireshark doesn't know how to decrypt it it doesn't realize that it's quick we're only going to see it it's a world i'm going to see it identified as quick if we get some of this initial handshake behavior before we actually see the application very briefly quick is simply sitting on top of udp it establishes a connection but notice this in the very initial packet think of this as almost like the tcp syn right this is just hey how you doing do you talk quick are you open on this udp port we send out that initial and if we come down to our quick information notice this the tls client hello is embedded within the quick initial now there's there's a lot we could say about the quick initial packet let's keep it very simple basically david what i'm doing is i'm saying hey here's my ip address here's yours here's my port here's yours this is the most important part the destination connection id i'm establishing now at the quick layer this connection identification number here's you here's me think of these as almost like let's just call them just to understand the idea it's almost like a new port number okay in a way like i'm gonna come talk to you on this port here's who i'm coming from just so you i so we have an understanding here here's what's cool about quick now the underlying stuff can change the ip addresses can change let's just say that i'm watching this video from my office and i walk out to my car and i flip from wi-fi over to the lte network yeah the whole network changed even the udp port numbers could change right now tcp would need to reconnect to that new network yeah quick i just identify i just keep coming back to you and i have the same connection id and we can just resume this connection even if i change networks that's cool pretty sweet yeah it's very good and from the very initial packet i'm sending my client hello that tls 1.3 hello which is one of the reasons why it took so long to get here with quick is that they were waiting until we had a one round trip way of establishing the connections that happened with tls 1.3 so tls 1.3 client hello is going out the very first packet do you notice what we have here we don't have that tcp handshake we already bought ourselves one round trip yeah immediately right out the gate now with this once this initial ends and uh really i'm only looking at one handshake before i'm starting to move data so from the time i start the conversation with that server until the time i'm actually using the application and getting data is several round trips less yeah right at a minimum one if not more especially when i'm going back to a conversation i've had in the past so that's that's your high level quick it's simply a new transport layer protocol that is poised to take on a lot of the workload on the internet that's already happening with youtube it's already happening with google it's already happening with facebook and we're pretty sure that as things move forward the many more will follow so i mean the big difference here is just to summarize is tcp is slow lots of overhead with tcp so rather than using tcp we're using udp um it less round trip stuff we don't have to keep checking things i mean tcp where you and i have been in this game for a long time it was developed in a world that was very different to today's world slow connections lots of drops stuff like that so we're replacing tcp with udp and then we're running quick directly over udp to get rid of like the slowness and tcp and tls's all right that's correct basically tcp we start to have something called head of line blocking yeah and what that is is it's a it's a concept where basically i can go back to the the scenario where i was sending you a lot of requests at once yeah i would say hey david give me this image that image that javascript give me give me all this stuff give me give me give me give me give me and if there's any problem on the network if there was any packet loss or any type of out of orders or anything that would mess up the tcp connection the application would come to a screeching halt basically everyone pull your brakes hang on there's been a loss packet so even if you had b let's say you got the request for david bumble and chris for all three files but there was some packet loss in you responding to just one of those responses well tcp doesn't know about the data that's above it so tcp would go wait a second everyone stop stop stop hang on re-transmit okay now we're good now we can continue and move this application along that's called head of line blocking if someone ahead of you we've all been there in the supermarket we happened to pick the one lane where someone had a credit card problem they had to call their bank and there you are it just bogs the whole thing up in a similar way that that's what head of line blocking does especially over tcp it cares too much about every bite yeah so what quick does quick care is too but what it does is it handles that recovery on a stream based on a stream level so now i can tell which stream had the loss was it david was it bumble was it chris was it grier which one of those files that were requested actually experienced the loss let's only impact that stream and the rest can keep going as if nothing happened that's great that's one of the benefits to quick and so and and the point though the whole reason for doing it over udp is because now i can plug this transport layer entity this new thing i can put it i can put it within a packet and i can send it to any kernel in the world all kernels support tcp and udp yeah yeah so now i imagine if i took quick and i put it right over ip yeah nightmare i'd have to imagine what would happen from a network perspective okay the routers are saying what is this access lists would break uh firewalls would need to understand what it is load balancers couldn't handle it uh but putting it over udp now all of this infrastructure just treats it as a udp stream and it's interesting because it's using udp port 443 as the servers are right yes it is that's the that's the standard quick port numbers udp 443 so just to just the the sort of the mechanics i initially if i open up chrome and i go to youtube the initial session is tcp https for port 443 here and then you had that like redirect and then it tries to move too quick is that correct that is correct so not all networks are going to support quick yet yeah there's some environments i have clients that are like we don't want udp 443 because we don't trust it yet so they literally block it yeah so that's fine youtube can handle that youtube's like fine oh you don't want to go quick let's keep on tcp that's fine that's not a problem so it could be from a security perspective or it could be from a browser perspective what if i'm using a browser that doesn't yet fully most of them do anymore but let's just say i was using a browser that doesn't support quick yet so the server could come back like it did here the 302 found the alternate service um that one that we looked at earlier yeah the alternate service isn't a must it's just a suggestion right so if the client can do it then the client will initiate quick if not it'll say forget you i don't know quick let's keep going down the tcp lane that's brilliant so just to step back right to the beginning of what we discussed the trick here or the the takeaway here is that you've got to get those session keys and um you've give i'll link it again below the video you've given us a document where you show how to do that for different operating systems here so somehow you've got to get those keys and like you did on the mac export it so that why shot can grab those keys to do the decryption is that correct absolutely so i'll give you uh there's an article that shows you how to do it or if you'd prefer to see see how to do it that's where i would just link back to the one on my channel that shows you windows i do it on windows 10 with chrome and i demonstrate how to set up that environment variable how to store it how to start up that capture and get the packets that you can then bring that key into yeah that's great i'll link to both the article and your video below so anyone who wants to watch you know how to do this on windows go to chris's youtube channel have a look at that anything else you want to share chris about this or have we kind of covered the the basics of it yeah absolutely i think um boy there's a lot to share about tcp i think we're just uh we're scratching the surface but i i think what i'd like everyone to take away from this is that there's a lot going on at the packet level not everything needs to be decrypted in order to troubleshoot especially using tcp there's a lot we can do we can look at re-transmissions we can look at network around trip times application response time for me i also don't want you to think that if i don't have decryption then wireshark is useless yeah that's not true either a lot of the troubleshooting that i do is without the key right someone will send me a pcap and they'll say hey what's going on here what's wrong and what are the odds that they were capturing the tls key at that time yeah exactly pretty unlikely so that means i'm going to have to get in and do some encrypted analysis so wireshark is still a very powerful tool with or without decryption however since so much is encrypted uh now we it does really help us to be able to do some decryption to take a look at the gets the response strings uh what file was held up what uh what are some of these underlying things and especially as we're moving into quick quick after the first packet is completely encrypted yeah so in order to make heads and tails of what's really happening having that decryption option is nice but back to just repeat myself again i just don't want everyone to think if i don't have decryption then i have nothing why even look at the packets because because that's not true there's a lot we can still see even in an encrypted flow yeah i think that's so that it's good that you highlight that because a lot of people will have that concern that you know um if i don't capture the keys i can't really see anything so let me let me ask you the difficult questions now in a in a subsequent video or or can you like briefly explain how on earth would i capture the keys with man in the middle um or a server is that like a whole separate uh video that we should do yeah that's something we we certainly could we could look at doing that for sure um i i think it's not as easy as it sounds no for for good reason yeah exactly right um there are also uh i find with a lot of my clients what they do is they just end up having a tls proxy yeah what did i'll show you what that means yeah good one yeah so so basically it's known that it's a tls entity literally it's a box that everything points to all browsers know that they that's their web proxy and it actually terminates the connection then that proxy box turns around and establishes the connection to whatever site they're going to so they have a central focal point where tls sessions are stored but that's something that it knows about everybody's got it in there um you know it's not malicious it's a designed built-in place where keys are captured that said that that technically is a man in the middle but everyone knows about it and it's it's a policy kind of thing to do it just sitting in a coffee shop that's a whole different story so chris this is brilliant you've shown us and just make sure that i've got my summary correct you've shown us how do you export a key so that we can capture the session and decrypt it with wireshark you've shown us how to like select that through wireshark you've explained quick you've explained a whole bunch of stuff is there what are your most important pieces of advice for someone who wants to learn wireshark so like is it important and i think you've answered that already and then how would you learn it like if you were starting today how would you suggest someone learn why shock i mean i would suggest going to look at your youtube channel as an example but are there any other resources that you found that have been really beneficial that's a great question um i was there myself how do you learn wireshark and a big one is to install it and look at it daily if possible right protocols or languages yeah right we could be speaking in english spanish portuguese but the more we do it the more we're going to understand what's really happening same thing with wireshark we can't just break it out once a year when that problem happens it's not going to work so install it and then there's there's content like my youtube channel i invite everybody to stop by i have a mini series on wireshark it takes you from the installation the configuration setting up a profile setting up a filter and some basics on how tcp works i know you david you have a you have a video series on udemy you have some wireshark content out there as well so there is some great stuff on youtube from a book perspective you know what i suggest people do and maybe we can link this down below as well there's some really good books that just talk about the protocols themselves yeah right so one that i really like is tcp illustrated yeah and it's not your casual reading book it's great to put you at sleep at night if you really need that but it's it digs deep into the protocol itself that we're looking at with wireshark so there is some great content out there a few searches and i'm sure you'll be able to find it oh he's got it i need to ask you the question is it do you is second edition as good as the first edition because i see some people that's it's it's better that's the one you have it yeah that's the book right it's a great book i'll link that below um i mean it's interesting because there are books i have books on wireshark per se but use pushing us more to learn the protocols rather than like just trying to learn wireshark yeah yeah absolutely in fact in my courses i spend the first you know if the scores if if the course is two days uh i spend the first uh hour on the interface and then boom we're into the protocols let's actually learn to use it yeah and then that will then teach us more about the interface and filters and buttons and the the actual analyzer itself i agree with that strategies i always like to use the analogy it's like trying to learn to ride a bike bicycle you're only going to learn by doing it and falling off a few times yeah so chris really want to thank you for you know demonstrating wireshark i'm going to twist you to come back in our next video are you going to be able to show us like the dodgy protocols on a network and how to discover like dodgy stuff happening i think that would be a fun track to go down let's go ahead and take a look at a stream of data in wireshark and let's build some filters that will specifically point out the stuff that's weird yeah and and be able to identify that quickly i think that's a very important skill especially for cyber security professionals or if we want to go down the security path yeah so everyone you know please put in the comments below you know what kind of stuff would you like chris to answer what kind of videos would you like him and i to create i definitely want to create a you know a bunch of videos with chris if he's up for it uh what kind of stuff would you like us to you know talk about um and make sure that you go to his channel subscribe to his channel he goes into much more detail than i do so chris thanks so much for you know this video looking forward to the next one absolutely david thank you so much for having me and appreciate anybody that watched and uh this has been great i've had a good time brilliant thanks [Music] you

Channel: David Bombal

Views: 33,837

Keywords: quic, tls handshake, tls, tls explained, tls protocol, tls 1.3, quic decryption, wireshark, https, https decryption, chris greer, http/2 vs http/3, tls decryption, quic transport, quic wireshark, quic over udp, udp, tcp, udp vs tcp, how quic works, quic connections, quic vs tcp, quic replace tcp, network analysis, transport layer, http3 over udp, http3 quic, ssl decryption, ssl decrypt, wireshark tutorial, wireshark capture, tls encryption, tls 1.3 wireshark

Id: yodDbgoCnLM

Length: 27min 59sec (1679 seconds)

Published: Mon Nov 29 2021