[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.
