WEBVTT - This file was automatically generated by VIMEO 1 00:00:08.200 --> 00:00:11.300 Hello everyone. Welcome back in this playlist 2 00:00:11.300 --> 00:00:14.700 section will take a deep dive into the network. Protocols 3 00:00:14.700 --> 00:00:18.400 such as TCP and UDP and Sumo. So, 4 00:00:18.400 --> 00:00:21.400 in part one, we'll be taking a look at ECP first 5 00:00:21.400 --> 00:00:22.500 part by the UDP. 6 00:00:23.600 --> 00:00:26.900 So as we have looked at in a previous module as 7 00:00:26.900 --> 00:00:29.700 to, how does a TCP session is being maintained? 8 00:00:29.300 --> 00:00:33.000 So TCP is a connection-oriented protocol. That 9 00:00:32.400 --> 00:00:35.500 means it will create the history as 10 00:00:35.500 --> 00:00:38.500 to what the request was and ensure 11 00:00:38.500 --> 00:00:42.000 that packets are being delivered in a timely fashion. So 12 00:00:41.200 --> 00:00:44.300 just to reiterate the TCP handshake, is 13 00:00:44.300 --> 00:00:47.400 a three-way handshake in which the first step the 14 00:00:47.400 --> 00:00:50.400 client will send out syn packet, which 15 00:00:50.400 --> 00:00:53.200 will have a random value X, just to initiate the connection. 16 00:00:54.700 --> 00:00:57.400 Followed by talk knowledge that particular request, the 17 00:00:57.400 --> 00:01:00.800 server will send back seen an attack in 18 00:01:00.800 --> 00:01:03.500 which the app could be limited by value. 1 19 00:01:03.500 --> 00:01:07.200 and sin will have understood random number and 20 00:01:06.200 --> 00:01:09.300 order to finally confirm the 21 00:01:09.300 --> 00:01:13.200 connection to client will again acknowledge was 22 00:01:12.300 --> 00:01:15.100 knowledgeable and packet with an 23 00:01:15.100 --> 00:01:18.600 increment value of y plus 1. So 24 00:01:18.600 --> 00:01:21.800 now let's try to figure out, how can we actually analyze 25 00:01:21.800 --> 00:01:22.700 using the tools? 26 00:01:25.400 --> 00:01:28.400 You can see, I have a tool called Wireshark that 27 00:01:28.500 --> 00:01:31.600 I will be using in order to analyze the TCP packets. 28 00:01:32.800 --> 00:01:35.500 So my shop is nothing but a packet capture 29 00:01:35.500 --> 00:01:38.700 tool which can be used over the network to 30 00:01:38.700 --> 00:01:41.600 capture draw traffic and this particular tool 31 00:01:41.800 --> 00:01:45.000 will actually segregate each of those requests and 32 00:01:44.200 --> 00:01:46.500 give us more addition Commission. 33 00:01:47.900 --> 00:01:50.200 This is something very similar to 34 00:01:50.200 --> 00:01:53.300 a proxy tool that we can use for web browsers as 35 00:01:53.300 --> 00:01:57.000 well, which are actually sniff out the web traffic such 36 00:01:56.400 --> 00:02:00.400 as top speed of Fiddler. Let's 37 00:02:00.400 --> 00:02:03.200 try to focus on the first three requests over here. 38 00:02:04.600 --> 00:02:07.300 It's what I've tried for your is that I've actually 39 00:02:07.300 --> 00:02:11.000 looked at an entire TCP stream connection. So 40 00:02:10.200 --> 00:02:13.400 this is the first particular packet that I have on 41 00:02:13.400 --> 00:02:14.300 my packet capture. 42 00:02:15.700 --> 00:02:18.200 So as we can see, we have all 43 00:02:18.200 --> 00:02:21.400 the three particular handshake in place. That is 44 00:02:21.500 --> 00:02:24.200 the same packet followed by the scene 45 00:02:24.200 --> 00:02:24.800 and back. 46 00:02:25.800 --> 00:02:28.100 And the last again being an act packet. That is 47 00:02:28.100 --> 00:02:29.400 a three-way handshake. 48 00:02:31.200 --> 00:02:34.300 This is the particular header sequence that we can see 49 00:02:34.300 --> 00:02:37.100 who you that has the source port and the 50 00:02:37.100 --> 00:02:42.000 recession Port of those communication between two particular eyepiece. So, 51 00:02:41.600 --> 00:02:45.000 if you look at the first sequence 0, 52 00:02:44.300 --> 00:02:47.700 that is something known as a relative sequence 53 00:02:47.700 --> 00:02:50.600 number. The reason particular 54 00:02:50.600 --> 00:02:53.200 tool is showing the degree sequence. Number is 55 00:02:53.200 --> 00:02:55.100 just for human readable form. 56 00:02:56.400 --> 00:02:59.700 In actual practice, we will have a huge pseudo random number 57 00:02:59.100 --> 00:03:02.600 that will be used for the network. It 58 00:03:02.600 --> 00:03:05.800 is something that makes it very difficult and interesting for 59 00:03:05.800 --> 00:03:10.700 the network. In order to perform any session. Hijacking. So 60 00:03:10.300 --> 00:03:13.400 if we want to actually see the raw sequence 61 00:03:13.400 --> 00:03:16.200 number, so what can do is that just go to 62 00:03:16.200 --> 00:03:16.600 edit? 63 00:03:17.500 --> 00:03:18.300 Preferences. 64 00:03:19.600 --> 00:03:22.000 Protocols and scroll all the 65 00:03:22.200 --> 00:03:23.400 way down to TCP. 66 00:03:27.700 --> 00:03:30.500 Once you go to TCP, we see a particular option that 67 00:03:30.500 --> 00:03:34.100 says rate of sequence numbers. Just try to uncheck 68 00:03:33.100 --> 00:03:34.700 this box. 69 00:03:36.100 --> 00:03:37.300 Just let us click on, okay. 70 00:03:38.800 --> 00:03:41.400 Now what we see is a pseudo random 71 00:03:41.400 --> 00:03:44.500 number. So that is how a particular 72 00:03:44.500 --> 00:03:47.100 value as we increment. I to 1. If you see in 73 00:03:47.100 --> 00:03:50.400 this particular, second request was intact. So the logic to 74 00:03:50.400 --> 00:03:53.400 remain the same. We're sequence, packet 75 00:03:53.400 --> 00:03:56.400 will have a pseudo random number in order to make the session ID, 76 00:03:56.500 --> 00:03:59.200 quite unique and record backward would 77 00:03:59.200 --> 00:04:02.600 be incremented by 1. And similarly, on 78 00:04:02.600 --> 00:04:05.700 the last packet. You can see an ack packet 79 00:04:05.100 --> 00:04:07.100 would be granted by one. 80 00:04:08.400 --> 00:04:11.500 This is something we can actually use to analyze. And 81 00:04:11.500 --> 00:04:14.700 for each of those TCP streams. You can actually 82 00:04:14.100 --> 00:04:17.300 if you want to understand how the companies are really 83 00:04:17.300 --> 00:04:20.500 happening. You can just click on a particular packet and 84 00:04:20.500 --> 00:04:23.300 just click on follow. And the TCP stream that 85 00:04:23.300 --> 00:04:26.400 is how you can actually see the raw packet in place. 86 00:04:28.800 --> 00:04:31.700 So based on the traffic, this is since is something that 87 00:04:31.700 --> 00:04:34.700 is being encrypted over SSL and TLS. We 88 00:04:34.700 --> 00:04:37.400 see that we are not able to read actual 89 00:04:37.400 --> 00:04:40.400 data, but for normal scenarios, there 90 00:04:40.400 --> 00:04:44.000 is a place where a non-secure protocols 91 00:04:43.200 --> 00:04:46.200 such as FTP or 92 00:04:46.200 --> 00:04:49.300 an HTTP protocol is being used. That 93 00:04:49.300 --> 00:04:52.600 is somewhere. We can actually see the raw packets in place and 94 00:04:52.600 --> 00:04:55.200 we can actually read what data is being 95 00:04:55.200 --> 00:04:58.200 transferred between both of those assets over 96 00:04:58.200 --> 00:04:58.400 there. 97 00:04:58.600 --> 00:04:58.800 Cool. 98 00:05:02.900 --> 00:05:06.300 Moon covered. Let's look at UDP protocol. 99 00:05:07.500 --> 00:05:10.200 So in contrast seed, TCP itself, this 100 00:05:10.200 --> 00:05:13.500 is the conditions less protocol and in base, the data is 101 00:05:13.500 --> 00:05:16.200 sent over the connection automatically. 102 00:05:17.600 --> 00:05:20.600 Unlike PCP. There's no proper communication in 103 00:05:20.600 --> 00:05:23.500 which there will be no acknowledgement or anything. 104 00:05:23.800 --> 00:05:26.700 Once the client sends a request. So 105 00:05:26.700 --> 00:05:29.500 will actually start bombarding with the response and 106 00:05:29.500 --> 00:05:33.000 just hoping with the fact that the data just reaches client. 107 00:05:34.600 --> 00:05:37.500 This protocol is actually needed in terms as 108 00:05:37.500 --> 00:05:40.700 compared to TCP because there are many protocols 109 00:05:40.700 --> 00:05:43.800 that would need a faster data services, 110 00:05:43.100 --> 00:05:46.700 such as DNS tftp or 111 00:05:46.700 --> 00:05:49.900 corrected example, we can focus on video 112 00:05:49.900 --> 00:05:52.600 stream. So these have to be real time 113 00:05:52.100 --> 00:05:55.500 in such a way that all the packets are 114 00:05:55.500 --> 00:05:58.000 sent back to the client as soon as possible. 115 00:06:02.100 --> 00:06:05.800 Let's take a look at again, over the wash cycle itself. How 116 00:06:05.800 --> 00:06:08.400 does one actually figure out, figure out or 117 00:06:08.400 --> 00:06:11.400 UDP packet? Or the search bar? 118 00:06:11.900 --> 00:06:13.900 You can just type our UDP. 119 00:06:15.400 --> 00:06:19.000 What is that do is that it will list out all the protocols that 120 00:06:18.100 --> 00:06:20.400 are working over? UDP. 121 00:06:23.200 --> 00:06:26.300 So unlike TCP, we can see that a UDP packet is quite 122 00:06:26.300 --> 00:06:30.000 small in beta cells. Eight, bytes in the header and 123 00:06:29.200 --> 00:06:32.400 only four fields. That 124 00:06:32.400 --> 00:06:35.400 would be your Source. Port destination, port and 125 00:06:35.400 --> 00:06:38.200 the length of the data itself. That's one where 126 00:06:38.200 --> 00:06:41.500 the packet which will actually use to check the checksum. 127 00:06:41.100 --> 00:06:44.200 So checksum is just to calculate if all 128 00:06:44.200 --> 00:06:47.400 the data has been sent as it is or if 129 00:06:47.400 --> 00:06:48.400 they have been tampered. 130 00:06:49.700 --> 00:06:52.200 But if you see in this particular scenario, it shows that it 131 00:06:52.200 --> 00:06:55.500 is unverified. So again, let's go back 132 00:06:55.500 --> 00:06:56.100 to edit. 133 00:06:57.100 --> 00:06:57.900 Preferences. 134 00:06:59.500 --> 00:07:02.100 Protocols, scroll down all the way 135 00:07:02.100 --> 00:07:02.800 to UT p. 136 00:07:06.800 --> 00:07:09.700 So we do see an option, which says validate 137 00:07:09.700 --> 00:07:12.200 the you to pick Jackson. So let's just click on 138 00:07:12.200 --> 00:07:12.400 it. 139 00:07:15.300 --> 00:07:18.400 So once we just clicked on it, we can see. Now it is able to 140 00:07:18.400 --> 00:07:21.800 actually calculate the checksum. This is something that 141 00:07:21.800 --> 00:07:24.400 will actually validate the data saying if someone 142 00:07:24.400 --> 00:07:26.000 has actually tampered it or not. 143 00:07:30.300 --> 00:07:33.200 Same time if you want to figure out if which Protocols are 144 00:07:33.200 --> 00:07:36.200 actually using UDP, we can just click on the YouTube 145 00:07:36.200 --> 00:07:39.200 itself and just apply as 146 00:07:39.200 --> 00:07:42.500 column. So which will actually say 147 00:07:42.500 --> 00:07:45.700 if a particular protocol over the sniffed 148 00:07:45.700 --> 00:07:48.100 packet itself is actually using you to be 149 00:07:48.100 --> 00:07:48.500 alone. 150 00:07:51.600 --> 00:07:54.600 So just a summary to the section PCP is 151 00:07:54.600 --> 00:07:58.000 always reliable and it will follow a three-way handshake. This 152 00:07:57.200 --> 00:08:00.500 is used in most of the cases where 153 00:08:01.700 --> 00:08:04.100 We need to ensure that connection is 154 00:08:04.100 --> 00:08:07.100 actually reliable weather. Data is actually arriving on 155 00:08:07.100 --> 00:08:08.400 time and in sequence. 156 00:08:09.800 --> 00:08:12.500 And UTP is something that is being used 157 00:08:12.200 --> 00:08:16.400 for more, offer fast data transmission. So 158 00:08:15.400 --> 00:08:18.600 that means that the application layer 159 00:08:18.600 --> 00:08:21.400 is the one which will have to take care of 160 00:08:21.400 --> 00:08:24.400 all the error control or the sequence of data to 161 00:08:24.400 --> 00:08:26.800 something that the protocol itself will not take. 162 00:08:28.300 --> 00:08:29.700 Edible section. Thank you.