A random hacker is not likely to intercept your HTTP message. They would need to be on the way between your browser and the target site.

A more realistic case is an enterprise network or an ISP.

Yeah. My ISP is doing exactly that. HTML pages over HTTP are injected with some javascript code. Sadly, it's the only ISP available in the entire country.

A solution is to go through a VPN, they will see a steady stream of encrypted data.

It's just pushing the problem. Now you need to trust the VPN.

Right, but when it comes to VPN, as oppose to ISP, you have hundreds of choices, so you can pick one that you can trust.

Cheap $5/mo VPS + WireGuard/OpenVPN (Google search for any number of tutorials).

Of course, now you need to trust your VPS provider but I'd trust someone Digital Ocean before I'd trust a cheap VPN provider.

At some point you must trust something or someone

Some minor points. I’ve not seen HTTPS written as HTTPs before. It stands for Hypertext Transfer Protocol Secure, and is not the plural of HTTP (one HTTP, two HTTPs, three HTTPs, etc.).

The proper name for certificates is TLS certificates, even though many people still use the word SSL for it (which refers to a deprecated protocol that’s not used anymore). It’s fine to use SSL, but omitting TLS isn’t a good idea.

Ack. I will rectify HTTPS to HTTPs. While writing I had the same doubt.

It's TLS certificate now. In the next article, I'll be adding a small note on the history of SSL to TLS.

Hi there. The image named 'Asymmetric Key encryption' seems wrong. You may want to fix it.

Eg. Contradicts with wikipedia article: https://en.wikipedia.org/wiki/Public-key_cryptography

Thanks Buddy. I have corrected it.

Just to clarify, encryption happens with the public key and decryption with the private.

This probably doesn't help because in practice that's not how it's done at all.

For a modern HTTPS connection what happens is that two participants use a Key Agreement process which results in them both knowing a random secret that nobody else knows. This secret is ephemeral which means once the connection closes they'll both forget what it was.

They both use this shared secret to choose the same several symmetric keys and use those keys to encrypt (and decrypt) the actual HTTP traffic.

For HTTPS in particular the main asymmetric cryptography is used for signatures, proof that this is really news.ycombinator.com for example. Your web browser doesn't encrypt messages to news.ycombinator.com but after Key Agreement happens the server will send a message proving it participated in this agreement you've just done, signed using its private key, and your browser uses the public key to check that this is a genuine signature.

No, it doesn’t work that way for HTTPS. Public Key Cryptography is a relatively expensive operation. So the public/private keys are used to create and exchange a temporary symmetric encryption key. That symmetric encryption key is used to encrypt and decrypt the HTTPS requests and responses later by the client and the server.

What you describe is used that way when you want to send, say encrypted emails to someone else when you have their public key.

Thanks

If trying to speak to the layperson I think lines like this can be misleading:

"When you are sending a message over HTTP, anyone on the network can see what message is being sent. Further, anyone can intercept the message, modify it and send it to the server."

To me a network is a graph of clients and servers and peers. Ie. Nodes on your graph that your message doesn't visit. The above sentence suggests that those peer nodes can somehow grab your message on its way and modify it, even if your message isn't routing through that node.

Or maybe that is actually the case?

Peer nodes on a local network can see all messages, even those not addressed to them, since the common model is broadcasting packets and selectively processing them on each client and ignoring packets intended for others (in promiscuous mode, one can capture packets in the local network from all devices, but those packets may or may not contain encrypted data). I’m not sure about modifying the read packets and sending them across though — that would require a more sophisticated attack on the gateway or router and the sending device, in my understanding, which means it’s no longer a peer but an interceptor sitting in between.

The key being “local network”, so if you are connected to a wifi access point you can see everyone using that access point. You can’t “see” packets beyond the router that connects your local network to the next one. The local network is a shared domain.

Wouldn’t a packet be destined from router to only one client having the internal IP address of that client? In this case other peers on the same network won’t know if any communication happened between the router and that peer. Same for when a node sends packets to the gateway.

No, that’s not how local networks work. Whether wired Ethernet or wireless with WiFi/Bluetooth, every packet sent from one device or from the router/gateway is seen by every other device in the same network (the same router or gateway boundary). By default, devices choose to act only on the packets addressed to them, and ignore the others. This is why using HTTP (not HTTPS) on a public WiFi network is a risk because everyone else around, if they want to, can sniff and read all the packets and know what exactly you’re up to.

It is amazing to me that the air India website doesn't use https. What is going on there?

It looks like the site is just static content. The login/register form goes off to a different domain which is TLS secured.

But the attacker could alter the static site to use HTTP on the login/register form.

Why should the layman care about how HTTPS works ?

The article is not for the layman but for beginners who are interested in knowing the internals of HTTPS. The explanation is in layman terms. You can find plenty of literature on https online but it's not necessary you would grasp everything in a blink of an eye.

Let's be honest here, the article is to demonstrate that you have some grasp of how https works.

In particular the statement "They confirm the identity of the certificate owner & provide proof that a certificate is valid. " is dangerously misleading for the "layman" as the basic HTTPS certificate issuance does not involve any sort of owner identity confirmation, just that whoever requested the certificate had control of the DNS record for that domain at the time of the request.

Thanks for the feedback, I'll find ways to simplify this & explain it in lucid terms so that readers don't find it difficult to comprehend.