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.