[MUSIC] Hello and welcome back. In this lesson, we're going to do
a review of the HTTP protocol. First, we will review with the way the
communication happens between the client and the server. Next, we will delve into more
details about what the HTTP requests look like and what the HTTP response
from the server looks like. And then we're going to talk about the
stateless property of basic or core HTTP. Then, we will talk about the side
effect of HTTP without encryption. Last, I'm going to talk about HSTS, which
stands for HTTP strict transport security. So after this lesson, you will be able to
describe and discuss the HTTP protocol, including communication requests and
responses, sides effects, and HSTS. Let's get started. Now, as you may recall,
when the client and the browser wants to communicate with
a website, or the server for the website, first it creates a TCP connection with the
server, and then it sends over HTTP data. So again, in general, HTTP protocol
is done over the TCP/IP protocol. So then the server responds
back with a HTTP response, and it's again,
using a TCP/IP communication channel. So once again, the HTTP protocol or communication is done
over a TCP/IP channel. So the way the HTTP request looks
like from a web browser client, it looks like the following. First, it mentions
the type of HTTP method, otherwise known as HTTP verb,
that it's going to use. So for example, it might use the get,
post, put, or delete method. And then it's going to mention the path
of the resource that it wants to act upon using the HTTP verb. And then it's going to mention what HTTP protocol version it would like
to communicate with the server. And then, following that, the HTTP request
will also include one or more headers. And these headers gives the server
more information about how to handle the client's request. And then optionally, there is also,
after the headers, the HTTP body. And this is extra data, for example, when
the client performs an HTTP post method. So note that HTTP/1.1 and
earlier versions are human-readable. However, with HTTP/2 and above,
it's not human-readable, so you can't use Wireshark to sniff out
HTTP/2.0 packets and read them directly. So I should say, Wireshark out of the box,
but you can have it set up such that it puts the HTTP/2 frames together and
shows it to you as a human-readable form. So again, in order to read any
communication between a client and a server using HTTP/2 an above, you need to have a little bit
more ability to recreate or put together the frames, such that you
can then eventually read it yourself. So even though this is
the case at HTTP/2 and above are not human-readable by itself,
the HTTP messages in HTTP/2 and above follow the same format as
HTTP/1.1 and earlier versions. With the HTTP protocol response,
so the server responds back using the version that the client
wanted to communicate with, and then it also adds in the status code
of the HTTP request processing. So how did the server process? How well did the server
process the request? Was it okay or
was the resource not found, etc.? So this is a status code for when
the server performed the HTTP process. And then after that it adds
the status message, so this is the message that is
matching the status code. After that the server also adds
in the HTTP response headers. And as you can see, for example, in this diagram there's
the server response header. So it tells a client what
kind of server it is, and the type of data that it's sending back,
and the length of that. The basic or
core HTTP protocol is stateless. So that means that the relationship
between the current and any previous requests from a specific
client are unrelated and independent. But then how is it that we can add state? The answer is to extend the HTTP
header capabilities to use cookies. So cookies is an HTTP header and
cookies allow for a session. Now, without communication encryption,
HTTP request and HTTP responses between a client and a server can be read
over the network by an eavesdropper. So this also means that an attacker
can hijack a client's session. As you can see in this diagram,
the attacker uses a packet sniffer to eavesdrop the communication
between the client and the server. The attacker then is able
to obtain the session ID that is sent from
the client to the server. Last, the attacker creates a connection
between itself and the server, and uses the same session
ID as a victim client, effectively hijacking the victim's
victim client session. And there's an interesting article from
the New York Times that can give you a little bit more context, in terms of a real world example
of how this can be done. So now with all of that being said, I'm
going to give a very quick introduction to HSTS, and HSTS stands for
HTTP strict transport security. So some sites can be initially
communicated with using only HTTP. So this is HTTP that is unencrypted,
instead of HTTPS. So HTTPS being HTTP that is encrypted. So now this presents an opportunity for an attacker to hijack the connection
between the client and the server, and then redirect the client to a site
that the attacker controls. But with HTTP strict transport security, the first time the client communicates
with a server, the server tells the client to automatically communicate
with it using HTTPS. So the browser then remembers to always
use HTTPS for any future connections. So in summary,
we talked about the protocol form of the HTTP communication
between a client and a server. And we mentioned about how
basic HTTP is stateless. And we also mentioned how in
order to add a session state, you would need to extend the HTTP header
to include this thing called cookies. And then we chatted about the side
effect of HTTP without encryption, so not using HTTPS. And then last, I gave an introduction to
HSTS, or HTTP strict transport security. That's it for now. Thanks for listening.