In the previous module, we have seen about user authentication in a lot of detail. We had seen how the user sends their credentials to their server from the client-side in either the header of their request message or the body of the request message and then subsequently, when they are authenticated, then their client will include either the cookie or the token in the header of the request message going from the client to the server. I'm sure some of you were cringing about the fact that we were communicating over in an insecure channel, meaning that anybody sitting in the middle who can listen to their messages going between the client and the server would be easily able to capture the credentials and then impersonate the genuine client. Of course, at that point, their emphasis was more on arranging the client and server communication with authentication of the client on the server-side. But any time you need to use user authentication, first, in the form of, say, supplying the credentials to authenticate yourself and thereafter, authenticating yourself by including either the cookie or the token in the header of the request message, you should be doing this over a secure channel. You should never communicate over an insecure channel, which means that you should not be using HTTP and then including these credentials into either the header or the body of the request messages. Instead, you should be using a secure version of the HTTP protocol or the HTTPS. Let's briefly talk about HTTPS in this lecture. Along the way, I will give you a five-minute introduction to cryptography and security. Obviously, cryptography and security is a very big topic in its own right. I'm just going to introduce you to the bare essentials that you need to understand to learn how HTTPS actually works. With this background, let's proceed to understand about cryptography and then onto the HTTPS protocol and how you would configure a server to use the HTTPS protocol and then the client to contact the server using HTTPS protocol, thereby, communication between the client and the server can be done in a secure manner by encrypting the data being sent between the client and the server-side. When you venture into the field of cryptography and security, you'll often hear people talking about symmetric key cryptography. Now, what does cryptography involve? If you need to send a message over a channel to another user, then you would want to be able to encrypt the message in such a way that only the receiver will be able to decrypt the message and obtain the information that you are trying to send to the receiver. So both the sender and the receiver should understand on establish between the two of them how this encryption process and how the decryption is going to work. For this to work, any encryption and decryption works based on exchange of secret keys. So in symmetric key cryptography, both the sender and the receiver will share a secret key between the two sites, and this secret key is known only to the sender and to the receiver side. So when the sender needs to send the message, then the sender will encrypt this message using a cryptography algorithm, which uses the secret key as the other input to this algorithm. And once this message is passed through this cryptography algorithm, then an encrypted message will be generated. Now, this encrypted message will be sent to the channel across to the receiver side. If you have a third party malicious user sitting in between and listening and capturing this encrypted message, they would have a hard time decrypting this message because for decrypting an encrypted message, you still need the secret key. Now, on the receiver side, when the encrypted message is received, then the receiver will apply and a decryption algorithm, which also takes as the input, the same secret key that was used on the sender side to encrypt the message. So upon decryption, the original message will be retrieved and can be processed on the receiver side. Now, if a malicious third party wants to decrypt this encrypted message, they are going to face an uphill battle because the process of encrypting using the secret key will turn the message and can, in turn, encrypt the message. Without possessing the secret key, it is going to be next to impossible to decrypt the encrypted message. Well, that is stretching get a little bit far. It would be inordinately difficult to decrypt the encrypted message. If you use brute force techniques, then eventually, you will end up decrypting the encrypted message. But it is going to take so long and require so much of computation power. It will be not worth the effort for the third party malicious user to try and decode the encrypted message. So you are essentially making it really difficult for somebody to decrypt the message if they don't possess the secret key. Now, since the secret key is known only to the sender and the receiver, the two end parties, the sender and the receiver, can communicate with the assurance that in encrypted message from the sender side can only be decrypted by the receiver side. So this is how symmetric key cryptography works. The fact that you have the same secret key being shared between the sender and the receiver means that the inclusion of decryption process used the same secret key, hence, symmetric key cryptography. Of course, with the symmetric key cryptography, one of the issues is that both the sender and the receiver needs to have access to the same secret key. Now, if the sender and receiver are communicating over an insecure channel, it is going to be difficult for both sides to come to an understanding about the same secret key without disclosing it to others. So this is where another algorithm called public-key cryptography is very useful. How does public-key cryptography work? Now, in public-key cryptography, the idea is that you have two different keys. You have a public key and a private key. Now, the public key can be widely distributed to anyone that you want. So when somebody wants to send a message to you, they are going to use your public key to encrypt the message. So if a sender here wants to send the message to the receiver, then the sender will use the public key off the receiver to encrypt the message on the sender side using the encryption algorithm. Now, once the encrypted message is sent across over the insecure channel to the receiver side, the receiver will then use the private key that only the receiver knows in order to decrypt. Now, for public-key cryptography to work as we saw, the public key can be widely distributed without any concern. But since the private key is only known to the receiver side, only the receiver will be able to decrypt the message, and, again, a third-party intruder that captures this encrypted message will find it inordinately difficult to decrypt the message. Now, of course in public-key cryptography, the public and the private key are two different keys. Now, then your obvious next question would be why not simply use public-key cryptography for encryption. The problem is that using public-key cryptography for encryption and decryption is an expensive process, and so that is why we don't use public-key cryptography for their entire communication. Instead, the public-key cryptography is going to be used primarily for the sender and the receiver to agree upon the common secret key that the two are going to use. We will later on see how the public-key cryptography can be used to establish the common secret key between the sender and the receiver and then subsequently use symmetric key cryptography for further communication. One protocol that uses this approach is the Secure Sockets Layer and also the Transport Layer security protocols, SSL and TLS in short. So many times when you read documentation, you might hear about SSL and TLS. These cryptography protocols enable secure communication between the sender and the receiver over an insecure network like the Internet. The sender and the receiver will communicate over this Internet using encrypted messages, which only the sender and the receiver can decrypt. And this approach, either the SSL or TLS, uses a combination of public-key cryptography together with symmetric key cryptography. Their exact process of doing this, I will explain in the next slide. In addition, using SSL or TLS, we are trying to maintain two different things. We are, first, trying to maintain the privacy of the communication between the sender and the receiver so that no malicious third party can extract the message from the encrypted message. Second, we are also trying to maintain integrity, meaning that when the sender sends a message, the receiver will be able to be assured that the message has not being tampered with. So both security and maintaining integrity is very important in this case. So both privacy and integrity has to be maintained by this secure communication protocol that we build for exchange between the sender and the receiver. Let's briefly talk about how SSL or TLS actually work. This is done through a handshaking process which I have illustrated in this diagram here. When a client wants to communicate with the server, the client sends a message to the server, specifying that the client wants to communicate with the server securely. At this point, the server will send back the certificate to the client, which contains a public key, which has been certified by the certification authority as belonging to that particular server. So that way, when the client receives this public key plus the certification by the certification authority, the client will be able to verify the server's credentials. So, the client needs to establish that it is really talking to the server, that it is intending to communicate with. So at this point, when the client verifies the server's credentials, the client now has access to the public key of the server. Once the client gets hold of the public key of the server, then the client will generate what is called as the pre-master secret. This pre-master secret is something that both the client and server will use to generate what is called as a session key. So, the client generates a pre-master secret, the client then encrypts that secret using the server's public key, and then sends the secret across to the server. Now, remember that once the secret is encrypted using the public key, nobody other than the server will be able to extract the information from the encrypted message. So, when the server receives this encrypted message, the server extracts the pre-master secret from this message. Now, both the client and the server possess the same pre-master secret. At this point, both the client and the server will use the same set of steps starting with the pre-master's secret, and with the same set of values, that will generate a key called as the session key. Now, when the session key is generated both on the clients side and the server side, it will be exactly the same session key, because both will follow exactly the same process for generating the session key. So, at this point, both the client and the server, now possess a secret key which is the same on both the sites. So, all subsequent communication between the server and the client, can then proceed using symmetric encryption. So, when the client needs to communicate with the server, the client will encrypt the data using the secret session key, and then send over their data. Similarly, when the server needs to communicate with the client, the server will obviously use the same session key to encrypt the data and then send it over to the client. Now, since the client possesses the same session key, the client will be able to decrypt the message and extract the unencrypted message. By using this procedure, the client and the server has ensured that the communication between them is private. Also, we manage to ensure that no malicious third party can intercept the message and cause any changes to the message. So, integrity of the message is also maintained, and the privacy of the communication between the client and the server is also maintained. So, this whole discussion that I have presented to you over the last few slides, is in a nutshell, how secure communication between the client and the server can be ensured using the symmetric key cryptography and public key cryptography. Now, obviously, there is a lot more to this than what I've explained here, but this understanding of how cryptography works is sufficient enough for you to understand how the whole process works. Now, if you are interested in learning more about this, one good source for learning about Cryptography Protocols is a very good book by Jim Crozon Keith Ross called Computer Networks. This book has a very easy to understand chapter about cryptography and security as applied to network communication. Now that we have established the process for being able to communicate securely between a client and server, let's look at how the internet itself leverages this, for communication between a client and the server using HTTP. Now, this is where the HTTPS protocol comes into the picture. As you already understand about the internet, the internet is a layered architecture, where the IP and the TCP form the network, and the transport layer which runs on top of the underlying network. Now, on top of the transport layer, you have the secure socket layer or the transport layer security lining as a thin layer on top of TCP which ensures secure communication between the client and the server. And on top of it HTTP can run. So, HTTP essentially involves HTTP plus the use of encryption, decryption supported through SSL and TLS. Obviously, even for HTTPS protocol, there is a lot more detail. But from the perspective of the implementation of the server side, what we have understood here is sufficient enough for us to understand how to configure a server to use secure communication between the client and the server. Now, of course the first question that will come to your mind is, that the server needs a public key and a private key. For a public key cryptography, how does the server generate this? If you are running a real production server in your environment and providing service for users to access your server, then obviously you need to go through the certification process. This is where you will approach a certification authority, for example, corporations like VeriSign and Thawte Corporation which are Public Certification Authorities. There are a few more around the world. So, you will approach them, and these Certification Authorities will then authenticate your credentials, they will ensure that you are who you claim to be, and then they will verify your credentials, and then at that point, they will issue you a public key and a private key for use on your server site. So once they issue the public key and the private key, the public key will be certified by the Certification Authority, and then the public key will also carry, in addition, the certificate. So, this is the certificate that you will send to the client's site. Since clients can establish the authenticity of these Certification Authorities, if you look at any browser you would notice that most browsers will have the certificates for all these established Certification Authorities already built into them. So they will be able to establish your credentials, or rather, they will be able to establish that the private key belongs to you, by obtaining your certificate and then checking or verifying your certificate knowing that it has been signed by one of these established Certification Authorities. Upon this process, client will be able to establish your authenticity. Now, in this course, we just want to understand how each HTTPS works, and also want to have a simple way of setting up the server with a public key and the private key. Since we are doing this as an exercise to understanding HTTPS, we can use a tool called open SSL that is already available on our computers to generate what is called the self-signed certificate. Self-signed keys are not acceptable in the outside work. But since we know that we are using it only for our testing purposes, we can use self-signed certificates, simply for understanding the process of the secure communication between the client and server. So, how do we use open SSL? So far using open SSL you can generate Keys, using three commands that I show you here. You execute these three commands in that sequence, as specified here and that will help you to generate a private key and a certificate that you can make available from the your HTTPS server for clients to download and thereby obtain your public key for secure communication. So this is the operation we are going to do in our exercise that follows this lecture to establish and issue DPS service.So the three steps that we do is, first, we will generate the private key by using the first command. Then after that we will generate a cert.csr which will then be used for us to generate a certificate that can be distributed to the client side by the third command shown there. So these steps will enable you to generate a private key and also a corresponding certificate that can be issued to the client. Again to emphasize, if you are running a production server, then you need to obtain a public key, private key pair, from one of the Certification Authorities like VeriSign and Thawte corporation. How does node itself work in helping us setting up the HTTPS? Now this is where I am briefly reviewing the code that we will use in the exercise that follows in order to set up our servers. Node itself has the HTTPS as a core module within node. So we will set up HTTPS by requiring this core module. We will also use the file system core module because the private key and the certificate that we generate will be stored on our server side, and they will be required by your express application in order to set up your secure server. So here we will use the file system with the readFileSync method to read in the private key and the certificate from the files that we generate using the steps that we have seen in the previous slot. So once these two values are ready, then the options for your HTTPS server is set up and then you can configure your secure server to provide HTTPS based communication from the server site. Now that you have a quick understanding of how your HTTPS works, and how it leverages the use of both public key cryptography and symmetric key cryptography for ensuring secure communication between the client and the server. Let's move onto the exercise to actually configure our express server that we have been building so far to use HTTPS protocol.
