Hello everyone. In this lesson,
we're going to talk about issue number four using
HTTP for sensitive client-server exchanges,
and we're going to talk about that in
more detail to make it a little bit more real for you.
Then we're going to talk about mitigating this issue.
Last, I'll briefly introduce Let's Encrypt,
which makes it easier for your web server to use HTTPS.
At the end of this lesson,
you'll be able to use HTTPS for
sensitive client-server exchanges. Let's dive in.
So this issue of using HTTP only for
sensitive client-server exchange can
be looked at in the following way.
Let's say that we have a user's browser and they
want to access a web application
on the other end of this diagram here.
Now, these gray nodes,
the gray circles here,
represent network switches and they connect
the user to the network gateway
on the left-hand side here.
But they also have a malicious node or malicious machine,
which are on the same network as the victim user.
What can happen is that for example,
this malicious node can use a tool called
ettercap to perform ARP spoofing in
order to trick the network gateway
into thinking that it is the victim node.
So that's the node that's running the user's browser.
ARP spoofing isn't something that I'm
going to get into much detail here,
but needless to say,
it is a way for the computers in
a network to be able to identify which
node belongs or which
network interface belongs to which computer.
So that allows different computers
to talk to each other on this network.
So continuing on, we have
this malicious node and it's tricked
the network gateway into thinking that it is
the victim computer using ARP spoofing.
So what the malicious node goes on to do is to
use something like wireshark to perform
packet sniffing on the network traffic,
and they would place it in something
called promiscuous mode to
basically have a look at all of
the network traffic coming,
going without actually dealing with it,
or processing these network packets itself.
It just basically passes through
the malicious node, and in this way,
the malicious node can examine
the network packets that should be going to
the victim computer and examines
these network packets and then
passes them on to the actual victim computer.
So now the malicious node knows exactly what is going on
between the web application server
and the user's browser.
So mitigation for this is to use
HTTPS between the client and the server.
What the server ends up having to do is to
obtain a browser trusted HTTPS certificate,
and what happens is when
the user's browser connects to
the server for the first time,
the server will give the browser
it's HTTPS certificate before
making any sort of
sensitive communication between itself and the browser.
This HTTPS certificate basically allows
the browser to start an encrypted channel with a server.
So now I'm going to introduce Let's Encrypt.
Let's Encrypt allows for
you as the owner of the server that runs
the web application to use HTTPS in an automated fashion.
So what it does is at a high level,
it performs domain validation first.
So basically, it checks
whether the server that you're using is
a server that controls
a particular domain for your web application.
Once Let's Encrypt has verified that that is the case,
then that particular server is allowed to request,
renew, and or revoke
HTTPS certificates for the particular domain.
Here's a link to a little bit more detail
of how Let's Encrypt works.
But I highly recommend that you use Let's Encrypt to
create HTTPS certificates for your domains.
In summary, we talked about this issue of using
HTTP only for sensitive client-server communication,
and then, I discussed how you can mitigate this by using
encryption for your HTTP traffic, so using HTTPS.
Then I briefly introduce
the system called Let's Encrypt to make it
easier for you to use HTTPS for your web applications.
That's it for now. Thanks for listening.