The HTTPS protocol explained! — The basics

To know about HTTPS, we should first know what HTTP is.

HTTP or the Hypertext Transfer Protocol is the protocol used for viewing webpages on the web and is the most widely used in the world today. All the information exchanged between the computer and the webserver is transferred over the public internet in plain/clear text, making it vulnerable to hacking. Sensitive data such as passwords and credit card information, name, address, etc. could easily be read by an attacker. You would be surprised by the number of ways or places where you are susceptible to have your data intercepted by bad guys in your day to day life. Most common of them being coffee shops, restaurants and public WiFi places where attackers have been known to meddle with the public Wi-Fi settings and just absorb the Internet traffic around them. They can then use sophisticated analysis to determine sensitive data that you may have considered safe.

There are several points of possible breaches before your request hits a web server from your browser and comes back to your browser, be it a wireless router, or Internet Service Provider(ISP), the fibre optics to internet exchanges. Some popular attacks being DNS spoofing and Man in the middle attacks. So using HTTP, your Internet sessions are public domain. You have no true privacy. This is why using a secure protocol is important when transferring personal and sensitive data.

What is HTTPS?

Here comes HTTPS. Which as most people rightly answer, is nothing but Secure HTTP. HTTP with a security feature. But it is not just a padlock that you see on your browser window! There is much more to it. The Internet world is rapidly moving towards it everywhere.

So how does HTTPS make it secure? Encryption. Instead of data flowing over the wire in plain text, it is now encrypted using encryption algorithms. An attacker can no longer comprehend your data and will only see scrambled data which they cannot make any sense of. The most common attack is the Man in the Middle Attack wherein an aggressive attacker could set up their own infrastructure to reroute your request! You think you are visiting a particular website www.abc.com but they could reroute it and you could actually be looking at a similar-looking website served by an altogether different un-secure server which could do anything with the data you share such as your location, credit card info, etc. Without using HTTPS you have no surety you are talking to the desired server. And the server cannot determine if it really is talking to you.

With HTTPS, there is a level of data integrity that protects you from an attacker intercepting your requests and the server’s responses. The certificates require that each end knows how to encrypt and decrypt the data and only they know how to do this. Just in case you think the bad guy can fake a certificate, they can’t. At least they can’t forge the certificate or try to decrypt the data with the public key. They won’t have access to the private key. The certificate contains the public key of the webserver. The attacker’s proxy does not have the matching private key. If the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the webserver. The attacker may try to forge the certificate and provide their own public key. This will destroy the signature of the certification authorities. The browser will warn you about the invalid certificate.

On a high level this is what happens during an HTTPS Handshake conversation:

1. Computer: Hey! Identify yourself!
2. Server: Here, take a look at my certificate.
3. Computer: Eh! That looks good to me. Let’s begin the exchange.
4. Server: Cool, I acknowledge. Let’s begin.

Or what the handshake would look like if it were a chat

In HTTPS the only two parties that can read the data are the server and your browser. The TLS (Transport Layer Security) or SSL(Secure Sockets Layer) layer acts as a shield, blocking unwanted eyes from watching your conversation.

Why HTTPS?

A lot of websites now use HTTPS by default, regardless of whether sensitive data is being exchanged.

Example: Go to any website which does not require you to share any personal information, for instance, some news site. Neither are you logged in nor are you providing any of your details or address. Have you wondered, why then is it using HTTPS when no sensitive data is being shared in this case?

There are several reasons. Google is flagging websites as non-secure if not using HTTPS protocol. It also penalizes the site in search rankings. You must have noticed, since the update from Chrome 55 to Chrome 56, they started displaying “Non-Secure” in the address bar beside the URL not using HTTPS for those websites collecting sensitive information, and gradually moved towards showing the warning to all HTTP sites irrespective of sensitive data involved, with the release of Chrome 68.

Firefox started to show “This connection is not secure. Logins entered here could be compromised” next to input login fields in a form.

Using HTTPS also ensures that you as a user are served only the content that the website wants to show you, and is not modified in any way by the time it reaches you.

Browsers are now holding the websites more accountable to serve content securely. That is why major websites have now started to use HTTPS regardless. Not just that, you will also be able to use more functionality in browsers. For instance, HTTPS is one of the three core requirements to be a PWA. Plus your site won’t be marked as “NOT SECURE” by Chrome and other browsers.

HTTPS is also required to unlock modern browser features like service workers and hardware APIs like WebUSB and Bluetooth access. Features like getting a user’s location, accessing their microphone, or storing data locally on their device, all require that your website supports HTTPS.

If you still think that using HTTPS for your website is hard, think again. The commonly perceived barriers to incorporating HTTPS no longer hold true. For example, the cost of buying a certificate. In the past SSL certificates were expensive. That has changed today as most certificates are free. If you pay for a certificate, you are buying a certificate with a more rigorous screening process and possibly insurance. One more being complexity. Previously, it used to be hard to set up certificates which again is a fairly simplified process today. Speed was another concern due to the performance penalty involved because of the encryption/decryption, which again is negligible today with the recent protocol versions. There used to be compatibility issues, for example, an HTTPS website showing advertisements requires them to be HTTPS too, which is not that big of a concern today, given the universality of the protocol. By now, I hope you must have realized and have been sold on how all these are trivial compared to the security features and advantages that HTTPS provides.

HTTPS has now become a norm, and no, you cannot turn a blind eye to it.

To know more in-depth about the underlying protocol handshake in itself, you can read in my next article I published here.