WEBVTT 00:00.110 --> 00:00.620 Hey, everyone. 00:00.620 --> 00:01.520 And welcome back. 00:01.520 --> 00:06.650 In today's video, we will have a high level overview about the Https protocol. 00:06.650 --> 00:11.120 Now, Https is basically an extension to Http. 00:11.420 --> 00:18.950 Now in Https, the communication is encrypted using the transport layer security, which is also referred 00:18.950 --> 00:20.390 as the TLS. 00:20.480 --> 00:24.530 Now TLS is basically a newer version of SSL. 00:24.680 --> 00:28.190 I'm sure you might have heard SSL somewhere down the way. 00:28.310 --> 00:33.380 Now the protocol, the Https protocol is referenced here. 00:33.380 --> 00:41.450 So this protocol is also referred to as Http over TLS or Http over SSL. 00:41.690 --> 00:49.130 So many times within your browser when you open up websites like banking websites or typically websites 00:49.130 --> 00:56.420 which might contain a sensitive information, you will see this lock and also green Https. 00:56.420 --> 01:02.160 So this lock basically means that your community version is secure. 01:02.550 --> 01:10.440 So this is my test website and if you see the domain is labs internal.com and it has this green lock. 01:10.440 --> 01:14.010 All right so this green lock and it is https. 01:14.040 --> 01:16.140 Same goes with the banking website. 01:16.140 --> 01:21.360 Even for banking website you see it has this green lock and it has the Https. 01:21.360 --> 01:26.790 So that basically means that the communication that might be happening between the client so client 01:26.790 --> 01:30.240 can be this browser and the website here. 01:30.240 --> 01:37.350 In this case it is city that communication is encrypted and that can be verified with this green lock 01:37.380 --> 01:40.440 or the Https within the domain. 01:41.400 --> 01:47.340 So let's understand certain scenarios where Https proves to be very useful. 01:47.670 --> 01:55.380 So in this scenario you have a user who is sending his username and password in a plain text to web 01:55.380 --> 01:57.180 server for authentication. 01:57.180 --> 01:58.740 So you have a web server. 01:58.740 --> 02:02.730 So this can be certain applications and this is the user. 02:02.730 --> 02:10.020 So you open up this website from your browser and the website asks you for login and password. 02:10.020 --> 02:16.290 So you put your login username as KB Labs and you put the password as the certain password. 02:16.620 --> 02:23.070 Now if there is an attacker who is sitting between them, so if there is an attacker who is sitting 02:23.070 --> 02:30.270 and sniffing the network, then he will be able to fetch all the credentials which are passing in this 02:30.270 --> 02:32.160 network within plain text. 02:32.160 --> 02:37.080 So if you see over here, you have an attacker who is doing a man in the middle attack. 02:37.110 --> 02:42.330 He fetched the username, he fetched the password and he stored it within his database. 02:42.330 --> 02:48.150 So the longer he sniffs the network, the more username and password he will be able to get. 02:48.180 --> 02:53.460 Now, the reason why he is able to get the password and username is because they are travelling in a 02:53.460 --> 02:54.300 plain text. 02:54.300 --> 02:59.490 So there are various plain text protocol like you have FTP, you have Http. 02:59.640 --> 03:06.540 So if you use that plain text protocol to transfer sensitive data, then if there is an attack then 03:06.570 --> 03:08.610 your credentials would be leaked. 03:08.640 --> 03:13.680 Now there is also a second scenario where you have a man in the middle with integrity attacks. 03:13.680 --> 03:20.910 So what happens in the integrity attack is that attacker is changing the payment details while the packets 03:20.910 --> 03:21.930 are in transit. 03:21.930 --> 03:30.990 So let's say that you are sending information that send $100 to Zelle at the rate so now attacker can 03:30.990 --> 03:35.520 modify that detail, so attacker can receive it and he can modify the details. 03:35.640 --> 03:40.110 So it says send $100 to attacker at the rate example dot internal. 03:40.110 --> 03:47.850 So now the destination server will receive this details and if the destination server sends $100 to 03:47.850 --> 03:51.000 the attacker, then his attack is completely successful. 03:51.000 --> 03:56.790 So this is the integrity attack where the data itself is changed during the transit. 03:56.790 --> 04:04.140 So to avoid the previous two scenarios that we discussed and also various others, various cryptographic 04:04.140 --> 04:11.220 standards were clubbed together to establish a secure communication over an untrusted network. 04:11.220 --> 04:16.020 And those standards which were clubbed together were known as SSL. 04:16.050 --> 04:23.940 TLS So SSL was the initial version of the protocol, which was basically intended for secure communication. 04:24.060 --> 04:30.090 So SSL 2.0 was released in the year 1995, then certain improvements. 04:30.090 --> 04:33.900 Then you have SSL 3.0 on 1996. 04:33.930 --> 04:35.850 Then the name got changed. 04:35.850 --> 04:42.090 So SSL, the various protocols which are used in SSL 3.0 could be easily compromised. 04:42.240 --> 04:47.580 So let's say that you are using a secure communication with SSL 3.0. 04:47.610 --> 04:54.390 Then the protocols which were being used because SSL and TLS are just cryptographic standards. 04:54.390 --> 04:57.690 So it in turn contains a lot of other protocols. 04:57.690 --> 04:59.940 Some protocols are generally used. 05:00.140 --> 05:00.650 Encryption. 05:00.650 --> 05:03.800 Some protocols are being used for integrity and others. 05:03.800 --> 05:05.900 So SSL 3.0. 05:05.930 --> 05:09.820 The protocols that were used here were deemed to be unsafe. 05:09.830 --> 05:11.980 That means they could be compromised. 05:11.990 --> 05:12.800 So. 05:12.890 --> 05:19.250 SSL 3.0 ceased to be used and you had the brand new standards. 05:19.250 --> 05:21.710 So TLS is just the name change. 05:22.130 --> 05:28.060 The overall concept remains the same here with different protocols being used here. 05:28.070 --> 05:37.370 So you have TLS 1.0 in 1999, then you have 1.1, then you have 1.2 and you have the latest 1.3 in 2018, 05:37.370 --> 05:38.420 which was released. 05:38.450 --> 05:42.530 Now let's understand Https in a easy way. 05:42.530 --> 05:49.670 So what happens here is that every website has a certificate, so every website which uses Https has 05:49.670 --> 05:50.600 a certificate. 05:50.600 --> 05:56.120 So certificate is basically like a passport which gets issued by a trusted entity. 05:56.120 --> 06:00.060 So passport generally gets issued by a government. 06:00.060 --> 06:01.380 So whichever government. 06:01.380 --> 06:06.950 So in my case, if I am living in India, then the passport is issued by government of India. 06:06.960 --> 06:13.050 However, before passport gets issued, whatever contents are there within that passport. 06:13.050 --> 06:19.620 So it might be your name, your date of birth, your address, that contents will be verified by the 06:19.620 --> 06:20.370 government. 06:20.370 --> 06:26.700 So typically in India, before the passport is issued, you will see that the cops, they visit your 06:26.700 --> 06:29.940 place to verify whether you are actually living there. 06:29.940 --> 06:33.930 And the data that you have shared is not malicious one. 06:33.930 --> 06:37.320 So everything is verified within your passport. 06:37.320 --> 06:42.030 And in a similar way, the certificate is also like a passport. 06:42.030 --> 06:48.780 It contains a lot of information and that certificate is issued by a trusted entity. 06:48.810 --> 06:56.730 So this certificate has a lot of details like your domain name, its validity, the public key and others. 06:56.730 --> 07:01.710 So this is a sample certificate on how exactly it looks like. 07:01.710 --> 07:06.900 So if you see this certificate is issued to Vodacom, similar to passport. 07:06.900 --> 07:10.880 So if I have a passport, the passport will have a name, say Zebra. 07:11.040 --> 07:17.640 Similarly, the certificate that is been issued for your website, it will have the domain name of your 07:17.640 --> 07:19.680 website, which is Vodacom. 07:19.680 --> 07:23.730 Now, along with that, it has a lot of other information like version. 07:23.730 --> 07:29.460 You have serial number, you have certificate signature algorithm, you have the issuer and also the 07:29.460 --> 07:33.630 validity as well as the public key related information. 07:33.810 --> 07:40.050 Now generally, whenever you open up a Https website, the web server will send you its certificate. 07:40.050 --> 07:41.400 So that is the first thing. 07:41.400 --> 07:45.480 So you have, let's say the web server has sent you its own certificate. 07:45.480 --> 07:49.590 So this is like a big certificate because it contains a lot of information. 07:49.740 --> 07:51.660 Now the browser. 07:51.660 --> 07:57.660 So in this case client verifies if it trusts the certificate issuer or not. 07:57.660 --> 07:58.860 So this is a big thing. 07:58.860 --> 08:03.390 So the client has to validate if it trusts or not. 08:03.390 --> 08:03.900 Okay. 08:03.900 --> 08:10.380 Now if it trusts, it will also verify all the details which are within the certificate. 08:10.380 --> 08:16.290 Like when you go international, then during the channel they will verify each and every thing. 08:16.290 --> 08:24.150 Then once it verifies and it accepts it to be genuine, then it will take the public key information 08:24.150 --> 08:25.500 from this certificate. 08:25.500 --> 08:31.260 So this certificate has the public key and then it also initiates the negotiation. 08:31.260 --> 08:37.500 Now we know that a TLS is basically used primarily for secure communication, so that is one of the 08:37.500 --> 08:38.870 important use case. 08:38.880 --> 08:44.400 So in order for secure communication, it takes the public key information so you will understand the 08:44.400 --> 08:48.030 public and private key if you know the asymmetric key encryption. 08:48.030 --> 08:55.470 So asymmetric key encryption is used to generate a new temporary symmetric key which will be used for 08:55.470 --> 08:56.760 secure communication. 08:56.760 --> 08:58.110 So what happens here? 08:58.110 --> 09:02.040 It takes the public key information and a secure password. 09:02.040 --> 09:05.190 So it's something like a secure password is generated. 09:05.190 --> 09:13.740 So that secure password, which is referred as a symmetric key, will be used for encrypted and decryption 09:13.740 --> 09:15.690 related operation throughout the channel. 09:15.720 --> 09:22.050 However, that secure symmetric key is passed through asymmetric key encryption here. 09:22.170 --> 09:23.970 So that's the high level overview. 09:23.970 --> 09:26.130 Let me quickly show you a few things. 09:26.250 --> 09:29.540 So if I just open up the labs internal.com. 09:29.550 --> 09:31.110 So this is our test website. 09:31.110 --> 09:36.330 So when I just open this up, it basically says secure connection. 09:36.330 --> 09:41.790 So let me just expand it and it says verified by let's encrypt. 09:41.790 --> 09:48.240 So that basically means that whatever details that are part of this certificate are being verified by 09:48.240 --> 09:49.110 a issuer. 09:49.110 --> 09:51.600 In this case, the issuer is let's encrypt. 09:51.600 --> 09:53.280 There can be multiple issuers. 09:54.090 --> 09:59.610 So when you do a more information, you will be able to get the certificate. 10:00.120 --> 10:00.870 Information. 10:00.870 --> 10:05.970 So here we see that this certificate is issued to labs internal.com. 10:06.420 --> 10:13.020 It's verified by letsencrypt and it expires on 24th September 2019. 10:13.050 --> 10:18.330 Now, if you go into the technical details, it says that the connection is encrypted. 10:18.330 --> 10:23.790 And basically these are the protocols which are being used for the overall encryption. 10:23.790 --> 10:28.080 And here you have TLS version 1.2. 10:28.200 --> 10:33.090 So if you want to look into the actual certificate, this is how the certificate looks like, where 10:33.090 --> 10:37.470 you have the common name, you have the serial number, you have the begins on. 10:37.470 --> 10:45.240 So when it was issued till when it is issued, that basically means the expiry as well as the fingerprint. 10:45.270 --> 10:50.090 Now, if you look into the details, these are all the details which are part of the certificate. 10:50.100 --> 10:54.960 So you have the certificate version, you have the serial number, you have the issuer. 10:54.960 --> 10:57.390 So in this case, the issuer is Letsencrypt. 10:57.630 --> 10:59.860 We already seen the validity. 10:59.890 --> 11:02.560 Now, this is one of the important part. 11:02.560 --> 11:07.660 So this is the public key algorithm, which is RSA, and this is the actual public key. 11:07.930 --> 11:08.440 All right. 11:08.440 --> 11:14.230 So this is the public key through which the new symmetric key is generated, which in turn would be 11:14.230 --> 11:17.320 used for the encrypted communication. 11:17.320 --> 11:23.110 So it's like you cannot really send that symmetric key towards the website in plaintext. 11:23.110 --> 11:26.980 If you send it in plaintext, again, the attacker will be able to find that out. 11:26.980 --> 11:34.810 So you make use of this asymmetric key encryption to send the new symmetric key, which will then be 11:34.810 --> 11:36.430 used for communication. 11:36.430 --> 11:37.840 So what happens? 11:37.840 --> 11:40.270 The web browser takes this public key. 11:40.270 --> 11:45.880 Then the symmetric key is encrypted with this public key and sent it over to the web server. 11:45.880 --> 11:52.450 Now, since the web server holds the private key, it will be able to decrypt the encrypted packet and 11:52.450 --> 11:54.940 then the communication can begin. 11:55.030 --> 11:59.410 Now one question comes is why will browser trust this? 11:59.410 --> 12:05.560 So let's say browser receives a certificate and the certificate says verified by x, y, Z. 12:05.860 --> 12:08.140 Now why will browser trust that? 12:08.140 --> 12:09.310 That is the first question. 12:09.310 --> 12:12.970 And second question is who will browser trust and who will it not trust? 12:12.970 --> 12:15.130 So in order to understand that. 12:17.520 --> 12:18.920 Let's go to options. 12:18.930 --> 12:24.390 We'll go to privacy and security and let's go to view certificates. 12:24.540 --> 12:30.900 So here, this basically contains the list of certificate authorities, which browser trusts. 12:30.900 --> 12:38.550 So these are the entire list of the certificate authority, which my current Firefox browser trusts. 12:39.180 --> 12:46.650 So if you go a bit up within the trusted entities, you also have let's encrypt over here. 12:46.650 --> 12:48.900 So this is how things work. 12:48.900 --> 12:54.870 So generally these issuers that you have, these issuers, you will have to pay to them. 12:54.870 --> 12:56.550 So let's open up one of them. 12:56.670 --> 12:59.610 So one of the issuers, you have a Comodo. 12:59.820 --> 13:04.140 So Comodo is also one of the trusted entities within the browser. 13:04.140 --> 13:11.580 So if you look into the SSL certificates, you can basically purchase the SSL certificates from them. 13:11.580 --> 13:18.490 So basically they will verify because the issuer, whoever is the issuer, has to verify the details. 13:18.490 --> 13:23.410 So if you're going through Comodo, then you will have to verify. 13:23.440 --> 13:27.280 Then the Comodo will verify the details here. 13:27.670 --> 13:29.260 So let's do one thing. 13:29.260 --> 13:31.570 Let me quickly open up Wireshark. 13:35.910 --> 13:40.260 And let's capture the packets going from the wireless interface. 13:40.950 --> 13:45.150 And now let's open up a new private window. 13:45.570 --> 13:48.390 And I'll open Labs internal.com. 13:49.980 --> 13:51.780 So let's go back to Wireshark. 13:51.810 --> 13:53.610 I'll stop the packet capture. 13:53.760 --> 13:54.930 So let's do one thing. 13:54.930 --> 13:58.150 Let's quickly find out the IP address associated with the domain. 13:58.170 --> 13:59.940 So this is the IP address. 14:00.600 --> 14:04.140 And we'll quickly create a filter. 14:06.880 --> 14:08.290 So this is a filter. 14:08.290 --> 14:13.470 So any packet going from my laptop towards the destination. 14:13.480 --> 14:16.210 So currently you see the first packet was sin. 14:16.210 --> 14:18.580 So this is part of the TCP handshake. 14:18.580 --> 14:22.000 So as part of the TLS handshake, here you have the client. 14:22.040 --> 14:22.270 Hello. 14:22.270 --> 14:28.450 So any client who wants to communicate via the TLS protocol, the first packet is generally the client. 14:28.480 --> 14:28.810 Hello. 14:29.110 --> 14:32.490 So if you go a bit down, you also have the client key exchange. 14:32.500 --> 14:37.630 So generally we already discussed that the server would typically send a certificate. 14:37.630 --> 14:42.160 So the certificate would have all the information, including the public key. 14:42.160 --> 14:48.820 So once the public key is being received by the client and the symmetric key is generated, then you 14:48.820 --> 14:51.100 have the key exchange, which happens. 14:51.130 --> 14:53.710 Then you have the Changecipherspec. 14:53.710 --> 14:57.730 And just after Changecipherspec you have the encrypted message. 14:57.730 --> 14:59.890 So this is part of the protocol. 14:59.890 --> 15:06.770 Again, we will not be discussing in detail about the TLS handshake as of now, but generally after 15:06.770 --> 15:11.720 this encrypted handshake message, then you typically have the application data. 15:11.990 --> 15:18.170 Now if you look into the application data, so all the data is basically encrypted, so you will not 15:18.170 --> 15:21.170 really know what exactly is being passed through. 15:21.200 --> 15:27.650 So if there is any attacker who is sitting in between, he will not be able to get what exactly is this? 15:27.680 --> 15:31.460 And if you look into the data protocol, it is Http over TLS. 15:31.490 --> 15:33.710 This is something that we discussed in the Slide one. 15:33.710 --> 15:39.350 To conclude this video, we'll just discuss the web server configuration because here when we open up 15:39.350 --> 15:43.310 labs internal.com, right, it automatically happened. 15:43.310 --> 15:47.030 The https trusted entity automatically appeared within the browser. 15:47.030 --> 15:52.310 But internally we saw that there was a lot of things that happens in the TLS handshake. 15:52.310 --> 15:58.010 So within the web server configuration, also the web server has to supply the certificate to the client. 15:58.010 --> 15:59.840 Otherwise how will the client know? 15:59.840 --> 16:04.400 So basically, so let's say this is a server name, this can be labs internal.com. 16:04.400 --> 16:11.360 So what happens here is that you have a stanza of SSL underscore certificate where this is the certificate 16:11.360 --> 16:11.630 chain. 16:11.630 --> 16:15.530 So this is the certificate which is being passed to the client. 16:15.530 --> 16:20.330 So client will then verify this certificate contents. 16:20.330 --> 16:23.300 And you also have the SSL certificate key. 16:23.300 --> 16:25.430 So this is basically the private key. 16:25.430 --> 16:30.500 So we know that within the asymmetric key encryption there is both a public key and the private key. 16:30.500 --> 16:37.790 So if a browser is encrypting the data with the public key, then the web server will decrypt the data 16:37.790 --> 16:42.080 with the corresponding private key, which is being stored within the web server. 16:42.080 --> 16:48.590 So the importance of this private key holds to be tremendously important because generally if this private 16:48.620 --> 16:54.080 key is being stolen, then the communication can be decrypted as well. 16:54.080 --> 16:57.290 So that's the high level overview about Https. 16:57.290 --> 17:04.540 I hope at a glance you understood the Https protocol and why exactly it is being used for. 17:04.550 --> 17:07.130 So with this we'll conclude this video.