1 00:00:03,920 --> 00:00:06,615 In the previous module, 2 00:00:06,615 --> 00:00:10,905 we have seen about user authentication in a lot of detail. 3 00:00:10,905 --> 00:00:17,610 We had seen how the user sends their credentials to their server from the client-side 4 00:00:17,610 --> 00:00:20,270 in either the header of 5 00:00:20,270 --> 00:00:24,870 their request message or the body of the request message and then subsequently, 6 00:00:24,870 --> 00:00:26,460 when they are authenticated, 7 00:00:26,460 --> 00:00:31,680 then their client will include either the cookie or the 8 00:00:31,680 --> 00:00:38,499 token in the header of the request message going from the client to the server. 9 00:00:38,499 --> 00:00:41,820 I'm sure some of you were cringing about 10 00:00:41,820 --> 00:00:47,010 the fact that we were communicating over in an insecure channel, 11 00:00:47,010 --> 00:00:50,520 meaning that anybody sitting in the middle who can 12 00:00:50,520 --> 00:00:54,780 listen to their messages going between the client 13 00:00:54,780 --> 00:00:57,570 and the server would be easily able to capture 14 00:00:57,570 --> 00:01:03,195 the credentials and then impersonate the genuine client. 15 00:01:03,195 --> 00:01:04,815 Of course, at that point, 16 00:01:04,815 --> 00:01:09,025 their emphasis was more on arranging the client and 17 00:01:09,025 --> 00:01:13,575 server communication with authentication of the client on the server-side. 18 00:01:13,575 --> 00:01:19,215 But any time you need to use user authentication, 19 00:01:19,215 --> 00:01:21,945 first, in the form of, say, 20 00:01:21,945 --> 00:01:25,940 supplying the credentials to authenticate yourself and thereafter, 21 00:01:25,940 --> 00:01:29,445 authenticating yourself by including either the cookie or 22 00:01:29,445 --> 00:01:33,840 the token in the header of the request message, 23 00:01:33,840 --> 00:01:36,290 you should be doing this over a secure channel. 24 00:01:36,290 --> 00:01:39,890 You should never communicate over an insecure channel, 25 00:01:39,890 --> 00:01:44,160 which means that you should not be using HTTP and then including 26 00:01:44,160 --> 00:01:48,780 these credentials into either the header or the body of the request messages. 27 00:01:48,780 --> 00:01:56,455 Instead, you should be using a secure version of the HTTP protocol or the HTTPS. 28 00:01:56,455 --> 00:02:01,830 Let's briefly talk about HTTPS in this lecture. 29 00:02:01,830 --> 00:02:07,140 Along the way, I will give you a five-minute introduction to cryptography and security. 30 00:02:07,140 --> 00:02:12,143 Obviously, cryptography and security is a very big topic in its own right. 31 00:02:12,143 --> 00:02:16,110 I'm just going to introduce you to the bare essentials that you need to 32 00:02:16,110 --> 00:02:21,820 understand to learn how HTTPS actually works. 33 00:02:21,820 --> 00:02:29,430 With this background, let's proceed to understand about cryptography and then onto 34 00:02:29,430 --> 00:02:34,110 the HTTPS protocol and how you would configure a server to use 35 00:02:34,110 --> 00:02:40,276 the HTTPS protocol and then the client to contact the server using HTTPS protocol, 36 00:02:40,276 --> 00:02:45,165 thereby, communication between the client and the server can be done in a secure manner 37 00:02:45,165 --> 00:02:51,180 by encrypting the data being sent between the client and the server-side. 38 00:02:51,180 --> 00:02:56,175 When you venture into the field of cryptography and security, 39 00:02:56,175 --> 00:03:00,375 you'll often hear people talking about symmetric key cryptography. 40 00:03:00,375 --> 00:03:02,970 Now, what does cryptography involve? 41 00:03:02,970 --> 00:03:07,635 If you need to send a message over a channel to another user, 42 00:03:07,635 --> 00:03:10,800 then you would want to be able to encrypt the message in 43 00:03:10,800 --> 00:03:14,310 such a way that only the receiver will be able to 44 00:03:14,310 --> 00:03:16,570 decrypt the message and obtain 45 00:03:16,570 --> 00:03:21,050 the information that you are trying to send to the receiver. 46 00:03:21,050 --> 00:03:26,730 So both the sender and the receiver should understand on establish between the two of 47 00:03:26,730 --> 00:03:32,930 them how this encryption process and how the decryption is going to work. 48 00:03:32,930 --> 00:03:34,365 For this to work, 49 00:03:34,365 --> 00:03:41,265 any encryption and decryption works based on exchange of secret keys. 50 00:03:41,265 --> 00:03:43,765 So in symmetric key cryptography, 51 00:03:43,765 --> 00:03:50,678 both the sender and the receiver will share a secret key between the two sites, 52 00:03:50,678 --> 00:03:55,165 and this secret key is known only to the sender and to the receiver side. 53 00:03:55,165 --> 00:03:58,260 So when the sender needs to send the message, 54 00:03:58,260 --> 00:04:04,755 then the sender will encrypt this message using a cryptography algorithm, 55 00:04:04,755 --> 00:04:09,795 which uses the secret key as the other input to this algorithm. 56 00:04:09,795 --> 00:04:13,875 And once this message is passed through this cryptography algorithm, 57 00:04:13,875 --> 00:04:17,068 then an encrypted message will be generated. 58 00:04:17,068 --> 00:04:24,160 Now, this encrypted message will be sent to the channel across to the receiver side. 59 00:04:24,160 --> 00:04:28,140 If you have a third party malicious user 60 00:04:28,140 --> 00:04:32,450 sitting in between and listening and capturing this encrypted message, 61 00:04:32,450 --> 00:04:34,740 they would have a hard time decrypting 62 00:04:34,740 --> 00:04:38,580 this message because for decrypting an encrypted message, 63 00:04:38,580 --> 00:04:40,645 you still need the secret key. 64 00:04:40,645 --> 00:04:42,375 Now, on the receiver side, 65 00:04:42,375 --> 00:04:44,856 when the encrypted message is received, 66 00:04:44,856 --> 00:04:48,815 then the receiver will apply and a decryption algorithm, 67 00:04:48,815 --> 00:04:50,715 which also takes as the input, 68 00:04:50,715 --> 00:04:56,590 the same secret key that was used on the sender side to encrypt the message. 69 00:04:56,590 --> 00:05:00,585 So upon decryption, the original message will be retrieved 70 00:05:00,585 --> 00:05:05,240 and can be processed on the receiver side. 71 00:05:05,240 --> 00:05:11,260 Now, if a malicious third party wants to decrypt this encrypted message, 72 00:05:11,260 --> 00:05:14,280 they are going to face an uphill battle because 73 00:05:14,280 --> 00:05:18,240 the process of encrypting using the secret key will turn the message and can, 74 00:05:18,240 --> 00:05:19,590 in turn, encrypt the message. 75 00:05:19,590 --> 00:05:21,830 Without possessing the secret key, 76 00:05:21,830 --> 00:05:26,760 it is going to be next to impossible to decrypt the encrypted message. 77 00:05:26,760 --> 00:05:30,200 Well, that is stretching get a little bit far. 78 00:05:30,200 --> 00:05:35,490 It would be inordinately difficult to decrypt the encrypted message. 79 00:05:35,490 --> 00:05:39,210 If you use brute force techniques, then eventually, 80 00:05:39,210 --> 00:05:43,245 you will end up decrypting the encrypted message. 81 00:05:43,245 --> 00:05:48,880 But it is going to take so long and require so much of computation power. 82 00:05:48,880 --> 00:05:53,175 It will be not worth the effort for 83 00:05:53,175 --> 00:05:58,580 the third party malicious user to try and decode the encrypted message. 84 00:05:58,580 --> 00:06:01,770 So you are essentially making it really difficult for somebody to 85 00:06:01,770 --> 00:06:05,355 decrypt the message if they don't possess the secret key. 86 00:06:05,355 --> 00:06:09,480 Now, since the secret key is known only to the sender and the receiver, 87 00:06:09,480 --> 00:06:12,390 the two end parties, the sender and the receiver, 88 00:06:12,390 --> 00:06:16,335 can communicate with the assurance 89 00:06:16,335 --> 00:06:18,780 that in encrypted message from 90 00:06:18,780 --> 00:06:22,240 the sender side can only be decrypted by the receiver side. 91 00:06:22,240 --> 00:06:25,485 So this is how symmetric key cryptography works. 92 00:06:25,485 --> 00:06:30,330 The fact that you have the same secret key being shared between 93 00:06:30,330 --> 00:06:32,400 the sender and the receiver means that 94 00:06:32,400 --> 00:06:35,420 the inclusion of decryption process used the same secret key, 95 00:06:35,420 --> 00:06:38,911 hence, symmetric key cryptography. 96 00:06:38,911 --> 00:06:41,395 Of course, with the symmetric key cryptography, 97 00:06:41,395 --> 00:06:44,440 one of the issues is that both the sender and 98 00:06:44,440 --> 00:06:48,805 the receiver needs to have access to the same secret key. 99 00:06:48,805 --> 00:06:53,940 Now, if the sender and receiver are communicating over an insecure channel, 100 00:06:53,940 --> 00:06:58,230 it is going to be difficult for both sides to come to an understanding 101 00:06:58,230 --> 00:07:03,510 about the same secret key without disclosing it to others. 102 00:07:03,510 --> 00:07:09,315 So this is where another algorithm called public-key cryptography is very useful. 103 00:07:09,315 --> 00:07:12,195 How does public-key cryptography work? 104 00:07:12,195 --> 00:07:14,610 Now, in public-key cryptography, 105 00:07:14,610 --> 00:07:17,595 the idea is that you have two different keys. 106 00:07:17,595 --> 00:07:21,085 You have a public key and a private key. 107 00:07:21,085 --> 00:07:26,520 Now, the public key can be widely distributed to anyone that you want. 108 00:07:26,520 --> 00:07:29,335 So when somebody wants to send a message to you, 109 00:07:29,335 --> 00:07:34,350 they are going to use your public key to encrypt the message. 110 00:07:34,350 --> 00:07:39,795 So if a sender here wants to send the message to the receiver, 111 00:07:39,795 --> 00:07:44,385 then the sender will use the public key off the receiver to 112 00:07:44,385 --> 00:07:50,240 encrypt the message on the sender side using the encryption algorithm. 113 00:07:50,240 --> 00:07:53,100 Now, once the encrypted message is sent across 114 00:07:53,100 --> 00:07:56,640 over the insecure channel to the receiver side, 115 00:07:56,640 --> 00:07:59,625 the receiver will then use the private key 116 00:07:59,625 --> 00:08:03,210 that only the receiver knows in order to decrypt. 117 00:08:03,210 --> 00:08:06,645 Now, for public-key cryptography to work as we saw, 118 00:08:06,645 --> 00:08:10,760 the public key can be widely distributed without any concern. 119 00:08:10,760 --> 00:08:14,150 But since the private key is only known to the receiver side, 120 00:08:14,150 --> 00:08:19,325 only the receiver will be able to decrypt the message, and, 121 00:08:19,325 --> 00:08:23,070 again, a third-party intruder that captures 122 00:08:23,070 --> 00:08:28,410 this encrypted message will find it inordinately difficult to decrypt the message. 123 00:08:28,410 --> 00:08:29,670 Now, of course in public-key cryptography, 124 00:08:29,670 --> 00:08:33,385 the public and the private key are two different keys. 125 00:08:33,385 --> 00:08:36,900 Now, then your obvious next question would be why 126 00:08:36,900 --> 00:08:40,686 not simply use public-key cryptography for encryption. 127 00:08:40,686 --> 00:08:44,445 The problem is that using public-key cryptography 128 00:08:44,445 --> 00:08:48,383 for encryption and decryption is an expensive process, 129 00:08:48,383 --> 00:08:54,890 and so that is why we don't use public-key cryptography for their entire communication. 130 00:08:54,890 --> 00:09:00,600 Instead, the public-key cryptography is going to be used 131 00:09:00,600 --> 00:09:04,290 primarily for the sender and the receiver to agree 132 00:09:04,290 --> 00:09:08,270 upon the common secret key that the two are going to use. 133 00:09:08,270 --> 00:09:12,210 We will later on see how the public-key cryptography 134 00:09:12,210 --> 00:09:16,380 can be used to establish the common secret key 135 00:09:16,380 --> 00:09:19,845 between the sender and the receiver and then subsequently 136 00:09:19,845 --> 00:09:24,686 use symmetric key cryptography for further communication. 137 00:09:24,686 --> 00:09:29,790 One protocol that uses this approach is the Secure Sockets 138 00:09:29,790 --> 00:09:35,088 Layer and also the Transport Layer security protocols, 139 00:09:35,088 --> 00:09:37,365 SSL and TLS in short. 140 00:09:37,365 --> 00:09:40,395 So many times when you read documentation, 141 00:09:40,395 --> 00:09:44,020 you might hear about SSL and TLS. 142 00:09:44,020 --> 00:09:48,660 These cryptography protocols enable secure communication between 143 00:09:48,660 --> 00:09:55,110 the sender and the receiver over an insecure network like the Internet. 144 00:09:55,110 --> 00:10:03,150 The sender and the receiver will communicate over this Internet using encrypted messages, 145 00:10:03,150 --> 00:10:06,410 which only the sender and the receiver can decrypt. 146 00:10:06,410 --> 00:10:09,266 And this approach, either the SSL or TLS, 147 00:10:09,266 --> 00:10:16,220 uses a combination of public-key cryptography together with symmetric key cryptography. 148 00:10:16,220 --> 00:10:18,905 Their exact process of doing this, 149 00:10:18,905 --> 00:10:21,290 I will explain in the next slide. 150 00:10:21,290 --> 00:10:25,050 In addition, using SSL or TLS, 151 00:10:25,050 --> 00:10:27,415 we are trying to maintain two different things. 152 00:10:27,415 --> 00:10:29,940 We are, first, trying to maintain the privacy of 153 00:10:29,940 --> 00:10:32,880 the communication between the sender and the receiver so that 154 00:10:32,880 --> 00:10:39,165 no malicious third party can extract the message from the encrypted message. 155 00:10:39,165 --> 00:10:42,150 Second, we are also trying to maintain integrity, 156 00:10:42,150 --> 00:10:44,550 meaning that when the sender sends a message, 157 00:10:44,550 --> 00:10:50,025 the receiver will be able to be assured that the message has not being tampered with. 158 00:10:50,025 --> 00:10:57,145 So both security and maintaining integrity is very important in this case. 159 00:10:57,145 --> 00:11:01,110 So both privacy and integrity has to be maintained by 160 00:11:01,110 --> 00:11:04,200 this secure communication protocol that we build 161 00:11:04,200 --> 00:11:08,235 for exchange between the sender and the receiver. 162 00:11:08,235 --> 00:11:13,865 Let's briefly talk about how SSL or TLS actually work. 163 00:11:13,865 --> 00:11:22,585 This is done through a handshaking process which I have illustrated in this diagram here. 164 00:11:22,585 --> 00:11:26,020 When a client wants to communicate with the server, 165 00:11:26,020 --> 00:11:28,920 the client sends a message to the server, 166 00:11:28,920 --> 00:11:34,405 specifying that the client wants to communicate with the server securely. 167 00:11:34,405 --> 00:11:40,068 At this point, the server will send back the certificate to the client, 168 00:11:40,068 --> 00:11:42,105 which contains a public key, 169 00:11:42,105 --> 00:11:43,800 which has been certified by 170 00:11:43,800 --> 00:11:48,410 the certification authority as belonging to that particular server. 171 00:11:48,410 --> 00:11:51,210 So that way, when the client receives 172 00:11:51,210 --> 00:11:56,325 this public key plus the certification by the certification authority, 173 00:11:56,325 --> 00:11:59,960 the client will be able to verify the server's credentials. 174 00:11:59,960 --> 00:12:03,510 So, the client needs to establish that it is really talking to the server, 175 00:12:03,510 --> 00:12:07,345 that it is intending to communicate with. 176 00:12:07,345 --> 00:12:09,040 So at this point, 177 00:12:09,040 --> 00:12:11,788 when the client verifies the server's credentials, 178 00:12:11,788 --> 00:12:17,110 the client now has access to the public key of the server. 179 00:12:17,110 --> 00:12:20,850 Once the client gets hold of the public key of the server, 180 00:12:20,850 --> 00:12:25,005 then the client will generate what is called as the pre-master secret. 181 00:12:25,005 --> 00:12:28,560 This pre-master secret is something that both the client and 182 00:12:28,560 --> 00:12:33,045 server will use to generate what is called as a session key. 183 00:12:33,045 --> 00:12:36,870 So, the client generates a pre-master secret, 184 00:12:36,870 --> 00:12:41,880 the client then encrypts that secret using the server's public key, 185 00:12:41,880 --> 00:12:44,880 and then sends the secret across to the server. 186 00:12:44,880 --> 00:12:48,735 Now, remember that once the secret is encrypted using the public key, 187 00:12:48,735 --> 00:12:51,690 nobody other than the server will be able to 188 00:12:51,690 --> 00:12:55,110 extract the information from the encrypted message. 189 00:12:55,110 --> 00:12:58,440 So, when the server receives this encrypted message, 190 00:12:58,440 --> 00:13:03,300 the server extracts the pre-master secret from this message. 191 00:13:03,300 --> 00:13:08,863 Now, both the client and the server possess the same pre-master secret. 192 00:13:08,863 --> 00:13:12,720 At this point, both the client and the server will use 193 00:13:12,720 --> 00:13:18,150 the same set of steps starting with the pre-master's secret, 194 00:13:18,150 --> 00:13:20,902 and with the same set of values, 195 00:13:20,902 --> 00:13:24,230 that will generate a key called as the session key. 196 00:13:24,230 --> 00:13:28,157 Now, when the session key is generated both on the clients side and the server side, 197 00:13:28,157 --> 00:13:30,630 it will be exactly the same session key, 198 00:13:30,630 --> 00:13:36,565 because both will follow exactly the same process for generating the session key. 199 00:13:36,565 --> 00:13:37,950 So, at this point, 200 00:13:37,950 --> 00:13:39,540 both the client and the server, 201 00:13:39,540 --> 00:13:44,670 now possess a secret key which is the same on both the sites. 202 00:13:44,670 --> 00:13:48,570 So, all subsequent communication between the server and the client, 203 00:13:48,570 --> 00:13:52,599 can then proceed using symmetric encryption. 204 00:13:52,599 --> 00:13:55,035 So, when the client needs to communicate with the server, 205 00:13:55,035 --> 00:13:59,640 the client will encrypt the data using the secret session key, 206 00:13:59,640 --> 00:14:01,340 and then send over their data. 207 00:14:01,340 --> 00:14:05,100 Similarly, when the server needs to communicate with the client, 208 00:14:05,100 --> 00:14:07,440 the server will obviously use 209 00:14:07,440 --> 00:14:12,365 the same session key to encrypt the data and then send it over to the client. 210 00:14:12,365 --> 00:14:15,215 Now, since the client possesses the same session key, 211 00:14:15,215 --> 00:14:21,255 the client will be able to decrypt the message and extract the unencrypted message. 212 00:14:21,255 --> 00:14:23,453 By using this procedure, 213 00:14:23,453 --> 00:14:30,099 the client and the server has ensured that the communication between them is private. 214 00:14:30,099 --> 00:14:33,930 Also, we manage to ensure that no malicious third party can 215 00:14:33,930 --> 00:14:38,310 intercept the message and cause any changes to the message. 216 00:14:38,310 --> 00:14:41,125 So, integrity of the message is also maintained, 217 00:14:41,125 --> 00:14:43,260 and the privacy of the communication between 218 00:14:43,260 --> 00:14:46,108 the client and the server is also maintained. 219 00:14:46,108 --> 00:14:50,970 So, this whole discussion that I have presented to you over the last few slides, 220 00:14:50,970 --> 00:14:52,635 is in a nutshell, 221 00:14:52,635 --> 00:14:58,210 how secure communication between the client and the server can be ensured 222 00:14:58,210 --> 00:15:05,454 using the symmetric key cryptography and public key cryptography. 223 00:15:05,454 --> 00:15:10,080 Now, obviously, there is a lot more to this than what I've explained here, 224 00:15:10,080 --> 00:15:14,490 but this understanding of how cryptography works is 225 00:15:14,490 --> 00:15:19,540 sufficient enough for you to understand how the whole process works. 226 00:15:19,540 --> 00:15:22,860 Now, if you are interested in learning more about this, 227 00:15:22,860 --> 00:15:28,515 one good source for learning about Cryptography Protocols is a very good book 228 00:15:28,515 --> 00:15:34,800 by Jim Crozon Keith Ross called Computer Networks. 229 00:15:34,800 --> 00:15:38,910 This book has a very easy to understand chapter 230 00:15:38,910 --> 00:15:44,995 about cryptography and security as applied to network communication. 231 00:15:44,995 --> 00:15:48,985 Now that we have established the process 232 00:15:48,985 --> 00:15:54,440 for being able to communicate securely between a client and server, 233 00:15:54,440 --> 00:16:00,640 let's look at how the internet itself leverages this, 234 00:16:00,640 --> 00:16:05,320 for communication between a client and the server using HTTP. 235 00:16:05,320 --> 00:16:09,950 Now, this is where the HTTPS protocol comes into the picture. 236 00:16:09,950 --> 00:16:13,915 As you already understand about the internet, 237 00:16:13,915 --> 00:16:17,905 the internet is a layered architecture, 238 00:16:17,905 --> 00:16:22,165 where the IP and the TCP form the network, 239 00:16:22,165 --> 00:16:27,490 and the transport layer which runs on top of the underlying network. 240 00:16:27,490 --> 00:16:29,755 Now, on top of the transport layer, 241 00:16:29,755 --> 00:16:35,800 you have the secure socket layer or the transport layer security lining as 242 00:16:35,800 --> 00:16:39,265 a thin layer on top of TCP which 243 00:16:39,265 --> 00:16:43,095 ensures secure communication between the client and the server. 244 00:16:43,095 --> 00:16:45,492 And on top of it HTTP can run. 245 00:16:45,492 --> 00:16:52,830 So, HTTP essentially involves HTTP plus the use of encryption, 246 00:16:52,830 --> 00:16:56,073 decryption supported through SSL and TLS. 247 00:16:56,073 --> 00:17:00,150 Obviously, even for HTTPS protocol, 248 00:17:00,150 --> 00:17:01,530 there is a lot more detail. 249 00:17:01,530 --> 00:17:05,745 But from the perspective of the implementation of the server side, 250 00:17:05,745 --> 00:17:12,075 what we have understood here is sufficient enough for us to understand how to 251 00:17:12,075 --> 00:17:19,120 configure a server to use secure communication between the client and the server. 252 00:17:19,120 --> 00:17:23,070 Now, of course the first question that will come to your mind is, 253 00:17:23,070 --> 00:17:25,800 that the server needs a public key and a private key. 254 00:17:25,800 --> 00:17:27,360 For a public key cryptography, 255 00:17:27,360 --> 00:17:29,330 how does the server generate this? 256 00:17:29,330 --> 00:17:32,265 If you are running a real production server in 257 00:17:32,265 --> 00:17:36,792 your environment and providing service for users to access your server, 258 00:17:36,792 --> 00:17:40,525 then obviously you need to go through the certification process. 259 00:17:40,525 --> 00:17:45,100 This is where you will approach a certification authority, for example, 260 00:17:45,100 --> 00:17:48,915 corporations like VeriSign and Thawte Corporation 261 00:17:48,915 --> 00:17:53,630 which are Public Certification Authorities. 262 00:17:53,630 --> 00:17:55,987 There are a few more around the world. 263 00:17:55,987 --> 00:17:58,160 So, you will approach them, 264 00:17:58,160 --> 00:18:03,960 and these Certification Authorities will then authenticate your credentials, 265 00:18:03,960 --> 00:18:07,220 they will ensure that you are who you claim to be, 266 00:18:07,220 --> 00:18:09,285 and then they will verify your credentials, 267 00:18:09,285 --> 00:18:10,680 and then at that point, 268 00:18:10,680 --> 00:18:18,725 they will issue you a public key and a private key for use on your server site. 269 00:18:18,725 --> 00:18:21,705 So once they issue the public key and the private key, 270 00:18:21,705 --> 00:18:27,010 the public key will be certified by the Certification Authority, 271 00:18:27,010 --> 00:18:30,540 and then the public key will also carry, 272 00:18:30,540 --> 00:18:32,626 in addition, the certificate. 273 00:18:32,626 --> 00:18:38,165 So, this is the certificate that you will send to the client's site. 274 00:18:38,165 --> 00:18:43,935 Since clients can establish 275 00:18:43,935 --> 00:18:48,446 the authenticity of these Certification Authorities, 276 00:18:48,446 --> 00:18:52,950 if you look at any browser you would notice that most browsers will have 277 00:18:52,950 --> 00:18:58,115 the certificates for all these established Certification Authorities 278 00:18:58,115 --> 00:18:59,715 already built into them. 279 00:18:59,715 --> 00:19:03,685 So they will be able to establish your credentials, 280 00:19:03,685 --> 00:19:07,605 or rather, they will be able to establish that the private key belongs to you, 281 00:19:07,605 --> 00:19:12,540 by obtaining your certificate and then checking or verifying 282 00:19:12,540 --> 00:19:16,620 your certificate knowing that it has been signed by one 283 00:19:16,620 --> 00:19:20,955 of these established Certification Authorities. 284 00:19:20,955 --> 00:19:26,370 Upon this process, client will be able to establish your authenticity. 285 00:19:26,370 --> 00:19:27,870 Now, in this course, 286 00:19:27,870 --> 00:19:31,125 we just want to understand how each HTTPS works, 287 00:19:31,125 --> 00:19:34,050 and also want to have a simple way of setting 288 00:19:34,050 --> 00:19:38,460 up the server with a public key and the private key. 289 00:19:38,460 --> 00:19:43,791 Since we are doing this as an exercise to understanding HTTPS, 290 00:19:43,791 --> 00:19:48,690 we can use a tool called open SSL that is already available on 291 00:19:48,690 --> 00:19:55,375 our computers to generate what is called the self-signed certificate. 292 00:19:55,375 --> 00:19:59,780 Self-signed keys are not acceptable in the outside work. 293 00:19:59,780 --> 00:20:03,705 But since we know that we are using it only for our testing purposes, 294 00:20:03,705 --> 00:20:06,300 we can use self-signed certificates, 295 00:20:06,300 --> 00:20:08,685 simply for understanding the process 296 00:20:08,685 --> 00:20:12,910 of the secure communication between the client and server. 297 00:20:12,910 --> 00:20:15,405 So, how do we use open SSL? 298 00:20:15,405 --> 00:20:18,585 So far using open SSL you can generate Keys, 299 00:20:18,585 --> 00:20:22,680 using three commands that I show you here. 300 00:20:22,680 --> 00:20:26,475 You execute these three commands in that sequence, 301 00:20:26,475 --> 00:20:30,020 as specified here and that will help you to generate 302 00:20:30,020 --> 00:20:34,990 a private key and a certificate that you can make available from 303 00:20:34,990 --> 00:20:38,910 the your HTTPS server for clients to download and 304 00:20:38,910 --> 00:20:44,555 thereby obtain your public key for secure communication. 305 00:20:44,555 --> 00:20:48,510 So this is the operation we are going to do in our exercise that follows 306 00:20:48,510 --> 00:20:54,510 this lecture to establish and issue DPS service.So the three steps that we do is, 307 00:20:54,510 --> 00:20:59,740 first, we will generate the private key by using the first command. 308 00:20:59,740 --> 00:21:07,980 Then after that we will generate a cert.csr which will then be used 309 00:21:07,980 --> 00:21:12,090 for us to generate a certificate that 310 00:21:12,090 --> 00:21:16,720 can be distributed to the client side by the third command shown there. 311 00:21:16,720 --> 00:21:22,545 So these steps will enable you to generate a private key and 312 00:21:22,545 --> 00:21:30,590 also a corresponding certificate that can be issued to the client. 313 00:21:30,590 --> 00:21:34,094 Again to emphasize, if you are running a production server, 314 00:21:34,094 --> 00:21:38,610 then you need to obtain a public key, private key pair, 315 00:21:38,610 --> 00:21:44,205 from one of the Certification Authorities like VeriSign and Thawte corporation. 316 00:21:44,205 --> 00:21:50,400 How does node itself work in helping us setting up the HTTPS? 317 00:21:50,400 --> 00:21:54,900 Now this is where I am briefly reviewing the code that we will 318 00:21:54,900 --> 00:22:00,357 use in the exercise that follows in order to set up our servers. 319 00:22:00,357 --> 00:22:07,910 Node itself has the HTTPS as a core module within node. 320 00:22:07,910 --> 00:22:11,815 So we will set up HTTPS by requiring this core module. 321 00:22:11,815 --> 00:22:15,410 We will also use the file system core module because 322 00:22:15,410 --> 00:22:20,760 the private key and the certificate that we generate will be stored on our server side, 323 00:22:20,760 --> 00:22:23,250 and they will be required by 324 00:22:23,250 --> 00:22:28,170 your express application in order to set up your secure server. 325 00:22:28,170 --> 00:22:30,810 So here we will use the file system with 326 00:22:30,810 --> 00:22:36,135 the readFileSync method to read in the private key 327 00:22:36,135 --> 00:22:40,440 and the certificate from the files that we 328 00:22:40,440 --> 00:22:45,380 generate using the steps that we have seen in the previous slot. 329 00:22:45,380 --> 00:22:48,780 So once these two values are ready, 330 00:22:48,780 --> 00:22:54,930 then the options for your HTTPS server is set up and then you can configure 331 00:22:54,930 --> 00:23:02,225 your secure server to provide HTTPS based communication from the server site. 332 00:23:02,225 --> 00:23:07,680 Now that you have a quick understanding of how your HTTPS works, 333 00:23:07,680 --> 00:23:12,120 and how it leverages the use of both public key cryptography 334 00:23:12,120 --> 00:23:14,970 and symmetric key cryptography for 335 00:23:14,970 --> 00:23:18,545 ensuring secure communication between the client and the server. 336 00:23:18,545 --> 00:23:21,885 Let's move onto the exercise to actually configure 337 00:23:21,885 --> 00:23:29,230 our express server that we have been building so far to use HTTPS protocol.