How does HTTPS work

Someone peeks in the middle

As we have seen, HTTP is the agreement for trading requests and responses. But with plain HTTP, the content travels along the road as plain text.
A packet passes through the router at home and many routers beyond, and anyone along the way who looks in can read passwords and card numbers as they are. It is like mailing a postcard: everyone it passes can read it. The cookie number we worried about in the last lesson is exposed the same way.

Tap the 'middle person' on the road to peek at a message sent over plain HTTP. The secret can be read as is.

We have confirmed that a peek reveals everything, because the content lies open on the road.
So how can we stop it? We cannot block the road or remove everyone in the middle; the internet was built as a road that passes through many hands. So we change the idea: make the content unreadable even when it is seen. We lock it.

Locking it

The first step is locking. Before sending, the content is scrambled by a set rule so that no one can make it out. This is called encryption, and turning the scrambled content back into the original is called decryption.
Locked content is a jumble of characters, so the middle person sees no meaning in it. Only the receiver, who holds the key, turns it back into the original. It is like mailing the postcard inside a locked box: you can see the box, but not what is inside.

Tap the message to lock it (encryption). Once locked, the characters are scrambled and the middle person cannot read them.

Locked, the message cannot be read by the middle person. But one hard part remains: to unlock it, the receiver needs the key.
You cannot have shared a key in advance with a site you are visiting for the first time, so the key would have to travel along the road too. Then the middle person would get the key as well. That is like locking the box and mailing the key with it. How can this be solved?

Hand out the lock, keep the key

There is a clever solution: make the lock that closes and the key that opens separately. Anyone can take the lock and snap it shut; this is called the public key. Whatever it locks opens only with the matching private key.
So it is fine to scatter the lock along the road, because it can only lock, never open. Lock something with the lock the receiver handed out, and it opens only with the private key the receiver alone holds.

The receiver hands out a public key (the lock). Lock with it and send, and only that person's private key opens it. The middle person's key will not.

Now the key problem is solved. The lock can be handed out freely, because the private key that opens it stays in the receiver's hands alone.
In real HTTPS, this method is used just once at the start to agree safely on a secret key the two sides share; after that, that key is used to lock and unlock quickly. But one thing still remains. Is the other side that handed you the lock really the site you were looking for? What if a fake held out its own lock?

Checking that it is real

The last piece is checking identity. Along with the lock, the site presents an ID called a certificate. A certificate is a proof in which a trusted authority vouches that "this lock really belongs to this site."
The browser already holds a list of trusted authorities, so it checks the certificate to see whether it is genuine. A fake site cannot get such a guarantee, so when the certificate does not match, a warning pops up and stops us.

Two sites present certificates. Tap each to check whether it is real. The real one passes; the fake one raises a warning.

Now everything is in place. The content is locked so it cannot be read, only the receiver holds the private key that opens it, and a certificate checks that the other side is real. With these three together, we are safe even with someone in the middle: they cannot read anything, and a fake is exposed.
The lock icon in the address bar means exactly that this agreement is switched on. But the lock only means the conversation is locked; it is not a guarantee that the site itself is trustworthy.

Summary

In short: plain HTTP leaves the content in the open, so it can all be seen in the middle. HTTPS locks the content (encryption).
The lock, a public key, is handed to anyone, and what it locks opens only with the matching private key. A certificate also checks that the other side is real. That is why card numbers, and login cookies too, can be sent without worry.

Tap the key points in order to review. (plain text can be peeked at → lock it → hand out the lock, keep the private key → check it is real with a certificate)

Now you know how data on the network is protected: lock it, guard the key, and check who is on the other side.
So far we have looked, one by one, at packets, addresses, route finding, name lookup, reliable delivery, the conversations of the web, and how they are protected. The next lesson brings these pieces together and follows, from start to finish, everything that happens from the moment you type an address until the page appears on screen.