5. Hypertext Transfer Protocol (HTTP) Part 5
Now we’re going to modify our lab topology and this time we’re not going to use our F five big IP device because we want to communicate directly to the web servers. As we have here. We have the two network, we have the external where our client PC is connected. We also have the internal where our servers are directly connected. As we know, we have the Fyb IP device that is sitting in between and is both connected to the external and internal network. Now we want our client, Windows client to be connected to the internal network. Why? Because we’re going to bypass the F five big IP device and we’re going to use the same network adapter.
But this time we’re going to change the IP address to 172 dot 16 dot one dot 30 still using slash 16 and this training servers are using 172 dot 16, dot zero dot zero slash network. So our Windows client PC and the training servers will still be in the same network. And we’re going to test later Http traffic from our Windows PC to the servers and dissect Http messages, Http requests and Http response. I’m here in our Windows client PC and we’re going to test the Http connection to one of the web servers and dissect the Http messages. First, let’s change the IP address to a network of 170 216 00:16. So I just said that we cannot reach one of the servers.
I’m going to change the IP address now properties and I’m going to change this to 172, 116, 130. This is correct. I’ll click OK. And close. Let me try to ping it and it’s successful. I’m now going to open a web browser and I’m going to point it to 170 216 21 the first web server. It is successful. Now we take a look at the Http messages and this time we’re going to use the native tool, the Developer tools available in our Google Chrome. I’m going to click the dotted three icons here and I’m going to select Developer Tools under More Tools. And as you can see, the network tab is already selected. But we don’t have any entries.
That’s fine, all we need to do is click the refresh button and now you see we have entries not only for the web page, the index PHP or the index HTML. We also have other files like the image files. Now I’m going to click first the web page, the 170 216 21. And as you can see, first is the general. This is a mix of Http requests and Http response. Now for the Response and Request header I’m going to click Source or View Source so that we get the raw information. Okay, back to the general. We have the requested URL, we have the method which is Get and the status code which is from the Http response 200.
Okay, now under Response header you will see the server information including the web server Apache, version two. Two. We also have the application PHP, version five four. And it is using guns. It for the http compression. And obviously it’s using or responded with the status code 200. Okay, now for the Http request it’s using Get as a method. The connection. Keep alive the user agent. We are using Google Chrome and the accepted content. This is text HTML and the accepted encode loading, which is accepted compression is deflate and GC. But we know the response. It uses or it’s used Gun zip compression. Now, this is the content of the HTML page. If we click preview, we have the preview of the page.
6. Hypertext Transfer Protocol (HTTP) Part 6
Http is the Tcpbased application that listens to port ATM. When the client wants to connect via Http, it opens a web browser and points to the address or the name of the web server. How does it do it? Through the URL or Uniform Resource Load. Locator. Http is a connectionless application. When I say connectionless, this runs on the application side, not on the transport side, because we know that it’s already using TCP, which is a connection oriented layer for protocol. Now, as I mentioned, it is connectionless. How does it work again with the client sends Http requests to the server. The client disconnects. When the server response is ready, it will reestablish a connection back to the client and sends the response.
It is also a stateless application, meaning if the client completes the transactions http request and response, that’s it. They don’t know each other anymore. The only time they know each other is during the transaction Http request and response. Now, if they want to reconnect, they will do the same process over again. Since this is a client and a server based protocol on the client side, it must talk Http. And a program application that it uses can be a web browser. For GUI, we also have a Cli version which is curl for the server side it uses a web server and there are many kinds of web servers. Depends on your preference. There are many types of web servers.
We have Apache. We have NGX. And for Windows they have Iif. Now, the minimum configuration on a web server side is a web server that runs in an operating system. And you can access that web server over the network with the use of HTML files. Now, HTML files is already a default file when you example run an Apache Web Services. But when you access this webpage, it is a static web pages. If you want to run dynamic full fledged web servers, you may want to run a web development platform such as Lap, Linux, Apache. These are the operating system and web servers. We also have the database My, SQL and PHP is the programming language, the application and script.
This PHP allows us to create dynamic web pages and also connect to the database to pull or add information. We also have JavaScript. JavaScript is a script, but unlike PHP, this runs on the client side and this is just optional in running web applications. In our demonstration we dissect the Http messages. The first thing that you will see in a web browser is the general. Now the general is a mix of Http requests and response. You see the requested URL, the method, the status code, the remote address and the Rest header. But the Http header looks like this as you can see, we have the method.
They get the destination host, the connection, the cache control and we also have the user agent. In this case we are using Chrome. We also have the access, contents, language encoding and text. Now there are other Http header information. These are cookies and different types of accepts, content type, content length, user agent. We’ve already provided an example. In this case we’re using Chrome and we also have referred. Now for those who doesn’t know what referer means, it’s like this if you use Google to search a website and from the search result you click that website and Google takes you there. Your referral is Google. In short, it’s the page that takes you to that website. Http method is a command that tells the server what to do and this is initiated by the client.
We have many types. We have get with trips data from the server, post, submit data to the server, put update data already on the server and delete and obviously this delete data from the server. Http Response now from our demonstration we showed you how the Http response looks like. And the most important part of Http response is the status code. As you see, the status code is 200 and it also tells us the information of the web server. It is using an Apache web server running on a deviant Linux, the application PHP running on version five four again devian Linux and some of the information such as content encoding is running gcp compression and many more.
Http status codes. As I mentioned, this is one of the most important information inside our Http response. Now we have the 100 level, which is informational. This tells us that the server has received the request and is processing it. 200. This is some level of success. It also tells us that the web server successfully received, understood and accepted the Http request. And this is actually one of the most common status codes. 300 level or Redirect this tells us the web server needs to do further action or redirect the request of the client to another URL. 400 client Error the request doesn’t have what it needed from the client. Let’s say the field is missing or the URL is incorrect.
500 Server Error well, the best example for this is you think everything is okay as far as what you send, but you’re still getting an error because there is something wrong from the server side. And these are the most common Http status code. 200 okay? Or again, this is probably the most common amongst all status code because if you receive a correct response from the web server, the status code probably has a 200 okay, we have 201 OK created and this is more commonly used in a blog post. We have 301 moved to URL. So the best example of these is if you try to connect to a web server or to a website, but it redirects you to another website or to another URL.
The status quo for that is 301. 304 is almost the same with 301, but it’s the cached version. 400 bad requests. This is when we are not sending the correct input or parameters. For one, this is an authorized Http request for four not found. Also one of the most common Http status code. If the directory or file or the URL doesn’t exist, it will return with 404 not found editor and lastly, we have the 500 internal server error. It’s pretty much anything on the server side. If there are problems in the server side, you may probably get a 500 internal server error.
7. Transport Layer Security (TLS) / Secured Socket Layer (SSL) Part 1
Now, let’s talk about the difference of these three technologies https or the hypertext transfer protocol secure versus secure socket layer SSL and TLS transport layer security. Now, first let’s talk about Https. Https is a web app application. Same with Http. But we added security so that we can increase privacy in the Internet. Why is that? Our goal is to prevent known attacks such as man in the middle. Why? Because based on our previous discussion, our Http message consists of body header. All of these are encrypted. They are sent plain text over the network. Now, before, back in the 90s, only the banking or retail or online shops and websites with payment transaction only use Https.
But nowadays it’s pretty common. Almost any website is using this technology to provide privacy. It can be email, it can be social media, it can be just games or even commercial websites. Now, if you want to enable Https, you need to purchase certificate. What certificate can be SSL. Now. What is SSL? SSL is the technology that provides secure connectivity between two systems. In our example, these are client server. It’s not just an example. Even in the real world is a client server communicating securely? Okay? Now, SSL certificate is used also to encrypt the protocols payload tunneling it through Http. SSL certificate is the small data that digitally buys a cryptographic key to an organization detail. So, inside the certificate we have information.
And this information is the server or the organization’s information. And the certificate is like an online identification that is used to encrypt data between, again, the client and the server. SSL is not only used for Http. A lot of people is thinking that SSL is Https. No, SSL is just a technology to make our web application secure. Take note, SSL is an independent protocol. As a matter of fact, it can be used on other applications such as email messaging, voice over, IP and many more. Now, what is TLS or the transport layer security? This is very simple. TLS is the updated and more secured version of SSL. In short, SSL is obsolete. And what we’re using on the past few years is TLS.
8. Transport Layer Security (TLS) / Secured Socket Layer (SSL) Part 2
Let’s talk about Https and digital certificates. First, I’m going to create a pair of keys. So I’m going to use Red for the private key and I’m going to use Blue for the public key. Now, there is a rule, any message encrypted by the servers public key can only be decrypted by the server’s private key. So let me highlight this. Any message encrypted by servers public key and only be encrypted by servers private key. So meaning if the server send a request and it receive a reply, which is encrypted and it uses its public key for encryption, oh, sorry, it received a message and this message is used it’s public key for encryption. That means only its private key can be used for decryption.
Okay, so let’s have an example. Here we have a client and we have a server here and they are connected. It can be internet, it can be directly connected. It doesn’t matter. The first thing that you will do is the client will send a request. Let’s say this is Zurion. com. Now the Zurian. com is running Https. So it has also a private key and a public key. Again, red for private key and dark blue for the public key. Now the server will respond back and say, hey, I have a certificate and this certificate is signed by the CA or the certificate authority. We’re going to talk about more on the certificate authority in a bit. But also take note, there is a public key by the certificate authority and there is also a public key from the server.
Now as soon as the client received this certificate, it will verify if this certificate is valid. And so let’s say this is step number two. Now, step number 2. 1 is from the client web browser. It will know and verify, let’s say trust that the CA public key is valid. It’s saying, hey, based on my understanding, which is coming from the web browser, I know this certificate authority, this CA, and I trust it. Now I can further verify. Now, assuming everything is okay, this certificate is signed by known CA. It will reply back to the server. It say, okay, I confer, you are who you say you are. Now I’m going to create a secret message or a message with a secret key. Going to add here secret key. And I’m going to encrypt it. I’m going to secure this using your public here. So as you can see, this is public and this will be a secured message.
So as you can see, the client encrypted the message using the server’s public key. Why did the client knows the public key? Well, because it’s already attached here in the certificate. Now as soon as the server received this message, the SAP message that the client sent, it is highlighted that it encrypted this message using the server’s public key. Now for the server to know the secret key inside the message, it needs to decrypt it using its private key. Good. Now what happened is the server now knows the secret key and it will tell the client. Hey, Mr. Client. Since we’re the only pair in the entire Internet knows the secret key, we can now start communicating securely. And this is how our secured communication starts. This is what makes https the entire communication from client to server encrypted.
9. Transport Layer Security (TLS) / Secured Socket Layer (SSL) Part 3
Let’s talk about CA or the certificate authority. The CA is the third party Mtt who may sure and verify who they really are. Who’s who? Well, most of the times these are the web servers, the website information, and the organizations. So what I have here is a client and before client server, let’s just define CA. Here in I or Whiteboard is the third party entity Verifies server identity. There you go. So what I have here again is a server. Sorry, it’s a client. And we have no, sorry, we have a server here and we have to see a server there. Now, first thing is the server needs to generate a CSR certificate signing request CSR. And along with the CSR, it will also generate a pair of keys.
And like what we did from the previous Whiteboard discussion, we have the private and we have the public keys. Okay? Now the next thing the server will do is it will send the CSR to the CA requesting the certificate authority. Hey, Mr. CA, can you please sign this CSR? Now the CA, assuming everything is configured properly, the CA will sign it. And not only that, it will tell the server this is now a valid certificate and this is signed by me. I will also add my public key. So this public key is from the CA. We’re also going to add a private key. There you go. Now, like the discussion we had on the previous White boarding session, anyone can verify a public key.
Anyone can verify the public key. And in this case, it can verify if it was signed by the CA. Okay, in his perspective, I’m sending you this certificate. I signed it with my public key, and anyone can verify that it was signed by myself. Now, as soon as the server received the certificate, it can now verify by its web browser. From the web browser list, you will see that the trusted you will see there the trusted CA. So we have many of those. We have verisign, which is now acquired by human tech. We have GoDaddy, we have Google, we have Microsoft Cyber Trust and many more. Okay, now I’m going to add here browser now verify.
All right, if you recall from the previous discussion, when the server sent a certificate to the client and this is signed by a CA, the client Verifies it to the web browser, and the client says, hey, I trust and I know the CA. Let me further check. And then the client sent back a message, a secret message to the server using its public key for encryption. So the point is, when the server sent a certificate, we are using the certificate created by CA and it’s with its public key. Now this public key is used to verify that this is signed by the CA. And if the CA is trusted by the client browser, in short, it can now reliably determine that the information in the certificate provided by the server is 100% legit, 100% true, trusted and confined by the certificate authority.
