Working of HTTP and HTTPS | “Security” explained
Behind the scenes of how security works in HTTPS.
HTTP stands for Hypertext Transfer Protocol and it’s a communication protocol that is used for data communication on World Wide Web. So to access any webserver, you need to put a URL on the browser. So by following HTTP protocol, client and server agree on certain request and response structure like HTTP version, request headers, URL, body(optional).
For e.g http://www.xyz.com
Browser understands that it needs to use the http protocol and it will try to connect with the IP of www.xyz.com (the machine where the web server is running). Specifically, it will try connecting with PORT 80 of that machine. Because by default, HTTP web servers run on port 80 of machine.
🌎 HTTP requests and responses are sent in a plaintext, and it means that anyone 🕵️♂️ can eavesdrop/read them. So any information you send can be intercepted by someone else on the network 😲.
So, HTTPS comes to rescue. HTTPS just adds a “Secure” layer.
🔒HTTPS brings a secured version of HTTP where every message sent between client and server is encrypted. And both Client and server have the capability of encrypting and decrypting as communication happens from both ends(request/response). But how does this work ? Who gives them this capability.
HTTPS web servers run by default on port 443. So as soon as you write
https://www.xyz.com. Browser understands it needs to connect to 443 port of the machine where server is running.
Let’s dive deep…on the security part now.
In simple terms, Client and server both need to exchange some information before real communication starts. So that they understand what type of encryption and decryption they both would use.
First Client and server do the 3 way TCP handshake and then a TLS handshake which works as below :
This TCP handshake happens so that both client and server look at sequence numbering on the other sides. This would be needed to order the segments coming on each side as TCP is a transport layer protocol which needs to detect any missing or out of order segments.
Now comes the TLS handshake… (Happens in case of HTTPS)
Let’s see how TLS1.2 does this. TLS 1.3 is just faster and more secure but TLS1.2 is best way to understand this. (TLS is a protocol (upgrade to SSL) which is a cryptographic protocol that protects data integrity and privacy for internet communications).
TLS : Transport Layer Security
So,
🤝 Client and Server do a TLS handshake. During a TLS handshake, the two communicating sides exchange messages to acknowledge each other, verify each other, establish the cryptographic algorithms they will use. Even this exchange happens securely.
🤝 See the attached images to see each stage of handshake. At the end of the all stages, both client server have a same session key and they would use them to encrypt or decrypt any messages and thus hold a secure communication.
TLS Handshake :
Stage 1
Client sends all TLS versions that it can support to the server. Server has to pick one and send it back to client so that client knows what it chose.
Client sends :
- All TLS versions supported by it
- List of Cipher suites supported by it : Cipher suites is a set of cryptographic algorithms that client supports.
- A Client random string (We will see it in later stages how it works)
Server choses and sends back to Client :
- Chosen TLS Version
- Chosen Cipher Suite
- SSL Certificate : This certificate authorises the identity of the server. There is usually a certificate authority which issues these certificates to Server. When client receives the SSL certificate, it will be able to tell that server is the actual entity who it claims to be. SSL certificate contains a public key (We will see how it would be used later).
- Server Random String (We will see it in later stages how it works)
Stage 2
Client verifies the certificate that server sent to it, with the CA (Certificate Authority). This is to verify the identity of the server.
Now Client will do a smart thing, Client will send a encrypted “Premaster secret” to server. It will be encrypted with the public key that server sent with the SSL certificate. Now if server is legit, it would have the private key to decrypt and read the premaster secret.
Stage 3
Remember in Stage 1, Client received a “Server random string” from Server and Server received a “Client random string” from Client.
Also both have the premaster secret that was shared in Stage 2.
Client generates a “Master Secret” using
1. Server random string and 2. Premaster secret.
Using the master secret, it generates a “Session Key”
Server generates a “Master Secret” using
1. Client random string and 2. Premaster secret.
Using the master secret, it generates a “Session Key”
Beauty of the cryptographic algorithm is that both will arrive at the same result of the session key. So now, both have a same session key which they will use to encrypt and decrypt the messages for the main communication that will happen after the handshake.
This is called Symmetric encryption through which they will communicate further. On both side, there is a private key (Session key) which they generated and that can be used to encrypt and decrypt the messages.
So this is how TLS 1.2 works. The further versions (TLS1.3) tries to optimise over this to make it more secure and fast.
Thanks for reading. Follow and subscribe for more.
You can also follow and connect over My LinkedIn : https://www.linkedin.com/in/sourav-singh-6b57b5101/
