WEBVTT 1 00:00:00.080 --> 00:00:01.919 You know that feeling when you're sitting in a dead, 2 00:00:02.000 --> 00:00:05.759 silent room, maybe it's late at night, your laptop is open, 3 00:00:05.839 --> 00:00:09.080 your phone is on the table, and it just feels well, 4 00:00:09.080 --> 00:00:11.839 it feels uceful, it feels peaceful. But if you could 5 00:00:11.880 --> 00:00:14.400 actually see what was happening in the air around you, 6 00:00:14.720 --> 00:00:18.239 if you have like X ray vision for data, that 7 00:00:18.679 --> 00:00:21.519 room would be absolute chaos, would be screaming. 8 00:00:21.679 --> 00:00:24.199 Oh yeah, it would be completely deafening. 9 00:00:23.879 --> 00:00:29.280 Because every millisecond there are thousands of these invisible conversations happening. 10 00:00:29.640 --> 00:00:33.039 Your phone talking to the router, your laptop negotiating with 11 00:00:33.119 --> 00:00:39.000 some server in Virginia, your smart bulb checking for firmware updates. Right, 12 00:00:39.280 --> 00:00:43.920 it is a massive, frantic, highly orchestrated exchange, and usually 13 00:00:43.960 --> 00:00:45.439 we are just completely blind to it. 14 00:00:45.520 --> 00:00:47.799 Well till something breaks, you know. That's usually when we 15 00:00:47.840 --> 00:00:50.320 actually start paying attention to the network exactly. 16 00:00:50.479 --> 00:00:52.560 And that is exactly where we're going today for this 17 00:00:52.640 --> 00:00:55.560 deep dive. We are looking at the invisible nervous system 18 00:00:55.600 --> 00:00:58.479 of the modern world. We're basing our discussion today on 19 00:00:58.520 --> 00:01:02.439 a really comprehensive guide called Network Forensics with wire Shark 20 00:01:02.880 --> 00:01:04.200 by Pavicshaw, and. 21 00:01:04.159 --> 00:01:06.079 I think it's important to right off the bat, this 22 00:01:06.200 --> 00:01:09.799 isn't just a basic how to manual. Shaw really frames 23 00:01:10.200 --> 00:01:14.439 wire Shark, which by the way, is the absolute industry 24 00:01:14.519 --> 00:01:18.560 standard tool for analyzing network traffic. He frames it as 25 00:01:18.599 --> 00:01:21.760 a lens. It's a way to capture those invisible packets 26 00:01:21.760 --> 00:01:24.560 flying through the air and basically freeze them in time 27 00:01:24.640 --> 00:01:26.120 so we can actually dissect them. 28 00:01:26.280 --> 00:01:28.799 So our mission today is to step into the shoes 29 00:01:28.840 --> 00:01:32.319 of that forensic analyst. We are going to trace the 30 00:01:32.400 --> 00:01:35.640 life of a data packet. We're going to see how 31 00:01:35.719 --> 00:01:38.239 your devices agree to talk, how they handle it when 32 00:01:38.239 --> 00:01:42.680 messages get lost, and how they keep secrets. And we 33 00:01:42.760 --> 00:01:45.000 are starting at a place I honestly didn't expect a 34 00:01:45.040 --> 00:01:47.480 hardcore networking text to start. 35 00:01:47.319 --> 00:01:48.560 The dashboard of your car. 36 00:01:48.560 --> 00:01:51.359 A car, because apparently before we can even talk about 37 00:01:51.400 --> 00:01:53.640 the internet, we need to talk about the infotainment system. 38 00:01:53.799 --> 00:01:55.760 It makes perfect sense if you think about it, though. 39 00:01:56.159 --> 00:01:59.959 Modern cars are literally just networks on wheels that screen 40 00:02:00.120 --> 00:02:02.799 on your dash the integrated head unit. It isn't just 41 00:02:02.840 --> 00:02:03.560 a radio. 42 00:02:03.319 --> 00:02:04.560 Anymore, right, It's a computer. 43 00:02:04.799 --> 00:02:07.519 It's a massive hub. It's running an operating system. It 44 00:02:07.560 --> 00:02:09.800 talks to the heads of display and it has to 45 00:02:09.840 --> 00:02:13.199 pull data from sensors located all over the vehicle. 46 00:02:13.319 --> 00:02:16.840 And this introduces our first big concept which Shaw spends 47 00:02:16.879 --> 00:02:20.840 a good amount of time on the SAHM CAN the 48 00:02:20.879 --> 00:02:22.680 Controller Area network. 49 00:02:22.520 --> 00:02:26.000 Right, So to understand, can imagine the wiring in a 50 00:02:26.080 --> 00:02:29.680 car from say the nineteen sixties. If you wanted the 51 00:02:29.719 --> 00:02:32.400 brake pedal to turn on the tail lights, you basically 52 00:02:32.479 --> 00:02:34.719 ran a physical copper wire from the pedal all the 53 00:02:34.719 --> 00:02:36.240 way to the light. Simple. 54 00:02:36.319 --> 00:02:41.120 But now you have airbags, abs, engine, timing, climate control, navigate. 55 00:02:41.319 --> 00:02:43.479 I mean, if you ran a dedicated wire for every 56 00:02:43.479 --> 00:02:46.639 single connection today, the car would weigh ten tons exactly. 57 00:02:46.840 --> 00:02:50.120 It'd be impossible. So the CAN protocol solves this physical problem. 58 00:02:50.159 --> 00:02:53.159 It treats the car's components as nodes and they all 59 00:02:53.199 --> 00:02:54.960 share a single communication light. 60 00:02:54.960 --> 00:02:56.560 A serial bus, a serial bus. 61 00:02:56.680 --> 00:02:58.800 Yeah, it's almost like an old school party line telephone. 62 00:02:58.800 --> 00:03:00.879 Everyone's listening to the same way, and when a message 63 00:03:00.879 --> 00:03:02.719 comes down the line, the right note just grabs it. 64 00:03:02.800 --> 00:03:05.159 Shaw uses a really specific example here that I thought 65 00:03:05.199 --> 00:03:07.879 was great because it immediately raises the stakes. He talks 66 00:03:07.919 --> 00:03:09.639 about the spark ignition engine. 67 00:03:09.879 --> 00:03:13.120 Yeah, because the internal combustion engine is entirely a timing game. 68 00:03:13.680 --> 00:03:16.039 You need the stark to fire in the combustion chamber 69 00:03:16.120 --> 00:03:18.000 at the exact millisecond the fuel. 70 00:03:17.759 --> 00:03:20.240 Is compressed, and if that signal is late, the. 71 00:03:20.159 --> 00:03:23.599 Engine knocks or just straight up doesn't run right. So 72 00:03:23.639 --> 00:03:27.080 the engine control unit, the ECU, it needs to coordinate 73 00:03:27.080 --> 00:03:30.159 that spark instantly. It absolutely cannot wait for the air 74 00:03:30.159 --> 00:03:32.719 conditioning system to finish reporting the cabin temperature. 75 00:03:32.800 --> 00:03:34.280 It needs priority exactly. 76 00:03:34.319 --> 00:03:37.199 The network has to prioritize. And this is really our 77 00:03:37.240 --> 00:03:42.560 first core lesson in networking. Latency matters and protocols, which 78 00:03:42.560 --> 00:03:44.919 are basically just the rules of the road, are what 79 00:03:45.039 --> 00:03:47.080 prevent the entire system from crashing. 80 00:03:47.280 --> 00:03:49.800 Okay, so the CANbus is the model for the car. 81 00:03:49.879 --> 00:03:52.479 It's contained, but when we move out to the Internet, 82 00:03:52.759 --> 00:03:55.560 we need a much bigger model, and the source material 83 00:03:55.599 --> 00:03:57.719 brings up the famous OSI. 84 00:03:57.319 --> 00:04:01.840 Model, ah the open systems intercannation model. If you have 85 00:04:01.960 --> 00:04:05.159 ever taken to computer science class, you've definitely memorized the 86 00:04:05.199 --> 00:04:06.080 seven layer. 87 00:04:05.840 --> 00:04:09.120 DIP physical data link network all the way up to 88 00:04:09.159 --> 00:04:10.199 application at the top. 89 00:04:10.400 --> 00:04:14.039 It's a really elegant theoretical framework. It separates the raw 90 00:04:14.120 --> 00:04:17.120 physical cables which is layer one, from the routing at 91 00:04:17.199 --> 00:04:19.800 layer three. All the way up to the web browser 92 00:04:19.839 --> 00:04:22.920 you're actually looking at, which is layer seven. But Shaw 93 00:04:23.040 --> 00:04:24.680 makes a really critical distinction here. 94 00:04:24.800 --> 00:04:27.439 Yeah, he says, the OSCI model is great for teaching, 95 00:04:27.759 --> 00:04:32.000 but the TCPIP model is what actually runs the real world. 96 00:04:31.920 --> 00:04:36.519 Because TCPIP is practical. It condenses those theoretical layers into 97 00:04:36.560 --> 00:04:40.120 something workable. But the fundamental job is exactly the same. 98 00:04:40.399 --> 00:04:42.560 You take a request from your browser, let's say, get 99 00:04:42.600 --> 00:04:46.600 Megoogle dot com. You chop it up into tiny little pieces, 100 00:04:46.959 --> 00:04:48.600 you address them, and you show them onto the. 101 00:04:48.519 --> 00:04:50.199 Wire where the rubber meets the road. 102 00:04:50.720 --> 00:04:51.160 Literally. 103 00:04:51.519 --> 00:04:53.360 Okay, so let's get into the weeds here. Let's look 104 00:04:53.399 --> 00:04:56.079 at one of those actual conversations. Because the source heavily 105 00:04:56.120 --> 00:04:59.160 emphasizes that the Internet is not just a fire hose. 106 00:04:59.199 --> 00:05:00.879 You don't just blast a bunch of data at a 107 00:05:00.920 --> 00:05:02.959 server and cross your fingers hoping it catches that. 108 00:05:03.079 --> 00:05:04.000 Now you have to be polite. 109 00:05:04.040 --> 00:05:04.800 You have to shake hand. 110 00:05:04.879 --> 00:05:09.639 Yes, the TCP three way handshake. It is fundamental to 111 00:05:09.879 --> 00:05:13.560 everything we do online. Almost nothing on the web happens 112 00:05:13.879 --> 00:05:17.040 without this specific ritual happening. First, I really. 113 00:05:16.920 --> 00:05:19.040 Want to walk through this because I think people just 114 00:05:19.079 --> 00:05:22.800 assume computers connect instantly you click a link, Boom, it's there. 115 00:05:23.079 --> 00:05:25.959 But there's a whole negotiation happening. So let's roleplay this 116 00:05:26.040 --> 00:05:28.639 a bit. Okay, I will be my laptop. You can 117 00:05:28.680 --> 00:05:31.160 be the server. I want to download a file from you. 118 00:05:31.240 --> 00:05:33.240 I don't just start screaming give me the file. 119 00:05:33.560 --> 00:05:35.399 No, that would be UDP, which we can get to 120 00:05:35.439 --> 00:05:39.920 in a bit with TCP. You want guaranteed reliability, So 121 00:05:40.000 --> 00:05:44.560 step one, your laptop sends a syn packet syn it 122 00:05:44.639 --> 00:05:48.639 stands for synchronize. You're essentially walking up to me and saying, knock, knock. 123 00:05:49.040 --> 00:05:51.279 I would like to open a secure line. Here's my 124 00:05:51.399 --> 00:05:52.519 starting sequence number. 125 00:05:52.560 --> 00:05:54.279 Okay, so I've knocked. What's step two. 126 00:05:54.399 --> 00:05:57.639 I'm the server. I receive that knock. If I'm active 127 00:05:57.680 --> 00:06:01.160 and have the bandwidth, I reply with a yn ack, 128 00:06:01.759 --> 00:06:05.360 synchronize and acknowledge. I'm basically saying I heard your knock. 129 00:06:05.639 --> 00:06:08.199 That is the ACK part, and I'm also ready to 130 00:06:08.199 --> 00:06:10.720 synchronize our communication. That's the syn part. 131 00:06:10.920 --> 00:06:13.399 So we are halfway there. I know you're ready, you 132 00:06:13.439 --> 00:06:15.759 know I'm ready. Why isn't that enough? Why do we 133 00:06:15.800 --> 00:06:17.079 need a three way handshake? 134 00:06:17.480 --> 00:06:19.399 Because I don't know that you know that I'm ready. 135 00:06:19.439 --> 00:06:21.439 It sounds like a really bad comedy sketch. 136 00:06:21.800 --> 00:06:25.399 It does. It's very redundant, but that is exactly why 137 00:06:25.439 --> 00:06:28.639 we need step three. You have to send a final 138 00:06:28.680 --> 00:06:33.199 ack packet back to me acknowledged I got your confirmation. 139 00:06:32.839 --> 00:06:34.480 And once that third packet hits. 140 00:06:34.439 --> 00:06:37.959 Once that hits my specialized network card, the socket is 141 00:06:38.000 --> 00:06:41.800 officially open. Boom, we are connected and data can flow. 142 00:06:42.079 --> 00:06:46.000 And this little three step dance happens for every single website. 143 00:06:46.000 --> 00:06:49.480 You visit, every single site, every image resource on the page. 144 00:06:50.000 --> 00:06:53.519 Sometimes it happens dozens of times simultaneously just to load 145 00:06:53.600 --> 00:06:54.879 one single news article. 146 00:06:54.959 --> 00:06:57.920 Wow. Now you mentioned sequence numbers during that handshake, and 147 00:06:58.000 --> 00:07:01.000 the source material has these screenshots from wire Shark where 148 00:07:01.000 --> 00:07:04.759 there are these absolutely huge numbers associated with every package. 149 00:07:04.839 --> 00:07:08.399 Yeah, that is how TCP keeps the story straight. The 150 00:07:08.439 --> 00:07:12.360 Internet is incredibly messy. Packets don't always take the same route, 151 00:07:12.360 --> 00:07:14.560 so they don't always arrive in the right order. Imagine 152 00:07:14.600 --> 00:07:16.199 if I sent you a book in the mail one 153 00:07:16.240 --> 00:07:18.639 page at a time, page fifty might actually arrive at 154 00:07:18.639 --> 00:07:19.800 your house before page ten. 155 00:07:20.120 --> 00:07:22.160 So the sequence number is just the page. 156 00:07:21.959 --> 00:07:26.720 Number essentially, Yes, but it tracks individual bytes of data, 157 00:07:27.120 --> 00:07:30.000 not pages. So if I send you a thousand bytes 158 00:07:30.000 --> 00:07:32.920 of data, and my current sequence number is five thousand, 159 00:07:33.439 --> 00:07:35.600 The next sequence number will be six thousand. 160 00:07:35.879 --> 00:07:38.480 It's just simple edition, current sequence. 161 00:07:38.079 --> 00:07:40.360 Plus the data payload exactly, simple edition. 162 00:07:40.439 --> 00:07:43.920 Sure, simple addition. But in the wire Shark screenshots, show 163 00:07:44.040 --> 00:07:46.720 provides these numbers are terrifying to look at. They're like 164 00:07:47.399 --> 00:07:49.759 three billion, four hundred million in something. 165 00:07:49.839 --> 00:07:53.279 They're massive. Yeah, and that's because they're randomly generated for 166 00:07:53.319 --> 00:07:56.199 security purposes. Ye, you really don't want to start at 167 00:07:56.279 --> 00:07:58.399 number one every time you connect to your bank, or 168 00:07:58.519 --> 00:08:01.879 hackers can easily guess your sex a hijacket. But Shaw 169 00:08:02.000 --> 00:08:04.800 gives a really great pro tip here for anyone actually 170 00:08:04.800 --> 00:08:05.800 opening up wire. 171 00:08:05.560 --> 00:08:07.040 Shark relative sequence numbers. 172 00:08:07.120 --> 00:08:11.120 Yes, turn that setting on immediately. It just tells Wireshark look, 173 00:08:11.160 --> 00:08:13.480 I don't care that the real starting number is four billion. 174 00:08:14.160 --> 00:08:17.000 Just treat the very first packet as zero and count 175 00:08:17.040 --> 00:08:20.079 up from there. It makes the forensic analysis actually readable 176 00:08:20.079 --> 00:08:20.839 for a human brain. 177 00:08:21.160 --> 00:08:26.360 I definitely prefer starting at zero. Okay, so we've shaken hands. 178 00:08:26.439 --> 00:08:29.279 We are counting the bytes. But this is the real world. 179 00:08:29.879 --> 00:08:33.960 Backos cut fiber optic cables, WI Fi signals fade when 180 00:08:33.960 --> 00:08:36.519 you walk into the kitchen what actually happens when the 181 00:08:36.559 --> 00:08:37.559 conversation breaks. 182 00:08:37.840 --> 00:08:41.039 This right here is the absolute core of network forensics, 183 00:08:41.440 --> 00:08:44.840 spotting the errors. In the old days of TCP, if 184 00:08:44.840 --> 00:08:47.080 we were sending a stream of data, let's say we 185 00:08:47.120 --> 00:08:50.360 send packets one, two, three, and four and Packett two 186 00:08:50.519 --> 00:08:51.679 just vanishes into the ether. 187 00:08:51.799 --> 00:08:53.679 Receiver gets one, three and four and knows there's a 188 00:08:53.679 --> 00:08:54.399 hole in the middle. 189 00:08:54.559 --> 00:08:56.720 Right, it would send a message back to the server saying, hey, 190 00:08:56.960 --> 00:08:58.960 I got up to pack it one, but I am 191 00:08:58.960 --> 00:09:02.320 currently missing packet two. The problem was the center didn't 192 00:09:02.360 --> 00:09:05.120 know if packets three and four arrived safely either. Oh, 193 00:09:05.159 --> 00:09:07.519 I see, So it just played incredibly safe and resend 194 00:09:07.559 --> 00:09:09.240 everything from packet too onwards. 195 00:09:09.320 --> 00:09:11.320 It REASNDS two, three and four, But you just said 196 00:09:11.320 --> 00:09:14.159 three and four were already sitting there. That seems incredibly wasteful. 197 00:09:14.399 --> 00:09:17.720 It is terrible for bandwidth. It completely clogs the pipe. 198 00:09:18.120 --> 00:09:21.360 And that's exactly why Shah highlights a protocol feature called 199 00:09:21.519 --> 00:09:25.240 SCCK SACK Selective Acknowledgment. 200 00:09:25.480 --> 00:09:30.440 I love the acronyms and networking they always sound slightly aggressive. SAC. 201 00:09:30.919 --> 00:09:34.679 It is a total game changer for network efficiency. With 202 00:09:34.919 --> 00:09:39.480 SACK enabled, the receiver can be surgically precise. It says, ok, 203 00:09:39.679 --> 00:09:43.240 server I received everything up to byte one thousand, I 204 00:09:43.279 --> 00:09:46.320 am missing the next chunk. But and here is the 205 00:09:46.320 --> 00:09:49.360 clever part, I did receive the chunk from byte two 206 00:09:49.360 --> 00:09:50.519 thousand to three thousand. 207 00:09:50.799 --> 00:09:54.759 So it confirms the little islands of data it actually has. 208 00:09:54.519 --> 00:09:57.639 Exactly and wire shark you can actually see these specific fields. 209 00:09:57.679 --> 00:09:59.759 They are called the left edge and the right edge. 210 00:10:00.120 --> 00:10:02.960 They literally define the start and end boundaries of the 211 00:10:03.039 --> 00:10:04.720 data that actually made it through the chaos. 212 00:10:04.759 --> 00:10:06.840 So the center just looks at those edges and says, oh, 213 00:10:06.919 --> 00:10:09.120 you just need that one missing piece right in the middle. 214 00:10:09.360 --> 00:10:12.039 It's a surgical strike. It fills the pothole without having 215 00:10:12.039 --> 00:10:14.480 to repave the entire street. And when you are looking 216 00:10:14.519 --> 00:10:16.960 at a wire shark capture of a really slow network, 217 00:10:17.200 --> 00:10:20.039 seeing a ton of these sec K packets helps you 218 00:10:20.080 --> 00:10:22.480 diagnose that the network is dropping data left and right, 219 00:10:22.759 --> 00:10:25.200 but the protocol is fighting tooth and nail to recover 220 00:10:25.240 --> 00:10:25.840 it efficiently. 221 00:10:26.120 --> 00:10:28.000 It really gives you a lot of respect for the 222 00:10:28.000 --> 00:10:30.679 people who design these protocols. They just assume failure is 223 00:10:30.679 --> 00:10:33.080 inevitable and they build the system to plan for it. 224 00:10:33.200 --> 00:10:36.039 That is the entire philosophy of the Internet. It is 225 00:10:36.080 --> 00:10:39.559 technically classified as a best effort network. It promises to 226 00:10:39.600 --> 00:10:42.720 try its hardest, but it never promises to be perfect. 227 00:10:42.960 --> 00:10:45.159 Let's bring this a little closer to home for the listeners. 228 00:10:45.200 --> 00:10:49.960 We've been talking a lot about the theory of the handshakes, sacks, 229 00:10:50.120 --> 00:10:53.919 sequence numbers. But right now, you, the listener, are probably 230 00:10:54.000 --> 00:10:56.759 sitting on your home Wi Fi network. What does all 231 00:10:56.759 --> 00:10:57.879 of this look like for them? 232 00:10:57.960 --> 00:11:00.159 Well, if they open their command prompt on their you 233 00:11:00.200 --> 00:11:02.480 to right now and check their IP address. I can 234 00:11:02.519 --> 00:11:04.559 almost guarantee you what numbers it starts. 235 00:11:04.240 --> 00:11:07.240 With one nine, two six eight the absolute. 236 00:11:06.840 --> 00:11:09.799 Classic and shop points out this specific rule book that 237 00:11:09.879 --> 00:11:14.600 mandates this. It's called RSC nineteen eighteen. It's an engineering 238 00:11:14.639 --> 00:11:18.600 document that basically set aside certain ranges of IP addresses 239 00:11:18.919 --> 00:11:21.000 strictly for private internal use. 240 00:11:21.200 --> 00:11:24.559 Private meaning they literally don't exist on the real public Internet. 241 00:11:24.759 --> 00:11:27.159 Exactly. If you try to send a data packet to 242 00:11:27.200 --> 00:11:29.559 one und two point one six eight point one point 243 00:11:29.600 --> 00:11:33.440 five out on the public Internet, the major backbone routers 244 00:11:33.480 --> 00:11:35.840 will just laugh at you and drop it in the trash. 245 00:11:36.360 --> 00:11:39.480 Those addresses only exist inside the four walls of your house. 246 00:11:39.559 --> 00:11:42.240 But wait a minute, if my laptop has a fake 247 00:11:42.279 --> 00:11:44.840 private address. How am I reading the New York Times? 248 00:11:45.200 --> 00:11:46.960 How does the server in New York know where to 249 00:11:46.960 --> 00:11:49.399 send the web page back to if my address isn't real. 250 00:11:49.639 --> 00:11:52.039 That is the magic trick performed by that little plastic 251 00:11:52.120 --> 00:11:54.960 Wi Fi router sitting in your living room. It's a 252 00:11:55.000 --> 00:11:57.679 process called NAT Network address translation. 253 00:11:58.519 --> 00:12:01.799 I've definitely heard of NAT type when setting up gaming consoles, 254 00:12:01.840 --> 00:12:04.440 but explain what it's actually doing behind the scenes. 255 00:12:04.720 --> 00:12:07.399 Think of your home router like the mail room of 256 00:12:07.440 --> 00:12:11.000 a giant corporate office building. The employees inside the building, 257 00:12:11.000 --> 00:12:13.840 which are your phone, your laptop, your smart fridge, they 258 00:12:13.840 --> 00:12:17.559 all have internal phone extension numbers like extension one one two, 259 00:12:17.639 --> 00:12:19.960 one three. Those numbers don't work if you dial them 260 00:12:19.960 --> 00:12:23.600 from outside the building. The building itself, however, has one 261 00:12:23.960 --> 00:12:27.559 real public mailing address. That is your public IP address, 262 00:12:27.879 --> 00:12:30.200 and it's assigned to you by your Internet service provider. 263 00:12:31.200 --> 00:12:33.600 So when your laptop wants to send a request to Google, 264 00:12:33.960 --> 00:12:37.039 you hand that packet to the router. The router physically 265 00:12:37.039 --> 00:12:40.200 erases your internal extension the one ninety two point one 266 00:12:40.320 --> 00:12:43.320 six eight number, It stamps its own public IP on 267 00:12:43.360 --> 00:12:45.480 the return envelope, and it sends it out to the. 268 00:12:45.399 --> 00:12:47.960 Internet, so it's basically impersonating my laptop. 269 00:12:48.039 --> 00:12:50.480 It acts entirely on your behalf. And here is the 270 00:12:50.519 --> 00:12:54.240 really crucial part. It writes down in a little temporary ledger, 271 00:12:54.279 --> 00:12:57.080 I just sent a request to Google and it was 272 00:12:57.120 --> 00:12:59.519 for the laptop on extension one oh one. When the 273 00:12:59.559 --> 00:13:01.639 reply can it comes back from Google an instant later, 274 00:13:01.960 --> 00:13:04.120 it looks at that ledger, sees who originally asks for it, 275 00:13:04.159 --> 00:13:06.799 restamps the internal address on it, and passes it back 276 00:13:06.799 --> 00:13:07.480 to your laptop. 277 00:13:07.639 --> 00:13:10.559 And it is doing this for every single packet, for 278 00:13:10.639 --> 00:13:13.879 every single device in the house simultaneously. 279 00:13:13.200 --> 00:13:15.679 Thousands and thousands of times a second. That is exactly 280 00:13:15.759 --> 00:13:18.440 why cheap home routers sometimes freeze up and need to 281 00:13:18.480 --> 00:13:22.039 be rebooted. Maintaining that neat translation table in this memory 282 00:13:22.120 --> 00:13:23.080 is really hard work. 283 00:13:23.320 --> 00:13:26.360 That is just incredible, And related to this, the router 284 00:13:26.480 --> 00:13:29.000 is usually also the thing handing out those internal extension 285 00:13:29.039 --> 00:13:30.159 numbers in the first place. Right. 286 00:13:30.399 --> 00:13:35.200 Yes, that service is called DACP Dynamic Host Configuration Protocol. 287 00:13:35.840 --> 00:13:38.519 It's basically the office manager that assigns the extension so 288 00:13:38.600 --> 00:13:40.879 your phone and your laptop don't accidentally fight over the 289 00:13:40.919 --> 00:13:44.279 same IP address, but does something else that's absolutely critical 290 00:13:44.320 --> 00:13:47.120 and tells your computer where to find the DNS server. 291 00:13:47.320 --> 00:13:50.759 Ah DNS the famous phone book of the Internet. 292 00:13:50.879 --> 00:13:52.919 I actually prefer to think of it as the contacts 293 00:13:52.919 --> 00:13:57.000 app on your smartphone, because nobody actually memorizes phone numbers anymore. 294 00:13:57.039 --> 00:13:59.039 You don't type one four to two point two, five, 295 00:13:59.159 --> 00:14:01.360 zero point one nine, zero point four to six into 296 00:14:01.399 --> 00:14:04.720 your browser. You just type Google dot com. 297 00:14:04.879 --> 00:14:06.320 But the computers only speak in. 298 00:14:06.320 --> 00:14:09.399 Numbers, right, So the DNS system is the translation bridge 299 00:14:09.440 --> 00:14:12.519 between human words and computer numbers. And Shaw shows us 300 00:14:12.519 --> 00:14:14.480 something really fascinating here when we look at it through 301 00:14:14.480 --> 00:14:18.159 wire shark. We talked about TCP earlier, that highly reliable, 302 00:14:18.240 --> 00:14:22.759 slightly slow, handshake heavy protocol. DNS doesn't usually use CCP. 303 00:14:22.919 --> 00:14:24.200 It uses UDP, the. 304 00:14:24.240 --> 00:14:26.759 User Data Ground protocol. Why does it use a different rule. 305 00:14:26.600 --> 00:14:30.440 Book Because UDP is fire and forget there is no 306 00:14:30.519 --> 00:14:33.480 three way handshake, There is no polite Did you hear me? 307 00:14:33.519 --> 00:14:36.279 I heard you. You literally just shout into the void 308 00:14:36.480 --> 00:14:39.600 where is Google? And the DNS server just shouts back 309 00:14:39.639 --> 00:14:40.960 the IP address. 310 00:14:40.679 --> 00:14:43.279 Because speed is everything in that moment. You don't want 311 00:14:43.320 --> 00:14:45.399 to wait around for a multi step handshake just to 312 00:14:45.440 --> 00:14:47.720 find out where the website is located exactly. 313 00:14:47.840 --> 00:14:50.919 Every millisecond counts. And in wire Shark, if you dissect 314 00:14:50.960 --> 00:14:53.360 a DNS packet, you can see all the layers stacked 315 00:14:53.440 --> 00:14:56.519 up beautifully. You see the ethernet frame with the physical 316 00:14:56.679 --> 00:14:59.559 MS addresses of the hardware. You see the IP layer 317 00:14:59.600 --> 00:15:02.200 with the sore and destination addresses. You see the UDP 318 00:15:02.360 --> 00:15:04.039 transport layer operating on port. 319 00:15:03.919 --> 00:15:07.039 Fifty three, and then finally you see the payload, the 320 00:15:07.080 --> 00:15:08.440 actual query you typed. 321 00:15:08.600 --> 00:15:10.759 And this is where the deep dive gets very literal. 322 00:15:11.320 --> 00:15:13.759 Shaw encourages his readers to look down at pain three 323 00:15:13.840 --> 00:15:17.039 in the wire Shark interface, the raw hexadescimal dump. 324 00:15:17.120 --> 00:15:19.279 This is the part that looks like matrix code, just 325 00:15:19.360 --> 00:15:22.320 walls of numbers and letters like zero's and f's cascading 326 00:15:22.320 --> 00:15:23.480 on the right side of the screen. 327 00:15:23.759 --> 00:15:26.960 It really demystifies how the Internet works at a physical level. 328 00:15:27.320 --> 00:15:30.519 When you type www, the network doesn't actually send the 329 00:15:30.559 --> 00:15:34.240 letter W. It sends the hexadecimal value seventy seven. So 330 00:15:34.279 --> 00:15:36.159 if you look closely at that raw dump, you will 331 00:15:36.159 --> 00:15:39.080 literally see seventy seven seventy seven in the data stream. 332 00:15:39.279 --> 00:15:42.120 And what about a full word like YouTube, It's broken 333 00:15:42.159 --> 00:15:44.279 down letter by letter by its aske code, so it 334 00:15:44.279 --> 00:15:47.639 shows up as seventy nine six F seventy five, seventy four, 335 00:15:47.759 --> 00:15:49.360 seventy five sixty two sixty five. 336 00:15:49.639 --> 00:15:52.399 It is genuinely wild to think about. I mean, billion 337 00:15:52.440 --> 00:15:57.440 dollar industries, viral videos, entire political revolutions of being coordinated. Yeah, 338 00:15:57.480 --> 00:16:00.159 and at the very bottom of the technology stack, it 339 00:16:00.200 --> 00:16:03.639 is just seventy sevens and six f's flying as pulses 340 00:16:03.639 --> 00:16:06.039 of light through a fiber optic cable under the ocean. 341 00:16:06.120 --> 00:16:09.159 It is quite literally just data. But having that realization 342 00:16:09.240 --> 00:16:11.240 seeing it right there in wire Shark, it brings up 343 00:16:11.240 --> 00:16:13.679 the big scary question of network security. If it's all 344 00:16:13.759 --> 00:16:16.000 just data and I can easily see it wire shark 345 00:16:16.039 --> 00:16:17.879 on my laptop, can you see it too? If I'm 346 00:16:17.879 --> 00:16:19.519 sitting cross from you to coffee shop, can you see 347 00:16:19.519 --> 00:16:21.080 my bank password flying by an hexco? 348 00:16:21.399 --> 00:16:23.639 And that brings us to the final and honestly probably 349 00:16:23.639 --> 00:16:26.159 the most important topic covered in the source material, the 350 00:16:26.200 --> 00:16:28.080 locked box HTTPS. 351 00:16:28.600 --> 00:16:31.440 This is the fundamental difference between sending a postcard through 352 00:16:31.440 --> 00:16:35.960 the mail and sending a locked titanium. Briefcase, standard HTTP 353 00:16:36.120 --> 00:16:38.639 traffic is sent in clear text if you look at 354 00:16:38.679 --> 00:16:40.679 it in wire Shark you can read the news article 355 00:16:40.720 --> 00:16:42.639 the person is reading. You can see their search queries, 356 00:16:42.679 --> 00:16:44.759 you can read their password. It's just sitting right there 357 00:16:44.799 --> 00:16:45.720 in pain three. 358 00:16:45.519 --> 00:16:47.799 Which is terrifying for anyone using public. 359 00:16:47.519 --> 00:16:50.200 Wi Fi, which is exactly why almost the entire modern 360 00:16:50.240 --> 00:16:54.639 web has force fully moved to HTTPS. The S stands 361 00:16:54.639 --> 00:16:59.320 for security. It uses TLS Transport Layer security to completely 362 00:16:59.480 --> 00:17:02.320 encrypt the payload before it ever leaves your machine. 363 00:17:02.480 --> 00:17:04.839 But here is the nuance that I actually found really 364 00:17:04.839 --> 00:17:08.720 surprising in Shaw's breakdown. Even with HTTPS turned on, you 365 00:17:08.759 --> 00:17:11.160 can still see some things in wire shark. The connection 366 00:17:11.400 --> 00:17:13.200 isn't totally invisible. 367 00:17:12.720 --> 00:17:15.799 That's correct. The connection still relies on TCP underneath it all, 368 00:17:15.839 --> 00:17:18.160 so you still see that initial three way handshake. And 369 00:17:18.279 --> 00:17:21.160 right after that you see a packet labeled client hello. 370 00:17:21.400 --> 00:17:24.400 This is the very start of the secure cryptographic. 371 00:17:23.799 --> 00:17:27.319 Negotiation, the client hello. It sounds very polite. What is 372 00:17:27.440 --> 00:17:29.079 actually inside that packet. 373 00:17:28.880 --> 00:17:32.240 A lot of technical metadata. Your computer is essentially telling 374 00:17:32.319 --> 00:17:34.559 the server hi, here is a list of all the 375 00:17:34.599 --> 00:17:40.119 complex encryption codes and ciphers my browser understands. But crucially, 376 00:17:40.640 --> 00:17:45.359 it also sends the SNI the server name indication. Think 377 00:17:45.400 --> 00:17:48.720 of this as the two address printed on the outside 378 00:17:48.759 --> 00:17:50.400 of that locked titanium briefcase. 379 00:17:50.720 --> 00:17:53.039 So if a hacker or even just the network admin 380 00:17:53.079 --> 00:17:55.119 at my office is running wire Shark, they can see 381 00:17:55.119 --> 00:17:56.960 that I am visiting news eighteen dot com. 382 00:17:57.119 --> 00:17:59.559 Yes, they can see the destination IP, and they can 383 00:17:59.599 --> 00:18:01.799 clearly the domain name in the S and I field, 384 00:18:02.400 --> 00:18:05.640 but they absolutely cannot see what is inside the briefcase. 385 00:18:05.720 --> 00:18:07.559 So my boss knows I'm on a news site, but 386 00:18:07.599 --> 00:18:10.119 they have no idea which specific article I'm reading or 387 00:18:10.119 --> 00:18:11.440 what I'm typing into the search bar. 388 00:18:11.640 --> 00:18:14.960 Exactly in wire Shark, after that initial polite hello phase, 389 00:18:15.240 --> 00:18:18.359 every single packet that follows is just labeled application data. 390 00:18:18.720 --> 00:18:20.319 And if you drop down to look at the hexpain 391 00:18:20.319 --> 00:18:22.480 where we clearly saw seven seven seven seven to seven 392 00:18:22.559 --> 00:18:26.440 seven seven earlier, now it's just completely random garbage. It's 393 00:18:26.480 --> 00:18:27.480 crambled noise. 394 00:18:27.480 --> 00:18:29.759 Because the network sniffer doesn't have the key to unlock 395 00:18:29.799 --> 00:18:30.440 the briefcase. 396 00:18:30.720 --> 00:18:34.200 Right, The whole system relies on public key encryption. The 397 00:18:34.279 --> 00:18:37.240 destination server holds a private key that it never ever 398 00:18:37.359 --> 00:18:42.599 shares over the wire. Without that specific mathematical key, unscrambling 399 00:18:42.599 --> 00:18:45.039 that noise is virtually impossible. 400 00:18:45.240 --> 00:18:48.519 But Shaw mentions that in the context of forensic analysis. 401 00:18:48.880 --> 00:18:52.480