HTTPS stands for HyperText Transfer Protocol Secure; before we go further, an essential alphabet in that acronym is the P which stands for Protocol. If you’re a frequent user of the internet, you might have observed the address bar on your browser at times put an HTTPS in front of the website URL you’re currently visiting, and you might wonder what it means.
What Is A Network Protocol?
As long as you have transferred data over any network, you have encountered a network protocol; they are sets of laid-down protocols or rules that decide how different devices within the same network communicate with one another.
Network protocols are why different kinds of computers on a network can relate with one another on a large scale; without them, these networks would be chaotic.
For instance, your smartphone regularly connects and communicates on various networks and needs protocols to organize these connections. Network protocols determine things such as how and what can be sent and received on a network; for example, it’s the reason you cannot send images in an SMS.
Almost every day, your smartphone makes use of at least five network protocols– HTTP, TCP/IP, FTP, POP3/SMTP, and SMS.
The thousands of different network protocols perform three primary actions; Communication, Network Management, and Security. Of the many network protocols available, one of the most common is the HTTP network protocol, a close sibling of HTTPS whose operations are similar.
The HTTP Network Protocol
HTTP and HTTPS are very similar in the protocols that guide their operations; however, the “S” in HTTPS is a crucial difference. To explain HTTPS without getting distracted by the “S”, let’s first look at an explanation of HTTP.
As you’d probably have discerned, HTTP stands for HyperText Transfer Protocol; it is the protocol responsible for communication between web servers and clients– it is the protocol of the web!
You use HTTP every time you visit a webpage, submit a form online or click a button that sends any request online. HyperText documents allow the user to reference and access other text on the network using hyperlinks; most hyperlinks are underlined blue.
HTTP Request and Response
Each time you act on an HTTP network, you go through the Request-Response cycle– the client sends a request to the server, and the server sends back a response. HTTP is stateless, meaning that every request and response is independent of the other.
To establish some form of continuity in the user’s browsing experience, browsers use things such as Cookies, Local Storage, or Sessions to save user information for use in future requests.
HTTP Request Methods
HTTP requests have various methods or types of request which tells the server what you want to do on the particular request; the most common HTTP requests methods are as follows:
- GET– The HTTP GET request method requests a particular resource from the server. It’s a straightforward request that cannot send any additional data. When you type a web address in your browser, the browser automatically performs a GET request.
- POST– The HTTP POST request method sends data to the server; the data sent with a POST request is usually a new set. A good example is a registration form for a new user on a website.
- PATCH– The HTTP PATCH request method partially modifies a resource that already exists on the server. An example is changing your username or password on a website.
- DELETE– The HTTP DELETE request does what it says– deletes a resource from the server.
- PUT– The HTTP PUT request method changes data that already exists on the server. However, unlike the PATCH method, it doesn’t modify a resource; instead, it finds the resource address and replaces it with the new data sent with the request.
HTTP Status Codes
HTTP status codes are 3-digit codes that are usually part of your server’s response to every request made. These codes are usually found in the header and not the response’s body and are an essential tool in troubleshooting errors. There are various types of HTTP status codes, and the first number in the code groups them; they can start from between the numbers 1-5.
Through status codes, your server can let you know one of five things:
- 1xx— Relax; your request is still in progress.
- 2xx— Everything went great!
- 3xx— The server is redirecting you to a new location.
- 4xx— You’ve made a mistake in your request.
- 5xx— Your request was successfully received; however, the server has issues giving you a response.
The “xx” denotes two other numbers from 0-99 added to the prefix to get the message across. The most popular status code many web users know and see often is the 404 error which denotes that the server cannot find your requested resource and there’s no record it existed. The status code you generally want to see when you visit a webpage is 200, and 201 is what you’d want after submitting a POST request.
Parts Of An HTTP Request/Response
The request and response generally consist of the header and the body. The header contains information about the request and response; there are three groups to this information:
- General— It contains information such as the Request URL, method, and status code.
- Response Headers— This lets you know the content type, length, the time the server sent the response, etc.
- Request Headers— Tell the server the request method, the language it accepts, and the browser that sent the request.
A body is not compulsory on requests and responses. An instance where an HTTP request would require a body is sending form data; in this case, the form data would make up the request body. A typical example of an HTTP response is a webpage consisting of HTML, CSS, and JavaScript files– this webpage is the body of a response.
What Is HTTPS?
With a basic understanding of HTTP in place, let’s bring back the “S”; HyperText Transfer Protocol Secure (HTTPS) is– as the name states– the secure version of HTTP.
A massive security flaw in HTTP is that when information is sent and received using the protocol, the data (usually in small packets) are written in plain text. This plain text can be accessed and intercepted by anyone with the right software connected to the same network– a bad idea for secure communication.
Data Encryption
As the internet became widespread, there was a need to communicate using HTTP while keeping all data transmitted away from prying eyes, and Data Encryption was the solution to this issue.
Wikipedia defines encryption as the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. Encrypting data over HTTP would mean that even if there were an interception, the attacker would not understand or decipher the encrypted text.
To make encrypted data readable, you also need that key to decrypt the data; a good illustration of an encryption key is in the system used by the ancient Roman general, Julius Caesar, known as the Caesar Cipher.
It works by substituting all alphabets in a text with another located a fixed position after; for example, the text THIS IS A BOY using a cipher key of 2 would replace each alphabet with another two places after. The encrypted form of THIS IS A BOY would become VJKU KU C DQA; without the key, you would think what I wrote there is rubbish.
SSL/TLS For Encryption
The more technical term for HTTPS is HTTP over TLS; because HTTPS uses Transport Layer Security (TLS)– formerly known as Secure Sockets Layer (SSL)– for encryption. To understand how and why we use TLS, remember that you need a key for data encryption and decryption.
If the server encrypts data, the client would need to present the key to decrypt that data; the issue then is if the client sends that key over the network, it can be intercepted, rendering the encryption useless. Let’s take a step-by-step look at how TLS fixes this issue:
Step 1
The server creates two keys– the Private Key and Public Key; if you use the public key to encrypt, only the private key can decrypt and vice versa. The public key can be shared with everyone hence its name, while the private key remains on the server.
Step 2
When a client wants to connect with a protected server, it will generate a symmetric key. Then the client makes a GET request to the server requesting a connection.
Step 3
The server responds by sending a public key that the client will use to encrypt the symmetric key before sending it to the server.
Step 4
The server then uses the private key to decrypt the symmetric key, and both server and client will have the same key.
The above process was how SSL worked; however, there was a loophole. Hackers could intercept the GET request, generate public and private keys, send their public key to the client, and use their private keys to decrypt their symmetric key. The client was a sitting duck that didn’t have a way to tell original keys from keys created by intermediaries.
Step 5
The solution to the problem was Certificates. Certificates are a means to signal the client that the public key they’re getting comes from the server to which they sent a request. Trusted third parties called Certificate Authorities (CA) are the ones who issue these certificates.
Step 6
Instead of the server sending the public key directly to the client, it sends the public key to the CA to generate a certificate for its public key. The CA returns with a signed certificate containing basic information such as the server name and the name of the CA.
Step 7
The CA also generates a private and public key. The CA uses its private key to sign its public key and adds it to the certificate. This privately signed public key is attached to the certificate and is called a Signature.
Step 8
Also, the certificate is linked to an intermediary certificate whose duty is to prove that the certificate comes from the specified CA. And from there, a chain of certificates proving each other’s authenticity goes all the way to a Root Certificate.
Step 9
Using current versions of TLS, when the client sends a communication request, the server first sends the certificate(linked to the Root Certificate) as a response.
Step 10
The client verifies the certificate using its public key down to the Root Certificate, which is self-signed. We can trust the Root Certificate because it is a part of the Operating System; if the Root Certificate isn’t installed on the OS or is expired, your browser would bring up a warning that alerts you about this.
Step 11
The website loads up without errors if the browser can successfully verify every certificate down the chain.
How To Use HTTPS On A Website
According to W3Techs, 78.7% of all websites on the World Wide Web use HTTPS connections, proving that HTTP is gradually phasing out. A few years ago, it used to be very costly to get a signed digital certificate, restricting HTTPS connection usage to those who could afford it, such as big banks that performed transactions online.
However, a 2016 campaign led by the Electronic Frontier Foundation with the support of web browser developers led to the protocol becoming more prevalent.
Today, web hosting providers have the affordable option of giving multiple users a shared certificate, known as a multi-domain SSL certificate. Also, users that can afford it can choose to go for the more expensive option of an individual certificate registered strictly to them. Contact your hosting provider for an individual or shared plan to use HTTPS on your website.
The padlock sign usually on the address bar of web browsers lets users know that a website is secure, so getting an HTTPS connection is no longer a luxury for anyone who wants to host a website.