HTTPS and Secure Communication

Loading...

En provenance du cours de The Hong Kong University of Science and Technology

Server-side Development with NodeJS, Express and MongoDB

368 notes

The Hong Kong University of Science and Technology

Server-side Development with NodeJS, Express and MongoDB

368 notes

Cours 4 sur 4 dans Specialization Full-Stack Web Development with React

This course deals with all things server-side. We base the entire course around the NodeJS platform. We start with a brief overview of the Web protocols: HTTP and HTTPS. We examine NodeJS and NodeJS modules: Express for building web servers. On the database side, we review basic CRUD operations, NoSQL databases, in particular MongoDB and Mongoose for accessing MongoDB from NodeJS. We examine the REST concepts and building a RESTful API. We touch upon authentication and security. Finally we review backend as a service (BaaS) approaches, including mobile BaaS, both open-source and commercial BaaS services. At the end of this course, you will be able to: - Demonstrate an understanding of server-side concepts, CRUD and REST - Build and configure a backend server using NodeJS framework - Build a RESTful API for the front-end to access backend services

À partir de la leçon

Backend as a Service (BaaS)

In this module we learn about Mongoose population, a way of cross-referencing documents and populating the documents from other documents. We then review secure communication using HTTPS. We look at Backend as a Service (BaaS) and take a brief look at Loopback.

HTTPS and Secure Communication23:31

Exercise (Video): HTTPS and Secure Communication24:36

Rencontrer les enseignants

Jogesh K. Muppala
Associate Professor
Department of Computer Science and Engineering

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.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play